Contratos e alterações no software. Pagar ou não pagar?

Posted on Posted in contratos, pontos de função, Rotéiro de Métricas SISP

No dia 23/06/2015 participei do II Seminário de Metodologia Ágil do SISP, organizado pela SLTI/MPOG. Os guias do SISP apresentados neste seminário são muito importantes não só para os órgãos do SISP, mas também para os órgãos públicos em geral, pois ainda carecemos de bons modelos de contratação de desenvolvimento de software, haja visto os poucos casos de sucesso.

 

Pois bem, em determinado momento deste seminário surgiu a discussão sobre pagar ou não pagar pela alteração de funcionalidade já desenvolvida em iteração anterior. Sendo que funcionalidade aqui deve ser encarada do ponto de vista da Análise de Pontos de Função. No guia do SISP, ficou a orientação por não se pagar por essas alterações.

 

Vejo que essa orientação tem origem nos riscos apontados pelo TCU no seu Acórdão nº 2314/2013 (Veja o artigo que o Herbert escreve na época http://governoagil.com.br/2013/09/05/acordao-do-tcu-sobre-metodologia-agil/). Abaixo, transcrevo os riscos 11 e 14 listados neste acórdão e destaquei em negrito os pontos de maior interesse.

 

282. Risco 11: alteração constante da lista de funcionalidades do produto.
282.1. Uma vez que a mudança de requisitos …, previstas ou vislumbradas.
282.2. A alteração constante e descontrolada da lista de funcionalidades do produto durante o contrato pode levar a instituição contratante a exceder prazos e custos de desenvolvimento preliminarmente estimados. Por consequência, a materialização do risco ora em destaque pode conduzir à execução de desembolsos excessivos, contrapondo-se ao princípio constitucional da economicidade e ao princípio do planejamento, bem como a atrasos na entrega do produto final ao cliente (área demandante), opondo-se ao princípio constitucional da eficiência.…
285. Risco 14: pagamento pelas mesmas funcionalidades do software mais de uma vez, em virtude de funcionalidades impossíveis de serem implementadas em um único ciclo, ou em virtude da alteração de funcionalidades ao longo do desenvolvimento do software.
285.1. A construção do software …

 

Mas, se estamos discutindo contratações ágeis no governo é porque já percebemos que seguir os princípios ágeis é o melhor caminho para desenvolver software e é natural querermos levar esses conceitos para as contrações de desenvolvimento de software.

 

E aí surge um problema. A proposta do manual do SISP de não pagar por alterações talvez induza a contratada a utilizar um modelo cascata de desenvolvimento. Ou seja, levantar todos os requisitos no início, para não ter que desenvolver sem receber. Esta proposta também repassa todo o risco de aumento de custo para a contratada. E isso nos faz caminhar na direção contrária dos conceitos mais básicos dos métodos ágeis. Voltando ao Manifesto Ágil, de 2001, temos os princípios:

 

“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.”

 

“Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.”

 

Esses princípios existem porque os criadores do manifesto ágil acreditavam que desenvolver software é um processo de descoberta. Construir software não é o mesmo que seguir uma receita de bolo, é criar a receita. E para criar a receita, muitas vezes é preciso testar várias hipóteses e, algumas vezes, refazer parte do trabalho.

 

O quanto antes colocamos software nas mãos dos usuários, mais rápido temos feedback e mais rápido alteramos o software para atender às necessidades destes usuários. Assim, deveríamos pensar nossos processos de desenvolvimento (também nas contratações) em como colocar o software o mais rápido possível nas mãos dos nossos usuários. O que nos leva a encontrar vários MVPs (Produto Viável Mínimo, em inglês) em sequência até resolver todo o problema proposto no projeto. Para trabalhar assim, a mudança é inevitável e bem vinda.

 

Na verdade, a estratégia diminui drasticamente o risco e o custo de se desenvolver software. Ao colocar um software em produção em poucos dias ou semanas (a StartupDev é um bom exemplo), abrimos a possibilidade desse software sofrer várias alterações, mas também começamos a pagar mais cedo o investimento realizado.

 

Um sistema que induza o desenvolvimento de software a não aceitar mudanças tende a causar o efeito contrário. Voltaremos a especificações de requisitos longas e “completas”. Estas especificações longas tentam “adivinhar” o que o usuário vai precisar. Demora-se meses para entregar algo funcional para o usuário. O efeito já conhecemos: o software não é colocado em produção ou o software é colocado em produção com funcionalidades que o usuário não precisa. Ou seja paga-se por funcionalidade que não será usada.

 

Voltando ao acórdão do TCU, no risco 11 se lê: “A alteração constante e descontrolada da lista de funcionalidades do produto durante o contrato pode levar a instituição contratante a exceder prazos e custos de desenvolvimento preliminarmente estimados”.

 

O “descontrolada” não faz sentido no desenvolvimento ágil. No desenvolvimento ágil temos de forma clara qual é o objetivo do projeto e qual problema ele deve resolver. E aí todo o esforço do time do projeto deve ser direcionado para resolver este problema. Ou seja, as alterações não são descontroladas, mas sim direcionadas para atingir um objetivo.

 

Quanto a exceder prazos e custos estimados temos duas questões. Primeiro, no planejamento dos projetos, temos que começar a levar em consideração as alterações que serão realizadas. Com o tempo teremos um histórico e, tanto governo quanto contratada, saberão estimar melhor prazos e custos. Segundo, os prazos e/ou os custos podem ser fixados previamente, deixando o escopo variar. Assim, não haveria variação para cima de prazo ou custo. Além disso, poderia haver uma diminuição de custo ou prazo caso o objetivo do projeto fosse atingido antes do planejado.

 

Já no Risco 14, o seu título é: “pagamento pelas mesmas funcionalidades do software mais de uma vez”. Do ponto de vista da Análise de Pontos de Função, realmente estariam sendo pagas várias alterações em uma mesma função em diversas iterações. Já do ponto de vista do usuário, sempre haverá alteração real no sistema para que seja contado um ponto de função e, em consequência, haver pagamento à contratada. Ou seja, não se paga pela “mesma funcionalidade” mais de uma vez. Paga-se pelo valor agregado para o usuário em cada iteração.
E aí? Vamos aceitar mudanças ou não? Pagamos por elas ou não?

por Rodrigo Vieira

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *