Levando o assunto diretamente para desenvolvimento de sistemas, é comum encontrarmos etapas de concepção, análise e requisitos, nas quais existem algumas práticas de estimativas de esforço, mais maduras em algumas organizações, porém nem tanto em outras.
Sobre essa maturidade, posso afirmar que em algumas dessas organizações, estimativas é algo praticamente inexistente ou desestruturado de forma a não existir um padrão aparente ou que seja consenso ao de todos os envolvidos. Pior, é quando estimar software pode ser considerado um tabu, que é passado à frente na tradição oral da organização (“ninguém sabe o porquê, mas, estimar é algo que não funciona aqui…”). Então o que predomina é o método “Cálculo Hipotético Universal da Teoria Especulativa” (C.H.U.T.E.), utilizado para fechar orçamentos e propostas.
Quanto aos processos maduros de estimativas, sim eles existem, apesar de relativamente raros. Em geral são muito bem estruturados, com padrões muito bem concebidos, tornando-se um excelente mecanismo para contratação de serviços de desenvolvimento de terceiros e para dar segurança nas estimativas financeiras, comuns no setor governamental e grandes instituições financeiras. Mas param por aí. Minha provocação: estimar é o suficiente?… Não! A estimativa de software é parte de algo maior. Você com certeza vai me questionar, “se você faz a estimativa bem feita você tem maior assertividade no custo, esforço e prazo do seu projeto”. Sim concordo, mas isso não é o suficiente! O mundo corporativo moderno e as suas respectivas pressões por resultados (mais agilidade, mais velocidade, mais qualidade, menos desperdício, menor custo), nos fazem apontar os nossos esforços à melhoria da produtividade. Sendo mais objetivo, temos que fazer mais com no mínimo o mesmo; mas o foco real é fazer mais com menos, e da melhor forma possível, no menor tempo possível.
Existem ações pontuais de melhoria da produtividade, mas sempre dependem da boa vontade de alguns indivíduos e a captura do retorno, na maioria das vezes, é difícil, além de não ter sustentação a longo prazo. Dificilmente vemos ações estruturadas e objetivas ligadas à melhoria contínua de produtividade, o que é um desperdício enorme e têm o potencial de gerar ganhos substanciais de tempo e dinheiro.
Na prática, temos que equilibrar três dimensões no processo desenvolvimento de software: custo (dinheiro investido na entrega), qualidade (efetividade da entrega dentro dos requisitos e/ou expectativas do cliente) e produtividade (quanto é produzido com o esforço/tempo disponível). O prazo do projeto e a satisfação do cliente são consequências do equilíbrio entre essas três coisas. É muito comum existir nas áreas de suprimentos das organizações grande foco no custo, que são ações relacionadas a redução do valor da hora homem e custos de fábrica de software. Ações desse tipo tendem a reduzir significativamente o custo por hora, porém não garantem que a entrega será produtiva e assertiva. Quanto à qualidade, as empresas investem grandes esforços e dinheiro nos processos que tem por objetivo entregar os requisitos definidos da forma mais assertiva possível. Essas ações são efetivas, porém também não garantem que o ciclo de desenvolvimento seja produtivo (temos que convir que em alguns casos o torna improdutivo).
É raro encontrar unidades organizacionais com foco em produtividade, o que pode trazer equilíbrio das três dimensões citadas. Em geral, o investimento em iniciativas desse tipo parece alto, mas gera um retorno significativo, o que financia a adoção de um modelo de gestão da produtividade.
A gestão da produtividade permite que sejam analisados os resultados (sempre baseados em fatos e dados) de forma sistemática e com a utilização de métodos estatísticos, permitindo a identificação de ofensores e a adoção de ações que permitam a eliminação dos geradores de improdutividade.
Os requisitos principais para que exista a gestão da produtividade são:
- Unidade de medida definida e reconhecida (seja qual for: use case points, pontos de função, pontos de complexidade, métricas ágeis, funcionais e não funcionais).
- Documentação mínima para que seja possível dimensionar o software, adequada à métrica escolhida.
- Informações sobre o ciclo de desenvolvimento (mesmo que desestruturadas).
- Utilização de ferramentas de estatísticas para estruturação da informação.
- Um conjunto adequado de indicadores de desempenho da produtividade.
- Atuação concreta em ações de melhoria de forma holística (processos – internos e externos, pessoas, tecnologia, ferramentas e parceiros).
- Profissionais com capacitação e conhecimento adequados.
Tenho participado de projetos onde a combinação da gestão da produtividade com práticas Lean tem dado resultados significativos (temos vários artigos sobre Lean no nosso blog, vale a pena ler!).
Esse assunto é de certa forma polêmico e extenso, então gostaria de propor aqui uma reflexão. Aqui vão alguns sintomas que direcionam a necessidade de você atuar na melhoria da produtividade:
- Você não tem uma medida de software que é entendida por você, por suas equipes de análise e desenvolvimento de sistemas e, principalmente, por seu cliente final. Isso, em geral, gera conflitos que parecem insolúveis ou são bem desagradáveis.
- Há dúvidas quanto ao esforço estimado e realizado no desenvolvimento de um software.
- Você tem a sensação de que está gastando demais no desenvolvimento de software, mas não consegue argumentar com sua equipe de desenvolvimento ou com o seu fornecedor.
- Você tem a sensação de que controlou o seu custo por hora, mas não houve impacto perceptível nos custos totais dos projetos.
- Você percebe que o seu desenvolvimento de software é improdutivo, mas isso é visto somente de forma subjetiva, sem fatos e dados que comprovem sua percepção.
- As melhorias necessárias no ciclo de desenvolvimento de software aparecem o tempo todo, mas todas parecem ser prioritárias e você acaba perdendo o foco.
- Você tem a necessidade de conhecer a produtividade não apenas das equipes de desenvolvimento em si, mas também por outras perspectivas, como por exemplo: por fornecedor, por tecnologia, por senioridade, entre outras.
Leave a Comment