BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Modelo contratual tradicional: Maior risco de fracasso?

Modelo contratual tradicional: Maior risco de fracasso?

Favoritos

Introdução

Em 2007, o "Departamento para Comunidades e Governo Local do Reino Unido" (DCLG - Department for Communities and Local Government) assinou um contrato com a entidade "Sistemas de Ar e Defesa Europeus" (EADS - European Air and Defence Systems, também conhecido como Cassidian) para a entrega de um sistema de TI que pudesse sustentar o projeto FiReControl, o qual tinha como objetivo melhorar o serviço de resgates e o combate a incêndios, com a substituição de 46 salas de controle locais por uma rede de nove centros de controles regionais construídos para tal propósito. A expectativa era concluir o projeto em outubro de 2009 com custos originais estimados em £120 milhões. Dois anos depois, a expectativa de duração do projeto havia dobrado e os custos totais do projeto aumentaram em mais de 500%, para algo como £635 milhões. O contrato foi finalmente cancelado em 2010, após o desperdício de pelo menos £469 milhões resultantes da incapacidade do projeto de entregar.1

Essa é uma história decepcionante de um projeto de TI de grande porte fugindo do controle. Infelizmente não se trata de um incidente isolado, pois muitos projetos estão atrasados ou falham em entregar; um em cada seis supera em 200% os custos planejados e em quase 70% os prazos estimados.2 Parece que nenhuma organização está imune a esses riscos. Havia uma crença comum de que projetos de TI fora de controle estariam restritos ao setor público, mas estudos recentes demonstram que o setor privado não se sai nada melhor em comparação. As organizações do setor privado são simplesmente menos obrigadas a divulgar publicamente seus fracassos.

Então, por que os projetos de TI são tão arriscados e como podemos mitigar os riscos de insucesso?

Existe um abismo no mundo do desenvolvimento de software, de um lado os advogados buscam especificar as relações entre as partes contratantes com o máximo possível de certeza, do outro, tanto o negócio quando os praticantes do desenvolvimento de software estão operando em um ambiente cada vez mais complexo, dinâmico e interconectado.

As funções jurídicas e gerenciais, em geral, não adaptaram suas práticas ou valores para passar a levar em conta os desafios enfrentados tanto pelo negócio e quanto pelos praticantes do desenvolvimento de software. De fato, o modelo de contrato para o desenvolvimento de software (o "Modelo Contratual") e as práticas de gestão a esse relacionados quase não mudaram nos últimos 30 anos. Muito do pensamento no qual se baseia o Modelo Contratual remonta aos princípios desenvolvidos durante a Revolução Industrial por figuras como Henry Ford e Frederick Taylor.

Nossa visão é a de que o Modelo Contratual agrava os efeitos de uma gestão inadequada, e que tal gestão é em geral fundamentada em um pensamento falho que também é base para o Modelo Contratual. Descobrimos que mesmo se um projeto de TI utiliza pessoal e recursos internos, as organizações tendem a aplicar relações quase contratuais entre os departamentos internos para aquisição dos serviços de TI. Encontramos os mesmos princípios do Modelo Contratual em evidência nesse cenário também.

Não acreditamos em melhoras significativas no sucesso dos projetos de TI enquanto não mudarmos as bases de sustentação do Modelo Contratual e as respectivas práticas de gestão. Para os propósitos desse artigo, utilizaremos o termo "Projeto de TI" para representar qualquer iniciativa de mudança envolvendo o desenvolvimento de software.

Os fundamentos do Modelo Contratual

Acreditamos que qualquer contrato para o desenvolvimento de software fundamentado no Modelo Contratual possui três qualidades distintas, todas seriamente equivocadas. Utilizaremos os termos "fornecedor" e "cliente" para explicar as dinâmicas em um relacionamento externo. Contudo, conforme mencionado acima, muitos casos similares parecem se adequar mesmo que os projetos sejam desenvolvidos internamente.

As três características distintas de qualquer contrato para desenvolvimento de software fundamentado no Modelo Contratual são:

  • Requisitos com foco em entregáveis. O fornecedor deve fazer entregas que possuam todos os requisitos, conforme especificados pelo cliente no contrato. Utilizamos o termo "entregáveis" para nos referir a produto (ex. código, funcionalidades, funções, atributos), documentação e/ou serviços;
  • Mecanismos de controle de mudanças. O Modelo Contratual exige que qualquer mudança no escopo ou qualquer outro elemento do contrato deva ser regulado por um mecanismo de controle de mudanças. De forma geral, isso significa que para iniciar uma mudança, o cliente deve submeter uma solicitação de mudança para o fornecedor, descrevendo o conteúdo da modificação desejada. O fornecedor analisa o impacto da solicitação de mudança para o contrato como um todo, incluindo, em particular, os requisitos com foco em entregáveis, o preço e a data final para a entrega do projeto de TI. Com base nisso, o fornecedor propõe uma modificação no contrato. Após o acordo entre as parte para a modificação contratual, uma modificação formal é realizada ao contrato para incorporar a solicitação de mudança;
  • Desenvolvimento sequencial - O software é desenvolvido sequencialmente, em outras palavras, adota-se o modelo Cascata. O desenvolvimento é visto como um fluxo incessante em uma direção - como uma cascata - pelas fases de concepção, iniciação, análise, design, construção e testes. O fornecedor deve completar cada fase antes de iniciar a próxima, sendo a saída de cada fase a entrada para a próxima.

Vale ressaltar que não fazemos qualquer menção ao tipo de modelo de pagamento no Modelo Contratual. Se as três características do Modelo Contratual aparecerem em um contrato, o mesmo é considerado inadequado, independente dos mecanismos de mudança a serem adotados.3 Faz pouca ou nenhuma diferença se o preço é fixo, se é um contrato de custo alvo ou mesmo se é por tempo e materiais necessários, ainda que se apliquem bônus ou penalidades.

Para qualquer pessoal que não esteja diretamente envolvida com a implementação de um projeto de TI, o Modelo Contratual pode parecer sensato, pois cria a sensação de certeza e previsibilidade em relação ao projeto de TI, e ainda oferece um estrutura clara e compreensível para as várias atividade envolvidas no projeto. Aliás, ele reflete os modelos de contratação atualmente em uso.

Contudo, a combinação dos três elementos em uma relação contratual entre um cliente e um fornecedor se mostra como uma causa para os insucessos de muitos projetos de TI que poderiam de outra forma ter sido melhor sucedidos. Assim, argumentamos que aqueles projetos de TI que obtém sucesso o fazem a despeito do Modelo Contratual e das práticas gerencias relacionadas, não devido a elas.

Nesse artigo exploraremos algumas formas pelas quais o Modelo Contratual aumenta o risco de insucesso de qualquer projeto de TI.

Risco de insucesso potencializado

Qualquer projeto de TI está sujeito a riscos que podem ser categorizados em três tipos principais:

  • Risco de entrega. Esse é o risco de que o projeto de TI não seja entregue no prazo, no custo e com a qualidade necessária;
  • Risco de valor de negócio. Esse é o risco de que o projeto de TI não entregue o valor de negócio esperado;
  • Risco do modelo de negócio existente. Esse é o risco de que o projeto de TI prejudique a organização existente.

O Modelo Contratual só trata a primeira categoria de riscos e, pior, potencializa a exposição do cliente a todas as três categorias de risco.

Risco de entrega

O projeto FiReControl é um exemplo clássico do risco da entrega de um projeto de TI sair dos trilhos. O Escritório Nacional de Auditoria do Reino Unido observou que durante os primeiros dois anos do contrato, pouco progresso foi feito na direção de entregar o sistema de TI.4 Realmente, o DCLG não parece ter recebido nenhum software em funcionamento até o cancelamento do contrato. Não se sabe a razão disso, mas podemos supor.

Os princípios obsoletos do Modelo Contratual assumem que os requisitos podem ser previstos de antemão. Como resultado, tal modelo falha em adequadamente responder a condições em constante mudanças, o que força o cliente a aceitar custos desproporcionais ao retorno de um projeto de TI.

A falácia de prever os requisitos de antemão

A suposição de que os requisitos podem ser levantados de antemão é fundamentada em outras duas premissas. Primeiro, que os requisitos são plenamente entendidos tanto pelo cliente quando pelo fornecedor e, segundo, que o software possa ser concluído antes que qualquer mudança significativa ocorra. Em outras palavras, para funcionar no ponto ótimo, o Modelo de Contrato requer que ambas as partes possuam a informações perfeitas, o que é uma impossibilidade prática.

A própria dinâmica de um projeto de TI conduz a mudanças. É natural que conforme o cliente aprenda mais sobre a última tecnologia, suas vantagens e desvantagens em relação à atual, o cliente reveja seu pensamento sobre qual a melhor forma de tirar vantagem da tecnologia.

"... os requisitos do sistema não podem ser declarados completamente de antemão, nem mesmo por princípio, pois o usuário não sabe ainda - nem mesmo em princípio. Para afirmar o contrário é ignorar o fato de que o próprio processo de desenvolvimento muda a perspectiva do usuário do que é possível, traz novas ideias sobre o ambiente da aplicação e frequentemente muda o próprio ambiente." 5

Pela mesma razão, é natural que conforme o fornecedor aprenda mais sobre o processo de negócio do cliente, ganhe um maior entendimento dos problemas que o cliente está tentando resolver e as oportunidades que está tentando aproveitar.

Em qualquer evento, não é possível antecipar como interagirão muitos elementos diferentes de design de software antes que o software seja implementado e isso frequentemente leva a surpresas.

A premissa de que o software pode ser finalizado antes que mudanças significativas ocorram também é falsa, pois forças externas estão em jogo. A tecnologia evolui cada vez mais rapidamente, o mercado ou contexto no qual o conceito do software foi concebido continua a mudar. Assim, as oportunidades ou riscos a serem tratados pelo software também mudam. Por exemplo, a emergência de tecnologias disruptivas com o Facebook, o Twitter ou a tela touch do IPad podem ter um enorme impacto em qualquer plano existente para o desenvolvimento e distribuição de software. O ambiente regulatório também pode mudar.

Estudos recentes, liderados por Al Goerner, na Universidade de Missouri, Kansas City, demonstra que o valor inerente no escopo se esgota exponencialmente com o passar do tempo. Essa taxa de decaimento se parece muito com a meia-vida de um átomo radioativo instável. A "meia-vida" é a medida do tempo que leva para a substância perder metade de sua massa.

De acordo com estudos da Universidade de Missouri, a meia-vida do valor dos requisitos está decaindo rapidamente. Em 1980 era em torno de dez a doze anos, já em 2000 havia caído para algo em torno de dois a três, hoje está por volta dos seis meses.6

Em outra palavras, metade dos requisitos se tornará obsoleta ao final do sexto mês, metade do restante, ou seja, um quarto se tornará obsoleta após um ano e assim por diante. Assim, após 18 meses, de acordo com os estudos, apenas 1/8, ou 12.5%, dos requisitos ainda possuirão algum valor inerente.

Em seu desejo por certeza, o Modelo Contratual na verdade cria o risco de que quando a entrega finalmente aconteça, o que for entregue não atenda mais às necessidades do cliente.

O fracasso do Modelo Contratual para responder adequadamente a mudanças

Caso mudanças ocorram, o cliente desejará mudar os requisitos. Como uma parte integral do contrato, os requisitos não podem ser alteradas sem refletir uma mudança formal no contrato, conforme combinado pelas partes no acordo sobre o mecanismo de controle de mudanças. Em um contrato de preço fixo, as mudanças em geral são vistas como geradoras de trabalho adicional e o cliente deve pagar taxas adicionais. Não é incomum que fornecedores vejam o controle de mudanças como uma oportunidade para ampliar suas margens.

O estágio inicial do mecanismo de controle de mudanças é que o fornecedor analisa o impacto das mudanças solicitadas pelo cliente. Quanto maior e mais complexo for o projeto de TI, e quanto maior for a quantidade de trabalho envolvida para que o fornecedor leve a cabo o exercício. Algumas vezes, o impacto da solicitação de mudança é tão complexo que o fornecedor simplesmente não pode resolver como incorporar a solicitação no projeto de TI em andamento.

O processo de analisar o impacto de uma solicitação de mudança pode levar tanto tempo e ser tão extenso que tem um impacto desestabilizante no projeto de TI. A equipe está ciente que o trabalho atual pode se tornar redundante após a aprovação da solicitação de mudança. Quanto maior a mudança proposta, maior o intervalo gasto com análise e mais prejudicial pode se tornar seu efeito.7

Qualquer solicitação de mudança inevitavelmente causará atrasos no projeto de TI. É improvável que o cronograma original tenha estimado um buffer para que os recursos do fornecedor sejam desviados para essa atividade e para qualquer trabalho adicional a ser realizado. É por essa razão que ambos, cliente e fornecedor, consistentemente citam as mudanças aos requisitos como uma das maiores causas do fracasso dos projetos de TI.

Para tornar as coisas ainda piores, o Modelo Contratual exige o desenvolvimento sequencial. Somente após a fase de testes é que o cliente ganha visibilidade sobre o software. Até aquele ponto é muito difícil para qualquer um avaliar se um projeto de TI está nos trilhos. Os entregáveis de todas as fases anteriores estão documentados e são baseados em premissas. Apenas quando o software é construído de fato é que qualquer um pode avaliar com precisão se o projeto de TI está no caminho de conseguir atender a todos os requisitos. Contudo, há um longo intervalo, frequentemente na casa dos anos, entre a data na qual o cliente fornece os requisitos e a data em que recebe do fornecedor a primeira entrega de software em funcionamento. Quanto maior esse intervalo, maior será a chance de mudanças significativas ocorrerem durante esse tempo.

Risco de valor de negócio

O projeto FiReControl ressalta a importância de demonstrar desde o início como um projeto entregará o valor de negócio que se espera e como obterá o apoio de todos os envolvidos. O DCLG foi criticado pelo Escritório Nacional de Auditoria por não ter tornado suficientemente clara a demanda por um modelo padrão ditado centralmente para lidar com ligações de emergência e mobilização, operando a partir de centros de controle regionais construídos para esse propósito. Desde o começo, muitas autoridades locais para o combate a incêndios e resgates criticou a falta de claridade sobre como a abordagem regional iria aumentar a eficiência.8 A não ser que o software resultante entregasse valor de negócio tangível, não interessa quão sofisticado ou estado da arte seja, os usuários finais podem simplesmente decidir não utilizá-lo.

O risco de valor de negócio, atualmente negligenciado pelo Modelo Contratual, é muito mais sério. Existe, ao contrário, uma presunção que se o fornecedor entregar o software que atenda aos requisitos levantados, ele entregará, portanto, o valor de negócio para o cliente. Contudo, isso por sua vez assume que o cliente sabe o que precisa. O que descobrimos é que, apesar dos clientes serem muito bons a declarar o que eles queriam, muito mais frequentemente, os cliente não sabem de fato o que precisam. Como resultado, não é incomum para um cliente se desapontar com o software entregue, mesmo que o fornecedor demonstre que o software atende a todos os requisitos.

É uma acusação triste sobre o estado atual do desenvolvimento de software o de que um dos maiores riscos é que o fornecedor pode construir "o produto errado". Isso acontece sempre que o fornecedor executar perfeitamente os requisitos do cliente, mas o software entregue não adiciona nenhum valor real para o cliente. O software não adiciona valor porque não permite ao cliente resolver o problema que desejava tratar.

A razão pela qual os clientes têm tirado tão pouco valor de negócio do software entregue pelo fornecedor é que o Modelo Contratual não visa resolver os problemas do cliente e que gerariam valor. Ao invés, o Modelo Contratual é visa entregar os requisitos, ou seja, via os entregáveis de um projeto de TI que deveriam contribuir e facilitar o atingimento dos resultados desejados.

As pessoas compram um martelo para pregar um prego de forma que possam pendurar um quadro - eles sabem que podem atingir o resultado (pendurar o quadro) com a aquisição de um martelo. Infelizmente, no contexto do desenvolvimento de software não é tão direto para se fazer a ligação entre o entregável (o software) e o atigimento dos resultados pretendidos pelo cliente. Muitas pessoas simplesmente nem tentam. Isso cria um grande risco que o fornecedor irá apenas entregar o que o cliente pediu - um conjunto vago de requisitos - ao invés do que o cliente realmente precisava, que é atingir os resultados alvo.

O desenvolvimento de software envolve a transformação de ideia em entregáveis para atingir objetivos de negócio. O catalisador para projetos de TI é geralmente um business case. Isso se justifica no nível estratégico e financeiro da aquisição do software. O custo antecipado do software é justificado por várias premissas, tais como melhoras nos processos de negócio, aumento no market share, aumento de receita, redução nos custos de suporte e por aí vai. Após a aprovação interna do business case, os requisitos são levantados e assimilados de todos na organização cliente que tenham interesse no software resultante.

Assim, se um business case geralmente acontece antes da especificação dos requisitos, por que o software resultante não necessariamente entregará os resultados desejados?

Primeiramente, o business case não é testado. Em muitos deles há elementos que são fundamentados em suposições, não em fatos. Essas suposições não foram provadas como certas e é provável que muitas delas estão erradas. Idealmente, essas suposições deveriam ser testados antes que qualquer aporte significativo de recursos seja feito na construção de um sistema de software que entregue com base no business case. Mas isso raramente ocorre.

Em segundo lugar, o business case é produzido tipicamente a um nível muito alto e com o propósito de obter financiamento ou aprovação orçamentaria. Não é incomum que um business case seja muito ambicioso em termos do que o software deve atingir, pois oferece um argumento melhor para se investir na aquisição do software. É menos comum que um business case tenha um papel ativo nas mudanças de direção de um projeto de TI. É ainda menos comum que alguém revisite o business case à luz do progresso do projeto para medir o andamento do mesmo com referência ao business case.

As implicações não podem ser subestimadas. O departamente de defesa (DoD) é um dos compradores de software mais sofisticados no mundo: tem grande alavancagem na negociação de contratos por causa do tamanho dos gastos anuais. Mesmo assim, o DoD praticamente não obtém nenhum valor de negócio imediato de seus investimentos no desenvolvimento de software. É possível que outras organizações, menos experientes nas funções de contratação acabem recebendo ainda menos valor de negócio de seus gastos com TI?

A forma mais efetiva de qualquer organização reduzir seus gastos com TI é garantir que apenas software que entregue valor seja construído. Precisamos conscientemente conectar os níveis e esclarecer como o software resultante entregará os resultados de negócio.

O fracasso do modelo de negócio existente

O Modelo Contratual não trata a possibilidade do risco do fracasso do modelo de negócio. Simplesmente não há reconhecimento do fato de que quando o novo software seja lançado, isso possa impactar os processos de negócio existentes. Como resultado, o Modelo Contratual aumenta a exposição do cliente ao risco de fracasso do modelo de negócio existente que é indiscutivelmente a mais traiçoeira das três categorias de risco.

Talvez em 1980, quando o Modelo Contratual foi utilizado pela primeira vez, os sistemas de software eram razoavelmente específicos e limitados em termos de sua operação. Contudo, os sistemas atuais de software são utilizados por virtualmente todas as funções de negócio de uma organização - por exemplo, o diretor financeiro, o departamento de contabilidade, o diretor de marketing, as equipes de marketing e vendas podem todos precisar utilizar o mesmo sistema de software. Esse sistema de software pode interligar-se com outros sistemas de software de outras organizações - tais como os clientes ou os fornecedores da organização.

À luz dos muitos processos de negócio que podem ser impactadas pelo novo sistema de software, é essencial que a transição para esse sistema seja gerenciado de uma forma que possa limitar o risco de fracasso do modelo de negócio existente a um mínimo. Contudo, o Modelo Contratual geralmente exige que todos os requisitos sejam entregues em um único log. Quanto mais o projeto de TI, maior o lote deverá ser.

Para muitas organizações, é simplesmente infactível tentar assimilar um sistema de software nessa escala e complexidade em seus processo de negócio existentes tudo de uma vez. O risco de qualquer desses processos de negócio colapsar sobre a enormidade da mudança é grande. Seria muito melhor se a transição para o sistema novo for gerenciado em lançamentos menores, com ênfase na qualidade da experiência de usuário durante a transição.

Conclusão

Muita pesquisa e muitos estudos foram feitos sobre projetos de TI para buscar entender por que existem tantos fracassos e por que o tamanho desses insucessos é tão grande. Até o momento, o Modelo Contratual tem sido amplamente ignorado. Acreditamos que o referido modelo precisa de uma total revisão. Com a nossa dependência cada vez maior da TI e os gastos crescentes com TI, uma revisão do Modelo Contratual é urgente.

O livro sobre contratos flexíveis deve ser lançado em breve.


1 'The failure of the FiReControl project' Relatório de controle e auditoria geral do Escritório de Auditoria Nacional, 1 July 2011.

2 'Double whammy - How ICT projects are fooled by randomness and screwed by political intent' por Alexander Budzier e Bent Flyvbjerg, trabalho apresentado na Said Business School, Oxford, August 2011.

3 Às vezes o contrato não determina o desenvolvimento sequencial, mas a exigência pelo escopo e o mecanismo de controle de mudanças é quase tão problemático.

4 Infra.

5 'Lifecycle Concept Considered Harmful' por Daniel McCracken e Michael Jackson, ACM Software Engineering Notes, April 1982.

6 Não conseguimos encontrar mais detalhes a respeito desses estudo. Claramente a meia-vida das especificações serão diferentes para setores diferentes. Contudo, existem indícios de evidência para apoiar a visão de que a meia-vida seja ainda mais curta no setor de tecnologia.

7 'The curse of the change control mechanism' por Susan Atkinson e Gabrielle Benefield, Computers & Law, May 2011.

8 Infra.

Sobre os autores

Gabrielle Benefield é a CEO da Evolve Beyond e ajuda as pessoas a construir ótimos produtos e organizações. É a autora de Scrum Primer e é co-fundadora da Flexible Contracts em parceria com Susan Atkinson. Está escrevendo dois livros sobre Entrega de Resultados e HotHousing; frameworks adaptativos que enfocam nos resultados que interessam para o negócio e seus usuário, ao invés das entregas que criam desperdício e experiências de usuário que causam confusão.

Susan Atkinson é uma advogada consultar na Keystone Law e outra co-fundadora da Flexible Contracts. É uma advogada comercial, com enfoque em TI, terceirização, e-commerce e propriedade intelectual. Tem mais de quinze anos de experiência legal e trabalhou em contratos comerciais complexos e de alto valor, primariamente em tecnologia para serviços financeiros e setor público, e frequentemente em um contexto internacional.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT