Quais problemas do líder da equipe podem ser resolvidos com a ajuda do jogo

Olá pessoal! Meu nome é Yevgeny Rtishchev, em Sbertekh, trabalho como chefe de desenvolvimento de sistemas de TI nos projetos do Sistema Frontal Unificado. Em 24 de setembro, falei na conferência Saint Teamlead Conf 2018 em São Petersburgo. Meu relatório foi sobre o jogo realizado na equipe, que aliviou muito minha dor de cabeça como líder, ajudou com motivação e disciplina. O público aceitou muito calorosamente o tópico e fez muitas perguntas interessantes e valiosas.

Pareceu-me que alguns pontos do relatório foram perdidos. Portanto, no artigo, decidi falar novamente sobre meu experimento e compartilhar os resultados. Quem não esteve na conferência e quer ler uma história sobre uma ferramenta alternativa para uma rápida revisão de desempenho, gerenciando uma equipe durante um jogo, aumentando o envolvimento no desenvolvimento de produtos e como combinar os conceitos de "gamificação" e burocracia em grandes empresas - bem - vindo .

Introdução

Em seguida, contarei uma história consistente sobre como me tornar um líder de equipe, problemas conscientes e erros cometidos. Não vou esconder isso - a solução será a introdução de um jogo em equipe especial; portanto, se você não deseja e não deseja gastar 10 a 15 minutos do seu precioso tempo, pode ir para a seção "Agora todo mundo está explorando o MotC" e ler diretamente sobre a essência do jogo, erros de cálculo no equilíbrio e ajuste , bem como o que veio dele.

Problemas e dor

Quando cheguei à Sberteh, um novo programa interno foi iniciado e era necessário montar rapidamente uma equipe de desenvolvimento móvel. Um mês depois que saí, meu gerente (que estava me contratando) saiu e todas as suas tarefas e problemas se tornaram meus. Honestamente, antes disso eu tinha pouca experiência em gerenciar uma equipe de duas pessoas por um ano. Pelo contrário, era como orientação técnica e orientação de novos desenvolvedores. A equipe se expandiu rapidamente para 11 pessoas, evitei escrever código, desenvolvendo arquitetura e outras tarefas difíceis. Tornei-me suscetível às emoções e meus princípios de gerenciamento correspondiam ao gerenciamento situacional, e tive que parecer mais a longo prazo, desenvolver pessoas na equipe, criar novos líderes, marcar e incentivar aqueles que são bons em puxar, além de identificar e punir “bandidos” e pessoas preguiçosas.

Eu vi uma saída na introdução de elementos de gerenciamento regular. I.e. precisava de um sistema com regras transparentes para recompensas e punições. Ao mesmo tempo, eu realmente não queria reduzir tudo para
métodos comuns, a reação à qual sempre acaba sendo o oposto.



Primeiro, decidi fazer uma lista de problemas condicionais, ou melhor, aquelas coisas que eu faria
queria melhorar em equipe. Por exemplo, eu queria que os caras não se atrasassem para a disputa, se preparassem para isso, escutassem-se cuidadosamente e ajudassem na resolução de problemas. Muitas pessoas não gostam de stand-ups ou diariamente, porque considere um desperdício de tempo de trabalho.

O primeiro passo foi mudar o idioma que falamos na cerimônia ágil - começamos a fazer um stand-up em inglês. A decisão foi estrondosa: muitos prepararam o texto com antecedência, a duração foi reduzida (o inglês era lacônico e todos tentavam se concentrar apenas na essência).

E então eu percebi que precisava experimentar

Formulamos áreas problemáticas

A tendência ao pensamento sistêmico me dizia que, para fazer alguma coisa, é necessário primeiro formular problemas ou, mais precisamente, as coisas que eu gostaria de melhorar. Então eu
delineou as principais áreas.

Classificação dos membros da equipe

Nossa empresa possui uma linha de notas - esses são alguns níveis que têm suas responsabilidades formais, privilégios e remuneração salarial. O alinhamento real das forças muitas vezes difere do formal por razões óbvias: o número de vagas e suas notas são limitadas, todos os caras vieram para a equipe em momentos diferentes e sob condições diferentes, alguém mostrou um forte crescimento em um curto espaço de tempo etc. O procedimento de atualização é complexo, raro o suficiente e você precisa estar bem preparado para isso, ou seja, nomear objetivamente as pessoas que o merecem. No primeiro procedimento desse tipo, eu estava muito enganado: como era difícil para mim recordar todos os méritos ou fracassos de indivíduos, procedi da minha opinião subjetiva, talvez em alguns lugares por causa de minha própria disposição. E isso está errado.

Erros nessas situações são muito difíceis de corrigir. E eu me enganei pela primeira vez (um minuto de confissão). Mas experiências negativas são um bom professor. Percebi que precisamos de uma ferramenta clara - um indicador simples para ver todas as realizações e falhas de uma pessoa, em que áreas ela está crescendo. As informações sempre devem ser acessíveis e relevantes, e não há problema em ser público - todos os membros da equipe terão menos perguntas com as próximas alterações.

Assistência ao desenvolvimento de produtos

Quando cheguei, a empresa trabalhava de acordo com o modelo em cascata - na verdade, o banco era o cliente e a equipe da Sberbank-Technologies era a contratada interna. Um ano depois, a empresa mudou para grandes Agile - as equipes se tornaram descentralizadas, focadas no desenvolvimento de seus próprios produtos (que poderiam ser submódulos de um grande
sistemas). Nos ombros do proprietário do produto dessa equipe, além do gerenciamento linear e do arquiteto de serviço (no caso de um produto técnico), havia também uma nova função - gerenciamento de produto, ou seja, a formação de sua visão, um mapa estratégico de desenvolvimento, detalhamento e priorização de tarefas, bem como a responsabilidade pelo tempo de implementação.

E eu, como proprietário do produto, realmente queria que os membros da equipe não apenas cumprissem suas tarefas, mas também ajudassem o produto a crescer, trazer novas idéias, tirar parte de minhas responsabilidades e dores de cabeça. Por exemplo, muito tempo foi gasto na coleta de requisitos, desenvolvendo-os e decompondo-os em tarefas lógicas e seqüenciais específicas. Outro problema foi o suporte ao produto e a comunicação com os usuários. Nosso produto é uma biblioteca interna para o desenvolvimento de aplicativos móveis para iOS (já existe uma série de artigos no Habr sobre isso). E nossos consumidores são outras equipes de aplicativos. Em algum momento, o número de nossos usuários alcançou aproximadamente 120 desenvolvedores, designers e gerentes. E eu nem tinha 12 horas por dia para me comunicar com todos. Eu realmente queria que a equipe ajudasse ativamente nisso.

Planejando a precisão e a determinação rápida

Por um longo tempo, nossos indicadores de Story Points (doravante denominados SP) saltaram fortemente de um sprint para outro. Sempre que ocorria uma situação semelhante, devido à chegada de defeitos do PROM, ou
algumas tarefas super importantes não planejadas diretamente da liderança. Os caras queixavam-se regularmente e ficavam insatisfeitos, porque não conseguiam entender aonde o tempo havia passado, se a tarefa recém-recebida era mais importante que o sprint, que valor traria para o produto. Maior complexidade e a abordagem geralmente aceita para avaliar defeitos em 0 SP - sempre adicionei ao sprint
um certo número de defeitos para que possam ser trocados por críticos que chegaram logo durante o sprint.

Algo novo e fresco

Depois de dois anos trabalhando em um produto e na mesma equipe, as pessoas começam a se cansar, seus olhos perdem o brilho louco e a queda de produtividade.
A solução que teve que ser inventada foi acender a luz novamente e um pouco
animar a equipe.

Um pouco sobre a equipe

Eu gostaria de falar um pouco mais sobre a equipe: o proprietário do produto, o analista (também conhecido como Scrum Master) e 9 desenvolvedores do iOS. Você entende agora por que eu queria entender o equilíbrio de poder em uma equipe tão homogênea?



Alguns dados sociais: tivemos duas meninas e a idade dos participantes estava em
22 a 33. As áreas de interesse eram diferentes, mas tentamos organizar
atividades gerais da equipe: jogos regulares de tabuleiro, mini-eventos corporativos,
viagens conjuntas a conferências, etc.

Agora todo mundo está minerando MotC

Eu sempre tive um grande interesse na indústria de jogos. Quando criança, construí mundos inteiros a partir de lego-cubos, desenhei jogos de tabuleiro simples em um pedaço de papel, fiquei viciado em 3D Max e comecei a aprender ferramentas simples para criar jogos de computador - como Dark Basic ou Game Factory. Passei muito tempo no MMO, e o mais estranho - fiz minha própria versão do jogo Diablo 2 no editor de mapas do Warcraft 3 (ele até obteve sucesso na rede local da cidade).

Como você entende, mais uma vez eu queria criar um mundo de jogo e mergulhar
membros da equipe em desafio em tempo real



Os jogos, por si só, contêm uma base muito útil, a saber: competição, pontos e classificações, regras e violações, conquistas individuais e por equipe. Os jogos infectam com entusiasmo (que no nosso caso é semelhante ao envolvimento) e também ensinam a amargura da derrota e as alegrias da vitória.

A única coisa que resta é escolher uma configuração, criar mecânicas e regras, equilibrar a balança e também trabalhar na viralidade condicional.


A maior parte do meu relatório sobre o Saint Teamlead Conf foi dedicada apenas à criação do jogo e à conclusão de todos os pontos necessários (jogabilidade, problemas de equilíbrio, psicologia de 4 tipos de jogadores, etc.). Não traduzirei toda essa informação em texto - espero que os leitores interessados ​​esperem seis meses quando o olegbunin tornar públicas as inscrições (ou me escrever em particular). Você também pode ouvir a conferência do líder da equipe em 2 de novembro .

Como obter o MotC?

Em resumo, você pode obter moedas virtuais para executar determinadas ações:
1. Fechando tarefas de sprint. Isso é importante e precisa ser incentivado, porque é isso que agrega valor ao negócio. 1 Story Point trouxe 1,2 MotC. Por que não é o mesmo valor? Sim, é simples: primeiro, o número mágico já indica que existe algum tipo de coeficiente e, tendo indicado sua presença, você sempre pode alterá-lo com cuidado (para ajustar o balanço). Mais MotC - número inteiro, ou seja, é também um incentivo adicional para fechar um número maior de pontos da história. Para 3 você recebe 3 Motc e para 5 já 6.

2. Correção de defeitos. Como não há avaliação em SP, que seja no MotC. Diferentes níveis de criticidade tiveram peso diferente em termos de MotC. Mas, novamente, para incentivar a correção de defeitos (o que nem todos os desenvolvedores gostariam), um bug fechado sempre traz um número fracionário de moedas, que pode ser arredondado para baixo se mais um defeito não for fechado.

3. Correção de tarefas não impressas. Além dos defeitos, havia outras tarefas urgentes: o servidor de compilação quebrou, os testes de interface do usuário caíram, uma tarefa urgente e importante chegou do gerenciamento e muito mais. Agora, para eles, a pessoa recebeu o MotC e, assim, compensou a falta de SP no sprint.

4. Classificações e classificações. Já foram inventadas 4 categorias: campeão de SP, maximizador de contribuição (número máximo de MotC), herói de sprint e prêmio de equipe. O princípio dos dois primeiros, acho, deve ficar claro a partir do nome, com o resto - mais interessante. O herói do sprint foi escolhido pela equipe que votou no retro, e este foi um dos prêmios mais honoráveis ​​da equipe, tanto em termos de número de Mot quanto em termos de prestígio e importância. A presença de um prêmio de equipe é fundamental porque Isso mostra que não apenas o resultado pessoal é importante, mas também o resultado geral de toda a equipe. Foram inventadas três gradações: sprint regular, sprint superior e sprint com falha. O sprint era considerado normal, se mais de 78% da carteira de pedidos do sprint fosse fechada, se fosse 100%, esse é o sprint superior. No caso do sprint superior, toda a equipe recebeu um aumento generoso. Mas houve um outro lado da moeda - este é um sprint com falha.

MotC Negativo de Mineração

MotCs são importantes. Portanto, foi possível obter moedas com um valor negativo. O anti-mérito levou a isso:

1. Sprint com falha. No caso de executar menos de 78% da carteira de pedidos de sprint, toda a equipe recebeu mineração negativa.
2. Abrindo o defeito. Se houve um defeito inequívoco na tarefa de infusão, o MotC negativo foi obtido pelo desenvolvedor que injetou a solicitação de recebimento, bem como por seus revisores.
3. 3. Um sistema adicional de financiamento também foi inventado por se atrasar para uma discussão ou desatenção com os colegas. Ela agiu com base no princípio de "3 seguidos". 3 ícones idênticos entraram em colapso em um novo, no qual houve uma mineração negativa. Havia uma regra de anistia: ao receber mais de 25 MotC no sprint, o colapso não levou à mineração negativa, mas os crachás não foram redefinidos.

Como gastar MotC?

Sim sim O significado das moedas não está apenas nas classificações pessoais, mas também no fato de poderem ser gastas. Para isso, uma função de ativação foi inventada. Somente moedas positivas podem ser ativadas. Havia uma loja inteira em que havia mercadorias e seu valor. Para controle, seu número era limitado.

O que havia na loja?

1. A capacidade de deixar o trabalho mais cedo ou voltar mais tarde. O hodovichok mais importante.
2. Dia de trabalho remoto.
3. Possibilidade de seleção prioritária de tarefas no planejamento.
4. Recomendação do LinkedIn.
5. Escolhendo um módulo para desenvolvimento no Swift. Todo o código estava no Objective-C, e os caras realmente gostariam de desenvolver no Swift.
6. Bilhetes de conferência (se disponível).

Havia outras posições, mas aqui a regra mais importante é garantir a possibilidade de compra, caso contrário a confiança será prejudicada.

Correções durante o jogo

Durante o experimento, em certos pontos, problemas do equilíbrio primário tornaram-se visíveis.
Quais?

1. Jogadores modelo. Além dos desenvolvedores, havia um analista na equipe e sua capacidade de obter o MotC era muito limitada, porque a maior parte das tarefas para os storypoints foram aguçadas para o desenvolvimento. Além disso, as funções do analista incluíam parte das tarefas administrativas, que eram caras para monitorar constantemente. A solução foi introduzir o conceito de "mineração privilegiada", ou seja, um certo número de MotCs é automaticamente creditado por cumprir tarefas diárias. É interessante notar que no futuro outro desequilíbrio foi encontrado: na ausência de um analista (por exemplo, férias), alguém assumiu suas tarefas e, assim, participou da produção de mineração privilegiada.

2. Depreciação de tarefas. Com o tempo, certas tarefas repetitivas ficam mais fáceis de serem concluídas. Por exemplo, tínhamos um procedimento para liberar uma nova versão da estrutura (nosso produto) - que levava cerca de 1,5 a 2 horas de tempo puro. Com o desenvolvimento do DevOps, o tempo gasto foi reduzido para 30 minutos. Da mesma forma, a remuneração na MotC também caiu. Ou, periodicamente, havia tarefas para preparar novas formas de relatórios ou status. É difícil fazer isso pela primeira vez, mas é mais fácil repeti-lo - portanto, a estimativa em moedas diminuiu. A equipe percebeu esses ajustes adequadamente.

3. Pontos duplos para defeitos. Um exemplo para mostrar que em cada equipe haverá situações imprevistas e as regras precisam ser "ajustadas". Ficamos na mesclagem automática em cascata por um longo tempo (ou seja, ao injetar hotfix, as mesclagens automáticas apareceram nas versões anteriores e foram desenvolvidas). Em algum momento, decidimos interromper essa prática viciosa devido a constantes conflitos de mesclagem no develop-e e passamos à idéia de duplicar tarefas para todas as versões nas quais você deseja fazer o upload das alterações. Isso levou ao surgimento de várias tarefas semelhantes no JIRA:



Como resultado, formalmente de acordo com as regras, o jogador pode rapidamente executar e completar 2-3 tarefas e obter 2-3x moedas. Eu tive que introduzir correções para essas tarefas, porque sua complexidade diminuiu (mas certamente não zero devido a conflitos em potencial devido a alterações em ramificações individuais).

4. A idéia de recompensar por trabalhar com usuários. Eu realmente queria "forçar" os caras a ajudar nossos consumidores (e são cerca de 100 desenvolvedores de aplicativos, cheios de perguntas estúpidas e repetitivas). Tentamos abordagens diferentes: nomear atendentes, manter uma base de conhecimento detalhada, desenvolver uma comunidade de usuários especializados e incentivá-los. Mas apareceu uma solução simples: 1 vez por dia, rapidamente examinei o bate-papo de suporte no Slack e dei aos consultores mais ativos da equipe uma recompensa pequena, mas agradável, na forma de MotC. Caras avaliados

Em geral, um jogo é um processo vivo que deve mudar ao longo do caminho. O principal é garantir-se desde o início e deixar a oportunidade de manobras orgânicas. Mudar a mecânica do jogo pode causar ressentimento entre os jogadores. Inicialmente, eu tinha medo de não conseguir calcular corretamente o equilíbrio entre a mineração e o custo dos “prêmios” - então eu imediatamente indiquei que o número deles na loja é limitado e será reabastecido o máximo possível. Além disso, como você sabe, o mercado de suprimentos é controlado por um monopólio, que sempre pode declarar um déficit ou inflação!

Resultados e Observações

Todo o experimento durou 9 sprints (4 meses). Foram gastos 968 MotCs e 262. Havia três sprints de topo, a mesma pessoa se tornou o herói do sprint quatro vezes, a distribuição do MotC na equipe ficou assim:

	MotC	MotC +
Jogador 1	104	86
Jogador 2	203	203
Jogador 3	148	128
Jogador 4	65	47
Jogador 5	172	92
Jogador 6	58.	40.
Jogador 7	68	68
Jogador 8	95	77
Jogador 9	55	55

Aqui está - o único indicador que eu tanto queria criar.

A propósito, todo o banco de dados foi armazenado em Numbers (xls para MacOS) e enviado aos participantes uma vez por semana (no momento da emissão do MotC para retro). Havia 5 páginas com fórmulas transversais: histórico de mineração, histórico de compras, loja de ofertas, detalhes de mineração e tabela de resumo.

Fizeram uma pergunta na conferência - não demorou muito tempo para conduzi-lo.
A resposta é não. Pelo contrário, comecei a gastar menos tempo configurando tarefas no JIRA em
tudo e sincronizar com um caderno no qual eu escrevia regularmente
todas as tarefas delegadas. A tabela chamada "Detalhamento" foi apenas
um novo tipo de caderno no qual eu poderia escrever instruções e quando elas eram executadas
registre a recompensa. Abaixo está um exemplo de um sprint por jogador:

MotC	Mineração
1	Proposta para o Problema X
1	Ajude Makov a atualizar o ícone da biblioteca para uma demonstração
2	Preparando um Repositório com Boilerplate para IP (Demo para manuais)
2	Preparando um esquema XSD para um exemplo de IP, bem como consulta clichê
3	Fechamento de defeitos
16	Converter 14 SP
4	Maximizer SP

Quando o experimento terminou, perguntei aos rapazes - todo mundo estava feliz com as inovações e confirmei que era fresco e emocionante.


O resultado é uma situação ganha-ganha. Tornou-se mais fácil para mim gerenciar o desenvolvimento, os caras têm novas oportunidades e o espírito de desafio. Alguns caras descobriram por si mesmos novas formas de desenvolvimento e maneiras de beneficiar o produto. Ao mesmo tempo, toda a equipe tentou obter o melhor resultado até o final do sprint.

Não estou tentando provar que esta é a opção de gerenciamento correta ou uma ferramenta ideal - este é apenas um exemplo de como diversificar meu estilo de gerenciamento e, de uma maneira boa, "animar" uma equipe. , , , . Performance Review .

!

PS Facebook LinkedIn , - 2 .