🧒🏻 🖕 😝 Como criar processos e parar de zombar de uma equipe 🚶🏻 ☪️ 💍

Olá pessoal! Hoje eu queria falar sobre processos de desenvolvimento. À medida que a empresa cresce, não apenas o próprio negócio se desenvolve, mas também os problemas se acumulam no interior, principalmente durante o processo de desenvolvimento. Muitas vezes, eles estão tentando resolvê-los introduzindo algumas práticas e metodologias novas. Infelizmente, essa reorganização forçada do processo de acordo com livros e treinamentos muitas vezes leva a problemas ainda maiores - zombaria das pessoas.

Recentemente, falei na conferência Saint TeamLead Conf 2019 , em um relatório sobre como consegui encontrar uma série de problemas no fluxo de trabalho e depois superá-los gradualmente. Aqui tentarei descrever as práticas mais valiosas que me ajudaram não apenas a estabelecer um fluxo de trabalho, mas também a parar de zombar dos desenvolvedores. Os funcionários mudaram de atitude em relação à empresa como um todo e ao processo de trabalho.

Desafios do processo de desenvolvimento

Então, quando as abordagens prontas não deram resultado e estávamos quase desesperados, comecei a analisar os processos e comecei a analisar tudo pelos ossos. O resultado é uma lista de problemas:

O quadro está sobrecarregado de tarefas - havia um verdadeiro caos nele. Olhando para o quadro, entender os processos era quase impossível.
Não houve avaliações normais - não sabíamos como avaliar corretamente as tarefas de acordo com o prazo de entrega. Por esse motivo, os prazos estavam constantemente a caminho, os líderes de negócios entraram em desenvolvimento.
Estávamos constantemente enquadrando os prazos - não podíamos dizer exatamente quando o recurso entraria em produção, na maioria das vezes o lançávamos muito mais tarde do que o planejado devido a fatores externos, por exemplo, a empresa recorreu e pediu para executar rapidamente algum recurso urgente em primeiro lugar.
Não havia como entender como acelerar o desenvolvimento - a contratação de novas pessoas e o carregamento de engenheiros em 100% nem sempre agilizam o processo.
Planejamento e tarefas urgentes - se, de acordo com as tarefas atuais, fosse possível, de alguma maneira, fazer planos e indicar datas aproximadas, as tarefas urgentes que normalmente saíam da empresa interrompiam todos os planos.
As reuniões consomem tempo - o nosso erro mais comum: algo não funciona ou precisamos priorizar tarefas - e vamos nos reunir e discutir. Ou reuniões regulares, onde os desenvolvedores permaneciam por uma ou duas horas e não entendiam o que estavam fazendo lá.
O problema da motivação e envolvimento das equipes - muitas vezes algumas inovações foram simplesmente derrubadas pelas autoridades de cima, sem pedir a opinião da equipe de desenvolvimento, isso não pintou a atmosfera da equipe.

De fato, a tarefa de qualquer líder, seja TL ou CTO, é que ele se torne o elo entre negócios e desenvolvimento.

Para, de alguma maneira, sair dessa situação, nos voltamos para o método Kanban. O que ele nos diz? Vamos melhorar o que já está lá. Bem, fomos melhorar o nosso processo de desenvolvimento.

Colocando ordem no quadro

Começamos a discutir: se os defensores concluírem sua tarefa e entregarem ao front-end, eles a iniciarão imediatamente? Olhando para o quadro, isso é incompreensível. De acordo com os princípios do Kanban, dividimos cada direção do desenvolvimento (tínhamos 5 deles: back-end, front-end, DevOps, QA e design) em duas colunas: Do and Done. O problema imediatamente se tornou aparente: nossa largura de banda não nos permite executar quantas tarefas eles desejam de nós.

Kanban também diz: vamos introduzir um limite WIP e limitar o número de tarefas. Como estabelecemos limites? Empiricamente. Obviamente, eles falharam algumas vezes, mas depois pegaram para que não precisássemos acumular tarefas no local mais estreito. Um lucro adicional do limite WIP é um gatilho, que diz que, assim que tivermos a tarefa retirada, podemos executar o seguinte. Este é um tipo de sistema de tração.

O que isso levou? Os engenheiros começaram a ficar mais atentos às tarefas, porque quando não conseguem resolver um problema, um bloqueador é colocado nele. Não é possível executar mais tarefas, já que há um limite de WIP, os engenheiros devem esperar que eles ajudem a resolvê-lo. Há uma chance de ficar sem tarefas.

Quando começamos a analisar em detalhes o problema de retornar tarefas, verificou-se que todo mundo as faz de maneira diferente, por exemplo, alguém escreve testes e alguém não. Havia regras a esse respeito, mas aquelas que foram deixadas pelas autoridades. Eles não resolveram o problema dos desenvolvedores. Introduzimos novas regras ( Definição de Concluído ), que são integradas ao conselho. Eles poderiam atuar em alguma coluna e no tipo de cartão. Por exemplo, para uma API, você precisa do back-end para documentar todos os métodos e outras coisas. As regras eram acessíveis a todos e visíveis no quadro, e o mais importante, elas vieram dos próprios engenheiros e resolveram seus problemas. Se algo não foi feito, o engenheiro viu e foi fazer.

Tarefas de nota

Não sabíamos como avaliar as tarefas por prazos, e Kanban nos diz: “Sem estimativas”. O que fazer Nós acumulamos estatísticas e construímos esse cronograma. Este é um diagrama espectral, a dependência do número de tarefas no tempo.

Começamos a estudá-lo, vimos no gráfico 3 picos que correspondem a três tipos de trabalho. Com base nesses tipos, uma classificação e critérios para esse trabalho foram desenvolvidos. Introduzimos esses tipos no quadro de tarefas e, em seguida, para cada um no processo, adicionamos regras adicionais. Temos o seguinte:

Concordamos com o cliente, isto é, com a empresa, em um contrato de qualidade de serviço (SLA). Um gerente vem até nós e pergunta: "E quanto você criará esse recurso?" Não podemos dizer quanto faremos com certeza, mas podemos dizer quanto tempo será gasto em um lote inteiro dessas tarefas. Não havia necessidade de scrum poker, e paramos de torturar pessoas com perguntas sobre o tempo. Apenas analisamos as estatísticas e definimos as datas dos negócios.

Obviamente, essa abordagem também teve desvantagens. Por exemplo, isso não funcionou com tarefas de um novo tipo, para as quais simplesmente não tínhamos estatísticas. Eles fingiram estar de maneiras antigas, mas depois acumularam uma quantidade suficiente de dados e esse problema não deu em nada.

Então, nos deparamos com o fato de que algumas tarefas começaram a cair em outros tipos de trabalho. Realizamos uma pequena pesquisa e descobrimos que algumas tarefas foram realizadas muito mais rapidamente, porque a empresa prometeu aos parceiros algo e pediu aos desenvolvedores que as realizassem com urgência. E algumas tarefas, pelo contrário, não eram tão importantes, foram adiadas. Então, temos prioridades, ou seja, acordos sobre classes de serviço de serviços (CoS), colocamos no quadro. E para que os negócios não abusem e não estabeleçam maior urgência para todas as tarefas, foram introduzidos limites horizontais de WIP.

Como acelerar o desenvolvimento

Novamente virou-se para as estatísticas do rastreador de tarefas. Descobrimos que muitas tarefas dependem do quadro em antecipação a melhorias, verificações ou dados adicionais, ou seja, eles perceberam que o desenvolvimento pode ser acelerado. Eles começaram a analisar quantas tarefas estão acumulando, o quanto estão ociosas e descobriram que alguns recursos foram desenvolvidos menos do que esperavam aceitação. Decidimos definir um dia para a aceitação de recursos e o tempo para emissão de tarefas foi reduzido. E então fixamos o CD (Entrega Contínua) e começamos a enviar notificações.

Ficou claro que precisávamos de uma ferramenta para avaliar nossas melhorias. Decidimos usar o diagrama de fluxo cumulativo. Em poucas palavras, como é construído: atribuímos uma cor a cada centro de trabalho (colunas no quadro), coletamos estatísticas sobre quantos elementos (tarefas) estão em uma unidade de tempo em uma coluna e os plotamos no gráfico, colocando-os um sob o outro. No gráfico, o eixo X é o tempo, o eixo Y é o número de tarefas.

O que recebemos daqui? Aqui é fácil ver o lead time (tempo de produção) - a linha horizontal (a largura do fluxo ao longo do eixo X) começa com a declaração do problema e atinge o estágio de prontidão. Assim, aqui você pode ver como a tarefa passa por todas as etapas do desenvolvimento - a linha cruza todas as cores, cada uma das quais corresponde ao seu estágio. E também o limite WIP total da placa - a altura do fluxo ao longo do eixo Y. Como aumentar a velocidade de desenvolvimento? Você pode reduzir o limite do WIP (ou seja, tornar o fluxo no gráfico mais estreito) ou nosso fluxo, que é direcionado da origem para o canto superior direito do gráfico, tende a aumentar ainda mais (ou seja, para aumentar ainda mais a direção do fluxo, reduza seu ângulo em relação ao eixo Y). Para direcionar o fluxo mais forte para cima, você pode introduzir uma nova prática, por exemplo, implementar o Docker ou criar uma base de conhecimento conveniente. Isso não precisa ser uma inovação técnica; uma nova abordagem de gerenciamento também pode causar esse efeito.

Assim, temos uma ferramenta que mostra claramente quais melhorias funcionam e quais não.

Planejamento de negócios, tarefas urgentes e inúteis

O planejamento do desenvolvimento de negócios foi a maior dor. O que nós fizemos? Após receber a tarefa do negócio, foi realizada uma reunião entre o analista e o desenvolvedor, onde a decompuseram, e o desenvolvedor propôs soluções. Como resultado, entendemos quanto e quais recursos a tarefa exigia. E só então os negócios sem nossa participação fizeram seus planos e consideraram quanto podemos liberar recursos. No Kanban, isso é chamado de cadência de reabastecimento .

Em termos relativos, alocamos slots de um determinado tamanho, de acordo com os limites WIP, onde você pode colocar tarefas. Cada slot possui apenas um número limitado de tarefas. De outra maneira, esse método é chamado de "planejamento de copo".

Criamos uma ferramenta simples para negócios (uma tabela no Excel), na qual ela poderia planejar visualmente. Os gerentes brigaram entre si, discutiram qual tarefa é mais importante e depois vieram até nós e deram as tarefas ao desenvolvimento.

Como já tínhamos limitações, o negócio estava mais atento à escolha das tarefas, escolheu as mais importantes e não nos sobrecarregava com nenhuma bobagem que lhes ocorresse. E mais uma grande vantagem: eles mesmos selecionaram as tarefas sem a nossa participação, sem distrair os desenvolvedores para as reuniões, trabalharam em silêncio e não gastaram tempo nas reuniões.

Também voltamos nossa atenção para o problema de tarefas urgentes. Eles começaram a analisar estatísticas sobre eles e perceberam que essas tarefas não são tão urgentes. Por exemplo, precisamos de uma promoção para troca sazonal de rodas dos motoristas. Sabemos que isso sempre acontece 2 vezes por ano. Uma vez repetidos, reservemos vagas para essas tarefas no quadro com antecedência. Não haverá nada urgente - faremos outra tarefa na fila, não ficaremos sem trabalho. Como resultado, descobrimos que 60% das tarefas urgentes não são realmente urgentes.

Houve outro problema. Muitas vezes, vimos recursos, que acabaram recusando os negócios, porque acabaram sendo inúteis do ponto de vista comercial. Sugerimos que as empresas executem recursos de MVP que requerem várias vezes menos tempo que o desenvolvimento convencional. O feedback começou a ser removido muito mais rapidamente, e os engenheiros começaram a perceber que eram experimentos. Anteriormente, quando semanas de trabalho eram jogadas no lixo, eles se preocupavam, pois isso envenenou suas vidas.

Começamos a testar 85% dos recursos de maneira que, no final, liberamos muito tempo, que depois gastamos em hipóteses testadas na prática. Eles já trouxeram o dinheiro da empresa. Além disso, se algo desse errado no processo, o cliente do recurso da empresa poderia fazer correções em um estágio inicial, e não durante todo o ciclo de desenvolvimento.

Como resultado, foi descoberto um fato que nem todas as idéias funcionam. E como eles não funcionam, não os faça. Desde então, os desenvolvedores deixaram de se envolver em trabalho com macacos e fizeram exatamente o que a empresa traz dinheiro.

Reuniões

As melhorias que introduzimos naquela época já haviam matado várias reuniões inúteis. As discussões sobre priorização não eram mais, já que demos isso aos negócios, também planejamos sem engenheiros. Também abandonamos os ataques de cinco minutos aos gerentes com uma solicitação "ajude rapidamente". Havia apenas reuniões realmente necessárias. Também introduzimos a regra de que as reuniões agora estão agendadas para um horário específico, para que todos possam planejar sua agenda.

Como resultado, todas as reuniões sobre boltologia foram transformadas nos seguintes tipos de reuniões:

quando um analista deseja discutir um problema específico com um engenheiro, por exemplo, para encontrar a solução ou decomposição ideal;
quando algo está preso no quadro. Nesses casos, nos reunimos e caminhamos ao longo da placa da direita para a esquerda, perguntando aos engenheiros o que aconteceu, quem poderia ajudar. É importante que saímos das tarefas e não tentássemos calcular o que as pessoas estavam fazendo;
quando planejaram tarefas para sprint (cadência para reabastecimento);
quando eles levaram recursos;
Reuniões entre equipes de desenvolvimento, por exemplo, ao discutir o formato da API ou decidir quais eventos enviar.

Ponto-chave: convidamos para as reuniões apenas as pessoas diretamente envolvidas no assunto da discussão e que não chamavam ouvintes indicados, como antes. Os engenheiros mudaram fundamentalmente sua atitude em relação às reuniões, antes que não gostassem deles, mas agora é o contrário, eles parecem necessários e úteis para eles.

Motivação e envolvimento da equipe

Tudo o que implementamos: limites de WIP, avaliação de tarefas com base em estatísticas, rejeição de tarefas inúteis, etc. descritas acima, levaram à liberação de tempo para os engenheiros. O que eles farão agora? O maior equívoco é que ninguém fará nada. Eu mesmo ouvi repetidamente os caras: "Eu teria refatorado esse código, caso contrário, a perna do diabo quebraria". Sim, a princípio o engenheiro realmente dorme o suficiente e descansa por 2-3 semanas, e depois o que? Ele se senta sem tarefas, começa a se aproximar de seus colegas com uma proposta de ajuda, ajuda a concluir tarefas e, em seguida, os dois já estão sentados sem tarefas. "Vamos enviar correção de bugs" - a coluna com bugs estava vazia. "Envie o código que refatoraremos" - o código ficou mais rápido para escrever, o limite WIP pode ser aumentado. Então eles começam a implementar CD / CI, escrevem uma base de conhecimento. O que aconteceu Os engenheiros começam a fazer muitas coisas úteis, às quais suas mãos não chegaram. Essa é a velocidade que a empresa deseja, mas, por algum motivo, não pode obtê-la de ninguém. Anteriormente, o engenheiro estava bravo, queria que todos estivessem atrás dele e agora o paradigma humano mudou para: "Agora, como posso ajudá-lo?" O número de iniciativas cresceu e todas vieram de baixo, não de cima. E, no final, acabou sendo muito mais útil.

Resumo dos resultados

Conseguimos encontrar um gargalo no sistema e entender que não podemos fazer mais do que podemos.
Eles pararam de lançar trabalho inútil aos desenvolvedores e liberaram tempo para tarefas mais úteis.
Quando os engenheiros não tinham nada para fazer, começaram a avaliar melhor as tarefas, corrigir erros, começaram a automatizar processos e uma base de conhecimento apareceu.
Os engenheiros deixaram de ser estressados e ficaram mais gentis.
Conseguimos acelerar 4 vezes o lançamento de novos recursos por meio de melhorias, otimização do trabalho (aumento dos limites de WIP devido à automação e melhorias).
Temos estatísticas para os negócios e uma compreensão clara do que e como está acontecendo no desenvolvimento.
Aprendemos a economizar tempo (rejeição de tarefas desnecessárias, começamos a pensar nas tarefas com antecedência, a fim de evitar fatores adicionais etc.).
Reuniões e reuniões eram realizadas quando eram realmente necessárias (tornam-se mais flexíveis).
Todos começaram a pensar mais, o número de iniciativas aumentou. As iniciativas que nascem em equipes são sempre melhores do que as que vêm de cima. O processo continuava constantemente e todos se envolviam nele.

Conclusões

Neste artigo e relatório, queria chamar a atenção não apenas para as ferramentas e abordagens que apliquei, mas para o aspecto mais importante, que muitas vezes passa despercebido, mas, na minha opinião, não é menos importante. Começamos toda essa perestroika, porque tínhamos dores e queríamos nos livrar delas.

Você pode implementar algo "na testa" lendo livros inteligentes ou ouvindo um relatório sobre metodologias flexíveis, para que seja possível acelerar o desenvolvimento ou que os produtos funcionem melhor. Mas muitas vezes esquecemos que as pessoas fabricam esses produtos e, quanto melhor vivermos, melhor serão os produtos. Por exemplo, vou até os caras e pergunto: “E quais são suas dores? O que há de errado? ”, Antes de começar a implementar algo. E somente graças a essa abordagem, consegui fazer o que a empresa deseja - velocidade e qualidade no desenvolvimento.

PS Foi-me dito sobre uma empresa na Europa, quando você chega ao escritório lá, pode parecer que uma anarquia completa reina: os desenvolvedores, como queijo na manteiga, jogam consoles, ninguém trabalha. Mas isso é apenas à primeira vista, há uma atmosfera criada especialmente para as pessoas, para que elas possam criar e melhorar. No intervalo entre as tarefas de entretenimento, um joelho escreveu uma solução que foi implementada posteriormente e começou a trazer lucro para a empresa. Espero que nossa administração russa se mova nessa direção em um futuro próximo. E se, por algum motivo, você tiver algo errado, pense no que está fazendo. Bem, ou jogue este artigo para o chefe, mas e se isso ajudar :)

Como criar processos e parar de zombar de uma equipe