Desenvolvimento

Ξ Deixe um comentário

Estimar tamanho de software é o suficiente?

publicado por Clovis Hitos Gonçalves

Figura -Estimar tamanho de software é o suficiente?Um tema que constantemente vem à tona em minhas andanças pelos clientes em que atuo na Inmetrics é 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, é 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.

Autor

Profissional com experiência de mais de 20 anos em Tecnologia da Informação. Atuação em diversos segmentos de T.I., como operações de outsourcing de TI, governança (qualidade e processos), arquitetura de soluções (Serviços), pré-vendas e liderança de consultoria em eficiência de gestão de TI e inovação. Minhas diretrizes profissionais: - gerar o máximo de valor nas relações e projetos com meus clientes e pares - mudar a vida das pessoas para melhor, através do meu trabalho - ser reconhecido e tornar-me referência na minha área de atuação Gerente de Prática Consultoria - Estratégia, Inovação e Otimização de TI Inmetrics SA - http://www.inmetrics.com.br LinkedIn: http://br.linkedin.com/in/clovishitos

Clovis Hitos Gonçalves

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes