A instabilidade de projetos de software

Todos nós ja tivemos projetos que atrasaram, ficaram mais caro que o planejado, e até projetos que foram cancelados por não cumprir o esperado. É provavel que cada um deles tenha “falhado” por um motivo diferente, ou um conjunto de coisas diferentes.

É normal, hoje em dia, projetos falharem, e posso até dizer, rotineiro, que isso aconteça. A velocidade das mudanças do mercado e das próprias empresas não é acompanhada pelos modelos de gestão tradiciinais. Isso causa um erro de planejamento e consequentemente os atrasos e altos custos dos projetos.

O modelo de outras áreas

Conforme a popularidade dos softwares foi aumentando no decorrer dos anos, foi natural a adoção de técnicas de gerenciamento de projetos já consolidadas em outras áreas. Em especial, a industria de produção em massa. Por algum tempo, tudo se encaixou e os resultados foram bons, porém, quando softwares passaram a evoluir muito mais rapido e as industrias também, os modelos tradicionais começaram a falhar. Muitos problemas foram apontados como culpados: burocracia, falta de conhecimento, mal planejamento, estimativas, etc.

O meu argumento é de que, o principal erro foi entender software como um produto físico. Você ja viu um projeto de arquitetura, ou pelo menos, comprou um móvel novo pro seu quarto? É muito mais facil visualizar o resultado e entender a consequencia disso. Eu sei que um sofa, com as medidas certas, vai ficar bom na minha sala. Eu prefiro que seja marrom pra combinar com a cor do painel da TV.

Softwares são muito mais sutis. O fato de ser virtual, já altera como devemos pensar nele. A possibilidade de evoluir o próprio software sem recomeçar já é um grande fator que deve ser considerado na gestão. Outro ponto é que é muito mais dificil enxergar as consequencias e implicações de se ter o software, enquanto é muito facil perceber que se tivermos uma parede no meio do quarto, não cabe a nossa cama.

Muitos autores dizem que os requisitos de software, e ate mesmo os valores do próprio negócio, devem ser descobertos. É preciso conhece-los na prática, enxerga-los no dia a dia, enquanto tudo acontece. Um pouco disso é por causa da própria natureza humana, onde mudamos a todo momento, evoluimos, e enxergamos as coisas de maneira diferente. Outra coisa que costuma não ser levada em conta é como o software muda as pessoas, e como elas passam a enxergar um processo quando ele é feito através de software.

A essencia de Agile

É nesses pontos que as metodologias ágeis tem seu foco. Na constante mudança. O ponto mais forte do Agile é a rotineira checagem dos objetivos e do que foi construido. Estamos no caminho certo? O que fizemos realmente resolve o que nos propusémos? Será que não estamos resolvendo um problema que não é um problema?

O ciclo de levantar – desenvolver – validar se torna muito valioso em um mundo onde tudo muda muito rápido, inclusive a própria tecnologia. Até pouco tempo atrás, o trabalho de tornar o software mais performático poderia ser substituido por máquinas melhores, que em alguns momentos eram até mais baratas que o esforço dos desenvolvedores em melhorar a plataforma.

Acredito que a rotina de avaliar os esforços até o momento e os próximos objetivos a serem perseguidos poderia ter salvado muitos projetos que morreram, e economizado bastante dinheiro para muitas empresas.

Essencialmente, gestão de projetos é gestão de riscos. Um dos riscos que podem ser mitigados com esse tipo de abordagem é se estamos fazendo a coisa certa, no momento certo e do jeito certo. A agilidade traz também a noção de evitar desperdício. O que estamos fazendo realmente tem demanda? Vale a pena atender essa demanda? Esse tipo de questão evita que tenhamos softwares inchados, que fazem tudo mas não fazem nada bem.

Metodologias ageis são o caminho?

Não. Metodologias ágeis são ferramentas. Processos que ajudam no caminho. Furadeiras são ótimas para furar materiais mas inutil numa casa de palha. Os principios devem ser da própria equipe. Utilizar metodos ágeis podem ajudar, mas só quando o time sabe funcionar sem elas.

Um framework não desenvolve a aplicação para você, só te da atalhos. Você ainda tem que saber o que construir e como.

Por Pedro Fornaza

Desenvolvedor de software há mais de 10 anos. Formado em Sistemas de Informação. Empreśario. Trabalha principalmente com CRM e projetos Web.