Como funciona a gestão de projectos no Google?

Pelo que vi, os projectos de software construídos pelas equipas de engenharia no Google são geridos principalmente pelas equipas responsáveis por eles, semana após semana. As equipes descobrem o que precisam construir, e em que ordem, para alcançar seus objetivos de médio e longo prazo. Nós rastreamos tarefas (geralmente como bugs em nossa base de dados de bugs, embora eu tenha visto equipes usando planilhas, quadros estilo kanban cobertos em notas Post-It, e por um tempo o Pivotal Tracker foi popular). Nós os riscamos (ou rasgamos o cartão de história, para equipes de Kent Beck da velha escola) quando terminamos.

Tracking de tarefas é a parte menos importante do problema.

Figurar que o que você está construindo é a coisa certa a ser construída é o aspecto mais difícil e mais importante disto: não importa quando você termina sua tarefa se no final você construiu algo que não faz o que é necessário. Diferentes pessoas na hierarquia de gerenciamento têm a responsabilidade primária por diferentes aspectos deste problema: engenheiros garantem que o que eles estão construindo se encaixa no projeto geral do sistema, gerentes de programas garantem que o sistema que está sendo construído é realmente o que é necessário, diretores garantem que o trabalho não é redundante e que ele cumpre as cartas dos seus departamentos, e assim por diante.

O fato é que o desenvolvimento de software é quase sempre exploratório. Você tem um plano, e muitas pessoas já olharam para o seu plano para ter certeza de que você está fazendo a coisa certa da maneira certa, e então enquanto você constrói a sua coisa você descobre que as coisas não funcionam da maneira que você pensou que funcionariam, por uma infinidade de razões. Portanto, há uma grande quantidade de comunicação ascendente envolvida enquanto você conta à sua gerência o que descobriu e quais são as suas implicações.

Uma das grandes vantagens de trabalhar no Google é que eu posso ir a uma reunião com o gerente do meu gerente e falar sobre um problema que descobrimos, em detalhes, e ser compreendido. Em todos os outros lugares onde trabalhei, você tinha que controlar o fluxo ascendente de informações, porque isso chegaria a alguém que não entendesse a seriedade (ou inseriedade) de cada novo problema, e que tomaria decisões terríveis como consequência. No Google, os gestores tendem a ser eles próprios engenheiros - o risco quando se traz um problema à atenção deles é mais o de começarem eles próprios a trabalhar para o resolver, o que não é o seu trabalho.

Há muita variação no que estou a descrever. Por exemplo, o Google tem o mesmo problema com projetos de grande escala que todos os outros softwares já tiveram: quanto maior é um projeto, mais difícil é controlar o escopo e os limites do trabalho, e explicar os diferentes estilos de trabalho entre diferentes grupos. Esses são problemas realmente difíceis, especialmente porque ninguém sabe o suficiente para saber qual é a maneira certa de conciliar essas questões. Em alguns casos, o melhor que você pode fazer é adivinhar.

Outro problema é a velocidade, e em particular os prazos. As equipas podem sempre andar mais depressa do que estão. Mas o que você quer é que elas andem o mais rápido que puderem sem prejudicar a si mesmas e seu produto de trabalho. Mesmo sem um prazo, é difícil saber como definir corretamente essa discagem. A equipa está a mover-se lentamente porque existem problemas técnicos? Há algum problema de moral? Eles estão fora da sua profundidade? Eles estão entediados? Estão distraídos por questões de menor prioridade? A resposta a todas estas perguntas é sempre "sim"; o que não se sabe é quanto, o que se pode fazer para corrigir isso, e se se deve.

Também, é difícil medir a velocidade. A que velocidade a equipa está realmente a ir? Como você pode saber? Temos algumas metodologias internas que são muito boas nisto, para alguns tipos de equipas e alguns tipos de projectos. Também temos equipas que jogam poker de planeamento durante algum tempo e depois dizem o que não interessa, vamos apenas fazer as nossas coisas.

Quando se tem um prazo, as coisas ficam mais complicadas, porque a única forma de se conseguir fazer software num prazo é aceitando restrições. Nós o faremos até lá, mas ele não fará tudo o que você quer. Ou não estará à altura do nível de qualidade com que os utilizadores ficarão satisfeitos. Ou nós vamos queimar os membros da equipe e eles vão se mudar para outros projetos ou desistir.

Deadlines também significa que não só o produto da equipe estará sujeito a restrições, o fato de que temos que gastar tanto do nosso tempo trabalhando na definição dessas restrições significa que teremos ainda mais restrições, porque o tempo que estamos gastando na negociação de um novo conjunto de funcionalidades é tempo que não estamos gastando na construção de funcionalidades. Também não estaremos prontos quando terminarmos, porque precisaremos continuar fornecendo recursos bem depois do lançamento. ("Nós dissemos que lançaríamos no Q2, e fizemos. Lançamos em junho de 73")

Isso tudo parece muito vago, e não é nada parecido com um processo. Mas está realmente de acordo com os princípios gerais de gerenciamento de projetos de software. Nada no Guia de Sobrevivência de Projetos de Software do Steve McConnell está fora de lugar no Google, exceto que seu modelo assume que a gerência sênior não entende de desenvolvimento de software.

Relativamente ao que tenho observado no resto da indústria, os projetos de software do Google falham a um ritmo muito menor. Ou melhor, eles falham cedo, antes que o fracasso se torne doloroso e caro. Dois de nós passam uma semana planejando um projeto, construindo um protótipo, e fazendo algumas contas, e descobrimos, "Isso não vai funcionar", e enquanto em um nível esse projeto falhou, em outro é um grande sucesso, porque dez de nós não gastamos um quarto fazendo a coisa que não funciona.

Eu deveria dizer, essa abordagem muitas vezes não funciona tão bem quanto as pessoas gostariam que funcionasse.

As maiores "falhas" de software do Google são sucessos incompletos, projetos construídos por grandes equipes que conseguem atravessar a linha de chegada e depois têm que ser desfeitos e reconstruídos porque seu design não estava certo, ou porque o conjunto de recursos não corresponde aos requisitos reais, ou porque o mundo mudou durante os dezoito meses em que a equipe estava trabalhando em sua coisa. Há equipes no Google que são designadas para espaços com problemas críticos de negócios que são tão feios e espinhosos que, mesmo quando são bem sucedidos, parecem ter feito tudo errado. Isso é realmente doloroso (especialmente porque essas equipes provavelmente também estavam trabalhando dentro dos prazos, com todos os problemas que eu descrevi acima). Mas às vezes também é um resultado inevitável. Você olha a postmortem em projetos como este e pergunta "onde eles erraram?" e é realmente difícil ver como poderia ter sido diferente.