Fábrica de Software – Como estruturar
A teoria de Gestão de Projetos transborda em explicações sobre as estruturações organizacionais e possui comparativos sobre os modelos projetizado, funcional, matricial forte e fraco. Mas embora os gerentes de projetos tratem o assunto como conhecimento sedimentado, gostaria de trazer à tona a perspectiva do Gerente de Fábrica de Software (GFSW).
Conceituando: Fábrica de Software é uma organização responsável pelo desenvolvimento e, frequentemente, manutenção de softwares.
Originalmente, era intrínseco conceito de Linha de Produção, acreditando-se que este modelo traria mais eficiência e qualidade. Agrupariam-se os “operários” por competências, em ordem sequencial e ao final sairia um produto de software.
Este modelo tem sido bastante criticado nos últimos anos, o principal motivo é que nenhum desenvolvimento de software é igual a outro, mesmo que se trate de uma customização. Os mais radicais questionam que se a linha de produção nunca gera o mesmo produto, não há razão para utilizar o termo Fábrica de Software. Além é claro, da recorrente discussão sobre como tratar a manutenção.
Para suprir esta falha conceitual, as empresas recorreram aos conceitos de departamentalização Matricial e fizeram suas apostas. Algumas acreditaram nas vantagens das Matrizes Fraca e Forte e outras na estrutura Projetizada. Abaixo apresento minhas observações sobre o ponto de vista do GFSW mediante os modelos citados.
Matriz Fraca
Colaboradores são subordinados e coordenados pelo Líder Funcional e Gerente de Projetos funciona como “cliente” das áreas.
- Pontos fortes
- Qualidade na Gestão Técnica dos Recursos – Melhor projeção de carreira para os técnicos, facilitar o compartilhamento de informações entre eles é facilitado.
- Áreas de apoio tem um “lugar ao sol” – Testes, Qualidade e CM, que tem normalmente um perfil mais autonomo, não precisam ser desmembradas nos projetos.
- Pontos fracos
- Visão Geral de Alocação é prejudicada – Para ter uma visão geral dos recursos é necessário criar um Histograma de Recursos. Já participei da implantação de uma ferramenta dessas e garanto que dá bastante trabalho! Além disso, é necessária atualização semanal de Gerentes de Projetos, Líderes funcionais e colaboradores para chegar a análise de Capacidade x Demanda x Alocação x Uso Efetivo.
- Centralização de conflitos – O GFSW tem que decidir a prioridade entre uma Melhoria importante na área funcional ou o atendimento do Projeto. Ex: Atualizar o framework de desenvolvimento, beneficiando vários softwares em produção e entre alocar o arquiteto principal para resolver uma CR de um projeto. É como lutar contra si mesmo e perder sempre.
- Reports repetidos – O GFSW é obrigado a acompanhar status das Lideranças Funcionais e dos Gerentes de Projetos. Isto gera um belo overhead, traz problemas repetidos e frequentemente é necessário convocar reuniões envolvendo a equipe de projeto completa x equipe funcional.
- Problemas de comunicação – O Gerente de Projetos faz a interface com o cliente e passa para o Líder funcional a responsabilidade de transmitir as instruções aos técnicos. É um “telefone sem fio” iminente.
Modelo Projetizado
Os colaboradores são diretamente subordinados a um Gerente de Projetos.
Neste cenário os recursos técnicos podem ficar diretamente subordinados ao GFSW ou pode criar-se um “Gerente de Recursos Compartilhados”. É neste segundo contexto que analiso.
- Pontos Fortes
- Gerente de Recursos Compartilhados – Define-se um “Gerente de Recursos compartilhados”, aquele que negocia a alocação dos técnicos com os Gerentes de Projetos. As estruturas de controle (como Histograma) são simplificadas.
- Team leaders – Para suprir a ausência da referência técnica são instituídos team leaders, que fazem o acompanhamento técnico, sem envolver-se em assuntos administrativos. Os resultados costumam ser otimizados e os custos reduzidos.
- Pontos Fracos
- Envolvimento operacional – O GSFW é esporadicamente envolvido em problemas operacionais, tirando o foco de suas atividades, como por exemplo: Priorização de demandas (ex: quando um projeto atrasa e impacta no inicio da execução de outro), tirando o foco de suas atividades.
- Avaliação de mérito – Os Gerentes de Projetos disputam os “melhores recursos” e tem inicio a discussão sobre avaliação de mérito, como: “quais são os programadores mais produtivos”, “quais geram menos defeitos” e etc.
Matriz Forte
Colaboradores são subordinados a uma liderança funcional, mas são alocados em um projeto sob coordenação de um Gerente de Projetos.
Particularmente gosto muito dessa abordagem se for implantada através da criação de Programas com autonomia para gestão técnica e administrativa de todos os recursos necessário como: Analistas, programadores, testadores e Gerentes de Projetos.
Conceitualmente seria possível também ter o Gerente de Recursos Compartilhados nesta estrutura, mas analiso com base no Gerente de Programas.
- Pontos fortes
- Foco no Resultado – O envolvimento do GFSW resume-se a atividades administrativas como a análise de resultados individuais, projeção de carreira dos colaboradores, rotatividade, etc.
- Visibilidade atualizada – Com a divisão das responsabilidades, cada Gerente de Programa tem condições de ter status atualizados de todos os projetos diariamente.
- Relacionamento com o cliente mais personalizado – O Gerente de Programa tem condições de dar um tratamento diferenciado a seu cliente, aumentando a probabilidade de obtenção de um alto indice de satisfação.
- Pontos fracos
- Overhead administrativo – O Gerente de Programa pode ter overhead administrativos com temas relacionados a gestão de pessoas.
- Recursos sub-alocados – Os recursos técnicos podem ficar sub-alocados dentro de um Programa, sobretudo se não houver um mecanismo de “empréstimo” bem definido entre os Programas.
Diante dessa análise, particularmente vejo o Gerente da Fábrica de Software como um cargo funcional, focado principalmente na gestão do portfólio de produtos e serviços, busca de novos negócios, priorização de projetos, análise de resultados (sobretudo através de indicadores) e gestão administrativa. Acredito que o envolvimento essencialmente operacional afunila a visão tática necessária para a gestão de uma organização tão lucrativa como as Fábricas de Software. No entanto, reafirmo que para cada contexto há uma estrutura e que a análise deve ser feita caso a caso.
Eli Rodrigues
