Mostre Progresso
Gerentes bem-intencionados não gostam de pedir atualizações de status. É constrangedor, parece chato e fica ainda pior quando precisam fazer perguntas adicionais para entender claramente o que está acontecendo.
Os gerentes prefeririam poder ver o status eles mesmos sempre que precisassem. Vimos no último capítulo como organizar as tarefas em escopos ajuda a equipe a manter o controle do trabalho. Mas isso não ajuda diretamente o gerente. Existem alguns problemas com as tarefas que as tornam insuficientes para avaliar o status.
As Tarefas que Não Estão Lá
Considere uma lista com alguns itens concluídos e nenhum item incompleto restante. Isso pode significar que todo o trabalho está concluído. Mas também pode significar que a equipe sabe que há mais trabalho a ser feito, mas ainda não definiu as tarefas.
Às vezes, uma equipe define um escopo no início do projeto sem preenchê-lo com tarefas. Isso indica que algum trabalho precisa ser feito, mas que as tarefas reais ainda não foram descobertas.
Ou pense em fazer um QA no final de um escopo. Todas as tarefas estão concluídas. Não há mais nada a fazer. Então, o ato de testar preenche o escopo com novas tarefas para os problemas encontrados.
Isso remete à noção de tarefas imaginadas versus descobertas. Em nossa noção ingênua de uma lista planejada antecipadamente, alguém a preenche com itens que são gradualmente marcados como concluídos. Na vida real, os problemas são descobertos ao se envolver no problema. Isso significa que as listas de tarefas realmente crescem à medida que a equipe avança.
Se tentássemos avaliar em t2 o quão avançado está o projeto, seríamos enganados. Do ponto de vista de um observador externo, não há como saber se o número de tarefas pendentes vai diminuir ou aumentar. Para saber isso, você precisaria de mais contexto sobre o trabalho dentro do escopo para entender o que significa que essas tarefas específicas estão concluídas e se outras ainda podem surgir.
Estimativas Não Mostram Incerteza
Algumas equipes tentam atribuir estimativas às suas tarefas ou escopos para relatar o status. O problema com as estimativas é que elas têm um significado muito diferente dependendo da natureza do trabalho sendo estimado.
Digamos que você tenha duas tarefas, ambas estimadas para levar quatro horas. Se uma tarefa é algo que a equipe já fez dez vezes no passado, você pode ter confiança na estimativa. Suponha que a outra tarefa seja algo que a equipe nunca fez antes, ou que tenha interdependências pouco claras. Ela pode levar quatro horas se tudo correr perfeitamente, mas devido às incertezas, pode se estender por dois a três dias. Não é significativo escrever "4 horas, ou talvez 3 dias" como a estimativa.
Reconhecendo isso, criamos uma maneira de ver o status do projeto sem contar tarefas e sem estimativas numéricas. Fazemos isso mudando o foco do que está feito ou não feito para o que é desconhecido e o que está resolvido. Para possibilitar essa mudança, usamos a metáfora da colina.
O Trabalho é Como uma Colina
Cada trabalho tem duas fases. Primeiro há a fase de subida, onde descobrimos qual será nossa abordagem e o que vamos fazer. Depois, uma vez que conseguimos ver todo o trabalho envolvido, vem a fase de descida, a execução.
Vamos usar um exemplo cotidiano para entender a sensação da colina.
Suponha que você está planejando dar um jantar. Você marcou a data, mas ainda faltam algumas semanas e você ainda não pensou no que vai cozinhar. Você não tem ideia de que tipo de culinária será ou qual prato fazer. Isso te coloca no início da colina, na parte inferior esquerda.
Em seguida, você pensa em quem vai participar e nota que algumas pessoas são vegetarianas. Isso elimina algumas opções (como churrasco), mas ainda deixa muitas opções abertas. Você considera tanto culinária italiana quanto indiana. Você acha que cozinhar comida indiana pode ser mais divertido, com opções vegetarianas mais interessantes. Então decide procurar receitas indianas.
Neste ponto, a pergunta “Qual é a porcentagem de conclusão do projeto?” nem faz sentido. E se alguém perguntasse quanto tempo levaria para fazer as compras e preparar, você também não poderia responder porque ainda não escolheu um prato. A resposta seria: “Fiz algum trabalho para descobrir que tipo de culinária, mas ainda não reduzi para um prato específico.” Podemos representar isso colocando você no meio da subida da colina do “descobrindo”.
Em seguida, você faz algumas buscas online e consulta seus livros de receitas. Você quer encontrar uma receita que seja interessante, mas que não exija ingredientes muito difíceis de encontrar. Você escolhe uma receita e prepara uma lista de compras.
Agora você está em uma posição muito diferente de antes. A sensação muda de “Ainda não tenho certeza do que estou fazendo” para “Agora sei o que fazer.” Você está no topo da colina.
Deste ponto de vista, você pode ver todas as etapas que restam. É até justo estimar quanto tempo todo o trabalho levará (“Vamos ver... uma hora para fazer as compras, 30 minutos de preparação, 45 minutos de cozimento...”)
No dia anterior ao jantar, você vai ao supermercado e compra os ingredientes. Isso te move para baixo na colina. Você está mais perto de terminar a tarefa.
Em seguida, vem o trabalho de preparar e cozinhar a refeição.
Depois que a refeição termina, resta apenas um pouco de trabalho: a limpeza.
Note como a colina mostra o sentimento do trabalho em diferentes estágios. A fase de subida é cheia de incertezas, desconhecidos e resolução de problemas. A fase de descida é marcada por certeza, confiança, ver tudo e saber o que fazer.
Escopos na Colina
Podemos combinar a colina com o conceito de escopos do último capítulo. Os escopos nos dão a linguagem para o projeto (“Localizar”, “Responder”) e a colina descreve o status de cada escopo (“subindo”, “descendo”).
Para ver o status dos escopos, podemos plotar cada um com uma cor diferente na colina.
Esta é uma captura de tela de um projeto para implementar eventos recorrentes no Basecamp. Aqui, “Edições aplicáveis no futuro” é um escopo que ainda está sendo trabalhado, com incertezas significativas a serem resolvidas. Os outros dois escopos não têm mais incertezas significativas e “Eventos recorrentes globais” está mais próximo de ser concluído.
Status Sem Perguntar
Criamos uma funcionalidade exclusiva do Basecamp para criar gráficos de colina e atualizá-los com alguns cliques. Os membros da equipe, que têm o contexto completo de onde o trabalho está, intuitivamente arrastam os escopos para a posição correta e salvam uma nova atualização que é registrada no projeto (veja mais em “Como Implementar o Shape Up no Basecamp”).
Para os gerentes, a capacidade de comparar estados anteriores é o recurso principal. Ele mostra não apenas onde o trabalho está, mas como o trabalho está progredindo.
Com essa visão de segunda ordem, os gerentes podem julgar o que está em movimento e o que está parado. Eles podem ver quais problemas a equipe escolheu resolver e quanto tempo passaram em cada estágio, desde o desconhecido até o conhecido e concluído.
Esse relatório se torna o primeiro destino do gerente quando ele se sente ansioso sobre um projeto. Como é de autoatendimento, não há necessidade de interromper a equipe com a pergunta constrangedora sobre o status. E nos casos em que algo não parece certo, o gerente pode entrar diretamente em uma conversa sobre a parte relevante do trabalho. “Parece que ‘Salvamento automático’ está subindo a colina há um tempo. Qual é o desconhecido que está segurando isso?” O gerente pode discutir essa parte específica do projeto sem ter que primeiro desvendar de todas as outras coisas que estão progredindo como esperado.
Ninguém Diz "Não Sei"
Ninguém quer levantar a mão para a gerência e dizer “Eu não sei como resolver esse problema.” Isso faz com que as equipes escondam incertezas e acumulem riscos. Os momentos em que alguém está empacado ou dando voltas são onde residem os maiores riscos e oportunidades. Se pegarmos esses momentos cedo, podemos resolvê-los com a ajuda de alguém mais experiente ou reformulando o conceito. Se não os pegarmos, os problemas não resolvidos podem se arrastar tanto no ciclo que colocam o projeto em risco.
O gráfico de colina permite que todos vejam que alguém pode estar empacado sem que essa pessoa precise realmente dizer isso. Um ponto que não se move é, efetivamente, uma mão levantada: “Algo pode estar errado aqui.”
Uma vez identificado, a linguagem de subida/descida facilita a conversa. É menos sobre a pessoa (“Parece que você está empacado!”) e mais sobre o trabalho. A pergunta é: O que podemos resolver para superar essa dificuldade?
Prompts para Refatorar os Escopos
Às vezes, investigar um escopo empacado revela que ele não está empacado de verdade. O problema está em como as linhas do escopo foram desenhadas.
Aqui está um caso em que o escopo "Notificar" ficou preso na colina por muito tempo.
Quando verificamos com a equipe, descobrimos que o trabalho estava avançando bem. O problema era que "Notificar" não era uma única coisa. Tinha três partes diferentes: projetar um e-mail, entregar o e-mail no back-end e exibir a notificação em um menu no aplicativo. A equipe tinha, em grande parte, concluído o código para entregar o e-mail. O design do e-mail estava quase resolvido. Mas eles ainda não haviam começado a exibição no aplicativo. Não era possível dizer se "Notificar" como um todo estava concluído porque partes dele estavam e partes não.
A solução em um caso como este é dividir o escopo em escopos menores que possam avançar independentemente.
Agora a equipe pode mover cada ponto para mostrar com precisão onde o trabalho está.
O benefício vem em um segundo nível. Com os escopos separados, eles podem avançar independentemente ao longo do tempo. Agora a equipe pode mostrar mais progresso com mais frequência do que antes.
Construa Seu Caminho Morro Acima
Algumas equipes têm dificuldade com retrocessos quando tentam o gráfico de colina pela primeira vez. Elas consideram um escopo resolvido, movem-no para o topo da colina e depois precisam deslizar de volta quando descobrem um desconhecido inesperado.
Quando isso acontece, muitas vezes é porque alguém fez o trabalho de subida com a cabeça em vez das mãos. Conceber uma abordagem em sua mente é apenas o primeiro passo da subida. Muitas vezes temos uma teoria de como resolver algo — “Vou só usar essa API” — e depois a realidade se revela mais complicada. É bom pensar no primeiro terço da subida como “Eu pensei sobre isso”, o segundo terço como “Eu validei minha abordagem” e o terço final até o topo como “Estou longe o suficiente com o que construí para acreditar que não haja outros desconhecidos.”
Resolva na Sequência Correta
Além de ver onde o trabalho está, podemos usar o gráfico de colina para sequenciar o trabalho — quais problemas resolver em qual ordem.
Alguns escopos são mais arriscados que outros. Imagine dois escopos: um envolve geocodificação de dados — algo que a equipe nunca fez antes. O outro é projetar e implementar uma notificação por e-mail. Ambos têm desconhecidos. Ambos começam na base da colina. É aqui que a equipe se pergunta: Se estivéssemos sem tempo no final do ciclo, qual desses poderíamos facilmente resolver — apesar dos desconhecidos — e qual poderia se mostrar mais difícil do que pensamos?
Isso motiva a equipe a empurrar o trabalho mais assustador colina acima primeiro. Uma vez no topo, eles o deixam lá e procuram algo criticamente importante antes de concluir o trabalho de descida. É melhor levar alguns escopos críticos ao topo cedo no projeto e deixar o aperto dos parafusos para depois.
O trabalho se expande para preencher o tempo disponível. Se a equipe começar com o modelo de e-mail primeiro, pode facilmente passar semanas iterando no texto ou criando o melhor design de e-mail de todos os tempos. Mas eles não precisam fazer isso. Existe alguma versão de um modelo de e-mail que poderia ser trabalhada em um dia durante a última semana e seria suficiente. O geocodificador, por outro lado, pode apresentar problemas novos com os quais a equipe poderia lutar por semanas. Eles não querem que essa surpresa chegue ao final do ciclo.
Os jornalistas têm um conceito chamado “pirâmide invertida.” A ideia é que seus artigos começam com a informação mais essencial no topo, depois adicionam detalhes e informações de contexto em ordem decrescente de importância. Isso permite que os designers de jornais impressos coloquem a parte crucial da história na primeira página e cortem o final conforme necessário sem perder nada essencial.
Equipes eficazes sequenciam sua resolução de problemas da mesma maneira. Elas escolhem os problemas mais importantes primeiro, com mais desconhecidos, levam-nos ao topo da colina e deixam as coisas mais rotineiras ou menos preocupantes para o final.
À medida que o final do ciclo se aproxima, as equipes devem ter terminado as coisas importantes e deixado uma variedade de “desejáveis” e “talvez” em aberto. Isso nos leva ao próximo capítulo, sobre decidir quando parar.