Como não gerir um projecto de software

Por Luís Soares para o Pplware

A gestão de projectos não é uma ciência exacta, muito menos a de projectos de software. Em engenharia de software, existe alguma incerteza nas metodologias, nas estimativas, nas representações, entre outros. Um programador não é um robô (tal como um designer).

Ao contrário do que se passa noutras engenharias, é muito fácil falhar, porque não existe uma “receita” de como fazer as coisas bem. Sendo uma pessoa por si só complexa, um conjunto de pessoas e as suas dinâmicas podem ser muito mais.

É necessário perceber o que costuma falhar quando os projectos derrapam no tempo e nos custos associados. É importante que um gestor “dê dois passos atrás” e tente perceber os padrões emergidos ao longo do tempo. Existem diversas técnicas que podem ser usadas para o efeito (ex: 5 whys, análise de casos de insucesso).

Aqui, tentarei sintetizar o que tenho observado ao longo da minha carreira.

Desenvolvimento de software vs. produção em massa

Uma das principais falhas que identifico são modelos de gestão inadequados e desatualizados; muitos gestores de hoje acham que estão a gerir uma fábrica ou linha de montagem, quando na realidade a criação de software não é um processo mecânico e envolve muita criatividade e inspiração.

Charlie Chaplin - Modern Times

Um programador não é um robô; o processo de programação envolve iterações, otimizações e colaboração. Pode, por vezes, ter semelhanças com a arte: envolve inspiração (variável), tem cunho pessoal e não há uma receita para se programar bem, pelo que o algoritmo/programa ideal é o culminar de algo e não uma tarefa sistematizável.

Tal como com artistas ou designers, colocar pressão nos programadores para trabalhar mais rápido e mais horas, só traz resultados a curto prazo. A médio/longo prazo, a qualidade do produto é comprometida e a motivação dos programadores afetada (ambos de muito difícil retorno). O gestor que não perceba isto talvez esteja no ramo errado.

Imposição de metodologias

Outro problema comum é a inflexibilidade. Há gestores que consideram que modelos de gestão usados com sucesso em alguns projetos podem-se aplicar indefinida e indiscriminadamente noutros. Mesmo o Scrum, uma metodologia na moda, ágil e pragmática, não é a solução para tudo. Por outro lado, alguns gestores gostam de impor o uso de ferramentas que muitas vezes são inadequadas ou desnecessárias (ex: de imputação de horas); é sempre preferível que seja a equipa a decidir aquilo que mais valor traz ao projeto e à empresa.

O uso incorreto de metodologias pode ter um grande impacto, podendo mudar drasticamente o decorrer do projeto. Por exemplo, a maioria dos gestores/chefes desvaloriza ou desconhece por completo técnicas como a análise de tarefas, prototipagem em papel, pair programming ou o valor das iterações no desenvolvimento.

Transparência

Outra questão importante é a comunicação. Os gestores devem comunicar com a equipa informando sobre o negócio, objetivos, enquadramento, próximos passos, datas, parceiros, etc. Nenhum programador gosta de ser “um simples executante” sem voto na matéria ou sem poder questionar. A maioria dos programadores gosta de fazer uso do seu espírito crítico. A causa por detrás de um pedido alimenta a motivação do programador em implementá-lo.

Pouco ou nada deve ser escondido da equipa. Só na posse de todos os dados do projeto é que os programadores podem dar o seu melhor (ex: se um programador souber que algo se pode complicar, pode preparar o código para tal). Pela mesma razão, é nocivo afastar muito os programadores do negócio, do cliente e principalmente dos utilizadores.

Tratar de todo um processo e só depois dar à equipa para implementar é demonstrar falta de confiança nas suas capacidades. Por outras palavras, separar o levantamento e análise de requisitos de quem os vai implementar é nocivo para a motivação da equipa e consequentemente para o desenvolvimento do projeto. Análise e implementação devem estar de mãos dadas.

A bottom line é que todos estão a lutar pelo mesmo fim: o sucesso do projeto/empresa, pelo que todos devem partilhar da mesma informação.

Imposição de tecnologias

Um dos pontos mais graves na gestão de projetos talvez seja quando se impõe a utilização de certas tecnologias. Ou porque o gestor já usou e gostou, ou porque leu num blogue, por capricho, ou porque um amigo lhe contou... Pior ainda, é quando o faz antes sequer dos requisitos serem analisados. As tecnologias usadas devem emanar das necessidades e devem ser decididas pela equipa, isto é, devem ser consequência de uma necessidade e não o oposto.

Na verdade, impor seja o que for só pode resultar em desmotivação das equipas. Mesmo que a tecnologia faça todo o sentido, há que “conquistar as pessoas” através da justificação e não da imposição.

Dimensionamento

Outro problema grave que costuma ocorrer no fim do projeto é quando, em desespero de causa, os gestores (que mal conhecem a equipa) começam a adicionar mais elementos, convictos que isso vai acelerar a conclusão do projeto. A história clássica que ilustra esta situação é a de que 9 mulheres não têm um filho num mês…

A integração de um novo elemento exige tempo e esforço extra da equipa inicial e faz com que o processo se atrase, para além de que a própria pessoa tem um período de ramp up em que a produtividade é relativamente baixa. Por isso, o crescimento de uma equipa deve ser gradual e sustentado. Novos elementos devem ser adicionados previamente e devidamente guiados, mas para isso é necessário uma boa capacidade de antevisão e conhecimento das capacidades das pessoas.

Outro problema é quando os gestores acham benéfico espalhar um projeto por múltiplos locais do mundo, acreditando que isso vai acelerar o processo ou “criar sinergias”. Na realidade, está-se a lidar com culturas e timezones diferentes, o que só pode piorar as coisas. É impossível trabalhar dessa forma a não ser que estejamos a falar de um projeto em fase de manutenção e com componentes bem separados e de fronteiras bem definidas.

Proximidade da equipa

Pessoalmente sempre defendi um modelo de gestão mais informal, em que o chefe é um líder e não um chefe clássico. Um líder não dá ordens; um líder comanda a direção e velocidade do “barco” e evita os obstáculos. Idealmente, o chefe deve ser parte integrante da equipa, metendo as “mãos na massa” de vez em quando ou em alocação reduzida. Na realidade, isto tem consequências benéficas como:

• Criar um espírito de equipa mais coeso pela partilha dos problemas e dos sucessos
• Saber, em tempo real, o estado corrente do projeto
• Imbuir autonomia e poder de decisão no seio da equipa
• Conhecer melhor os elementos da equipa (ex: problemas)

(O Scrum leva isto mais longe dizendo que não há chefes de equipa: todos o são e ninguém é; a equipa é responsável por analisar, atribuir prioridades e implementar.)

É verdade que a gestão de projetos é uma disciplina por si só, aplicável a qualquer domínio. No entanto, sou cético no que toca a gestores “genéricos” sem formação/experiência em software, que consigam levar tal tipo de projeto a bom porto. O chefe, ou melhor, o líder, deve emergir naturalmente, quando isso é possível. Mais importante que saber mexer no MS Project é ter empatia: perceber as pessoas e ter sensibilidade para as suas potencialidades, preocupações e aspirações.

Qualquer programador se incomoda (e desmotiva) com estimativas infundadas do estilo «isso são 5 minutos», «está tudo feito» ou «são 5-10 linhas de código», mostrando total desconhecimento das tecnologias/projeto e desrespeitando a equipa e o seu trabalho.

Gestores que só falam em termos genéricos, buzzwords para impressionar e frases sem conteúdo (mumbo jumbo), estão distanciados da realidade da equipa e pouco podem ajudar (podem é prejudicar). Um gestor deve conhecer a equipa e só estando perto da mesma a pode proteger e apoiar. Gestores e chefes isolados em gabinetes pertencem ao passado.

David Brent - The Office