- Resultado de uma pesquisa com mais de 100 empresas de big tech
- Ao resumir a forma como a big tech gerencia projetos ⇨ "depende do contexto (It Depends)"
- Na maioria dos casos, não existe uma metodologia ou forma de trabalho fixa, e cada equipe escolhe o que melhor se adapta a ela
- Empresas de capital aberto ou que receberam investimento demonstraram baixa satisfação com a presença de PMs dedicados, enquanto empresas sem investimento apresentaram alta satisfação
- A autonomia da equipe e o nível de satisfação têm alta correlação
- Mesmo em equipes com problemas, a causa geralmente não era a metodologia, mas sim a incapacidade de comunicar bem a visão, falta de transparência ou deficiência de ferramentas
- O JIRA recebeu respostas majoritariamente negativas
- Formas de gerenciamento de projetos que não funcionaram bem
- Os engenheiros não participam da estimativa do prazo do projeto
- Os requisitos mudam mesmo havendo um PM dedicado
- Equipes sem autonomia para mudar uma abordagem de gestão de projetos que falhou registraram baixa satisfação
- Como a big tech conduz projetos
- Os engenheiros lideram a maioria dos projetos
- Não há uma metodologia fixa, e a equipe pode escolher livremente
- Em projetos no nível de equipe, não há um Project Manager dedicado. Em projetos grandes, com várias equipes ou toda a empresa envolvida, há um Technical Program Manager. No caso da Uber, a proporção é de cerca de 1:50
- Ferramentas de desenvolvimento de primeira linha são oferecidas, e isso tem grande impacto em ciclos curtos de iteração
Estruturas organizacionais da big tech que impactam projetos
- Ambiente básico
- Engenheiros e equipes têm autonomia
- Não são recursos inconscientes (operários de fábrica), mas solucionadores de problemas curiosos
- Dados, código e documentação internos são compartilhados com transparência
- Os engenheiros também têm exposição ao negócio e às métricas de negócio
- Em vez de comunicação hierárquica, a comunicação engenheiro-a-engenheiro acelera o trabalho
- Investimento em uma experiência de desenvolvimento menos frustrante
- Salários mais altos, justificados por maior alavancagem
- Capacidade de contratar talentos melhores
- Equipes autônomas e empoderadas
- Equipes com responsabilidade claramente definida
Product Manager sim, Project Manager não
- O papel do Product Manager é entender "What game we're playing" e "How we're going to play it"
- Em muitos casos, os Product Managers de empresas de big tech não fazem Project Management
- A equipe é responsável pela execução, e na maioria das vezes um gerente técnico (líder de equipe) é responsável por conduzir o gerenciamento do projeto
- Em equipes autônomas e empoderadas, é raro que a gestão do projeto aconteça de cima para baixo ⇨ todos fazem juntos
- Dúvidas comuns quando não há um Project Manager dedicado
- Projetos no nível de equipe: simplificar o processo e fortalecer as relações interpessoais
- Projetos complexos: a big tech conta com Technical Program Managers (TPMs)
- Program Managers / Project Managers dedicados de fato existem. Em geral, estão ligados a relações externas, clientes e planejamento de execução de longo prazo
- Ambientes centrados em produto e por que não usam Scrum
- O Scrum executado em sprints não combina bem com cenários em que se faz deploy rapidamente
- Infraestrutura e ferramentas de desenvolvimento substituem muitas atividades do Scrum
- As empresas de big tech perceberam que investir em infraestrutura e ferramentas para desenvolvedores gera ganhos de produtividade
- Facebook, Google e Netflix não usam Scrum. Por quê?
- Pessoas competentes e autônomas precisam menos desse tipo de estrutura
- Quando se dá liberdade para uma equipe competente decidir como operar, é possível alavancar melhor seu potencial
- Escalar uma organização de engenharia vai muito além dos processos no nível da equipe
- Ainda assim, seria um erro simplesmente imitar a big tech e não usar Scrum
→ Há situações em que usar Scrum faz sentido e pode gerar maior produtividade
- Equipe "kitchen sink": quando um único time precisa resolver tudo (startup em estágio inicial)
- No momento de formar uma nova equipe
- Quando os deploys acontecem uma vez a cada algumas semanas
- Quando é obrigatório fazer relatórios padronizados de andamento do projeto
Como devemos operar equipes?
- Mudanças iterativas são sempre melhores do que mudanças de "big bang"
- É mais difícil ensinar alguém a pescar do que simplesmente dar o peixe
- Direcionamento, mentoria e coaching têm cada um seu uso
- Direcionamento é dar suporte de forma complementar com microgerenciamento apenas quando a pessoa conseguiria fazer sozinha, mas não consegue naquele momento
- Quanto menos pessoas forem necessárias para tomar uma decisão, mais rápido será possível decidir
- Otimizar para prestação de contas é otimizar para um ambiente de menor confiança
- Consultores tendem a priorizar resultados fáceis de medir, porque essa é a forma mais simples de provar seu valor
- Aprender com concorrentes diretos é algo subestimado
- Alguns dos melhores engenheiros preferem pedir demissão a serem microgerenciados
8 comentários
"A maioria das respostas sobre o JIRA foi negativa"
Acho que é necessário gerenciar issues em algum formato, e eu também tinha uma visão negativa do JIRA, então tentei de propósito outras ferramentas (
github issues, trello, asana etc.).Mas, no fim, o clássico acaba sendo o melhor, e acabei voltando para o JIRA...
Ainda assim, continuo pensando se não existe uma forma melhor.
Em que aspecto você achou que o velho conhecido é melhor?
Eu gosto do YouTrack. É uma ferramenta de PM criada pela JetBrains, e vi que dá para gerenciar projetos no tanto que eu preciso.
Nossa equipe migrou para o Linear, e no geral o nível de satisfação aumentou bastante. Recomendo dar uma olhada.
Parece que é este produto, https://linear.app/. Parece interessante.
As vantagens que eu sinto são
É mais ou menos assim que eu vejo.
O que fazem as ferramentas de desenvolvimento de primeira linha?
Trouxe assim mesmo para preservar a sensação do texto original.
No momento, acho que dá para considerar que estas são as melhores ferramentas de desenvolvimento que uma organização pode oferecer.