A gestão pode salvar ou acabar com um projeto. Esse guia é um compilado da minha experiência em projetos que falharam, deram mais certo que o esperado e muitos que ficaram na média.
Nenhum dos princípios é obrigatório. Você não precisa usar e nem mesmo concordar com nenhum deles.
Lembre-se: no final das contas, projetos são feitos de pessoas. Nenhum software, cerimonia ou metodologia vai funcionar se as pessoas não se comprometerem com o projeto e se esforçarem para dar certo.
Gerencie os riscos
Boa parte da gestão é sair do caminho da equipe, remover qualquer problema que possam ter e mante-los no caminho. Analisar os possiveis riscos e estar preparado pode evitar muita dor de cabeça. Os riscos podem ser de todos os tipos: problemas tecnicos com pc, internet, energia, etc.; problemas de saúde e disponibilidade; problemas de comunicação; e até um risco de gestão, no caso, por exemplo, de um projeto arriscado, é importantissimo que os stakeholders estejam bem informados, ou um projeto promissor pode morrer antes de vingar.
Evite desperdícios
Tudo que acontece no projeto ou com o projeto, deve ter um objetivo claro e uma razão para existir/acontecer. Desperdiçar tempo, atenção ou recursos é um dos maiores motivos de projetos explodirem o orçamento. Isso inclui cerimônias agile (será que fazelas realmente te deixa mais “ágil”?) e reuniões. As reuniões devem partir, na maioria, da própria equipe, garantindo que o assunto seja importante para o projeto.
Cuidado tambem com o desperdício de prioridades: priorizar tudo, ou as coisas erradas, pode trazer um atraso muito grande ao que realmente interessa no projeto.
Reavalie o caminho (PDCA)
O mundo dos negócios e de TI mudam com uma frequência muito alta. Manter o projeto na direção certa é obrigatório. E essa direção pode mudar a qualquer momento. Nada pior do que fazer certo a coisa errada. Reavaliar manter, também, o foco no objetivo do projeto, que pode ajudar a evitar desperdícios e “perfumarias”.
Estime só o necessário
Estimativas são grandes ferramentas. Grande parte das decisões, inclusive a de se um projeto vale a pena ser produzido ou não, pode ser feita através de estimativas. Dito isso, estimar toma tempo e custa caro. Estime apenas onde for necessário. Estimativas devem ajudar em uma decisão, caso contrário, não faça.
Estimativas podem, também, ser confundidas com compromissos. E como sabemos, tudo pode acontecer no decorrer de um projeto. Estimativas não são mais que palpites, muitas vezes com pouca informação sobre o assunto, é muito facil erra-las. Mas, apesar de serem apenas projeções, quando feitas, faça o máximo para cumpri-las.
Adie as decisões
Diferente de estimativas, decisões são, sim, compromissos. Toda decisão precisa de informações para ser tomada. Deixar para o último momento possível pode garantir um maior volume de informações para uma decisão mais acertada. Tente decidir qual tenis comprar: o A ou o B. Se você é como eu, não conseguirá comprar sem ao menos ver, e quando possível, experimentar. Decidir sem informação é um tiro no escuro. A probabilidade de errar é muito grande.
Tome decisões
Poucas decisões são irreversíveis. Tomar uma decisão é fazer progresso. Hoje em dia, com tantas opções, pode ser muito dificil escolher. Usar javascript ou golang? Microserviços ou monolito? Isso pode levar a algo chamado “analysis paralysis”, que é quando, com tantas opções, não conseguimos escolher. Não deixe que uma indecisão pare o projeto. Não escreva uma monografia antes de escolher, tome decisões e siga em frente. Se no futuro, algo for provadamente inadequado, mude! E na dúvida, vá com o mais simples.
Documente
“Porque sempre foi feito assim.” não é resposta para a pergunta: por que fazemos assim?. Documentar garante que nós de amanhã saberemos o porque nós de hoje fazemos o que e como fazemos as coisas.
No manifesto agil, a frase “Software em funcionamento mais que documentação abrangente” tem dois pontos importantes:
- “mais que”: não significa faça apenas um, e sim, quando tiver que escolher, escolha do primeiro, mas nao ignore o segundo.
- Documentação abrangente: em nenhum lugar é dito para nao escrever documentação, apenas prefira uma não abrangente;
Algumas opções interessantes são: ADRs, padrões de commit (conventionalcommits), architecture.md e até mesmo guias de uso para usuários de alto nível.
Dê autonomia
Não permita que sua equipe seja formada de crianças. Deixe que eles tomem decisões, façam do seu jeito e vivam com as consequências. Gerir o projeto não é ser onipresente e onisciente. Microgerenciamento mina a motivação e o controle da equipe, toma todo o seu tempo (que provavelmente você não tem sobrando) e acaba por criar os incentivos errados.
Incentive a comunicação
Uma equipe deve funcionar como uma unidade. Ou todos remam no mesmo ritmo, ou ninguem sai do lugar. Mantenha um canal sempre aberto, faça com que as pessoas se comuniquem. Deixe que todos saibam de tudo a todo tempo. Só com informação é possivel fazer com que a equipe funcione a 100%, especialmente quando em homeoffice.
Comunicação não é só chat e emails. Pode tomar varias formas. Code reviews, RFCs, e até os commits no repositório. O importante é que as informações necessárias sejam expressadas nesses meios, de maneira clara, permitindo que todos os envolvidos tenham conhecimento do que acontece no projeto.
