Com uma pergunta dessas eu com certeza estou causando confusões nas mentes das pessoas que não entendem exatamente o que estou dizendo. Vou dar alguns exemplos de coisas que tenho visto ultimamente para que as conclusões possam fazer algum sentido…

Primeiro, o contexto: as experiências têm se passado no dia-a-dia do trabalho de imersão Ágil que temos feito na Agence. Segundo, não vou citar nomes de clientes ou coisas do tipo e tentarei ser o mais claro possível sem ofender ninguém. Terceiro, se alguém se ofender, sinta-se à vontade para expressar seus argumentos nos comentários, pessoalmente ou de qualquer outra forma. O que vou colocar aqui é apenas meu ponto de vista atual sobre desenvolvimento (ágil) de software.

Tenho visto uma tendência de empresas que tem mostrado um trabalho legal, de não atenderem grandes corporações multinacionais para dar preferências à startups. Com isso, refleti um pouco sobre como isso acontece no meu dia-a-dia, visto que tenho a oportunidade de atender tanto clientes abrindo um novo pequeno negócio ou dando uma “guinada” no seu pequeno negócio atual, quanto grandes corporações multinacionais ou governo.

Percebi algo interessante. Se falando de desenvolvimento ágil, mais especificamente SCRUM, temos a figura do Product Owner (PO). Esse é um papel bastante difícil de se assumir, visto que este cara visa o ROI como principal fator de sucesso de um projeto de software, pelo menos na cartilha. Fazendo um paralelo para o mundo real, nem com os cliente mais “engajados” que atendemos, tenho nutrido esperanças de ter um legítimo PO.

Vou mostrar o que geralmente acontece em dois cenários distintos: projetos para grandes empresas e para pequenas empresas.

Grandes empresas

Quando temos nosso “gerente de projeto” dentro das grandes empresas, esse cara geralmente tem uma formação em TI e pós-graduação/mestrado/MBA/cursos de extensão na área de Gerenciamento de Projetos. OK, ele entende um pouco de software e também um pouco de PMI. Infelizmente, ele não PAGA pelo projeto, mesmo havendo cobrança de seus clientes internos, o dinheiro não sai do bolso dele. Esse é o que considero nosso pior cenário de trabalho pois, a mentalidade cascata (ou cascateiro) é predominante (com raras exceções). Argumentos por parte do cliente:

• Nossos analistas do departamento de TI vão levantar os requisitos para o projeto e abrir uma RFP, RFQ ou outro nome novo para isso.
• Temos um orçamento pré-definido para esse projeto.
• A área (leia-se, quem solicitou o projeto/cliente interno) não tem disponibilidade de “homologar” o projeto em partes. E, como é de praxe, nós que estamos desenvolvendo o projeto não costumamos ter contato com “a área“.
• Não faz o menor sentido o projeto “ir para o ar” antes de ser terminado.
• Há um contrato a ser cumprido, que muitas vezes prevê multas para atrasos.

Como era de se esperar, não é um espanto haverem divergências de requisitos (e várias reuniões para discutir o assunto) no final do projeto. Mesmo tentando trabalhar de forma iterativa, isto é, apresentando o sistema em partes para esse gerente de projeto, no final, quem de fato vai usar o sistema, acaba por não participar dessas “entregas” parciais e acaba “mudando” de idéia quando vê o projeto terminado, meses depois que ele foi “concebido”. As palavras entre aspas nessa frase tem um significado muito relevante:

• Concebido: O custo/prazo/escopo do projeto tem que ser fixo. Logo, antes de assinar um contrato, temos que entender muito bem o que vai ser feito, geralmente apresentando protótipos que são “assinados à sangue” pelo gerente de projeto e pelo pessoal que solicitou o projeto.
• Mudando: naturalmente, você já entendeu que as reuniões no fim do projeto são para negociar mudanças que, é óbvio que acontecem.
• Entregas: como são feitas para o gerente de projeto e obedecendo a especificação inicial (ou as datas de pagamento do contrato), é uma mera prova de que o cronograma está sendo cumprido.

Resultado final: na maioria das vezes o projeto sai mais caro e demora mais que o previsto. Lembre-se que o escopo mudou e até hoje não vi nenhum projeto que não tenha mudado. A não ser que seja algo muito pequeno (entenda-se, projetos com menos de 300 horas ou 2 profissionais durante 1 mês).

Pequenas empresas

Pequenas empresas por outro lado não tem árvore de dinheiro e por isso tem que otimizar ao máximo cada centavo “gasto” em software. Por isso, não é nenhuma novidade que consigamos fechar projetos de escopo aberto com duração e custo fixo. Neste caso, conseguimos à cada apresentação para o cliente, ter um feedback exato se estamos mesmo indo no caminho certo. E, acreditem, na maioria das vezes o projeto vai para o ar antes daquele prazo inicial previsto terminar.

Aqui, de fato, conseguimos aplicar a cartilha de desenvolvimento iterativo de forma eficiente. Conseguimos fazer menos software, reduzir o time-to-market, gerar valor para o cliente e cultivar um relacionamento muito bom com os clientes.

–

Para concluir, segue um paralelo sobre custos e prazos (esta informação é empírica e baseada apenas na minha observação dos projetos no último ano):

Perfil dos projetos analisados: o prazo geralmente é de 3 a 4 meses para um volume de cerca de 1.500 horas. Nesses projetos trabalhamos com equipes de 3 a 6 pessoas envolvendo uma pessoa que faz o atendimento ao cliente, dois desenvolvedores plenos, um ou dois desenvolvedores júniors e um designer.

–

Para finalizar… Nem sempre é fácil usar princípios básicos que norteiam desenvolvimento ágil como neste caso, desenvolver de forma iterativa. Muitas vezes os projetos já começam no modelo cascata e, como somos consultorias que prestam serviço para esses clientes, não temos muito o que fazer para alterar o cenário. Neste caso, posso afirmar que seu cliente não é Ágil!

Obrigado para quem leu até aqui!! Fico à disposição para trocar idéias sobre o assunto. []‘s e boa semana!