Responsabilidade do Repasse de Trabalho #

Fizemos nossas apostas e agora é hora de começar o próximo ciclo. Como o time começa?

Atribua Projetos, Não Tarefas #

Nós não começamos atribuindo tarefas a ninguém. Ninguém desempenha o papel de "encarregado das tarefas" ou "arquiteto" que divide o projeto em partes para outras pessoas executarem.

Dividir o projeto em tarefas logo no início é como passar o pitch por um triturador de papel. Todos recebem apenas pedaços desconectados. Queremos que o projeto permaneça “inteiro” durante todo o processo para que nunca percamos de vista o panorama geral.

Em vez disso, confiamos na equipe para assumir o projeto inteiro e trabalhar dentro dos limites do pitch. A equipe vai definir suas próprias tarefas e sua própria abordagem para o trabalho. Eles terão total autonomia e usarão seu julgamento para executar o pitch da melhor maneira possível.

As equipes adoram receber mais liberdade para implementar uma ideia da maneira que acham melhor. Pessoas talentosas não gostam de ser tratadas como “apertadores de parafuso” ou apenas executores de tarefas.

Os projetos também saem melhores quando a equipe é responsável por cuidar do todo. Ninguém pode prever no início de um projeto o que exatamente precisará ser feito para que todas as peças se encaixem corretamente. O que funciona no papel quase nunca funciona exatamente como foi projetado na prática. Os designers e programadores que estão fazendo o trabalho real estão na melhor posição para fazer mudanças e ajustes ou identificar peças que faltam.

Quando as equipes são designadas a tarefas individuais, cada pessoa pode executar sua pequena parte sem se sentir responsável por julgar como todas as peças se encaixam. Planejar tudo antecipadamente faz você ficar cego para a realidade ao longo do caminho.

Lembre-se: não estamos dando às equipes liberdade absoluta para inventar uma solução do zero. Fizemos a modelagem. Definimos os limites. Agora vamos confiar na equipe para preencher o esboço do pitch com decisões reais de design e implementação.

É aqui que nossos esforços para definir o projeto no nível certo de abstração — sem muitos detalhes — serão recompensados. Com seu talento e conhecimento dos detalhes, a equipe chegará a um produto final melhor do que poderíamos ter conseguido tentando determinar a forma final com antecedência.

Concluído Só Depois do Deploy #

No final do ciclo, a equipe implementará seu trabalho. No caso de uma equipe de Pequeno Porte com alguns pequenos projetos para o ciclo, eles farão os deploys cada um conforme considerarem apropriado, desde que isso aconteça antes do final do ciclo.

Essa restrição nos mantém fiéis às nossas apostas e respeita o circuit breaker. O projeto precisa ser concluído dentro do tempo que orçamos; caso contrário, nosso apetite e orçamento não significam nada.

Isso também significa que qualquer teste e QA precisam acontecer dentro do ciclo. A equipe acomodará isso delimitando os aspectos mais essenciais do projeto, terminando-os cedo e coordenando com o QA. (Falaremos mais sobre isso depois.)

Para a maioria dos projetos, não somos rígidos quanto ao cronograma da documentação de ajuda, atualizações de marketing ou anúncios aos clientes e não esperamos que esses itens aconteçam dentro do ciclo. Esses itens têm um risco de "cauda fina" (nunca demoram 5x mais do que pensamos) e são, na maioria das vezes, tratados por outras equipes. Muitas vezes, cuidamos dessas atualizações e publicamos um anúncio sobre o novo recurso durante o cool-down após o ciclo.

Kick-off #

Começamos o projeto criando um novo projeto no Basecamp e adicionando a equipe a ele. Em seguida, a primeira coisa que faremos é postar o conceito modelado no Quadro de Mensagens. Postamos o pitch original ou uma versão condensada dele.

A primeira coisa no projeto Basecamp é uma mensagem com o conceito modelado

Como nossas equipes são remotas, usamos a sala de chat no projeto Basecamp para organizar uma chamada de início projeto.

Organizando uma chamada com a equipe para revisar o trabalho modelado

A chamada dá à equipe a chance de fazer quaisquer perguntas importantes que não estejam claras na descrição escrita. Então, com uma compreensão geral do projeto, eles estão prontos para começar.

Orientação Inicial #

Nos primeiros dias de trabalho, o trabalho não parece “trabalho”. Ninguém está marcando tarefas como concluídas. Nada está sendo implementado. Não há entregáveis para ver. Muitas vezes, nem há muita comunicação entre a equipe nos primeiros dias. Pode haver um tipo estranho de silêncio no ar.

Por quê? Porque cada pessoa está concentrada tentando descobrir como o sistema existente funciona e qual o melhor ponto de partida. Todos estão ocupados mapeando o terreno e se orientando.

A equipe descobrindo onde começar

É importante que os gerentes respeitem essa fase. As equipes não podem simplesmente mergulhar em uma base de código e começar a construir novas funcionalidades imediatamente. Eles precisam se familiarizar com o código relevante, pensar no pitch e explorar alguns becos sem saída curtos para encontrar um ponto de partida. Interferir ou pedir status muito cedo prejudica o projeto. Isso tira o tempo que a equipe precisa para encontrar a melhor abordagem. A exploração precisa acontecer de qualquer maneira. Pedir por progresso visível só vai empurrá-lo para debaixo do tapete. É melhor capacitar a equipe para dizer explicitamente "Ainda estou descobrindo como começar" para que eles não precisem esconder ou disfarçar esse trabalho legítimo.

De modo geral, se o silêncio não começar a se quebrar após três dias, esse é um momento razoável para intervir e ver o que está acontecendo.

Tarefas Imaginadas vs Descobertas #

Como a equipe recebeu o projeto e não as tarefas, eles precisam criar as tarefas por conta própria. Aqui, notamos uma diferença importante entre as tarefas que achamos que precisamos fazer no início de um projeto e as tarefas que descobrimos que precisamos fazer no decorrer do trabalho real.

A equipe naturalmente começa com algumas tarefas imaginadas— aquelas que eles presumem que terão que fazer apenas pensando sobre o problema. Então, à medida que colocam a mão na massa, descobrem todos os tipos de outras coisas que não sabíamos com antecedência. Esses detalhes inesperados compõem a verdadeira maior parte do projeto e, às vezes, apresentam os maiores desafios.

As equipes descobrem tarefas fazendo trabalho real. Por exemplo, o designer adiciona um novo botão na interface de desktop, mas percebe que não há um lugar óbvio para ele na versão mobile. Eles registram uma nova tarefa: descobrir como revelar o botão no celular. Ou a primeira versão do design tem uma boa hierarquia visual, mas então o designer percebe que precisa de mais texto explicativo em um lugar que desorganiza o layout. Duas novas tarefas: Mudar o layout para acomodar o texto explicativo; escrever o texto explicativo.

Muitas vezes, uma tarefa aparecerá no processo de fazer algo não relacionado. Suponha que uma programadora esteja trabalhando em uma migração de banco de dados. Ao olhar para o modelo para entender as associações, ela pode encontrar um método que precisa ser atualizado para uma parte diferente do projeto mais tarde. Ela vai querer anotar uma tarefa para atualizar esse método depois.

A maneira de realmente descobrir o que precisa ser feito é começar a fazer o trabalho real. Isso não significa que as equipes começam construindo qualquer coisa. Elas precisam escolher algo significativo para construir primeiro. Algo que seja central para o projeto e, ao mesmo tempo, pequeno o suficiente para ser concluído de ponta a ponta—com UI funcional e código funcional—em alguns dias.

Nos próximos capítulos, veremos como a equipe escolhe esse alvo e trabalha junta para conseguir um protótipo totalmente integrado funcionando.