No mundo das práticas ágeis, o termo “gestão de projetos” soa como algo ultrapassado, uma prática que já foi adotada no passado mas não se usa mais. Mas eu não acredito nisso. Aliás, acho que práticas de gestão de projetos poderiam ajudar e muito a conciliar uma dualidade bastante comum nas organizações: somos ágeis, mas queremos/precisamos de planejamento semestral/anual.
Eu estou no desenvolvimento de software há alguns anos e posso afirmar que, no começo da minha carreira, o termo da moda não era ágil. Era CMMI (Capability Maturity Model Integration). Ser uma empresa certificada CMMI pelo menos nível 3 era um diferencial, principalmente para empresas de consultoria de desenvolvimento de software. Eu tive a oportunidade de participar do processo de certificação Accenture SPAILA nas áreas de processo RD (Requirements Development) e REQM (Requirements Management). Tive a oportunidade de ser uma das entrevistadas. Uma experiência riquíssima e que me ensinou muitas coisas.
Atualmente, a grande maioria das empresas tech trabalham com frameworks ágeis, porém tem processos que precisam ser cumpridos. Seja por legislação, seja por ser uma empresa de capital aberto ou etc. Logo, não é possível viver a versão romantizada da agilidade em que se planeja para as próximas sprints. Muitas empresas trabalham com planejamentos semestrais/anuais ou tem um processo de priorização complexo. E daí não tem outro jeito, o termo projeto surge e vejo que muitos engineer manager sofrem para conseguir conciliar tudo isso.
O que é um projeto?
De acordo com o PMI, projeto é um esforço por um período limitado (início e fim bem definidos) que gera um resultado claramente especificado (produto/serviço/etc) com recursos/orçamento pré-estabelecidos. Logo um game é um projeto, um aplicativo é um projeto, um espetáculo de dança é um projeto, uma graduação é um projeto.
E o que um engineer manager tem haver com gestão de projetos?
Eu pesquisei vagas de engineer manager no linkedIn de várias empresas de tecnologia e encontrei algumas expectativas que apareceram em mais de uma vaga:
- Fomentar uma cultura de trabalho em equipe e melhoria contínua;
- Alinhar expectativas com stakeholders sobre missão do time;
- Atuar em parceria com o time de produto nas definições de produto/roadmap;
- Garantir que o time adota boas práticas de desenvolvimento de software;
- Estimar e planejar tarefas de engenharia antecipando riscos e dependências;
- Acompanhar métricas do time e dos sistemas;
- Acompanhar e controlar o budget do seu time;
- Remover blockers durante o processo de desenvolvimento;
- Dar visibilidade das atividades/priorizações;
- Garantir que o roadmap está “on track”;
Propositalmente, eu omiti expectativas em relação a gestão de pessoas, desenvolvimento do time, 1:1s, recrutamento para que possamos focar na gestão de projetos.
Lendo a lista acima e comparando com as expectativas sobre um gerente de projetos, consigo identificar algumas coisas em comum entre os dois papéis. Os dois:
- Gerenciam equipes;
- Gerenciam recursos;
- Gerenciam riscos;
- Gerenciam dependências;
- Tem uma grande responsabilidade em manter a comunicação clara entre os envolvidos no projeto;
- Garantem que os processos são seguidos (por exemplo a adoção de boas práticas no desenvolvimento de software);
- São responsáveis por divulgar status e métricas;
- São responsáveis por acompanhar o andamento das atividades e garantir que estejam no prazo;
Dado a todos estes itens em comum, um engineer manager terá muito mais sucesso no seu papel se tiver habilidades de gestão de projetos.
Conhecer conceitos de gerenciamento de projetos pode ajudar a evitar situações desgastantes e frustrantes
Acredito que todas as pessoas engineer managers já passaram por situações desgastantes ou frustrantes que poderiam ter sido evitadas com a aplicação das boas práticas de gerenciamento de projetos. Para quem duvida, segue alguns exemplos:
Eu não tinha entendido que esta feature não seria entregue no MVP e ela é mandatória.
Quem nunca ouviu isso de um stakeholder? E isso ocorre majoritariamente por uma comunicação ineficiente entre todos os envolvidos. Cada um tem um entendimento da situação, assume certas coisas e espera um resultado. Isso causa decepção para o time que trabalhou duro e não teve sua entrega reconhecida como de valor e para os stakeholders que não tem o produto que esperavam.
Não conseguimos fechar o contrato com o fornecedor A, não sendo possível a integração. Logo, a release vai atrasar em X semanas.
Esta é outra situação clássica para mim. Isso ocorreu porque não se tinha uma visão clara de milestones e de necessidade de recursos ao longo do desenvolvimento. Não tínhamos claro até quando o contrato deveria ter sido fechado com o fornecedor, logo isso não é comunicado. Daí na hora de integrar, descobre-se que o contrato não está fechado.
O serviço do time A não ficou pronto. Logo, teremos que paralisar o desenvolvimento até que time consiga liberar o seu serviço pois dependemos dele para efetuar a transação T.
Em muitas empresas, ainda temos estas dependências fortes entre os times. E mesmo conversando e combinando o jogo, esta situação ainda acontece. Pode acontecer uma repriorização do backlog do time A e a construção do serviço ser despriorizada. Porém, você só vai descobrir a repriorização no momento em que seu time remove o mock e pergunta sobre o serviço que deveria estar no ambiente de testes. Isso ocorre porque não é feita uma gestão de dependências.
A entrega atrasou pois teremos que adaptar a lógica do software. O time previu que utilizaríamos um certo recurso de infraestrutura, porém este recurso não está disponível pois sua alocação em produção não estava previsto no orçamento.
Normalmente, os recursos são limitados. Nesta ocasião a pessoa manager não garantiu que teria os recursos necessários durante o planejamento. A pessoa deixou o time desenvolver sem garantir que teriam os recursos necessários disponíveis gerando retrabalho e atrasos nas entregas.
Estas situações são apenas algumas do que eu já vi em todos estes meus anos de carreira, trabalhando em várias empresas diferentes. Há várias outras situações que eu poderia citar aqui, mas acredito que já consegui ilustrar como práticas de gerenciamento de projetos podem ajudar a minimizar todos estes transtornos e frustrações que desmotivam o time, impactam na relação entre time e stakeholders e, para empresas que trabalham com metas, causam o não atingimento delas.
E se podemos nos desenvolver para minimizá-las, por que não? Então, recomendo fortemente que você vá estudar para tirar o melhor do que o gerenciamento de projetos pode fazer por você e seu time no contexto da sua empresa.
anapaulamota.me 
Deixe um comentário