Nossa equipe desenvolve produtos de crédito e garantia para pessoas jurídicas. A direção é jovem, as primeiras edições começaram em 2018. Fizemos check-in e estudamos o mercado, lançamos um cheque especial, um empréstimo para aumentar o faturamento e garantias bancárias. Os planos eram lançar um empréstimo contra um contrato, empréstimos hipotecários e outros produtos.
Sintomas
Nosso processo de iniciar rapidamente a mecânica do supermercado tem acumulado muletas. Nós os toleramos e, como você deve imaginar, uma vez percebemos que as tarefas dos processos começaram a se desenvolver por muito tempo. Isso se refletia na constante transferência de lançamentos, as tarefas não eram concluídas no prazo. Os bugs estavam se acumulando, afetando um pequeno segmento específico de clientes.
Houve situações em que a liberação para a próxima tarefa, que já havia sido movida por dois meses, foi novamente adiada indefinidamente. Ao mesmo tempo, a liberação do cheque especial quebrou as garantias bancárias. Houve uma dessincronização da compreensão do produto. Os desenvolvedores consideraram coisas importantes que a equipe de negócios nem prestou atenção. Por outro lado, as principais características dos produtos permaneceram desconhecidas.
Para sair da situação de crise, foi criado um grupo de trabalho, que se encarregou de fazer “rápido e bom” de “ruim e longo”. Para nós mesmos, definimos metas para melhorar o desempenho e reduzir o número de bugs.
Problemas
Aprofundando os processos da equipe, encontramos um emaranhado de problemas que não podiam ser resolvidos individualmente, eles exigiam uma abordagem integrada:
- pilha de tecnologia antiga;
- processo kanban longo e torto;
- os negócios subiram para os assuntos internos de desenvolvimento;
- a equipe de desenvolvimento estava perdendo o interesse no projeto;
- toxicidade geral.
Contarei com mais detalhes como isso foi expresso.
Pilha de tecnologia antiga. Nosso processo foi escrito em IBM ODM, um sistema com uma série de recursos que atrapalhou a equipe. Eles foram descritos em detalhes pelo nosso arquiteto Denis Kotskinno caso de um projeto vizinho (embora houvesse IBM BPM, mas em geral tudo é justo). Separadamente, observo que não existem no mercado especialistas com experiência neste sistema.
Processo de entrega longo. Oficialmente, nos posicionamos como uma equipe kanban, mas os processos pareciam um cruzamento entre cascata e scrum. O legado do desenvolvimento em cascata é que negócios, desenvolvimento e teste se comunicam apenas no cartão Jira. Todos tinham um pensamento claro: "Fiz minha parte no trabalho, minha cabana está no limite."
Não viemos para o Kanban imediatamente. No início, usamos Scrum com sprints, que se mostra melhor em projetos jovens. Então eles perceberam que era moralmente difícil para a equipe transferir tarefas de sprint para sprint e mudaram para kanban. Então ficou claro que ninguém sabe trabalhar com o fluxo de entrada, o ciclo de desenvolvimento começou a aparecer. Isso se manifestou no fato de que as tarefas do negócio eram recebidas uma vez por semana, depois a equipe avaliou, ficou claro que nada estava claro, e a tarefa foi enviada para a semana seguinte. Ao mesmo tempo, em palavras, fizemos kanban e procuramos gargalos.
Eu entendo que as ideias de Kanban e Scrum não se contradizem e existem exemplos onde uma combinação de metodologias mostra bons resultados. Mas quero enfatizar que havia uma posição radical do kanban puro. O grande número de retornos do teste ao desenvolvimento também diminuiu bastante, o que sinalizou a baixa qualidade da tarefa nos estágios iniciais.
Violação do modelo de papel. Os analistas de negócios estavam engajados na arquitetura - eles propuseram uma solução técnica para o problema. Isso levou ao fato de que muitas vezes abandonaram a descoberta profunda em favor da elaboração e especificação da solução, e esse hack, juntamente com uma arquitetura fraca, desacelerou o desenvolvimento várias vezes.
Perda de interesse da equipe no projeto.Uma equipa jovem, talentosa e ambiciosa. Inicialização pura. Após o lançamento e expansão, começaram as dores do crescimento. A pressão constante do negócio, a complexidade do desenvolvimento devido à falta de refatoração, problemas internos acumulados, o acúmulo de meses à frente levaram à fadiga banal e ao esgotamento.
Por causa de tudo isso, a atmosfera na equipe azedou. Os problemas eram corrigidos no retro, mas não resolvidos, e vagavam de semana para semana. A toxicidade geral disparou, qualquer diálogo sobre o trabalho transformou-se em censuras mútuas.
O que nos fizemos
Falando francamente, no início entendemos apenas que precisávamos reescrever o processo do zero para nos livrarmos das muletas e fortalecer a equipe com desenvolvedores experientes. Seis meses depois, posso citar mais duas coisas que nos ajudaram:
- Reconstruindo o processo kanban. Graças ao centro de entrega da Tinkoff Biznesa, que rapidamente se aprofundou em nossos problemas e ajudou a adaptar Jira.
- Sincronização de negócios e TI. Aqui, fomos movidos pela crença de que a equipe deve ter um bom entendimento do produto, e não apenas executar as tarefas que o trarão.
No final, reescrever o processo resolveu o problema da pilha de tecnologia e ajudou a se livrar das muletas. O repensar do processo Kanban ajudou a reconstruir o modelo e reduzir o número de devoluções, ou seja, aumentou a velocidade de entrega das tarefas ao produto. Uma série de atividades de sincronização e repensar os formatos atuais endireitou a atmosfera geral.
Parte 1. Reescrevendo o processo
Então, começamos a reescrever o processo do IBM ODM para o Camunda. Os motivos da escolha da Camunda estão descritos no artigo de Nikolay Nshipyakov...
Nos processos de candidatura, utilizamos esse termo como fase - uma parte logicamente fechada do processo, com um significado claro para o cliente, por exemplo, “Recolha de documentos” ou “Assinatura de um contrato de empréstimo”. A primeira tarefa para nós foi lançar um contrato de empréstimo. Percebemos que a lógica das três etapas é específica para ele, e o resto não difere das etapas análogas de um empréstimo circulante. Na verdade, escrevemos três etapas de um novo produto na Camunda. No futuro, todo o estágio foi reescrito quando uma tarefa de negócios apareceu para sua mudança séria.
Surge uma pergunta natural: como negociamos com a empresa? É claro que reescrever uma funcionalidade que já está funcionando leva mais tempo do que modificá-la no mecanismo antigo. Acabou tudo de forma simples: os colegas estavam prontos para investir em um novo processo, porque viram como funcionava bem em um projeto vizinho (e olá de novo, DenisKotskin) Ao mesmo tempo, o tempo de desenvolvimento do novo motor não foi muito maior, já que iniciamos o rodízio: os queimados se mudaram para outros projetos, contrataram funcionários com experiência no desenvolvimento e desenho de processos de negócios para substituí-los.
Parte 2. Alterando a ordem de realização de tarefas
Ao mudar o processo de desenvolvimento, nos baseamos nas seguintes diretrizes:
- Não deve haver etapas que não estejam refletidas no quadro.
- Conhecimento técnico deve ser dado à equipe.
- A equipe deve entender como a tarefa afeta os negócios.
Ao mudar o processo Kanban, identificamos novos estágios que anteriormente passavam implicitamente pelo estágio de desenvolvimento: isso é arquitetura e o encontro de três amigos. Naturalmente, a arquitetura não se realiza em pequenas mudanças, mas tentamos fazer uma reunião de três amigos para qualquer tarefa. Nastya tem um artigo sobre o método Three AmigoTravieso... Quero deixar um agradecimento especial a Nastya: seu treinamento em testes Agile nos inspirou a fazer muitas mudanças dentro da equipe.
A equipe recebe dados sobre o valor do produto no formato de uma história de usuário e uma avaliação do impacto da tarefa no produto. Pode ser difícil identificar o blefe de clientes empresariais experientes. Por exemplo, a classificação “Esta regra é importante, será verificada em todas as inscrições” é muito menos informativa do que “Fizemos uma análise, a regra recusará 10 inscrições adicionais por semana”. Portanto, antes de submeter uma tarefa ao desenvolvimento, eu valido a qualidade do valor escrito, como representante da equipe de negócios que compartilha os valores dos desenvolvedores.
Também desistimos de práticas que não funcionavam para nós. Por exemplo, agora raramente fazemos retro, apenas quando necessário - quando a necessidade de discutir algo se acumula. Isso acontece cerca de uma vez por mês. Com certeza resolveremos os problemas indicados no retro, pois é importante que cada membro da equipe veja mudanças positivas nas questões que o pesam.
Paramos de usar storypoints e avaliação de equipe de uma tarefa - trabalhamos com prazos que recebemos do negócio e, dependendo deles, gerenciamos o fluxo de entrada. Em grandes tarefas que são feitas por alguns meses, fazemos a decomposição: permite fazer uma espécie de check-points e aumentar a precisão do devido. Para monitorar o progresso, nos reunimos periodicamente e discutimos se estamos dentro do prazo. Se percebermos que não é, ajustamos o fluxo de entrada e fazemos menos tarefas pequenas. Quanto à precisão em cumprir o prazo, só posso dizer que, para nossa tarefa principal atual, nos encaixamos no prazo.
Em relação à redistribuição de funções, fortalecemos a equipe com um arquiteto e um segundo analista de sistemas. A equipe de negócios tenta explicar claramente o que é necessário na tarefa, que valor ela carrega, mas não para aconselhar ou entrar no funcionamento interno do desenvolvimento. Também cuido da equipe de negócios.
Parte 3. Sincronização das equipes de TI e negócios
Usamos vários formatos para sincronizar negócios e desenvolvedores.
Demonstração por tarefa. Esta é uma reunião de todos os interessados - analistas de portfólio, departamento de risco, profissionais de marketing e especialistas em TI - com uma discussão sobre o valor, o problema problemático e a solução técnica.
Uma reunião importante onde você pode encontrar erros perdidos na fase de descoberta e ter tempo para corrigi-los. Além disso, o gerente que lidera a tarefa não sabe ao certo quais processos da empresa serão afetados pela liberação. Conosco, tal publicidade nos permite prevenir situações em que mudanças no processo interrompam, por exemplo, relatórios analíticos.
Retro na tarefa.Nesta reunião, discutiremos os problemas de desenvolvedores e clientes que eles encontraram durante o desenvolvimento do problema. Conduzimos isso após a análise pós-lançamento - quando as paixões diminuíram e todos estão prontos para um diálogo construtivo. Depois de descobrir os motivos, formamos pontos de crescimento e uma nuvem de ideias, que tentaremos no futuro.
Realizamos palestras sobre produtos no formato de um programa educacional e posterior discussão. O objetivo deles é envolver o pessoal de TI no contexto de negócios. De acordo com o feedback coletado na forma de uma pesquisa com a formulação mais geral "Avalie a palestra de hoje", a avaliação média é de 8,5 em 10.
Resultado
Seis meses depois, reescrevemos mais de 80% dos processos, lançamos um empréstimo contra um contrato usando um motor completamente novo. O clima de equipe melhorou e nos tornamos mais eficientes. Para verificar isso, fizemos uma pesquisa com a equipe e tiramos estatísticas de Jira.
A pesquisa perguntou sobre o clima na equipe, a qualidade das especificações, desenvolvimento e arquitetura, a qualidade da comunicação com o negócio. De acordo com os resultados da pesquisa, a pontuação média dos rapazes que estão no projeto há mais de seis meses subiu de 6 para 8 pontos em 10. Infelizmente, a pesquisa não é totalmente honesta, pois foi realizada após as mudanças. Os números apresentados referem-se ao início do ano e ao início de julho. Portanto, é justo dizer que a situação da equipe melhorou, mas não se pode dizer o quanto.
O desempenho (número de tarefas por dia) dobrou durante esse período. Naturalmente, não à custa da decomposição: concordamos antecipadamente com certos padrões aos quais aderimos.
O número de retornos do teste ao desenvolvimento diminuiu ligeiramente. Ou seja, com um aumento múltiplo no número de tarefas exibidas para produção, o número de devoluções não aumentou. Isso indica uma melhoria na qualidade do desenvolvimento da tarefa nos estágios de descoberta e arquitetura. O número de bugs encontrados na produção não mudou.
O que aprendemos
Agora formularei algumas idéias que a equipe e eu aprendemos com nossa experiência. Se você tiver problemas semelhantes em suas equipes, espero que eles ajudem você também.
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .