Lidando com dívidas de sistemas

Pre-amble/tl;dr: Recentemente, publiquei The Lloyd Braun Principle of Agility principalmente como uma observação boba, mas verdadeira, sobre como a frase clássica de Seinfeld "Serenity now, insanity later" se relaciona com Agile. Terminei aquele post com uma declaração sobre como precisamos nos preparar melhor para a "Insanidade" que vem depois. Com isso em mente, estou apresentando minha abordagem para construir equipes produtivas. Trata-se de pagar sua dívida de sistemas.

A equipe de tecnologia moderna está quebrada. Confiamos demais nos Seniors e não aproveitamos os Juniors.

Tenho pensado muito sobre esse problema no ano passado, pois adaptei várias equipes ao nosso "novo normal". Meses atrás, comecei um artigo para apoiar o caso de que os gerentes de contratação deveriam contratar juniores. Para fazer um argumento eficaz, eu sabia que tinha que abordar uma preocupação comum: "Primeiro preciso de veteranos para treinar os juniores..." Rapidamente o artigo cresceu e cresceu.

Se você é novo em administração, este é meu "tratado" sobre administração. É sobre como construir equipes altamente eficazes e produtivas e é baseado em mais de uma década de gerenciamento bem-sucedido de várias grandes equipes.

O que se segue é uma longa leitura - então o tl;dr é:

Falamos muito sobre #Dívida Técnica, mas a Dívida Técnica é um sintoma de um problema maior que estou chamando de Dívida de Sistemas.

A receita é simples:

1) Encarregue seus Seniores de pagar sua Dívida de Sistemas e facilitar o trabalho.

2) ALUGAR. JÚNIOR.

3) Pare de lutar contra o atrito. Os juniores permanecerão por uma média de 18 a 24 meses. Eles querem experiências variadas. Eles vão procurar outros empregos. Como uma comunidade de tecnologia, QUEREMOS que os Juniores ganhem mais experiência em seu caminho para a Senioridade. Isso os torna melhores e nos torna melhores. Então, vamos abraçar o atrito. Vamos começar a nos concentrar em permitir que eles aproveitem ao máximo esses 18 meses e apoiá-los em suas próximas etapas.

Qualquer boa equipe de entrega enfatiza a usabilidade. Os princípios que orientam a usabilidade aparecem em muitas formas diferentes: o Princípio de Pareto , o Teste da Vovó , o Princípio do Bom o Suficiente e muito mais. E todos eles chegam a algo muito humano: isso é mais difícil do que precisa ser?

Vemos isso o tempo todo: designs minimalistas que priorizam a facilidade de uso e são hiperfocados em uma visão clara. Todo o resto é uma distração, é um inchaço.

Tem muita gente falando sobre liderança, gestão, equilíbrio trabalho/vida pessoal e trabalho remoto/pessoal. Tudo está sendo reavaliado - e a pergunta que persiste em minha mente há meses é simplesmente esta: o trabalho é mais difícil do que precisa ser? Não é de forma alguma uma questão nova, mas é um fio que permeia a maior parte da minha carreira. Adoro escrever código e criar produtos, mas uma visão holística pode revelar que mais código nem sempre é a resposta. Mais código significa mais custos de treinamento e manutenção.

Se você é um novo gerente, manter essa pergunta em mente pode ser muito valioso. Os gerentes são responsáveis por muito: você está ajudando cada indivíduo - a realizar suas entregas e seus objetivos pessoais. Você é responsável pela coesão e direção da equipe. Muitas vezes você é responsável por estabelecer processos e políticas. Depois, há alocação e planejamento de recursos, além de trabalhar com cronogramas de PTO. Mas a luz que guia tudo isso é a mesma pergunta: isso é mais difícil do que deveria ser?

Quando foi a última vez que você avaliou sua mecânica interna? Pensando em sua equipe de entrega como um produto, quão fácil é para seus consumidores (a equipe de negócios/operações) atingir seu objetivo? E pensando em todo o seu negócio como um produto, quão fácil é para os clientes alcançar o deles?

Com foco nas pessoas, as mesmas perguntas se aplicam: Quão difícil é para sua equipe fazer o trabalho? Que estruturas, estruturas, processos inventados e hierarquias existem que fariam sua avó balançar a cabeça com o quanto você complicou as coisas?

Uma Cartilha sobre Dívidas

Todo esse pensamento de avaliar criticamente seus processos internos é, de fato, uma parte da filosofia Agile que muitas vezes é negligenciada. As equipes afirmam que são totalmente ágeis ou um "híbrido ágil", mas, olhando mais de perto, você percebe que o que elas querem dizer é que estão simplesmente cortando cantos inconvenientes para entregar produtos desleixados mais rapidamente. Quando se trata de software, qualquer desenvolvedor experiente saberá exatamente o que isso se torna uma receita para uma dívida técnica cada vez maior. A piada contínua dos codificadores é que a última pessoa fez errado e, se você quiser fazer certo , precisará reconstruí-lo. Isso não é devido à preguiça ou falta de habilidade. O trabalho greenfield é mais fácil porque acaba com toda a dívida técnica - mas, deixado aos mesmos processos ruins, só vai crescer mais uma vez.

A Dívida Técnica é um sintoma, e mesmo quando você é bom em pagá-la ativamente - você ainda está apenas tratando o sintoma . Esse sintoma vem do erro de pensar que Agile é apenas sobre entrega de software.

Uma definição adequada de Dívida Técnica é o 'acúmulo de trabalho que precisa ser refatorado'. Como mencionado, surge de pegar atalhos quando se concentra na entrega. A menos que você esteja pagando ativamente, ele cresce rapidamente. O resultado de muita dívida técnica é fragilidade e instabilidade.

Na melhor das hipóteses, a Dívida Técnica é uma decisão intencional: é colocar algo a crédito com a intenção de pagá-lo mais tarde. Nesses casos, a Dívida Técnica não é ruim - desde que você seja diligente em pagar a dívida. A encarnação mais nefasta da Dívida Técnica é quando você aumenta a dívida sem querer, ou pior - você não sabe que a adicionou.

A Dívida Técnica lida com tecnologia, mas há um conceito semelhante de Dívida de Processo - processos herdados que se tornaram obsoletos, funcionam mal, criam atrito, impactam a dinâmica entre equipes ou podem não mais se aplicar à medida que as funções mudam. A dívida do processo cobre nossas deficiências operacionais não técnicas.

Existem ainda outras formas de dívida que impactam na entrega: Dívida de Projeto, Dívida de Arquitetura.

Claro, a dívida não é inerentemente má. Assim como você pode carregar estrategicamente uma quantidade saudável de dívida financeira, assumir qualquer uma dessas formas de dívida é uma decisão estratégica. Em vez de pagar $ 20.000 em um carro de uma só vez, você faz um empréstimo automático e distribui os pagamentos em 10 anos. Da mesma forma - a pilha de tecnologia que você usa, a maneira como estruturou o conjunto de habilidades de sua equipe, a antiguidade dessas funções e os processos que impulsionam seus negócios assumem uma forma de dívida que é paga ao longo de um período.

Apenas - às vezes não pagamos. Ou, pior: achamos que estamos pagando dívidas, mas na verdade estamos acumulando mais.

Apresentando: Dívida de Sistemas

Eu gostaria de introduzir um conceito que chamarei de Dívida de Sistemas (Sistemas como na Teoria de Sistemas; para mais informações sobre Teoria de Sistemas, leia o fantástico Thinking in Systems de Donnella Meadow ).

A dívida de sistemas é a causa principal e abrangente das formas de dívida posteriores que impedem ou impactam negativamente a entrega - seja por meio de decisões de negócios ou decisões técnicas, de arquitetura ou de processo. É o produto de atalhos calculados nos negócios, colocando o trabalho a crédito. A Dívida do Sistema impede o funcionamento do sistema por meio de seu projeto estrutural.

Em Thinking in Systems, Meadows fornece um exemplo simples de sistema: uma banheira. A entrada do sistema é a torneira e a saída é o ralo. Meadows explica como diferentes fatores podem fazer com que a banheira nunca encha, fique nivelada ou transborde. Um sistema ideal é o nível restante da água - com a entrada (torneira) e a saída (dreno) fluindo na mesma vazão. A Dívida de Sistemas seria consequência de atalhos na composição do sistema. Para estender a analogia da banheira, talvez a torneira esteja mal instalada e a água eventualmente vaze. Talvez a localização do dreno leve ao acúmulo de água em certas áreas, de modo que a banheira nunca possa drenar totalmente. Talvez nossa água precise de amaciamento e cause o acúmulo de cal.

Nesses casos, não há impacto imediato e ainda é possível criar um sistema ótimo - mas o que está oculto é o acúmulo de dívidas que está sobrecarregando o sistema: a torneira tem que correr mais rápido para compensar os vazamentos, ou a torneira corre mais devagar e a banheira demora mais para encher.

Se você estiver familiarizado com o livro de Meadows - muitos de seus exemplos estão enraizados na realidade com modelos geralmente fornecendo uma visão estática; o sistema não muda com o tempo. É perfeito para seus propósitos, mas quando se trata de indivíduos, equipes, operações e negócios, quem somos hoje não é quem seremos amanhã.

Para definir a Dívida dos Sistemas de uma forma ligeiramente diferente:

Dívida de Sistemas = Teoria de Sistemas + Modelo de Maturidade

Com as equipes de software, você vê a Dívida do Sistema se manifestar de algumas maneiras:

• Com o tempo, se não for gerenciado, as equipes desenvolvem cada vez mais "conhecimento tribal". Eles aparecem como hábitos bem-intencionados, atalhos e soluções alternativas. Porque eles produzem eficiências de curto prazo, eles resultam em deficiências de longo prazo sendo negligenciadas. Se não for pago, há um risco óbvio de perda de conhecimento devido ao atrito regular. Isso leva a perdas de produtividade, pois as equipes precisam girar e acelerar. ("Joe sabia disso, mas agora que ele saiu - teremos que gastar tempo descobrindo isso.") ou um acúmulo de dívida técnica devido ao desconhecimento. ("Não podemos atualizar esse componente. Sally o construiu e, sempre que o tocamos, ele quebra...")
• As equipes contam com padrões de design personalizados, regras de desenvolvimento não oficiais ou acordos que maximizam o fluxo local, mas esses padrões são difíceis de mudar. Isso impede a entrega quando algo não se alinha com um padrão estabelecido, tornando a equipe de negócios refém de decisões técnicas. ("Não podemos criar uma instância personalizada - nunca a projetamos dessa maneira.")
• As equipes que se tornam complacentes priorizam a manutenção do status quo em relação às retrospectivas disruptivas. Eles ainda podem ter retrospectivas, mas se perderam a fé na capacidade de lidar com os problemas reais, eles se concentrarão apenas em consertar coisas triviais. ("Estamos ficando sobrecarregados com solicitações de incidentes, mas tanto faz - só temos que continuar resolvendo-os, eu acho...")
• O mal-estar ou indiferença que vem ao atingir uma velocidade sustentável, apesar do atrito endereçável. A velocidade sustentável cria uma falsa sensação de eficiência. ("Precisamos mesmo mudar o processo? Atingimos nosso ritmo - por que interrompê-lo?")

Com as equipes de Produto e Operações, você vê a Dívida de Sistemas de maneiras semelhantes:

• O atalho "toda chamada do cliente é um alarme de incêndio" envolveu a equipe de desenvolvimento para corrigir rapidamente pequenos problemas, atrasa lançamentos, reduz a velocidade etc. ("Preciso que a equipe analise um problema levantado por um cliente irado, leva apenas 20 minutos...")
• O caos da última pessoa com quem falei é minha prioridade mais alta força a equipe a mudar constantemente de contexto e não pode se concentrar em um problema até a conclusão.
• Quando priorizar é um atalho através do uso de métricas enganosas. Por exemplo, o cliente caro que não está mais alinhado aos objetivos do negócio. Eles faziam sentido nos primeiros dias de Start-Up, mas à medida que o negócio amadureceu, esse mesmo cliente tornou-se mais problemático. ("Não sabemos se vamos querer reter este cliente, mas eles pagam-nos muito por isso temos de o fazer...")

Para reiterar: Todas as formas de dívida são quando optamos por pegar um atalho agora com a intenção de consertá-lo mais tarde. Dívida técnica é quando fazemos isso com código. Dívida de processo é quando fazemos isso com nossos processos formais. Dívida de sistemas é quando fazemos isso no nível organizacional. Prefiro vê-la como 'Dívida de Sistemas' em vez de 'Dívida Organizacional' porque pensar na organização como um sistema significa que as Dívidas Técnica, de Processo e de Design são todas causadas diretamente pela Dívida de Sistemas. Os fatores que nos levam a assumir a Dívida Técnica estão, em última instância, relacionados à Dívida de Sistemas. ("Você só pode salvar tantas pessoas de se afogarem em um rio antes de começar a olhar rio acima para determinar por que elas continuam caindo.")

Por exemplo: A equipe de desenvolvimento está lançando uma nova funcionalidade que foi devidamente planejada e orçada. A equipe está no caminho certo, mas nos estágios finais encontra um problema que força uma pergunta temida: atrasar o lançamento abordando o problema adequadamente ou fazer a correção mínima e resolvê-lo adequadamente na próxima iteração? Eles optam por assumir a Dívida Técnica: "Vamos obtê-la na próxima iteração."

É agora que a Dívida dos Sistemas começa a entrar na equação. A equipe realmente será capaz de lidar com isso? A equipe está adequadamente qualificada para refatorar? A empresa responderá com "está bom o suficiente, precisamos seguir em frente"? O custo futuro revelará que agora se tornou muito caro para fazer da maneira certa? Será que uma mudança nas prioridades ou um aumento nos problemas urgentes atrasará repentinamente a correção por outra iteração? Depois outra iteração, depois outra...

Além disso, olhando a montante: por que demorou tanto para encontrar o problema? Que suposições ruins foram feitas? Foram suposições ruins? Sempre há o problema que você não pode determinar até o final do jogo - mas então por que se tornou uma questão de atrasar o lançamento? As promessas foram feitas cedo demais? Deveria ter havido um buffer maior? Isso teria sido resolvido se a Pessoa A (vendedor de negócios upstream) falasse mais com a Pessoa F (desenvolvedor downstream) seguindo a cadeia mais curta ?

Outro exemplo bastante familiar vem com os modelos de infraestrutura, arquitetura e hospedagem nos quais nos prendemos desde o início, com base em suposições sobre como o negócio será escalado em 3 a 5 anos. Uma equipe pequena pode optar por assumir a dívida de infraestrutura e arquitetura desde o início em favor de uma entrega mais rápida do que aderir aos melhores princípios de DevOps.

Claro, é fácil pintar cenários como este sem os detalhes - mas independentemente dos detalhes e desculpas para esses detalhes: Dívidas de sistemas serão acumuladas. É inevitável. Tudo bem - apenas requer atenção constante e se concentra em reduzi-lo a níveis sustentáveis.

Atalhos de Compensação

Assumimos a dívida - do sistema ou não - como um atalho. Antes de nos aprofundarmos na Dívida de Sistemas e como pagá-la, vamos primeiro dar um passo para trás e perguntar por que estamos tomando atalhos? Atalhos, assim como Dívida, não são inerentemente ruins - mas devem ser analisados de perto.

Pensar em atalhos físicos é uma ótima maneira de começar. Se você já foi um pedestre ou ciclista, com certeza notou como as coisas são projetadas primeiro para os veículos e depois para os pedestres. Ao caminhar, você acaba pegando muitos “atalhos” e não segue as estradas – mas claro que não são atalhos. Esses atalhos são os caminhos ideais para um pedestre que pode ir aonde os carros não podem. Na verdade, construir nossas rotas principalmente para carros em áreas de pedestres intensos é [outra forma] (outra forma) de Dívida de Sistemas.

No mundo dos negócios, tomamos atalhos para compensar - falta de tempo, falta de orçamento, falta de recursos, falta de responsabilidade ou falta de uma visão mais ampla. Tempo, orçamento e recursos recebem os holofotes - mas a responsabilidade e uma perspectiva ampla estão exatamente no centro da minha pergunta inicial: isso é mais difícil do que deveria ser? Quando você está salvando pessoas de se afogarem em um rio, é olhar para a corrente (perspectiva ampla) e apontar para a pessoa (responsabilidade) que continua empurrando as pessoas para dentro.

Em outras palavras: se você vai ter uma conversa séria sobre Dívida de Sistemas, todos precisam fazer parte da conversa. Esforços localizados só chegam até certo ponto.

Então, como você paga a dívida do sistema?

Vamos voltar à pergunta anterior: é fácil para sua equipe de entrega entregar? Se você nunca considerou esta questão, é hora de obter algumas métricas! Essas métricas não fornecem necessariamente as respostas, mas são um importante ponto de partida. Quando se trata de KPIs, o melhor conselho que já recebi foi que um KPI individual não é bom nem ruim. É objetivamente apenas um número, um valor. É o seu negócio como sempre - e para você decidir se deseja ou não ajustar esse número para cima ou para baixo. Se você é fã do sistema OKR ou das metas SMART, isso é ótimo porque conhecer seus KPIs permite que você faça OKRs melhores que são facilmente quantificados.

Então, vamos começar com alguns princípios básicos e entrar no mato. O que se segue não é uma lista abrangente e pode haver perguntas mais adequadas para o seu grupo. Pense nesta lista como um ponto de partida para fazer perguntas melhores.

Entrega:

• Qual é o seu lead e tempo de ciclo para itens de alta prioridade/urgentes?
• Qual é o seu lead e tempo de ciclo para itens de baixa prioridade?
• Quanto você alocou para pagar a dívida?
• Quanto sua Dívida está aumentando?

Essas perguntas podem parecer familiares para quem acompanha o desempenho de sua equipe - mas lembre-se de fazê-las no nível da organização. O Lead Time do desenvolvedor pode ter começado quando o ticket foi criado - mas por quanto tempo ele existiu na cabeça de alguém?

Recursos:

• Qual é a divisão atual da sua equipe (sênior x junior)?
• Qual é o seu risco de atrito entre seniores e juniores?
• Qual é o custo de perder alguém sênior?
• Qual é o custo de perder um júnior?
• Qual o custo e duração da contratação?
• Qual é a duração da sua entrevista/integração?
• Qual é a duração do seu treinamento/ramp-up (e quais recursos precisam ser envolvidos e, portanto, perder produtividade?)

Carteira de Negócios:

• Supondo que o Quadro Estratégico do Gerente de Produto esteja definido, quantas exceções são feitas?
• Quantos épicos/recursos não estão enraizados em casos de negócios definidos objetivamente, vinculados a finanças e prazos?
• Como o pipeline de desenvolvimento de vendas/negócios alimenta sua lista de pendências de software e qual é o tempo de lead e ciclo para eles?
• Com que frequência os objetivos de negócios de alto nível mudam e quanto esse caos afeta os esforços posteriores?
• Quais são os objetivos de crescimento de longo prazo da empresa e como o conjunto de habilidades e o plano de recursos da equipe se alinham?

Backlog de Operações

• Quantos problemas de clientes são levantados diariamente?
• Quantos problemas de clientes precisam ir para o suporte de nível 1, 2, 3?
• Qual o tempo médio para resolução?
• Qual é o tempo de espera para um problema do cliente e qual é o tempo desde a chamada inicial até a criação do tíquete de desenvolvimento?

Ter uma noção simples de quanto tempo leva para algo ir do início à disponibilidade pode ser muito esclarecedor - especialmente quando se trata de um problema do cliente.

Há uma série de recursos que ajudam a melhorar as métricas acima - mas a principal filosofia por trás de tudo isso é: 1) Medir, 2) Analisar, 3) Resolver, 4) Repetir. Quanto mais problemas o Nível 3 puder descarregar para o Nível 2, mais o Nível 2 para o Nível 1 e quanto mais o Nível 1 permitir que o Cliente resolva de forma independente, mais produtivos todos se tornarão.

Desenvolvedores:

• Quanto tempo leva para eles pegarem a fonte e construírem?
• Com que rapidez você fornece credenciais para novos desenvolvedores?
• Com que rapidez eles podem se levantar e interagir com um ambiente inferior de trabalho?
• Quanto tempo leva para um desenvolvedor liberar o código para produção (medido a partir da data de contratação)?
• Quanto tempo leva para acelerar seu SDLC e processos?
• Se eles começarem no meio do Sprint, quanto tempo eles ficarão parados?
• No geral, qual é a sua curva de aprendizado atual?

Para comparação: o Etsy é um ótimo exemplo de eficiência e é uma ótima referência. A Etsy garante que os desenvolvedores implementem a produção no primeiro dia .

Visão holistica:

• Qual é a jornada de entrega desde o início até a disponibilidade? Mapeie o fluxo de trabalho - ele pode ser otimizado?
• Qual é a jornada do cliente desde as vendas até a receita (e além)?
• O que são RPO e RTO?
• Como o desempenho dos negócios se compara aos de alto desempenho de entrega, conforme descrito em Acelerar: a ciência do software enxuto e do DevOps ?
• Quais são os 10 principais cenários de desastres de pesadelo ? Isso é algo que a FedEx fez para melhorar suas operações e criar um 'Manual' interno para torná-los a empresa que são hoje.

Dados todos os números e métricas por trás do exposto, reiterarei que qualquer um desses números representa o seu negócio como sempre. Embora não sejam intrinsecamente ruins ou bons, a Dívida de Sistemas torna mais difícil manter esses números a longo prazo. Alguns números podem ser surpreendentes e revelar áreas onde essa dívida já pode ter causado impacto.

A próxima etapa é considerar como essas métricas mudam com o tempo - à medida que você amadurece e continua a amadurecer. Como exemplo - os engenheiros que criaram o produto principal prenderam você em uma arquitetura que está se aproximando dos limites de sua escalabilidade. Nesses casos, as equipes procuram como podem pagar a Dívida Técnica - mas e a Dívida de Sistemas? Dado um conjunto limitado de recursos, um risco crescente de desgaste e um negócio em amadurecimento - como você mantém os KPIs de entrega enquanto paga a Dívida Técnica?

'Mate seus queridos', demita suas 'estrelas do rock', destrua suas 'fábricas ocultas', pare de ser útil

Essas são várias declarações ousadas em um título. O ponto em tudo isso é que: Ser "útil" para criar atalhos em um processo pode ser perigoso. Se subscrevermos a ideia de que “o que é medido, é feito”, o problema de ser útil é que muitas vezes não é medido .

Imagine um cliente ligando porque excluiu acidentalmente um registro em seu portal ao mover-se muito rapidamente. Eles têm pouco tempo - e não podem passar pelo processo de restauração de um registro. Eles ligam e seu funcionário do Suporte ao Cliente, querendo ser útil, escala imediatamente para o engenheiro de banco de dados que, querendo ser útil, restaura imediatamente o registro. O cliente fica emocionado, a pontuação do NPS sobe. Tudo ótimo, certo?

Ignorando os riscos óbvios de alguém atualizar um banco de dados de produção por um momento, há muitas informações valiosas que se perdem ao serem úteis:

• Por que fazer uma ação tão dramática é tão fácil que o cliente cometeu o erro em primeiro lugar?
• Por que desfazer a ação dramática é tão difícil que eles tiveram que ligar?
• Por que o Suporte ao Cliente não conseguiu lidar com isso?
• Qual foi o impacto na produtividade resultante de ser útil e mudar de contexto ? (Uma tarefa aparentemente simples de 20 minutos acaba sendo mais de 35 minutos por causa do tempo que leva para voltar a um fluxo produtivo.)

Sejamos claros: meu título está em negrito. Mas, não estou defendendo a assistência a um cliente - no entanto, acho que tais ações devem ser seguidas com alguma análise de causa raiz. Nada excessivamente formal - mas algo para evitar um problema semelhante no futuro.

Em uma organização, melhorei a produtividade de nossa equipe de desenvolvimento em 50% simplesmente implementando um Playbook. Um cliente liga e é recebido com cortesia por um representante do Suporte ao Cliente que segue um fluxo de trabalho claro para a resolução. Se eles não conseguirem resolvê-lo, temos um ciclo de feedback para que eles encaminhem um problema apenas uma vez. O resultado foi uma equipe de suporte ao cliente mais capaz e qualificada, uma equipe de desenvolvimento com menos interrupções, menor estresse geral - e, mais importante, clientes satisfeitos.

O ponto é que, quando um trabalho útil acontece nas sombras, você não pode consertar a causa raiz.

Vemos o mesmo problema com o desenvolvedor Rock Star, que assume muito trabalho e responsabilidade para compensar uma equipe menos qualificada - apenas para que eles fiquem frustrados, se esgotem e saiam (um custo que pode ser devastador). O grande livro de Will Larson - um quebra-cabeça elegante - faz um ótimo trabalho de como lidar com suas "estrelas do rock".

O poder dos juniores...

Os idosos são críticos para o sucesso de uma organização e do produto - mas são igualmente um dos maiores riscos.

Por exemplo, um desenvolvedor sênior conhecerá a base de código por completo. Eles sabem o que está documentado e o que não está. Eles saberão onde ele escala bem e onde desmorona. Eles saberão onde os esqueletos estão enterrados. Nós recorremos a eles com frequência - contando com eles para criar e projetar recursos, arquitetar soluções e ajudar a resolver os bugs mais complicados. Eles são os gurus do conhecimento que podem responder a qualquer pergunta. Eles treinam e orientam a equipe júnior e são consultados no desenvolvimento de soluções.

Basta dizer que se pede muito da equipe sênior. É uma afirmação óbvia, dada a sua experiência e talvez interesse no sucesso da organização. No entanto, eu diria que é aqui que assumimos a maior dívida de sistemas.

Qualquer membro sênior da equipe que progrida em uma entrega é um atalho que acumula Dívida de Sistemas.

Vou reiterar porque é fácil interpretar mal. Você pode ter um membro sênior da equipe trabalhando em uma entrega, mas deve planejar para pagar a dívida que terá acumulado ao fazê-lo.

Contar com os seniores para entregas é um modelo falido - particularmente no mundo de hoje, onde há muitos candidatos juniores e qualificados de nível básico, e o risco de desgaste intermediário para sênior é alto e caro .

A força de trabalho virtual remota tornou mais crítico para qualquer organização elevar a equipe júnior/intermediária, reduzindo o impacto do desgaste da equipe sênior. Isso não significa diminuir a equipe sênior, mas significa uma diferença estrutural na abordagem.

Usando uma generalização, as equipes seniores de hoje são amplamente responsáveis pelas complexidades por trás dos sistemas: sua experiência e especialização produzem sistemas maduros e os componentes menores baseados em tarefas são implementados pelos membros mais juniores da equipe.

Este é exatamente o modelo que se mostra problemático quando um membro sênior da equipe sai, e também a estrutura que acumula Dívida de Sistemas. Nessa situação, o Sênior é responsável pelas complexidades e pode intervir para auxiliar quando a equipe júnior não consegue entregar (o desenvolvedor "Rock Star", por exemplo).

Esse problema é ainda mais exacerbado pela taxa atual de perda de pessoal: por exemplo, os desenvolvedores juniores nacionalmente permanecerão em uma função por 18 a 24 meses (mais tempo em empresas maiores). Em outras palavras, quando um Júnior atinge um ponto em que pode começar a fazer contribuições mais significativas, ele está de saída.

As organizações lutarão para reter a equipe sênior, lutarão (um pouco) para reter a equipe júnior - e estão constantemente sofrendo com a perda de conhecimento. Em última análise, esta é uma batalha perdida - mesmo que a equipe seja mantida ou novos membros da equipe entrem, eles agora estão na posição de ter que pagar uma grande quantidade de dívidas de sistemas.

Facilite o bom trabalho e aceite o inevitável

Imagine um pequeno restaurante com estrela Michelin. O chefe de cozinha está muito envolvido na produção dos pratos, com pratos complexos demais para serem distribuídos entre uma equipe de cozinheiros. O chef é o restaurante neste caso.

Compare isso com os restaurantes franqueados mais amplos. Você tem um chefe de cozinha no Corporate cuja responsabilidade é não produzir pratos que sejam consumidos pelos clientes. Em vez disso, seu objetivo é produzir pratos reprodutíveis. Pratos que podem ser facilmente reproduzidos (sem deixar de ser saborosos). Pratos otimizados de forma que a curva de aprendizado seja mínima - novos cozinheiros podem ser facilmente treinados para produzir os pratos, e a perda de sua eventual saída é menos impactante. Os chefes de cozinha também fazem parceria com especialistas em eficiência para ver como a cozinha do franqueado pode ser otimizada para entrega.

Esse é o modelo que devemos usar quando pensamos no time moderno. A responsabilidade da equipe sênior não deve ser a complexidade do produto. Deve ser totalmente focado em simplificar a entrega: simplificar o treinamento e o ramp-up, configurar os tempos, construir os tempos, simplificar o lead e os tempos de ciclo (em toda a linha, de Vendas/Solução de Produto, até o Planejamento de Iteração, até o Lançamento).

Como você estruturaria as coisas se soubesse que só pode reter pessoas por 18 meses? Na verdade, como você estruturaria as coisas se as colocasse em um contrato de 18 meses, com rescisão dura no final? Você gostaria que o ramp-up fosse o mais rápido e curto possível. Você gostaria que sua equipe de especialistas garantisse que suas novas contratações possam aumentar em semanas para que possam maximizar o impacto. Você gostaria de ter certeza de que sua equipe de especialistas pode manter uma porta giratória que maximiza a eficiência e nunca intervém para ajudar (pelo risco de acumular dívidas).

Ao construir um sistema que pode ser mais adaptável, que pode abraçar e alavancar o emprego de curto prazo, você reduzirá o impacto se perder um membro sênior da equipe porque o conhecimento se torna imortalizado no processo, não nas pessoas.

Tag, você é isso

Quem te ensinou a jogar pega-pega? Não importa onde você esteja no mundo, você provavelmente aprendeu a jogar esse jogo com outras crianças. Os adultos não precisam ensinar as crianças a brincar de pega-pega.

Pensamos nos memes como imagens engraçadas, mas a definição original de meme é um elemento de uma cultura ou sistema de comportamento transmitido de um indivíduo para outro por imitação ou outros meios não genéticos.

Marca é um meme. Ninguém é dono das regras. Ninguém é responsável por melhorar o jogo. Na verdade, as regras são simples, embora ainda ofereçam suporte a variantes como Freeze Tag. Além disso, pode ser adaptado a diferentes ambientes. Ele foi projetado para uma porta giratória de crianças que eventualmente se transformam em adolescentes legais demais.

Há muito pouca dívida de sistema em um jogo como o Tag. Compare Tag com outros jogos de playground que requerem mais jogadores ou mais equipamentos... British Bulldog, Dodgeball, Duck Duck Goose, Cops 'n Robbers, Red Rover. Talvez você tenha jogado esses jogos, talvez não. Esses jogos carregam um pouco mais de Dívida de Sistemas. Mais regras, mais equipamentos ou mais jogadores significam a necessidade de mais facilitadores.

Então, como podemos operar como Tag?

1. Aproveite os idosos para baixar a barra . Os idosos não estão lá para jogar Tag ou entregar a especificação. O objetivo deles é diminuir o nível: como as pessoas podem treinar mais rápido e agregar valor mais rapidamente? Como fazer lançamentos frequentes, incrementais e regulares com baixo risco de impacto? (*tosse tosse* DevOps, Agile)
2. Mapeie os processos, mapeie os fluxos e identifique os pontos de estrangulamento: talvez o problema não seja a equipe de software. Talvez não seja falta de uma equipe de testes dedicada. Talvez o problema seja upstream: a empresa está sobrecarregando o pipeline de entrega com prioridades conflitantes?
3. Qual é o driver para as pessoas fazerem uma pausa? Não há absolutamente nada de errado em fazer uma pausa - mas muitas vezes são dicas incríveis de uma corrente de frustração. Rastrear quando e por que alguém está se afastando pode ser muito informativo: talvez eles tenham se afastado porque o código demora um pouco para compilar e implantar. Talvez eles tenham se afastado porque precisam pensar mais profundamente sobre um desafio que estão enfrentando. (Isso não é uma coisa ruim, mas o problema poderia ter sido resolvido para reduzir a complexidade?) Talvez eles tenham se afastado porque a necessidade de um cliente os está frustrando. Talvez eles precisem respirar porque um novo recurso está forçando um redesenho ou revelando uma suposição ruim.
4. Observe a falta de pausas: Igualmente revelador é quando alguém está muito cabeça baixa. Eles não podem se afastar - sua atenção é necessária. Isso significa que há uma dependência muito grande de alguém, ou o trabalho e o escopo foram definidos de forma muito ampla, ou o sistema subjacente é muito mais complexo do que deveria ser.
5. Crie uma cultura de simplificação. Ou seja, seus gerentes, seus seniores, seus intermediários - todos devem ter o poder de dizer: "Isso é mais complicado do que deveria ser - como podemos tornar isso mais fácil?" Colete feedback - especialmente dos juniores. Os juniores não são valorizados o suficiente. Não cometa o erro de pensar que sua falta de experiência significa que eles são ingênuos. Os juniores nem sempre sabem que existem maneiras melhores, mas são muito francos sobre onde gastam (e desperdiçam) sua energia.
6. Sempre que um Sênior contribuir para uma entrega, descubra o porquê. Todo. Tempo. Um bug P0 no prod exigia uma correção urgente. O código de baixo nível exigia mudanças. Um cliente precisava de uma discussão. Os executivos precisavam de uma apresentação para uma atualização.

A maré alta levanta todos os barcos. Os idosos devem ser a maré, não os barcos.

A prova está no pudim

Um princípio orientador ao longo da minha carreira tem sido entender como o problema afeta a produtividade. Não foi fazer equipes mais eficientes, mas equipes mais impactantes. Os gerentes de produto têm como mantra medir o resultado, não a saída. A eficiência é importante quando você sabe o que está fazendo e só precisa fazer isso mais rápido. O impacto é um alvo móvel, amorfo e mal definido. Requer adaptação. É por isso que os princípios ágeis, OKRs, Lean e Kanban podem ser tão poderosos quando usados corretamente.

Concentrar-me nos resultados de todo o sistema e pagar a dívida do sistema me deu a oportunidade de causar impacto de várias maneiras.

• Para uma empresa SaaS, mapear o processo desde o estágio inicial de pré-venda até a implantação do código na produção. Medir o lead e o tempo de ciclo na perspectiva de cada etapa para identificar gargalos. Ao vê-lo como um sistema, poderíamos identificar como melhor qualificar, melhor desqualificar e como e quando reestruturar o processo de vendas e implementação com base no tipo de cliente. A aplicação de uma abordagem Kanban de trabalho puxado em vez de empurrado, estabelecendo limites estritos de WIP (enquanto ainda contabiliza a folga - veja a analogia Drum-Buffer-Rope de Goldratt ) e formalizando a Definição de Feito nos permitiu melhorar continuamente o próprio fluxo de trabalho. Por fim, um princípio adicional, neste caso, foi não permitir que o processo atrapalhasse a produtividade . Ao criar uma trilha acelerada, as coisas poderiam se mover mais rápido onde possível (ou seja, "atalhos"), mas sempre vinham com uma análise de onde o processo de linha de base falhou (ou seja, pagar a dívida do sistema). Isso simplificou as implementações de 6+ semanas para 2 e tornou-se um sistema autogerido.
• A contratação de uma Filosofia Juniors First me permitiu quadruplicar o tamanho de nossa equipe em 6 meses. Ao reduzir o tempo de aceleração e focar a equipe sênior em torno da produtividade do júnior, pudemos abraçar o inevitável e prever o atrito . Essa abordagem deixou qualquer Junior atingindo sua marca de 2 anos com duas opções atraentes: graduar-se em uma função mais intermediária, onde seu foco mudou para capacitar Juniors enquanto eles continuavam a desenvolver suas habilidades ou trabalhar com a equipe em uma saída amigável. Essa transparência ajudou a combater a coceira de 2 anos que os juniores sentem quando se deparam com a incerteza da carreira.
• Trazer as equipes de Operações e Desenvolvimento sob um guarda-chuva de processo. Isso alinhou as equipes para que, em vez de fluxos de trabalho paralelos, fosse circular: a saída da equipe de operações era a entrada da equipe de desenvolvimento. A saída da equipe de Desenvolvimento tornou-se a entrada da equipe de Operações. Ao implementar um manual "vivo" , com ciclos de feedback estratégico, as equipes tornaram-se cada vez mais autossuficientes. Isso liberou o envolvimento da equipe sênior nas operações e reduziu os prazos de entrega de mais de 7 meses para 3 semanas.
• Pivotar a visão da equipe de desenvolvimento de SaaS dos estágios de desenvolvimento de software (definição, implementação, validação, liberação) para foco no cliente com ênfase no impacto enquanto ainda prioriza o trabalho que está mais próximo da conclusão. Isso permitiu que as equipes de entrega tivessem um melhor senso de impacto e prioridades e permitiu que os negócios fossem mais conscientes e críticos em relação a trabalhos/clientes de baixo impacto.
• Investimentos na simplificação do processo de desenvolvimento iterativo, reduzindo os tempos de construção e implantação. Este foi um daqueles momentos de "Observação das pausas" em que a equipe frequentemente se afastava devido ao desamparo de um longo processo de construção/implantação. É importante ressaltar que a correção não foi totalmente técnica - mas baseada em um processo. Ao estabelecer um novo processo, as equipes de entrega ficaram 200% mais produtivas.
• Não construir software para ineficiências de processo. Por mais que eu goste de escrever código para resolver problemas interessantes, um novo código deve ser o último recurso. Mesmo que o código não tenha atalhos e nenhuma Dívida Técnica própria, o código precisa ser mantido. Você introduziu mais Dívida de Sistemas - e não abordou a raiz do problema. Esses casos são desenfreados e facilmente esquecidos - mas são o equivalente a resolver um vazamento no telhado colocando um balde no chão. A eliminação dessas correções abordando a raiz do problema cria eficiências imensuráveis e permite que a equipe trabalhe no que importa.

Mas sou apenas um gerente de nível médio, como posso implementar uma mudança em toda a organização?

Escrevi anteriormente que os esforços localizados só vão tão longe e mantenho isso. Quando toda a organização faz uma análise crítica de como ser mais eficiente, é aí que você vê uma melhoria real. Esforços localizados só vão tão longe - mas vão longe e, quando o fazem, trazem consigo o capital da influência.

O take-away

Vou concluir com estes princípios finais:

1. A dívida de sistemas é acumulada para qualquer atalho de negócios (software, design, processo ou outro). Isso, por si só, está OK.
2. Muita dívida é uma coisa ruim e requer um pagamento contínuo e intencional.
3. Este pagamento deve ser feito pela equipe sênior. A equipe sênior também deve se concentrar em como reduzir o risco de assumir dívidas futuras (procurando primeiro as ineficiências locais e depois as ineficiências de todo o sistema). Os idosos não devem trabalhar em entregas, mas quando o fizerem, deve ser uma vez. Estabeleça ciclos de feedback que perguntem "Por que isso foi necessário e como podemos evitá-lo no futuro?"
4. Uma boa medida da saúde da Dívida de Sistemas é observar a saúde da integração de sua equipe júnior. Planeje a saída de sua equipe júnior após 18 meses. Isso está ok. Capacite a equipe sênior para torná-los eficientes o mais cedo possível.
5. Encoraje a voz da equipe Júnior para identificar problemas. Mesmo problemas ingênuos são indicativos de um problema mais sério ("Quando recebo meu endereço de e-mail?"; "Como posso obter dados de teste?"; "O que nossa equipe faz?"; "Acabei de pegar o código-fonte e Estou recebendo erros de compilação.")
6. Planeje a saída de qualquer pessoa em qualquer função após 18 meses. Isso também está certo. A Equipe Sênior deve estar presente para trabalhar na construção dos processos e pipeline que permitem a entrega contínua , apesar das interrupções . Eles devem estar construindo processos autossuficientes, equipes autogerenciadas e auto-organizadas. A equipe júnior deve eventualmente se cansar do trabalho, porque se tornou repetitivo. Os membros da equipe devem se tornar redundantes e desnecessários constante e ativamente.
7. Plano para quem vai ficar além de 18 meses. Apesar de trabalhar para se tornarem redundantes, você nunca ficará sem trabalho que gere eficiência. Defina uma Estrutura de Carreira que eleva Juniores a Intermediários, Intermediários a Seniores que se alinha a eficiências focadas em resultados.
8. Trate o primeiro dia como se fosse o último dia: no primeiro dia de trabalho, os funcionários têm a melhor perspectiva do que é necessário para embarcar. Eles devem estar pensando: se outra pessoa entrar depois que eu sair, como isso pode ser melhorado?
9. Faça reuniões regulares apenas para perguntas estúpidas. Permita que as pessoas enviem (anonimamente) suas perguntas mais estúpidas. Você encontrará as maiores lacunas de conhecimento (e problemas) dessa maneira. Estes devem ser abordados.
10. Agende reuniões regulares de 'pagamento': reúna a equipe sênior e procure por ineficiências. Custo seu impacto. Custo sua resolução. (Esta lista é o motivo pelo qual sua equipe sênior nunca ficará sem trabalho.)
11. A parte mais importante do Agile é sua adaptabilidade. Ajuste com frequência. Tenha ciclos de feedback. O que estava funcionando antes não vai funcionar sempre. Isso não é um problema - essa é a norma. Qualquer um que seja resistente a mudanças e experimentações contínuas é uma parte maior do problema do que imagina.
12. Por último, e talvez o mais importante: este não é um exercício de 'equipe'. Este deve ser um exercício em toda a empresa. Embora você possa impulsionar as eficiências locais em sua equipe, elas só irão até certo ponto. Dito isto, se você não estiver em posição de influenciar uma abordagem de toda a organização, obtenha a adesão de seu gerente e, em seguida, crie estatutos em torno de suas equipes que isolem sua equipe de fatores externos. Trabalhe com seu gerente para definir o escopo de seu sistema menor, suas entradas e saídas e obtenha a aprovação dele sobre como você planeja avaliar, aumentar e pagar sua dívida de sistemas.

Isso é tudo! (Ele escreveu, reconhecendo toda a ironia de ter escrito seu artigo mais longo.)