É muito comum usar o método Cálculo Hipotético Universal da Teoria Especulativa (C.H.U.T.E.) para fechar orçamentos e propostas.

Por: Clovis Hitos Gonçalves

Um tema que constantemente vem à tona em minhas andanças pelos nossos clientes é a necessidade de melhoria da produtividade, em geral, no processo do ciclo de vida de desenvolvimento de um software, sustentação de sistemas, suporte à infraestrutura, entre outras áreas. É comum ouvir que os projetos de software são superdimensionados, caros e demorados.

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 é estimar que um software é um tabu 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.

Fonte: ComputerWorld

Texto original:
http://computerworld.com.br/como-fugir-dos-projetos-de-software-superdimensionados-caros-e-demorados