O Mítico Homem-Mês Mítico

Como líder de produto em uma empresa de tecnologia, sou um poço sem fundo de necessidades. Meu trabalho como Chief Product Officer da Mailchimp é levar ao mercado o produto que vai vencer em um espaço muito competitivo. As aspirações da Mailchimp são altas e, para realizá-las, precisamos entregar uma quantidade substancial de produtos ao mercado. Muitas vezes, para muitos na empresa, parece que estamos fazendo demais. Estamos sempre no limite das rodas saindo.

E quando você está fazendo muito e decide fazer mais do que isso, inevitavelmente começará a ouvir The Mythical Man-Month referenciado. É como uma daquelas bolas de alívio do estresse em que, se você apertar uma extremidade, sai o Mythical Man-Month na outra extremidade.

Publicado por Frederick Brooks em 1975 (você se lembra de 1975, certo? Quando o desenvolvimento de software se parecia 100% com o desenvolvimento de software em 2020?), este livro é bastante famoso entre os engenheiros de software. Especificamente, há um ponto em todo o livro que é famoso (não estou convencido de que as pessoas leiam nada além deste ponto, se leram o livro):

“...adicionar mais homens alonga, não encurta, o cronograma.”

Fácil correção. Vou apenas contratar mulheres para projetos de agora em diante (veja O Retorno do Rei e a luta contra o Rei Bruxo de Angmar).

Mas vamos supor que o ponto de Brooks seja válido independentemente da identificação de gênero dos engenheiros de software em questão. Aqui está o ponto: o software é difícil de construir com muitas interdependências complexas. E todos precisam trabalhar juntos para conseguir isso.

À medida que adiciono pessoas a uma equipe, elas precisam ser integradas e enxertadas no projeto. Alguém tem que conseguir o trabalho certo para eles. A equipe precisa se comunicar para garantir que tudo funcione em conjunto, e cada pessoa adicional aumenta a complexidade da comunicação geometricamente. E, em algum momento, adicionar pessoas se torna um fardo para o projeto – não um benefício.

Aqui está o gráfico do livro que ilustra esse ponto:

Este é um ponto absolutamente justo. É por isso que eu ouço tanto no trabalho. Colaboradores individuais exaustos e líderes exaustos vão jogar fora – não podemos ir mais rápido, não podemos fazer mais, parar a contratação, ler The Mythical Man-Month e se desesperar! A única solução aparentemente é parar de crescer e matar alguns projetos.

Quando eu, como CPO, digo: “vamos fazer isso!” a resposta é muitas vezes: “OK, então o que vamos matar?” O Mythical Man-Month transforma o desenvolvimento de produtos em um jogo de soma zero. Se queremos uma coisa, devemos impedir outra. Agora, isso é um mito real, e eu chamo de besteira.

E levado à sua conclusão patologicamente mal interpretada (chegaremos a isso), o livro aparentemente diz que a empresa de tecnologia mais rápida é aquela que emprega quatro pessoas – quatro homens , aparentemente. Qualquer coisa mais apenas retarda tudo. Alguém deveria enviar cópias do livro para Amazon, Apple e Google, para que possam consertar suas organizações obviamente inchadas.

O único problema com essa abordagem é que, em um espaço onde a concorrência está crescendo, iterando e executando – meramente controlando o crescimento organizacional – editar e focar a carga de trabalho para corresponder pode ser uma receita para a extinção. Você ficará mais são e menos estressado – até ficar desempregado.

E como proprietário do gerenciamento de produtos da minha empresa, não sou antipático com essa necessidade de desacelerar e focar. Devemos priorizar implacavelmente! Sem dúvida. Mas administrar um produto é um exercício de contradição. Devo priorizar o que tenho enquanto simultaneamente planejo fazer mais. Mas o que devo fazer diante do Místico Homem-Mês ?

Surpreendentemente, a resposta a esta pergunta vem do mesmo livro de Brooks. Aqui está outro gráfico no mesmo capítulo:

Há uma batalha no desenvolvimento de produtos em escala. Se o trabalho que você está tentando realizar for puramente particionável, vá em frente e adicione pessoas! Se o seu trabalho está todo conectado, então, em algum momento, adicionar pessoas é simplesmente errado.

Se alguém diz que eu absolutamente tenho que matar um projeto para começar outro, esse não é o caso. Se os dois projetos exigirem muito pouca comunicação e coordenação, podemos escalar.

É por isso que adicionar núcleos a uma CPU pode aumentar a velocidade do seu computador ou telefone até certo ponto - algo que os engenheiros devem saber. Claro, adicionar núcleos não me ajudará a concluir uma computação complexa de thread único. Mas pode me ajudar a executar várias tarefas independentes .

O conflito para um executivo de produto entre dimensionamento e priorização implacável pode ser gerenciado.

1. Você prioriza implacavelmente em locais que são de thread único (o backlog de uma equipe de produto, digamos).
2. Você dimensiona adicionando mais núcleos para lidar com o trabalho independente.

Muito raramente, no entanto, algo é totalmente independente de tudo o mais em uma empresa. No mínimo, sua empresa centralizará as funções de suporte (TI global, jurídica, RH, etc.) levando a gargalos.

É tudo sobre gerenciamento de dependências

O trabalho de um executivo de produto torna-se então não apenas criar uma estratégia, mas executar de uma maneira que maximize o valor para o cliente e o negócio, garantindo o rendimento e reduzindo o risco de interdependência o máximo possível. “Tanto quanto possível” sendo a chave aqui. Dessa forma, você pode fazer com que a empresa se pareça tanto com o último gráfico quanto com o primeiro. A interdependência é uma doença sem cura , mas seus sintomas podem ser controlados com muitos tratamentos.

Uma solução é montar uma direção estratégica para a empresa que minimize ou limite a dependência por meio de um portfólio de iniciativas cuidadosamente selecionado. O engraçado aqui é que muitas pessoas vão recuar sobre isso. Digamos que eu tenha duas opções, uma onde eu possa executar projetos A, B e C que têm muito pouca coordenação (digamos que eles impactam produtos diferentes ), e outra opção com projetos D1, D2 e ​​D3 que têm toneladas de interdependências ( digamos que todos impactam o mesmo produto). Muitas vezes, o Mês-Homem Mítico será invocado contra o plano anterior e não contra o último. Porque no papel parece mais .

Na verdade, é menos “focado”. Mas, na verdade, é menos difícil do ponto de vista da dependência e, portanto, é melhor com pessoal adicional.

Tenha em mente que não estou dizendo para escolher um monte de trabalho para a empresa que não está relacionado. Mailchimp não construirá um forno de micro-ondas tão cedo. Todo o trabalho deve seguir na mesma direção de longo prazo. Essa abordagem pode aumentar o risco da experiência do cliente (que discutiremos mais adiante), bem como a carga sobre funções globais, como pesquisa de clientes. Mantém-te atento a isso-

Outro tratamento é criar um processo de gerenciamento de produtos e programas que facilite a coordenação e comunicação de dependências, quando necessário , sem sobrecarregar as equipes de coordenação, se não for necessário . Às vezes, ao tentar gerenciar a coordenação para que possamos fazer mais , acabamos criando processos tão onerosos que acabamos fazendo menos. É um equilíbrio entre fazer pouca coordenação fazendo com que as peças não interoperem e fazer muita coordenação fazendo com que as peças nunca sejam construídas porque estamos todos em pé para a eternidade.

O argumento no Mythical Man-Month é que, à medida que você adiciona pessoas a um projeto de software, a comunicação precisa aumentar geometricamente. Por exemplo, se você tem 3 pessoas no projeto, são 3 linhas de comunicação. Mas se você tem 4, são 6 linhas de comunicação. Uma pessoa a mais, neste caso, leva ao dobro da comunicação! Diversão. (Isso é, obviamente, uma simplificação excessiva da comunicação em projetos de desenvolvimento de software.)

Pessoas diferentes têm papéis diferentes e, portanto, recebem diferentes quantidades de autonomia. Talvez o gerente de projeto precise se comunicar com todos da equipe. Mas um engenheiro que trabalha na API precisa se comunicar com o profissional de marketing do produto? Ou o profissional de marketing pode simplesmente passar pelo gerente de produto? Um bom processo e cadência de reuniões podem eliminar comunicações e reuniões desnecessárias. A questão é que a fórmula de intercomunicação de Brooks é um limite superior para a coordenação , não uma sentença de morte.

Por fim, use ferramentas, princípios e estruturas combinados com trabalho independente em vez de colaboração real para combater os sintomas de interdependência. Por exemplo, se eu puder coordenar os indicadores-chave de desempenho de duas equipes (KPIs, ou seja, medidas de sucesso) para incentivar o movimento mais ou menos na mesma direção, é mais provável que seu trabalho independente acabe “mais próximo” do que se seus KPIs incentivam o movimento ortogonal. Isso não garantirá que as coisas se encaixem perfeitamente, apenas que o trabalho que preciso fazer para que elas se encaixem no futuro seja menor do que poderia ser. Outros exemplos podem incluir o uso de declarações “even-over”, sistemas de design e testes automatizados.

Então tem um começo. Mas as interdependências assumem muitas formas além do código. Deixe-me dar um exemplo do Mailchimp.

Risco da experiência do cliente: o custo oculto (mas aceitável?) do trabalho de firewall

Como o cliente do Mailchimp geralmente é um pequeno empresário que é um novato em marketing (e existem milhões de pequenos empresários que se tornaram profissionais de marketing em todo o mundo), devemos oferecer uma experiência que seja perfeita e imediatamente compreensível de ponta a ponta . Não temos o luxo de montar o monstro de nuvens de Frankenstein por meio de aquisição da maneira que os jogadores corporativos podem. Não podemos esconder softwares mal integrados com consultores e gerentes de contas.

Como produto de consumo (pense no Instagram, Nintendo Switch ou Roomba), temos que ser utilizáveis ​​imediatamente. Para uma plataforma de marketing tudo-em-um destinada a impulsionar seus negócios, isso é difícil! E isso significa que cada coisa que o Mailchimp cria deve ser perfeitamente conectada a partir de uma perspectiva de experiência.

Mas, o particionamento perfeito de projetos apresenta risco de experiência . Não é que o código não possa ser escrito de forma independente. Isso pode ser alcançado, mas ainda há o risco de que os produtos pareçam ter sido construídos por equipes diferentes, e essa experiência pode ser muito confusa para o usuário. Nós esbarramos na lei de Conway – nossos clientes podem dizer onde termina o trabalho de uma equipe e começa o trabalho da outra equipe.

Então você tenta conectar o trabalho de todos juntos – não apenas no back-end, mas também no front-end. Na era do ecossistema, dominada pela excelência em CX de players como a Apple, isso se tornou quase uma aposta no espaço do consumidor. Mas este é um pesadelo Mítico Homem-Mês , embora não de uma perspectiva de engenharia desta vez. É de uma perspectiva de design de serviço. À medida que adicionamos mais pessoas a todo esse trabalho conectado de ponta a ponta, tudo fica mais lento para um rastreamento colaborativo.

Além da terceira correção que observei acima, usando ferramentas e estruturas em vez de observadores e portões de estágio, há outra válvula de liberação: faça algumas trocas deliberadas de experiência do cliente . Especificamente, onde nos sentimos confortáveis ​​em liberar uma experiência que está desconectada do resto (ou seja, que está abaixo da média)? Aceitar o risco e seguir em frente é o trabalho do líder de produto. E então você usa alguns critérios para resolvê-lo (talvez não esteja mantendo as áreas novas e de baixo tráfego do aplicativo com os mesmos padrões de experiência que suas “vacas leiteiras”) e toma uma decisão (por exemplo, iteração e aprendizado sobre polimento em inovações). Isso, é claro, vai além do design.

Você sempre pode causar um curto-circuito na lei de Brooks ao optar por firewalls, incluindo esforços que, em um mundo perfeito, não deveriam ser protegidos por firewall!

“

Vou ressalvar isso dizendo que o software que construo não mata ninguém. Eu não defenderia essa abordagem se estivesse construindo um dispositivo médico. Mas em uma empresa de software de marketing, posso isolar deliberadamente as equipes sabendo que aumentei as chances de incompatibilidade como uma compensação para aumentar o pessoal e mover-se mais rapidamente.

Fico triste em admitir que o Mês-Homem Mítico é uma realidade na minha empresa, e suspeito na sua também. Mas é gerenciável - esse é o resultado final. A paralelização e a mitigação de dependências nos oferecem uma saída que limita o status quase mítico do Homem-Mês Mítico . Portanto, da próxima vez que a dura dicotomia for levantada em sua empresa (escalar para ir mais devagar ou desistir de suas aspirações), lembre-se de que, se você for inteligente sobre como alinhar o trabalho, ainda poderá crescer muito.

Não se esqueça do lado mais suave da escala

Tenha em mente que gerenciar o Mythical Man-Month não impedirá os engenheiros de invocá-lo como magia negra. Eles estão invocando o princípio não apenas porque há alguma verdade nele, mas porque a escala é uma droga (sempre) de uma perspectiva emocional e cognitiva. Se acho que sou pago para escrever código e resolver problemas de clientes, a última coisa que quero fazer é mudar minha rotina e descobrir como trabalhar com novas pessoas e uma equipe maior.

Ao dimensionar sua empresa, lembre-se de ter empatia com a dor de dimensionar e mudar. Uma equipe que adiciona até mesmo um único membro se torna uma equipe totalmente nova do ponto de vista da confiança e da cultura. As pessoas estão cansadas dessa mudança. Isso significa que, enquanto você gerencia e mitiga o Mythical Man-Month , você precisará gerenciar as emoções que cercam o crescimento. Essa é talvez a tarefa mais crítica de todas.

A forte crença no Mês-Homem Mítico por uma equipe por si só pode trazer suas conclusões à realidade. É basicamente o equivalente à crença em voar em Peter Pan. Se a equipe acreditar que o dimensionamento os atrasará e eles não aceitarem a mudança, eles realmente desacelerarão.

Portanto, enquanto você trabalha para gerenciar dependências e introduzir ferramentas para ajudar a escalar, certifique-se de comunicar claramente o motivo por trás das práticas. Envolva as pessoas na seleção do trabalho e dos processos que mitigam os problemas de homem-mês, porque quando eles fazem parte da mudança e suas perspectivas mudam, de repente a escala torna-se pelo menos culturalmente possível.