O software “todo” não existe!

Este post não tem tags.

Compartilhe:

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.

Sobre o autor(a)

Co-fundador e Trainer na K21

Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e membros de equipes em mais de 15 países na Europa, América e Ásia.

No headers found for the table of contents.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Você já abandonou as estimativas porque achava que elas só faziam o time perder tempo? Eu também. Mas aprendi que elas podem ser mais úteis do que parecem. Já utilizamos Kanban há algum tempo e suas métricas nos são muito…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Em um mundo ideal, todos os times da empresa seriam de ponta a ponta. Indo desde a concepção do produto / serviço através de formulação de hipóteses, passando pela construção, entrega para o cliente até a aferição de resultados. Porém,…

Samuel Cavalcante - Consultor e Trainer na K21

Uma virada de qualidade nas cerimônias que facilitava, principalmente retrospectivas, aconteceu quando entendi que precisa ter mais conhecimento do grupo e que todas as atividades que executo, podem ser direcionadas conforme o contexto da equipe. 4 Quadrantes de Contexto da…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Um dos maiores desafios da gestão de fluxo é a identificação de gargalos e o que deve ser feito para removê-los. Geralmente, as pessoas analisam o quadro de tarefas e usam a lógica: se uma etapa do fluxo tem mais…