A “Equipe Cirúrgica” de Fred Brooks lida efetivamente com o fator de barramento?

Minha equipe de 4 desenvolvedores experientes trabalha em um aplicativo Windows grande e modular (aproximadamente 200 KLoC). Concentrei-me na base de código principal desde o início do projeto (há 3 anos) e gradualmente mudei para uma posição de desenvolvedor semi-líder, embora eu não seja o gerente da equipe.

Nossa iteração atual é uma atualização de interface do usuário de alta prioridade solicitada pelo gerenciamento superior, envolvendo cerca de 15 alterações na base de código principal. Quando solicitado pelo gerente, calculei que cada uma das 15 alterações levaria menos de quatro horas para eu concluir , totalizando menos de 7 dias úteis. Eu então me ofereci para realizar o trabalho. Em vez disso, o gerente decidiu dividir uniformemente todas as 15 tarefas para todos os quatro desenvolvedores.

Nos três dias desde que começamos o trabalho, observei duas coisas:

1. Os outros membros inexperientes da equipe concluíram cerca de 1 ou menos tarefas cada.

2. Lei de Brook em ação: gastei cerca de metade do meu tempo prestando assistência (tentando treiná-los no uso dos componentes). Como resultado, eu terminei apenas duas tarefas, em vez das 5 ou 6 esperadas.

Entrei em contato com meu gerente com minha preocupação de que estávamos atrasados ​​e, novamente, sugeri que eu concluísse as tarefas restantes. Meu pedido foi gentilmente recusado e os motivos declarados para dividir a carga uniformemente foram duplos:

1. Limite o fator caminhão / ônibus - intensificando agora outros desenvolvedores com essas habilidades, para que, no futuro, qualquer trabalho possa ser dado a alguém, não apenas a mim.
2. Para eliminar um "gargalo" (eu) e concluir o trabalho mais rapidamente.

Para ser claro, não tenho problemas com: a) investir tempo ensinando, b) pessoas tocando meu código ou c) segurança no emprego. Na verdade, sugiro regularmente ao líder da equipe que eu treine outros desenvolvedores em certos aspectos da base de código principal para reduzir o risco.

Nesta iteração, também temos uma grande coleção de correções de bugs de alta prioridade direcionadas, portanto parece que mais progresso poderia ser feito se a carga de trabalho fosse redistribuída.

No Mítico Homem-Mês, Brooks sugere uma " Equipe Cirúrgica ", onde cada equipe é composta por uma liderança + uma sub-liderança (o gerente e eu) e alguns papéis menores. Sinto como se estivéssemos naturalmente entrando nessa organização, mas meu gerente está trabalhando contra ela. Eu sinto que o fator de barramento já foi resolvido (o gerente é versado no código principal) e que o gargalo não existe (envolver mais desenvolvedores não tornará o trabalho mais rápido). Penso que, a esse respeito, uma equipe cirúrgica é uma coisa boa.

Esses são meus sentimentos, mas não sou um gerente experiente, nem tivemos que lidar com o fator ônibus (bater na madeira). Brooks estava certo? Você já trabalhou em uma "equipe cirúrgica" onde o fator de ônibus entrou em jogo? Existem técnicas melhores para gerenciar a experiência em distribuição?

Perguntas semelhantes:

• Como aumentar o fator de barramento e se especializar ao mesmo tempo?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

Na verdade, eu argumentaria que você está seguindo o modelo de "equipe cirúrgica". Por sorte!

Parte do objetivo do referido modelo é que os membros inferiores da equipe tenham um papel de assistente. Quando a equipe não está fazendo cirurgia cardíaca, é bom se mover mais devagar e dar a eles a chance de praticar algumas de suas habilidades ou de treinar responsabilidades.

O trabalho do cirurgião é examinar e gerenciar sua equipe, procurando pontos fracos e resolvendo-os, além de ser o principal desenvolvedor. Você não pode ter um não cirurgião (gerente de negócios) fazendo isso, porque ele não entende as habilidades necessárias, como um aprendiz de um mestre artesão.

Portanto, o gerente está aproveitando essa oportunidade para trabalhar em um de seus outros objetivos. Se durante o curso, alguma falha for revelada na equipe, ele poderá lidar com ela antes que se torne um problema. Digamos, contratando outro desenvolvedor.

Ou, os juniores podem cometer um erro. Este é o momento perfeito para fazê-lo, pois eles têm alguém vigiando por cima do ombro. Oscar Wilde disse

Experiência é simplesmente o nome que damos aos nossos erros.

Se esses juniores nunca tiverem a oportunidade de cometer erros, nunca irão melhorar. Isso não apenas roubará sua equipe de futuros desenvolvedores experientes, mas, de certo modo, rouba a eles uma oportunidade que eles deveriam ter tido.

Nossa empresa costumava trabalhar como você está sugerindo. Tínhamos apenas duas pessoas que entendiam uma parte crítica do código. Sempre que surgia uma tarefa nessa parte do código, em vez de passar algumas semanas a atualizar alguém, a tarefa seria atribuída a eles porque eles poderiam concluí-la em alguns dias. Isso realmente funcionou muito bem por um tempo.

O que aconteceu foi que o prato ficou tão cheio que, mesmo que eles possam concluir uma tarefa em 2 dias, levaria semanas para chegar ao topo da lista. Os gerentes teriam batalhas verbais ferozes sobre cuja tarefa era mais urgente. Tarefas dependentes urgentes permaneceriam desfeitas.

Eventualmente, os gerentes se cansaram de esperar e começaram a treinar suas próprias equipes. Sim, ficou muito mais lento por um tempo, mas agora nosso rendimento é muito melhor.

Você pode estar nessa primeira fase agora, onde pode lidar com o trabalho, mas não tem como prever quando entrará na segunda fase. Aqui está uma dica: isso sempre acontece no momento mais inconveniente possível. Seu gerente tem razão em ser atingido quando você ainda tem espaço para respirar.

Sim, é frustrante ver alguém lutar com algo que você poderia fazer muito mais rápida e facilmente. Tente ser pai de uma criança de dois anos em algum momento. Você faz isso porque ajuda toda a equipe a melhorar. O trabalho do seu gerente é se preocupar com o cronograma. Se você está preocupado com os erros de alta prioridade desfeitos, desafie-se a ver com que rapidez você pode corrigi-los.

Você pode não ser um gargalo agora, mas eventualmente o será se continuar fazendo todo o trabalho sozinho. Seu gerente percebe que é importante o suficiente para você aprender a delegar o risco de que seu projeto se atrase - confie nele. Depois que você aprender a deixar ir, seus juniores começarão a aprender e produzir muito mais sob sua orientação.

Você está aplicando uma restrição que pode não estar presente ou ser tão significativa quanto você pensa que é. Especificamente, você está preocupado com o tempo até a conclusão. Seu gerente, por outro lado, não parece preocupado com as restrições de tempo percebidas.

Se você tirar o tempo de entrega da sua pergunta, rapidamente começará a se perguntar por que está fazendo a pergunta em primeiro lugar.

Isso não quer dizer que o tempo esteja sempre disponível e você declarou que essa é uma solicitação de alta prioridade da alta gerência. Mas você não está a par de todas as conversas que seu chefe teve com elas. Ele pode ter negociado por mais tempo para que você gaste esse tempo treinando os outros membros da equipe.

E enquanto você acha que o fator de ônibus já foi abordado, seu chefe pode estar olhando para a próxima solicitação que não se encaixa facilmente nos 7 dias de trabalho de um de seus principais desenvolvedores. É muito mais seguro treinar a equipe em uma iteração menor, em que a magnitude objetiva do risco é muito menor.

Eu já havia sido um gargalo crítico antes; e honestamente, não é um lugar agradável para se estar. No meu caso, eu e o vice-presidente de TI conversamos e criamos um plano para corrigir permanentemente o problema. Doeu, mas doeu muito menos do que eu tinha sido transportada.

É fácil entrar na mentalidade de tudo que precisa ser eliminado o mais rápido possível. Um bom gerente identifica as raras oportunidades em que um pequeno atraso (para treinamento / educação cruzada) pode pagar dividendos significativos posteriormente.