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.
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

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.