Não é necessário ser um profundo conhecedor de TI ou mago para perceber o quão confusa e caótica é a lógica dos projetos tradicionais de software. Basta participar de um.
Quando digo tradicionais, refiro-me aos projetos que surgem a partir de uma demanda específica de um cliente ou de uma área interna. Tal demanda passa (quando passa) por um ciclo tradicional:
- A concepção;
- A elaboração da ideia em um documento ou apresentação e;
- A proposta técnica e comercial da empresa que deseja realizar o trabalho.
A empresa, que luta pelo projeto, na maioria das vezes invoca poderes sobrenaturais para estimar quantas horas são necessárias para a execução desse. E não raramente, tal estimativa não passa de um homérico chute. O pior, na maioria das vezes, o cliente adora e adota o chute como prazo final.
Quem participa ou participou de projetos de software, já sabe o resultado: problemas, seja na condução, no desenvolvimento ou na entrega.
O fato é: a empresa que executa o projeto não passa de uma “barriga de aluguel”. Não adianta tentar colocar em evidência as frases utilizadas no material de marketing, como “soluções sob medida” ou “equipe multidisciplinar focada em resultados”.
Vamos ser honestos: na maioria das vezes somos meros executores.
Projetos vendidos com horas fixas não dão margem para inovação. Inovar sai caro demais. Vivemos em uma cultura de desenvolvimento, não de pesquisa e desenvolvimento. Raramente numa proposta técnica vemos horas dispensadas para usabilidade, desempenho ou disciplinas que não sejam codificação, gerenciamento e testes.
Meu objetivo aqui é apenas questionar a forma como é vendido o projeto, não seu desenvolvimento.
Nenhuma metodologia ágil suporta projetos vendidos pela sede de comissão da equipe comercial. A área comercial precisa absorver o conceito, o “como desenvolver” e “como entregar” para entender o que vender e o que pode dar certo.
A proposta do Scrum – na minha opinião – é também vender ao cliente a capacidade de gerar soluções, propor novas ideias, de criação, de inovação, aumentar ou negociar o escopo, mostrando ao mesmo que ele terá o tão sonhado “valor agregado” no final do projeto.
Não proponho que o cliente assine um cheque em branco. Proponho apenas que a lacuna entre o comercial e a equipe técnica seja menor ou que exista uma sinergia entre ambos. Um projeto de software é muito mais que um monte de horas em uma planilha do Excel. [Webinsider]
…………………………
Acompanhe o Webinsider no Twitter e no Facebook.
Assine nossa newsletter e não perca nenhum conteúdo.
Cristian Arrano Townsend
Cristian Arrano Townsend - estudou engenharia da computação no Chile, trabalha com desenvolvimento de software há mais de 15. Atualmente é diretor técnico da Uaná Sistemas e da Código Forte.
Uma resposta
Bravo!