Recentemente, vejo muitos exemplos de como os gerentes de projetos técnicos (também conhecidos como CTO) seguem os cânones do culto ao Cargo no desenvolvimento e gerenciamento de projetos, em vez de introduzir entidades conforme necessário e desenvolver o processo com base nas necessidades atuais, recursos e habilidades disponíveis. artistas. Falaremos sobre como identificar um cultista de carga e quais os riscos que eles trazem para o projeto.
Discussões diárias da manhã (também conhecidas como Daily Standup)
À minha pergunta natural a um desses CTO - quão tangível é o benefício deste evento, o CTO respondeu honestamente - "Eu também não sei". Apesar de algumas vantagens para a equipe, parte da qual funcionou remotamente, as discussões certamente se resumiram a "Ontem escrevi código, hoje escrevo código e amanhã planejo escrever código também, mas, ainda assim, corrijo esses e outros erros". Como resultado, temos menos meia hora de cada membro da equipe. Algumas vantagens para os trabalhadores remotos é a comunicação diária com a equipe, para outras é importante. Na minha opinião, a utilidade de tais discussões diárias para o desenvolvimento é bastante pequena, pois a principal tarefa dessas reuniões gerais é trazer a todos informações sobre o status atual do desenvolvimento, planos para o futuro próximo (de uma semana a um mês), para discutir algumas questões que interessam tudo. Muitas vezes, essas discussões entram em discussões sobre alguns assuntos de nicho que são interessantes para algumas pessoas, e o restante começa a ficar entediado e esperar quando isso terminará. Isso certamente deve ser suprimido e discutido posteriormente, em um formato mais restrito. O estado atual de desenvolvimento e os planos são muito importantes, mas basta discuti-los uma vez por semana ou até menos, dependendo da velocidade com que a equipe trabalha.
Implantação na nuvem
Atualmente, estão disponíveis muitas ferramentas que permitem descrever a infraestrutura do projeto (serviços, redes, dependências) de uma forma conveniente, por exemplo, o Terraform. Isso é certamente útil, mas com um certo tamanho de projeto, por exemplo, quando se torna bastante complicado. Para a maioria das startups e pequenos projetos, essa é uma ferramenta redundante, uma vez que a infraestrutura muda extremamente raramente e é necessária a capacidade de implantar rapidamente outra produção, grosso modo, uma vez por ano, muitas startups podem simplesmente não sobreviver. Portanto, quanto mais simples o projeto for descrito - melhor, para muitos, o Docker Compose será suficiente.
Cobertura de código com testes de unidade
O entusiasmo excessivo pelos testes leva ao fato de que recursos preciosos de desenvolvimento são gastos com isso, aumenta significativamente o custo da refatoração (afinal, todos os testes afetados devem ser reescritos) e geralmente criam a ilusão de código confiável e sua operação correta. Eu conheci uma startup em que, após um ano de desenvolvimento, mais de 2000 testes foram escritos apenas para back-end! Para avançar efetivamente no desenvolvimento, os testes precisam cobrir apenas seções realmente importantes do código em que alguns cálculos são realizados e o diagnóstico manual de erros é difícil. Freqüentemente, para startups, a cobertura de teste pode ser adiada até que a estrutura do código se torne estável, e a lógica de negócios fique clara e dificilmente sofrerá alterações significativas. Para testes de unidade de front-end, eles geralmente são ineficazes, já que geralmente não existem cálculos e algoritmos complexos suficientes e é melhor cobrir a funcionalidade básica do SPA, como pressionar os botões durante a fase de teste do BlackBox por meio do Selenium ou similares.
Gerenciamento de processo de desenvolvimento
O cultista do CTO Cargo sempre usa as ferramentas e tecnologias que antes funcionavam para ele, ele leu anteriormente sobre algumas coisas legais ou foi informado sobre elas. A aplicabilidade de tudo isso nas condições atuais é difícil para ele avaliar, então ele segue claramente os cânones do culto à Carga - "afinal, um avião voou antes, então estou fazendo o certo". Convencer a CTO de que é melhor usar outras ferramentas e tecnologias para o projeto atual se torna uma tarefa árdua e não trivial, porque a CTO não está acostumada a analisar as consequências.
Gerenciamento de equipe
Há um caminho para o cultista da Cargo, e ele o segue. O fato de que o gerenciamento da equipe precisa ser construído com base no estado atual do projeto, seus requisitos, qualificações e limitações do contratante é novo para ele e ele não atribui nenhuma importância a isso, pois corre o risco de não conseguir lidar com isso. Não é fácil para ele admitir que deve haver uma atitude diferente em relação aos desenvolvedores Sênior e Médio, que existem desenvolvedores com especialidades em comunicação, abordagem de negócios e responsabilidade. Para ele, todas as peças no tabuleiro são iguais, ele faz os movimentos da mesma forma. Provavelmente, ele não ouviu sobre o fato de que é necessário identificar e usar os pontos mais fortes de cada desenvolvedor. Por causa disso, a eficiência do trabalho da equipe é significativamente reduzida, os desenvolvedores percebem isso muito bem e isso os deixa menos satisfeitos com o trabalho, geralmente é caracterizado por uma rotatividade decente. Freqüentemente, esses CTOs gostam de dizer que todos têm desenvolvedores do Fullstack, embora pessoalmente eu raramente tenha visto projetos de front-end e back-end igualmente fortes, muitas tecnologias precisam ser conhecidas em um bom nível.
Como não se tornar / não ser um cultista de carga
- Sempre adote uma abordagem crítica para a introdução de novas entidades (serviços, tecnologias). Se há pessoas em sua equipe que conhecem bem o MySQL, mas não trabalharam com o Postgres, não faz sentido escolher o Postgres se isso não lhe der vantagens significativas.
- O processo de desenvolvimento deve ser adaptado à equipe e aos negócios. Se o Vasya trabalha no Scrum e cobre tudo com testes de unidade, isso não significa que essa abordagem funcione para você também, você deve sempre avaliar e comparar criticamente com outras opções (Cachoeira). Como regra, o que funciona para uma equipe pequena deixa de funcionar para uma equipe grande e vice-versa.
- Identifique os pontos fortes dos membros da equipe e use-os ao máximo. Isso aumentará a eficiência de toda a equipe e os funcionários ficarão mais felizes, pois trazem mais benefícios por menos esforço.