Como sobreviver a uma equipe e a um líder de equipe dentro de um tamanho ágil XXXL

Sergey Rogachev desenvolve dois tópicos na Rússia: Scaled Agile Framework (SAFe) e Objectives and Key Results (OKR), e também conduz uma pesquisa "Agile in Russia" (a amostra inclui 1.500 respondentes). Graças a ele, já estamos sistematicamente, como país, abordando a resposta à pergunta: em quais indústrias o Agile funciona para nós, onde não funciona e quais os resultados que dá. Com base nas estatísticas, você pode entender onde sua empresa está localizada, se você precisa do Agile, por que e o que pode alcançar com ele.



Na TeamLead deste ano, Sergey falou sobre como o Agile está se transformando em uma grande organização e, consequentemente, como seu ambiente (líderes de equipe e equipes) está mudando e quais novos requisitos estão sendo impostos a vocês como líderes. E ele mostrou todo o processo Agile com fotos.









Introdução ao Agile



Se você já tem o Agile, como você decidiu? Você decidiu por conta própria e conscientemente de que exatamente este processo (Scrum ou Kanban) você precisa e o que exatamente ele ajudará a resolver seus problemas? Seu primeiro contato com o Agile foi assim?







... ou isso aconteceu?







Em grandes organizações, a história usual é quando um gerente chega: “É isso, amanhã todo mundo é Scrum! Não há tempo para descobrir - você é um Scrum Master ou um Product Owner. " Além disso, a partir do estudo "Agile in Russia", os números mostram: quanto maior a escala, mais frequentemente essa história ocorre. Mas não importa como você conseguiu entrar no Agile, vamos descobrir onde você chegou, o que é esse ambiente e quais requisitos ele impõe a você e suas equipes. Se isso não for feito, muitas vezes a implementação do Agile se transforma em uma fábrica de recursos.



No passado, os desenvolvedores pegavam ingressos de Jira. Agora eles fazem a mesma coisa, mas pegam do que agora é chamado de carteira: uma carteira é enrolada até você, você retira dela e a esteira continua. Ao mesmo tempo, em algum lugar, seus produtos apresentam ao usuário o que aconteceu no final: usuário e produto, beijo!







É realmente ágil? Nós não fizemos isso por isso.



O que é Agile e por quê?



Você sabe que Agile é uma abordagem de como executar projetos diante de grandes incertezas. Esta é a matriz de confusão de Stacy:







Agile funciona bem em uma situação em que você tem duas grandes incertezas:

  • o que você precisa fazer por seus consumidores para que votem em sua empresa e produto com dinheiro;


ou

  • você não sabe com quais tecnologias implementar isso,


então você se encontra em um ambiente complexo no qual é oferecido:

  • desista da opinião de que você sabe o que seus usuários precisam;
  • apresentar hipóteses;
  • conduzir uma série de experimentos;
  • obter feedback do usuário final (inicialmente insatisfeito e, no futuro, esperamos encontrar uma maneira de resolver seu problema).


Como resultado, suas equipes e, em geral, toda a sua organização têm dois focos:

  • Qual é o valor do cliente? Você precisa aprender como medi-lo trabalhando sistematicamente com o valor do cliente.
  • Faça isso rapidamente. Às vezes, é dito que a resistência de uma equipe é medida pelo número de hipóteses testadas por unidade de tempo.




Como colocar tudo isso em nossas realidades?



Qual é a tarefa do líder?



Existem dois atores no sistema: você, como líder, e suas equipes. Considere um exemplo simples: uma equipe fabrica um produto, mas o cliente está insatisfeito. O que devemos fazer como leads, qual é a nossa tarefa nesta história? Claro, descubra qual é o problema: você, como um especialista, vá e descubra. Digamos que a equipe de desenvolvimento envie para teste no último dia, então um grande número de problemas atinge o usuário. O que vamos fazer a seguir?



Já sabemos qual é o problema, identificamos. A coisa mais fácil de fazer agora é vir para a equipe e dizer: “Escutem, rapazes, vocês estão fazendo isso agora - não vamos fazer isso! Vamos fazer direito. ” Isso geralmente é feito com crianças. Digo ao meu filho de sete anos: "Vladik, não faça isso, por favor!" E isso, aliás, realmente funciona - ele para de fazer isso. É verdade que mais tarde minha esposa me disse que ele só não faz isso na minha frente. E quando estou no trabalho, tudo continua como antes.



Portanto, não funciona. O que fazemos então? Mudamos o processo, fazemos perguntas à equipe sobre o que pode ser feito para não fazer mal. Basicamente, tudo o que podemos como líderes é customizar o ambiente que determina o comportamento de nossas equipes. Criamos um ambiente que torna o comportamento negativo impossível e motiva as pessoas a se comportarem de maneira diferente:







Por exemplo, você está implementando Scrum. A partir de agora, fica impossível não entregar o resultado pelo menos uma vez a cada 2 semanas. Não, um desenvolvedor pode fazer isso, mas ele receberá um feedback motivador e estimulante quando você, como líder, convidar pessoas para revisar o sprint, que dirão tudo o que pensam sobre o produto, sem hesitar nas expressões. Aos poucos, por algum motivo, ele fica um pouco com vergonha de arrastar a mesma tarefa todos os dias - todos os dias ele tem que responder ao Daily Scrum o que fez ontem, o que fará hoje, e até com o acréscimo maldoso “dentro da meta do sprint”.



Ou seja, você cria um ambiente que muda gradualmente a maneira como as pessoas pensam, e elas começam a se comportar de maneira diferente. Nossa tarefa é pensar constantemente em como configurar o ambiente. Nesse sentido, não nos tornamos líderes de pessoas, mas mecânicos de montagem do sistema. Imagine um sistema - as engrenagens-parafusos giram por si mesmas (esses são nossos especialistas inteligentes), e existe atrito entre eles. Você corre com uma lata de óleo e adiciona onde algo começa a rachar - você configura um sistema que funciona por conta própria.



E os mais legais de nós fazem com que o sistema, por algum motivo, comece a se desenvolver. Por exemplo, você cria um ambiente no qual a equipe é capaz de ver os resultados do seu trabalho e, como dizem, se auto-orientar: o que mais pode ser feito para ficar ainda mais legal? No entanto, se você configurou tal sistema, você está com problemas, tristeza (ou alegria) - você não é mais necessário por este sistema (pelo menos no dia a dia), o sistema começa a se desenvolver. Isso é o que chamamos de equipe auto-organizada.



Mas como isso pode ser alcançado?



Qual é a responsabilidade da equipe Scrum?



Vamos de baixo para cima - pegue apenas uma equipe Scrum, sem escala ainda. Uma pergunta para você: quais são as responsabilidades das equipes no final do sprint? Quando a corrida termina, por que você os repreende?







A resposta usual é para recursos. Se uma equipe é uma fábrica de recursos, como os recursos estão relacionados entre si? Por que estamos fazendo esses recursos, e não outros? Não há resposta para essas perguntas - tal ambiente ainda não foi criado. Um exemplo clássico é a diretoria da equipe da Avito há cerca de 2,5 anos. Pode-se perceber que ao final do sprint muitas tarefas ainda estão inacabadas - apenas cerca de 40% estão prontas:







Vamos descobrir qual é o problema. Um dos problemas mais comuns no início é que as equipes não sabem avaliar. Precisamos ensiná-los o que é o Story Point, como abordá-lo corretamente se houver apoio, frente, etc. na equipe. Mostre a eles como fazer isso com um exemplo.



Há outro problema - eles podem fazer tudo, mas não têm foco. Em seguida, trazemos a equipe para uma retrospectiva e perguntamos: "Qual foi o propósito do seu trabalho?" Em resposta, uma cabra olha para o botão de acordeão e a pergunta: "Quais são os objetivos do sprint?" OK, vamos colocar em uma caixa grande o que você tem feito nas últimas duas semanas. Eles soam, você escreve. Depois disso, todos anonimamente colocam uma classificação no adesivo: "Até que ponto vocês, como equipe, alcançaram esses objetivos de sprint?" Ou seja, a equipe tem que responder à pergunta, revendo tudo o que foi feito:







Vejamos exemplos.



Metas de sprint - 8



Em essência, essas são tarefas comuns. Além disso, criei um ambiente que mostrava que cada funcionário tinha seu objetivo (tarefa). E quando outra pessoa atendeu, peguei um marcador de cor diferente:







Vê-se que cada um tinha seu trabalho. E o entendimento da equipe de como atingimos a meta é completamente diferente. Depois disso, geralmente é feita a pergunta: "Quanto somos uma equipe?" Pois parece que cada um serrou apenas sua própria obra. Provavelmente, o cara que deu um duque estava realmente carregando uma tarefa difícil e parece que ninguém o ajudou. O camarada com os nove não ajudou em especial - reduziu a tarefa e, provavelmente, no final do sprint estava empenhado no autodesenvolvimento, embora na outra parte da equipa houvesse bombardeamentos e fosse necessária ajuda.



Gols de sprint - 6 peças



É uma equipe diferente, mas a situação é a mesma. A compreensão da realidade já está perto de 8-9, mas há um seis. Este é exatamente o líder da equipe - ele entendia melhor do que ninguém o quão perto eles estavam da meta:







Gols de sprint - 5 peças



Comprimindo metas. É engraçado, mas já existe uma distribuição normal. 3-4-5 e 7-8-9 são duas subequipes de três pessoas dentro da equipe, que juntas arrastaram um trabalho e mais ou menos tiveram sucesso. Os caras do 3-4-5 tinham uma característica difícil, eles não aguentavam. Mas eles são quase os mesmos entendem que resmungaram. Os três seis são os idosos que entendem melhor o que está acontecendo porque ajudaram os juns nas duas partes:







Gols de sprint - 2-3 peças



E se você beliscar? Quanto menos metas de sprint, mais compreensão da realidade - o que realmente fizemos e o quanto alcançamos - começa a coincidir na cabeça das pessoas:







Por que mostrei tudo isso? Por que é legal se o time tem um objetivo?



A Importância do Propósito no Agile



Porque o Agile se diferencia dos clássicos por isso:







Nos clássicos, prometemos um conjunto de recursos e podemos continuar jogando: ou investimos mais recursos no desenvolvimento ou vendemos os prazos. Existem apenas esses dois parâmetros, porque você precisa fazer todo o volume.



No Agile, entendemos de antemão que estamos em uma área de incerteza e não sabemos de que conjunto de recursos nossos consumidores realmente precisam: só temos hipóteses. Às vezes eles dizem alucinações, e o maior especialista nelas é o nosso Product Owner. Ele alucina dentro de duas restrições: os recursos estão comprometidos (equipe em tempo integral, todos 100% alocados) e o sprint terminará exatamente quando terminar, nem antes nem depois. Ambos os parâmetros são fixos e queremos que o escopo seja flutuante. Isso não é uma coisa ruim, é um recurso legal: gostaríamos de poder mudar o escopo, recebendo feedback - estejamos fazendo isso ou não. Mas você precisa de um medidor - esse é o objetivo. Quando mais o alvo dispara?



Qual é o objetivo da Sprint Review?



Existem duas opções para conduzir uma revisão de sprint.



A equipe mostra ao product owner um produto funcional no final do sprint. Veja como ele olha para ele. Ele fez a pergunta mais crucial: “Product Owner, dê-nos o seu feedback: até que ponto alcançamos o objetivo do sprint? E como precisamos mudar o acúmulo adicional? " O Product Owner tem uma pose fechada: “O que posso dizer aqui? Bem, sim, os botões parecem funcionar. " Surge uma perplexidade: como pode um product owner dar feedback sobre botões de trabalho se não houver informações reais sobre como ele funcionará nos campos, ou seja, não há feedback dos consumidores finais: A







segunda opção é minha história favorita de uma das equipes da Avito, que também cerca de 2 anos. Essa equipe conecta vendedores e compradores no messenger. Possui duas métricas principais:

  • , , , ..
  • , .


A equipe dentro do sprint implementou um recurso banal - uma peça redonda, que mostra que do outro lado da linha o comprador ou vendedor está online: você pode escrever rapidamente e ele responderá imediatamente. Na revisão do sprint, eles mostraram os resultados de um teste A / B, implementando o recurso para produção para um número limitado de clientes e vendo se ele realmente se correlaciona com essas duas métricas. Não havia correlação óbvia e a equipe pediu mais uma semana para coletar os dados e entender: se esse recurso ainda for necessário, como modificá-lo?



Estas são duas opções diferentes. Seu objetivo funcionará quando você não o colocar apenas como um slogan, mas quando for formulado em métricas que podem ser medidas. Caso contrário, é novamente uma profanação.



Quais podem ser os objetivos de um sprint?



Você pode definir metas com base em marcos: faça um lançamento em tal ou tal data, etc. Há poucas informações aqui novamente: como você mede se isso é o que seus consumidores desejam?



OKR oferece uma abordagem diferente: definimos metas com base em métricas e específicas do cliente. Como um cliente interage com seu produto? Como isso afeta o fato de ele resolver seus problemas mais rápido, melhor, melhor, etc. e pronto para votar no seu negócio com dinheiro? Portanto, você deve ter medidores.



Uma das propriedades de uma meta, como diz o OKR, deve ser um nível de ambição. Ou seja, queremos melhorar a vida do cliente para um sprint não apenas, mas em quanto - até 80%, 52%, etc. Este é o medidor para onde você deseja pular:







Resumindo: que tipo de ambiente estamos criando?



O product backlog é apenas um conjunto de hipóteses. Nós, como mecânicos deste sistema, no nível da equipe, devemos mudar mentalmente a atitude das pessoas em relação ao acúmulo. Você tem alucinações em sua carteira. Portanto, sempre faça uma pergunta ao proprietário do produto, empresa, etc. - Por que estamos fazendo isso? Por que você tem certeza de que é disso que nossos clientes precisam? Se não tivermos certeza, como podemos medir se isso é realmente o que eles querem? Mude a mentalidade da equipa e dos seus clientes empresariais para, juntos, abrirem mão da sensação de saberem tudo com antecedência.



A equipe está comprometida com o objetivo do sprint. Por favor, não assuma nenhum compromisso das equipes para definição do escopo. É assim que você essencialmente os empurra para o Waterfall, embora você o chame de Scrum. Não se trata de fazer todos os recursos no sprint. Não, sua equipe dentro do sprint do processo Scrum pode até mesmo mudar seu product backlog se de repente descobrir que o que você alucinou há uma semana não era algo que o aproxima de seu objetivo. Claro, duas semanas é um curto período de tempo e, no final, talvez não mude muito para você. No entanto, mude mentalmente - em escala, este problema surge em toda a sua glória.



O backlog do produto e do sprint é apenas um plano para atingir uma meta. O plano deve ser verificado regularmente em relação ao resultado e alterado em caso de rejeição. Já disse que no Daily Scrum você precisa fazer a pergunta todos os dias: "O que estamos fazendo com o objetivo em geral correlacionado?" Gradualmente, você treinará as pessoas para pensar mais na meta do que no escopo. Mas primeiro, você precisa repetir isso várias vezes para que as pessoas finalmente entendam por que estamos fazendo isso.



O foco está mais no resultado final do que na previsibilidade dos prazos de entrega. Nós nos concentramos mais em obter algumas métricas alteradas do que apenas puxar recursos. É até possível não finalizar alguns recursos: talvez ao completar 2/3 de seu sprint backlog, você obterá uma melhoria nas principais métricas para o cliente, e não importará mais que 2 recursos não tenham sido concluídos. O objetivo é outra coisa.



Sprint Review - avalie seu progresso em direção a uma meta com base no feedback do cliente. Além disso, de clientes reais. Este é um desafio para todos os funcionários relacionados à prática de engenharia que sua equipe usa: integração contínua, implantação contínua, etc. Isso é o que está atualmente assolando outras indústrias onde o Agile está tentando aplicar.



Por exemplo, a empresa siberiana Gurman em Novosibirsk, que fabrica bolinhos, decidiu fazer uma experiência com a área da incerteza: e se você mudar o recheio aromatizante dos bolinhos ou a embalagem, como isso afetará o poder de compra do produto? Legal! - agora faremos experimentos e receberemos feedback. Mas o que significa experimento? Eles chegam ao varejista com um novo formato de bolinhos, mas o varejista não quer fazer pequenas compras e oferece um grande estoque para seis meses - é assim que dura um ano o experimento. Como resultado, Sibirskiy Gurman abriu sua própria loja, onde você pode obter feedback rapidamente, mas a loja é uma parte totalmente cara do projeto.



Em TI, como você pode ver, tudo é mais simples. Tudo já foi inventado. E em outros setores, as pessoas são criativas para obter feedback o mais rápido possível. Mas isso acontece para todos.



O que acontece na escala?



Em algum lugar aqui na foto está sua equipe. E começa: cada equipe tem seu próprio backlog, seu próprio objetivo, você entende quem é o seu cliente, mas por algum motivo muitas pessoas (empreiteiros, partes interessadas, etc.) vêm correndo para você que querem algo mais de você ( por exemplo, coloque suas alucinações em seu backlog), e por algum motivo você também deve fazê-las:







No nível dos sintomas finais, temos o seguinte:

  • Um grande número de dependências.
  • Muitas vezes não sabemos com antecedência de quem dependemos - essa é a pouca transparência de com quem tenho que negociar para lançar algum recurso. Você começa a fazer isso dentro do sprint e nesse momento você vai descobrir: acontece que não podemos mudar a API nós mesmos, temos que correr para ela; mas aqui você precisa concordar com os regulamentos, segurança da informação, etc. Ou seja, não se sabe com antecedência para quem recorrer.
  • , . , . , . .
  • — . - , , ? , , , . .
  • — . : « , ! !» — « ?» .


De onde vem tudo isso em uma escala e por que surge? Consideremos o exemplo de um exemplo clássico de obtenção de um empréstimo, de onde surgem todas essas dependências no banco.



A primeira coisa que o banco deve fazer é dizer às pessoas que tem ótimas condições de empréstimo: alta qualidade, rapidez, etc. Na verdade, trabalhar com um cliente começa com marketing. Em seguida, faz-se a avaliação, o cadastro, etc., até o fechamento total do empréstimo. A empresa possui serviços operacionais que atendem diretamente o cliente e se comunicam com ele:







Depois, há os sistemas de TI que dão suporte, aceleram, automatizam - em geral, eles fazem isso para que o cliente obtenha um empréstimo com calma e rapidez. É aqui que aparecem as nossas pessoas e a nossa estrutura organizacional. Aqui está um exemplo artificial: existem 310 desenvolvedores no departamento de TI de Moscou, 30 pessoas na Estônia e outro fornecedor na América (150 pessoas):







Um verdadeiro exemplo sobre mim. Quando eu estava obtendo minha terceira hipoteca em meu banco favorito, no estágio 2 (avaliação rápida dos pedidos) fui recusado. Na noite do mesmo dia, meu gerente VIP me liga com a pergunta clássica: “Sergey, está tudo bem com você no nosso banco? Talvez eu possa te ajudar com alguma coisa? " Claro, eu topei com ele: “Cara, o que aconteceu? Sou seu cliente VIP. Por que minha hipoteca foi negada quando tudo estava bem para mim? " Ele pediu um tempo limite e me ligou de volta à noite - ele não pôde responder imediatamente à pergunta, porque ele olhou para o CRM e não viu nenhuma informação lá de que eu tivesse enviado um pedido.



A razão é que, naqueles anos, esse banco terceirizava a primeira parte dos serviços operacionais para o parceiro. Ou seja, havia um banco-mãe e um banco parceiro que atendia os clientes na entrada - grosso modo, não foi o banco-mãe que me ama, mas o parceiro que me recusou. Como a responsabilidade de um banco terminava no cruzamento com a responsabilidade de outro, a integração foi interrompida. Um pequeno erro fez a matriz desconhecer que seu querido cliente não era muito bem tratado pelo banco parceiro. Nessas junções, uma empresa muitas vezes perde clientes e, como resultado, dinheiro.



Por que estou fazendo isto? Imagine que sua equipe Scrum - multifuncional em termos de backing, front, etc. - está em algum lugar dentro desta estrutura. A questão principal é: Quão multifuncional são suas equipes na solução de problemas de clientes? Idealmente, a multifuncionalidade deve ser tal que você possa ajudar o cliente em qualquer fase do seu ciclo de vida de comunicação com a empresa. Você pode imaginar quantas competências você precisa para caber em uma equipe Scrum, por exemplo, para 11 pessoas?



Infelizmente, em grande escala, este é o principal problema: a equipe deixa de ser multifuncional em relação ao cliente. A solução é esta: vamos montar uma grande equipe de equipes que, juntas, serão o mais multifuncionais possível.



Aqui está um exemplo (dois adesivos vermelhos). Um autocolante com a inscrição "Hipoteca" significa que estamos a alterar a estrutura organizacional de tal forma que surge uma divisão de hipotecas (ribeiro, tribo, comboio, etc., nas diferentes empresas tem um nome diferente). Combinamos negócios (responsáveis ​​por métricas financeiras para emissão de hipotecas) e equipes (ao vivo em Moscou e na Estônia) para desenvolver sistemas na primeira parte deste fluxo, corrigir quaisquer erros de integração, etc.:







Na minha história, o fornecedor não poderia ser arrastado para este tópico. Eles disseram: "Escreva-nos o TOR, faremos tudo." Mas, em qualquer caso, você forma uma divisão que olha para o seu cliente da forma mais ampla possível. Muitas vezes há um brinde: “Foco no cliente, valor”, mas conte o número de etapas que esta unidade fecha. Quanto mais fecha, mais frio fica, mais precisamente, vai ficando cada vez mais íngreme e vai poder resolver todos os problemas do cliente.



Por que estou contando isso? A tarefa do líder não é apenas construir um ambiente para o desenvolvimento da equipe. Primeiro você precisa entender:

  • Em que contexto você está?
  • Quais etapas e problemas do cliente sua equipe ou departamento resolve?
  • Quem é o seu negócio?
  • Qual é o KPI do cliente final para sua unidade de negócios? Ou seja, o que você melhora, e não só a sua equipe, mas todo o circuito.


Como exemplo, apresento três opções para unidades multifuncionais.



Opção 1: por canal com plataforma



Um deles é essencialmente o feed da web inteiro, onde estão todos os desenvolvedores da web. Por exemplo, para um banco, a principal métrica será a atração, de forma que o cliente tente calculá-la com uma calculadora de empréstimo e se transforme em um tomador de hipoteca.



Um aplicativo móvel (iOS, Android, etc.) já com métricas relacionadas à ativação e manutenção. Também pode haver uma divisão de plataforma, ou seja, fazer um componente, cujos consumidores são outras divisões:







Opção 2: por produtos com plataforma



A segunda opção é mais legal: você altera a estrutura organizacional de tal forma que cada unidade se torne multifuncional em relação aos canais. Precisamos consertar algo nos créditos - fazemos isso tanto no canal web quanto no celular, o mesmo com os cartões de débito. O departamento pode mudar completamente qualquer canal. Mas você precisa fazer isso para que as divisões possam fazer alterações na mesma base de código.



Esta é uma opção mais difícil, mas mais fria. O negócio gosta muito, porque o fluxo de débito está rendendo: dá para entender o quanto ganhamos, além de haver uma folha de pagamento para as equipes de desenvolvimento. Como consequência, você combina receita com custos. Seu departamento se torna uma pequena empresa dentro de uma grande, porque tem seu próprio P&L e você pode ver o quão eficaz você é como micro-organização:







Opção 3: fluxo de valor passo a passo



Os casos complexos têm um grande número de divisões e cada uma é responsável por um conjunto de métricas. Em grandes organizações, esta é a opção mais popular:







Que tipo de ambiente criamos em escala?



Em escala, criamos o mesmo ambiente que no nível de uma equipe. Na verdade, ele faz a mesma coisa, mas estamos aumentando a multifuncionalidade em toda a jornada do cliente. Portanto, há um mar de dificuldades: comunicação com negócios, outras equipes, ciclos mais complexos (não quinzenais, mas trimestrais):







Compartilhamento de planejamento de metas trimestrais: planejamento OKR (planejamento de PI)



OK. Sua equipe já entende que você não pode ajudar seu cliente em todas as etapas. Mas você entende que existe um negócio com o qual você precisa planejar para mudar as métricas do cliente. Veja, ainda há muita gente: cerca de 150 outros especialistas (10-12 equipes). E com quem, ao que parece, terá que se comunicar, porque você depende deles, e eles - de você.



Como comunicar? Em todas as abordagens, o Agile dá uma receita simples: "Basta falar: você tem um vício com alguém, vá falar com ele." Os desenvolvedores, especialmente aqueles que gostam de se comunicar mais com o monitor do que com outras pessoas, dizem: "Bem, não posso fazer isso - como posso apenas falar?" Portanto, todos os frameworks oferecem compulsão de comunicação: “Ok, você não pode se comunicar. Agora você vai se comunicar, mas de acordo com o seguinte algoritmo. "



O planejamento OKR colaborativo (em outra abordagem chamada PI Planning) está ganhando popularidade. A ideia é que por um longo período (um quarto) nós juntos, com toda a galera, entendendo quem é o nosso negócio e nossas dependências internamente, planejemos objetivos comuns. É um evento de dois dias, mas algumas pessoas conseguem realizá-lo em um dia se as equipes já aprenderem a se comunicar. Em termos gerais, este é um evento facilitado de perguntas e respostas de dois dias, como:

- De quem dependemos?

- O que estamos fazendo neste trimestre?

- Quais métricas financeiras queremos obter? Negócios, por favor responda.


Ou seja, garantimos que todos cheguem a um acordo com todos e acertem onde queremos correr até o final do trimestre. Estas são fotos reais de quando, há três anos, o Sberbank foi o primeiro a tentar lançar tais eventos:







O planejamento de OKR conjunto ou planejamento de PI é realizado em etapas.



Briefing



No início, é necessário um briefing. As empresas deveriam dizer: "Gostaria de ver isso no final do trimestre ..." E, por exemplo, aqui acima está o Sberbank há 3 anos, e abaixo - a empresa GameDev Xsolla de Los Angeles. Os americanos, aliás, contaram uma história simples que não têm problemas em ativar novos clientes: está tudo bem com as métricas de ativação. Mas há um problema com as compras repetidas: por algum motivo, a porcentagem de compras repetidas é muito baixa. E o segundo problema é que por algum motivo eles não compram serviços adicionais, o cheque médio é baixo. E o empresário perguntou: "Por favor, todas as funcionalidades deste trimestre são voltadas para a repetição de compras e aumento do cheque médio (serviços adicionais)":







Esta é uma das maneiras pelas quais uma boa visão pode ser: quando falamos sobre contexto de negócios e métricas financeiras. Mas não sabemos com antecedência o que será feito no trimestre. O que acontece depois?



Discurso do arquiteto



Em empresas de TI, definitivamente ouvimos o arquiteto. Uma história interessante para ele! - o ambiente também está mudando. Nessas sessões, os arquitetos finalmente entendem quem é seu cliente (a maioria dos arquitetos corporativos pensa que isso é um negócio):







Este arquiteto queria relatar rapidamente sobre a “terrível” paisagem de Sberbank e fugir: “Eu contei tudo a vocês! Além disso, ele deu uma arquitetura conceitual de 50-100 páginas. O que mais posso fazer aqui? Ainda compreensível, mas se houver alguma coisa - ligue. " Mas após a apresentação, um dos líderes da equipe fez uma pergunta:

- Caro arquiteto! O terceiro cubo do canto superior direito - você sabia que este sistema ainda não está em operação?

- Claro que eu sei. Eu mesmo desenhei esses cubos.

- Você sabia que será comissionado em seis meses?

- Sim, claro.

- Agora lembre-se que estamos na sessão de planejamento das metas trimestrais, e a empresa quer de nós funcionalidades, que, em tese, deveriam passar por este sistema.


Aqui, o arquiteto entende qual é a questão. E a equipe pediu que ele ficasse com eles, para que, quando planejassem suas características, pensassem juntos como tomar uma decisão inadequada.



Enxame (geração alvo)



Em seguida, as equipes partiram para o nado livre. Eles têm três horas e devem gerar metas pelas quais estejam dispostos a assumir a responsabilidade trimestralmente. Isso é chamado de enxame (enxame, zumbido). É uma espécie de rede, mas dentro da estrutura do trabalho:







claro, nem tudo é tão simples. As crianças recebem um algoritmo para atingir as metas adequadas que podem atingir no trimestre. Eles fazem folhas de flipchart que mostram os backlogs estimados de sprint um quarto à frente. Isso é necessário para que depois que eles, levando em consideração a disponibilidade deles, preencham grosseiramente suas pendências e conversem com outras equipes de dependência (quem, para quem, o que fará / não fará o quê), pergunte-lhes: “Se arrastar todas essas obras, objetivos que você vai atingir, e com que medida (métrica) você pode medir o grau de realização? "



Ou seja, planejamos os backlogs de trabalho, depois formulamos metas para eles, depois recusamos esses backlogs. É apenas uma técnica de como chegar a um estabelecimento de metas adequado. Em hipótese alguma pense que a galera vai comprometer todas as equipes para este conjunto de obras do trimestre:

- Equipe, encontre um objetivo!

- ... É isso aí!

- Tem certeza de que vai alcançá-lo?

- Não, você acabou de pedir para vir com.


Não, estamos facilitando, ou seja, ajudamos a chegar a objetivos mais ou menos adequados.

Na foto há representantes das equipes que foram obrigadas a se comunicar. Às vezes, chegam a esta sessão com o sentimento: "Sim, entendemos o que vamos fazer e parece que até conhecemos as dependências de outras equipes, porque conversamos com eles na semana passada." Mas quando você me pede diretamente para dizer o que as equipes farão neste trimestre, as dependências são finalmente reveladas:







Damos a eles uma ferramenta para que, depois de falar sobre seus vícios, possam exibi-los e ver quem depende de quem. Os saltos verticais são sprints dentro de um bloco, os saltos horizontais são equipes. No cruzamento, a equipe coloca qual recurso vai fazer e desenha com uma seta vermelha: “Mas eles nos prometeram fazer um sprint antes da API, então faremos um botão na frente”. Este é um protocolo de acordo que concordamos com você, quem, para quem, quando e o quê:







Apresentação dos proprietários do produto



Mais adiante na apresentação, os product owners mostram os resultados de suas equipes:







O único que está tentando colar no cérebro como o cenário de ponta a ponta funcionará é o negócio. Qualquer pergunta ao Dono do Produto no início do tipo: “Qual cenário de ponta a ponta funcionará?” - muitas vezes permanece sem resposta: “Espere, nós somos responsáveis ​​por este componente. Vai funcionar para nós, sua pergunta não é para nós. As balas voaram do nosso lado, procure em outras equipes a resposta para sua pergunta. " No início, a empresa não entende nada, mas tenta colar essa imagem na cabeça.



Dependências externas



A Xsolla possui a penúltima linha da Tech Ops. A galera já entendeu que é preciso se engajar no DevOps, respectivamente, para trazer o suporte dos ambientes para dentro das equipes. Mas naquela época (há seis meses) era uma unidade externa. O gerente de operação também apresentou - percorreu os adesivos vermelhos e confirmou: “Sim, você me empurrou aqui que precisamos implantar tais e tais ambientes. Eu assumo a responsabilidade, nós faremos ":







É interessante que quando ele disse em um adesivo o que fariam, sua equipe corrigiu:

- Espere, cara, nós não te perguntamos isso, mas outra coisa. Entendi?

- Entendi.

- Você vai fazer isso?

- Eu vou fazer isso.

- ESTÁ BEM.


Eles tiveram um problema com advogados, marketing, designers - esses caras estavam na América (em Los Angeles) e não compareceram a esta reunião. Portanto, as dependências deles foram suspensas, mas havia medo: talvez façam isso, mas você precisa ligar separadamente, comunicar-se, etc. A conclusão desta empresa foi que também os convidam para o próximo planejamento trimestral.



Tratamento de risco



Existe um certo algoritmo para como os riscos são tratados. Ideia principal: criamos um ambiente no qual, ao que parece, a alta administração pode definir tarefas. E não é nem assustador, eles estão prontos para pegá-los. Eles olham: “Se eu fechar o contrato com nossos terceirizados aqui, descobrimos que podemos fazer mais do que eu quero”, e então eles se envolvem.

Estes são exemplos de resolução de problemas que podem ser aceitos se você tiver tudo nesta reunião:







Votação de dedo



A última etapa é verificar se as equipes estão realmente preparadas para assumir a responsabilidade pelos objetivos que desenvolveram. Pedimos que levante os dedos:

  • 5 dedos - retos, muito confiantes em seus objetivos;
  • 1 dedo - com objetivos em geral, é um desastre, eles precisam ser refeitos.


Você olha o quadro geral e se vê pouca confiança na empresa, peça que olhem em volta: “Olha, parece que você mesmo não acredita em seus objetivos. Vá refazê-lo, faça-o para que você mesmo acredite em seus planos. Ninguém os empurra para dentro de você (pelo menos eles tentam) ":







Fim do trimestre retrospectiva conjunta: revisão OKR (inspecionar e adaptar)



No final do trimestre reunimos todos novamente. Na verdade, esta é uma grande retrospectiva (chamada OKR Review em OKR):







vou mostrar o que está acontecendo lá com um exemplo real. As metas que a equipe assumiu para este trimestre estão anotadas. Eles têm uma avaliação planejada do impacto nas métricas, ou seja, naqueles objetivos que o negócio queria da equipe e da empresa. A realização real é avaliada:







aqui novamente atira: você sabe como avaliar o fato do plano não apenas como "Parece-nos que esse recurso provavelmente influenciou", mas se os produtos com a empresa coletaram métricas reais de testes A / B, de algumas opções chegando aos clientes.



Outra opção: se a equipe ainda não configurou o engenheiro, não sabe como chegar rapidamente ao cliente, eles avaliam, como no Planning Poker, apenas com os dedos: "Parece-nos que há tanto atingimos esse objetivo":







Basicamente, eles definiram um percentual de realização: você pode ver que a equipe atingiu 88% no trimestre. A ideia é que essa métrica mostre:

  • Quão ambiciosos objetivos você define com o negócio;
  • Você sabe como transportá-los sem problemas:






No final, há uma retrospectiva regular e cada equipe trabalha separadamente. Ponto-chave: problemas comuns são retirados: não separadamente para cada equipe, mas aqueles que atiram vários de uma vez. Normalmente fizemos o critério 3+ times. Se eles têm um problema comum, então é necessário resolvê-lo no nível de toda a unidade:







Resumo. Qual é o problema do líder?



Qual é o desafio para nós em toda esta história? Parece estar claro o que fazer. Mas você está no contexto de um ambiente mais amplo: outras equipes, a empresa, entendendo quais partes da jornada do cliente você decide por e para quais clientes. Na verdade, existem muitos de nós, tais clientes potenciais e líderes de equipe:







Qual é o nosso requisito na escala? Qual é o problema do líder? O fato de que o tamanho importa ... :)







Cheburashka se transformou em um crocodilo para melhor sobrevivência nos ambientes hostis de grandes empresas ... Em outras palavras, você precisa se desenvolver. Este é um ditado dolorido, mas na verdade, se você não se desenvolver, as pessoas abaixo de você também não o farão. E em uma grande empresa, as demandas são implacáveis ​​sobre o tipo de líder que você deve ser. Você precisa ser capaz de configurar o ambiente para um grande número de equipes, ou seja, para se auto-desenvolver muitas vezes mais ativamente.



O que os líderes sobrevivem no Agile



Basicamente, você precisa parar de gerenciar pessoas. Crie ambientes nos quais as pessoas sejam autônomas. Pare de ser um especialista, torne-se um negociador.

Aqui está o que verificar o quão legal você se desenvolveu em todas essas áreas:







Este ano, realizaremos a segunda TeamLead Conf em Moscou, em vez da Saint TeamLead Conf em São Petersburgo. Já nos dias 16 e 17 de novembro, nos encontraremos ao vivo e discutiremos o que mudou durante esse período. Já ansiamos por verdadeiras conferências face a face. Para que você possa ver o carisma do palestrante no palco e depois peça a ele mais uma hora no corredor. Beber um café normal mensal e ver todas as pistas da equipe que você conhece ao mesmo tempo. E por mais um mês depois disso, classifique os registros com contatos, livros e palavras-chave.



, , , , . : , , -, , .



. . . 2019 .



All Articles