Fábrica de software – Gestão de Capacidade x Demanda

Demanda x Capacidade

A Gestão da Capacidade é um dos requisitos mais básicos de qualquer negócio, balancear pessoal/equipamento disponível para atender a demanda dos clientes, é o chamado controle de Capacidade x Demanda. Na indústria de manufatura o  tema é muito crítico, pois vendem ordens de produção antecipadamente e precisam manter as linhas de produção em seu funcionamento ótimo, ou seja, melhor aproveitamento possível de sua capacidade, daí nasceu o Planejamento e Controle de Produção.

As Fábricas de Software realizam projetos de desenvolvimento e melhorias de software e também possuem a necessidade de controlar a capacidade x demanda, para saber quando podem realizar novos projetos. Para endereçar essa necessidade elas podem ser organizadas com estruturas Matriciais e Projetizadas, a maioria prefere organizar de forma projetizada pela simplicidade do controle de recursos ou para garantir o atendimento a determinado cliente, mas existem as Fábricas que preferem a estrutura matricial, alocando profissionais conforme surgem projetos.Essa problemática me parece com a própria definição de economia, o estudo da escassez de recursos. Mas por que é tão difícil controlar capacidade x demanda numa Fábrica de Software? Neste post compartilho duas propostas de solução que aplicamos em estruturas fabris, com seus pontos fortes e fracos.

Fábrica de Software

A dinâmica de Fábrica de Softwares é similar,  independente de sua estrutura. Entram requisições de serviços, que são analisadas e estimadas, gera-se uma proposta, que aprovada gera um projeto, que é planejado e para ser executado precisa de recursos humanos e materiais.

Na fase de Planejamento do projeto, faz-se a combinação de que recursos serão necessários e quando estarão disponíveis. É um trabalho que requer compromisso e seriedade das áreas funcionais para garantir a disponibilidade do recurso planejado no período de alocação previsto.

Fatores complicadores bastante comuns são Atrasos de projeto e Repriorização de Projetos. Por conta destes e outros problemas menos comuns é que o controle de Capacidade x Demanda costuma requerer atualização periódica em base centralizada.

Algumas empresas, mesmo em organização matricial, preferem ter um “Gerente de Recursos Compartilhados”, que mantém o Histograma de Recursos atualizado e centralizado, além de evitar conflitos entre gerentes funcionais e gerentes de projeto. Outras preferem manter o poder da alocação na mão dos gerentes funcionais, com o intuito de incentivar atividades comuns nas áreas, como: Melhorias proativas de arquitetura, realização de workshops de atualização, construção de ferramentas internas, etc.

Histograma de Recursos é um diagrama que mostra a quantidade de horas de esforço disponível versus a quantidade de horas de alocação dos recursos em projetos.

Abaixo apresento o funcionamento de 3 casos de uso que experimentei em Fábricas de Software.

Caso 1 – Controle de Alocação

Este controle foi aplicado a um Programa com recursos compartilhados entre projetos multidisciplinares. Tratavam-se de projetos variados, de desenvolvimento de software a importação de design para aparelhos celulares, por conta disto contagens de tamanho eram inviáveis.

A planilha apresentava o controle de recursos ao longo do tempo

Caso 2 – Histograma Capacidade x Demanda Simples

Neste primeiro cenário, a Fábrica de Software era bem simples. Atendia somente a um cliente, com 5 projetos simultâneos e duas áreas funcionais: de testes e de gestão de configuração.

Os projetos contavam pontos de função e tinham tamanhos variados, havia bastante mudança de escopo e a equipe ainda era imatura sobre o aspecto de processos de engenharia de software e de gestão de projetos. Por estas razões, optou-se por montar um Histograma simples, que refletisse capacidade e alocação.

O Histograma retratava a capacidade (esforço técnico disponível) e demanda (necessidade dos projetos) e calculava se quanto seria a folga. Se positiva, poderia-se alocar mais projetos, se igual a zero, todos os recursos estariam alocados e se negativa, havia previsão de falta de recursos.

No exemplo abaixo, tem-se um quadro para controle de CAPACIDADE, que mostra a capacidade (esforço) disponível por pessoa ao longo dos meses – se zerado significa que a pessoa está de férias ou indispon’viel – deve ser sumarizado por função No quadro DEMANDA, tem-se o esforço demandado por função para cada projeto. E no último, o QUADRO RESUMO, mostra-se a disponibilidade capacidade x demanda por função. Neste exemplo inclui somente a função Programador, razão pela qual as demais estão zeradas.

Com a implantação do modelo foi possível verificar semanalmente a situação dos recursos, embora sempre houvesse um desvio considerável na alocação real, devido a requisições de mudança, atrasos nos projetos, etc.

Caso 3 – Controle completo

Este modelo foi implantado numa Fábrica de Software que usava a estrutura matricial, com áreas funcionais de Análise, Construção, Testes, Gerência de Configuração e Manutenção. Rodava até 10 projetos simultânos e tinha em torno de 80 funcionários atendendo a vários clientes. Apenas um percentual pequeno dos projetos utilizava contagem de pontos de função, então foi preferível usar um controle baseado em horas.

Neste caso, o controle continha a CAPACIDADE x DEMANDA exatamente como no caso 2, porém acrescentava a ALOCAÇÃO, que corresponde a quantas hora de fato cada pessoa foi alocada nos projetos, similar ao Caso 1, porém em horas; e incluía também o REPORTE DE HORAS, para comparar quantas horas cada foram trabalhadas em cadas projeto.

O objetivo do controle adicional era estudar a diferença entre a DEMANDA e ALOCAÇÃO, pois geralmente há grande variação. A DEMANDA servia para prever a disponibilidade de recursos de modo macro (por função), permitindo que o Gerente da Fábrica de Software soubesse quantas horas de esforço estariam disponíveis por função, conseguindo assim determinar a entrada de um novo projeto.

A perspectiva de ALOCAÇÃO, disciplinava a equipe de gestão a controlar quem estava sendo alocado em cada projeto no período e a de REPORTE DE HORAS, era utilizada pelos recursos para apontar suas horas, que deveriam somar exatamente a quantidade de horas trabalhadas na semana. Esta função só era ativada para os recursos se estivessem alocados, com isso tinha-se uma dupla checagem dos dados.

Estas 4 perspectivas permitiam ao Gerente da Fábrica de Software ter a noção exata da disponibilidade de seus recursos por função, a demanda planejada dos projetos, a alocaçõa real dos técnicos e finalmente, o apontamento de horas realmente gastas em cada projeto.

Por ser mais sofisticado, foi desenvolvido um sistema para controlar este histograma, contendo telas similares ao caso 1 e 2, mas também gráficos de barras por função, por projeto, alocação e horas trabalhadas por pessoa. Infelizmente não posso disponibilizar as telas por questão de confidencialidade.

Qual modelo escolher?

Para cada contexto existe um modelo adequado, deve-se observar se são projetos de mesma natureza, se existem times mais fixos ou se há constante necessidade de atualização da planilha e principalmente, deve-se avaliar o custo-benefício de cada solução.

Há que se considerar o tempo necessário para atualizar o Histograma, quanto mais detalhes, mais esforço e com isso a resistência do time de gestão e técnico, muitas discussões sobre a necessidade e benefício da ferramenta. Sugiro que comece sempre com o modelo do caso 1 e vá observando as necessidades que surgirem.

Espero ter ajudado!

Eli Rodrigues