Recentemente ministrei um CSM e um CSPO em Brasília onde a maioria das pessoas trabalhava com o Governo. Nessas duas aulas, ouvi várias vezes o seguinte questionamento:
“Ao se iniciar um projeto com métodos Ágeis, como podemos determinar custo e prazo sem conhecermos o “todo”, ou seja, sem descrevermos, o mais detalhadamente possível, o que é esse produto a ser gerado?”
Apesar de uma longa história de fracassos, muitas organizações no mundo ainda insistem em definir “todo” o software a ser desenvolvido no principio do projeto, como se fosse um edifício a ser construído. O Governo Brasileiro é uma delas, embora venha recentemente sinalizando importantes mudanças.
A verdade é que esse “todo”, quando se trata de software, não existe até que ele seja de fato criado. Ele não está escondido em algum lugar na cabeça do cliente ou em sua empresa, e assim bastariam, no início do projeto, a técnica adequada e tempo de planejamento suficiente para ser descoberto. O software “todo” ainda não existe.
Ao pesquisarmos as razões de fracasso para projetos, uma das respostas mais comuns é que o cliente não sabe o que quer, já que ele fica solicitando mudanças. O cliente, claro, tem desejos ou necessidades a serem supridas a partir do produto, e esses justificam a própria contratação do projeto. Mas ele não sabe os detalhes de como chegar lá. Como diz meu amigo e sócio Rodrigo de Toledo, se o cliente nunca sabe o que quer, então isso é fato. FATO! Vamos então encarar isso como fato e lidar com a realidade da melhor forma que pudermos. E lidar com a realidade significa aceitar a inevitável mudança como parte do processo, e não como inimiga. Ao invés de buscar meios de evitá-la, abraçá-la é o que conduzirá o projeto ao sucesso. E entender que essa “mudança”, na realidade, é o próprio processo de definição do produto.
O “todo” é, assim, criado progressivamente, a partir do feedback do cliente, que vê, recebe e usa incrementos do produto que lhe entregamos com frequência. A definição desse “todo” é, portanto, um processo contínuo de descoberta e de aprendizado, onde cliente e desenvolvedores caminham juntos definido, gerando, avaliando e realimentando o produto, de forma que atenda às necessidades desse cliente da melhor forma possível.
E o contrato? Bem, como produzir um contrato de algo que NÃO PODE ser detalhadamente definido a priori? Será que funciona mesmo assim criar um contrato detalhado, fingindo que podemos definir esse “todo” no início do projeto? Será que mentir (e, muitas vezes, acreditar na mentira) é a solução? Tenho certeza que não. Lidar com a verdade não lhe parece mais razoável?
Pense então como você faria o contrato para a criação de um produto novo, a ser inventado – porque software é assim – e construa sua solução para o contrato a partir daí. Topa o desafio? E então poderemos continuar essa discussão em um post futuro.
