Sozinho no campo não é um guerreiro. O caminho para o trabalho em equipe eficaz

Uma equipe é um grupo de pessoas que caminham juntas em direção a um objetivo comum, distribuem tarefas e responsabilidades por um resultado específico entre si. As equipes são criadas para resolver tarefas que uma pessoa não pode concluir. Uma equipe eficaz atinge a meta no menor tempo possível, com custo mínimo.

Reúna algumas pessoas e diga: “Agora você é uma equipe, estamos aguardando o resultado de você”, não vai funcionar. As pessoas precisam se organizar, dar-lhes um objetivo sensato, motivar e resolver problemas.



Apenas sobre essa decodificação do relatório de Evgeny Fedoreev no TeamLead Conf . No relatório, Eugene descreveu em etapas o processo de organização de uma equipe de desenvolvimento eficaz no Banki.ru: contratação, comunicação, compartilhamento de conhecimento e desenvolvimento de desenvolvedores e testadores dentro da equipe e do departamento.


Sobre o palestrante : Evgeny Fedoreev ( hardj ) atua no desenvolvimento de web há 15 anos, 6 deles na posição de líder de equipe, e agora ele lidera o desenvolvimento de novos projetos no Banki.ru.

O que é o Banki.ru?

O contexto da empresa é saber qual experiência será discutida. O Banki.ru é o maior portal financeiro independente do Runet, com uma audiência mensal de mais de 8 milhões de usuários únicos.

O departamento de TI emprega de 50 a 70 pessoas, divididas em 7 equipes de desenvolvimento. Todo o desenvolvimento é realizado internamente, não há desenvolvedores remotos; portanto, não há necessidade de processos e métricas apropriados.

A principal tarefa da equipe de desenvolvimento

Ao me preparar para o relatório, fiz às pessoas uma pergunta:

- Qual é o objetivo da equipe de desenvolvimento?
- Desenvolver.
- O que isso significa? Se uma pessoa senta, refatora, não traz benefícios, não resolve problemas de negócios - isso também é um desenvolvimento?
- ... Ele precisa ser desenvolvido de forma eficaz.

Eficiência no Desenvolvimento

O conceito de eficiência é uma coisa para um gerente e outra para um desenvolvedor.

Para o gerente, o desenvolvimento efetivo é previsível : quando a data de lançamento do recurso ou o prazo para concluir a tarefa é conhecido, a fim de realizar alguns eventos de negócios.

Para um desenvolvedor, isso é trabalho com uma dívida técnica . Esta é uma das dores desde que trabalhamos com elas. dívidas, refatoração, correções e melhorias recebem muito pouco tempo.

O próximo critério de desempenho é o número mínimo de erros. Pode-se escrever que o critério é a completa ausência de erros, mas sabemos que isso não acontece. Além disso, os testadores ficarão ofendidos, porque não serão necessários.

Desafios futuros . Eu deliberadamente não escrevi "arquitetura pensativa". Aprofundar-se e pensar com antecedência na arquitetura é mau, portanto o desenvolvimento deve ser tocado para o futuro, mas sem fanatismo.

Qualquer outro critério que toda equipe tenha.

Processo de desenvolvimento

Começamos a construir processos de desenvolvimento no Banki.ru depois que a empresa começou a se desenvolver e crescer. Novos parceiros e projetos apareceram e 6-9 desenvolvedores de back-end não foram suficientes. Chegamos à conclusão de que precisamos construir o processo de desenvolvimento e formalizá-lo para um trabalho eficaz.

Inicialmente, tínhamos três equipes, cada uma com três desenvolvedores de back-end e um gerente responsável por partes do site. Os desenvolvedores de back-end, além de seu trabalho, ainda estavam digitando e conectando os plug-ins do jQuery, pois naquele momento havia poucas pessoas no front-end.



Levamos dois desenvolvedores de front-end e mais dois testadores para viver sem bugs e pensamos que essa configuração seria suficiente.

Em um mundo ideal, o processo de desenvolvimento deve ser assim.

• O gerente de projeto coloca a tarefa na equipe de back-end e a executa.
• Se for necessária uma revisão, eles enviam a tarefa para a equipe de front-end.
• Após o refinamento, o frontend fornece o controle de qualidade.
• Sem bugs? - em produção.

Sugerimos que o mundo não é perfeito e o controle de qualidade retornará tarefas, pois os bugs estão presentes em qualquer desenvolvimento e adicionamos mais duas setas.



Após atualizar o esquema, decidimos que estava tudo bem e começamos a trabalhar nele - realizamos o planejamento de sprint e as próprias equipes de back-end colocaram as tarefas no plano. Eles trabalharam por 2 meses e perceberam que algo estava errado.

Nosso esquema se transformou. As tarefas saltam como uma bola de pingue-pongue: do controle de qualidade à frente e de volta aos desenvolvedores e até chegam aos gerentes.



As setas demoram muito tempo - o processo de entrega de uma tarefa para combater servidores é muito longo. Isso não nos convinha. Queríamos minimizar o número de setas para que as tarefas fossem concluídas mais rapidamente.

Como reduzir o tempo de entrega?

A primeira coisa que veio à mente foi fazer uma pergunta sobre por que estamos retornando tarefas ? Por que o back-end, o front-end e o controle de qualidade entendem o problema de maneira diferente? Por que as visualizações são diferentes? Chegamos à conclusão de que encontramos o culpado no gerente do projeto, que ele não descreveu as tarefas na íntegra, e pedimos ao PM para descrevê-las de maneira mais completa, para que todos pudessem entender o que significava.

Tínhamos três equipes de back-end planejando. Envolvemos testadores e desenvolvedores de front-end no planejamento , mas para 3 equipes havia apenas 2 desenvolvedores de front-end e 2 testadores. Muitas vezes eles não conseguiram chamá-los, porque alguém tinha que trabalhar.

Dividimos as tarefas separadamente em front-end e back-end para enviá- las ao desenvolvimento em paralelo, testando mais rapidamente e não aguardando toda a cadeia.

Tentamos todas as soluções. Como resultado, o tempo foi reduzido, mas ainda não estávamos felizes.

Nós pensamos no que fazer a seguir. Existem muitas empresas e práticas no mercado, e começamos a estudar, assistir, cavar e chegar à equipe de recursos.

Equipe de recursos

É quando a equipe tem todo o conjunto de pessoas para concluir a tarefa:

• desenvolvedores de back-end.
• desenvolvedores de front-end.
• Desenvolvedores de controle de qualidade.

Também existem conexões entre eles, as tarefas pulam e jogam pingue-pongue, mas as conexões são muito mais curtas e levam menos tempo. Toda a equipe participa do planejamento, ela está interessada no resultado e cria uma imagem única: o que fazer e como executar a tarefa no modo de combate em pouco tempo.

Nesse momento, mudamos para o Agile e o Scrum: convidamos treinadores e treinadores, realizamos master classes na empresa e iniciamos o clássico Scrum - sprints de duas semanas, avaliação, planejamento e preparação. Agora, as tarefas entram no modo de combate mais rapidamente, mas muitos problemas surgiram.

Problemas da equipe de recursos

Naquele momento, tivemos 6 problemas.

• Fator de barramento .
• Planejamento longo . Para o planejamento, reservamos meio dia ou mais: organizamos as tarefas, saímos para almoçar e, em seguida, organizamos. Quando o planejamento terminou, ninguém podia trabalhar e não queria - o dia estava perdido.
• Sprints não fechados . É uma dor grave - a maioria das tarefas nos sprints não chegou à coluna "Concluído".
• A natureza diferente das tarefas das equipes .
• O surgimento de novas equipes .
• Troca de experiência entre equipes .

Existem problemas, vamos resolver isso.

Fator de barramento

Inicialmente, cada equipe consistia em um desenvolvedor front-end, um testador e três desenvolvedores de back-end. Contratamos desenvolvedores de front-end adicionais - duplicamos as funções .

Introduziu reuniões semanais nas direções . Os desenvolvedores de front-end se reuniam separadamente a cada semana e discutiam novas tecnologias, solução de problemas e concordavam em práticas e abordagens comuns. Os testadores também se reuniram, conferiram, decidiram como testar e discutiram autotestes.

Os desenvolvedores front-end introduziram uma revisão de código de comando cruzado , quando um desenvolvedor resolve um problema em uma equipe e o revisa para outras equipes, e após pelo menos duas instruções, a tarefa é testada.

Autotestes foram adicionados . Havia um testador na equipe e não foi possível duplicá-lo, pois não havia tarefas para essa quantidade. Concordamos com a ajuda de um testador de outra equipe : ele cuidará das tarefas da equipe vizinha e substituirá o funcionário que sai de férias. Isso aumentou um pouco o tempo, mas as tarefas foram testadas.

Planejamento longo

Analisamos tarefas de planejamento. No momento dos sprints, todos trabalhavam e codificavam, e ao planejar quase a primeira vez que abriram tarefas e descobriram o que fazer, os testadores esclareceram a "definição de concluído" para entender como testar a tarefa.

O processo foi demorado. Decidimos desmontar as tarefas antes do planejamento : sugerimos que os desenvolvedores analisassem a tarefa em seu tempo livre, fizessem perguntas para que pudessem estar preparados para o planejamento.

Convidamos os gerentes a descrever as tarefas com mais detalhes , mas não muito, para não cavar uma tonelada de documentação.

Deliberamos , deliberadamente , uma hora adicional de higiene e não um tempo livre. Eles se reuniram em equipe, discutiram tarefas e vieram preparados para o planejamento.

Sprints Não Fechados

Isso é uma dor. Talvez alguém as feche, mas conosco na época - não.

Decidimos reduzir a capacidade do sprint de 10 dias úteis para 8 . Pensamos que planejaríamos 8 dias e deixaríamos os testadores por 2 dias.

Na realidade, descobriu-se que quando um desenvolvedor vê menos tarefas, ele as executa lentamente. 20% menos tarefas no sprint não davam nada.

No início do sprint, enquanto houver tempo, o testador fez casos de teste. Em teoria, no início do sprint, enquanto os desenvolvedores estão trabalhando, o testador não tem tarefas. Concordamos que, nesse momento, o testador pode executar todas as tarefas, elaborar casos de teste e, quando a tarefa chegar para o teste, ele executará nos casos de teste preparados e reduzirá o tempo para o teste. Globalmente, isso não ajudou, embora o tempo tenha sido ligeiramente reduzido.

Reduzir a capacidade do sprint e carregar o testador não ajudou, e pensamos em como resolver o problema. Nesse momento, um livro sobre o objetivo e várias práticas de Maxim Dorofeev chamou nossa atenção. Percebemos que empurrar o "não empurrável" não funcionaria e começamos a planejar um sprint a partir de um gargalo - a partir de testes . No planejamento, o testador fez uma avaliação, a capacidade de sprint foi calculada a partir dele e a tarefa foi executada para o testador.

Classe! Fomos aos gerentes para vender essa ideia:

- Decidimos planejar com os testadores. Os sprints fecharão, será legal!
- Espere, o que os desenvolvedores gratuitos farão neste momento? Haverá menos tarefas, eles terão tempo livre!
- Deseja que os sprints sejam fechados, que o desenvolvimento seja previsível ou o principal objetivo das pessoas?
- Não, ainda é um desenvolvimento previsível. Vamos fechar sprints.

Após o diálogo, uma equipe começou a trabalhar de uma nova maneira. O esquema mostrou sua capacidade de sobrevivência, trabalhamos nele, sprints fechados e os desenvolvedores tiveram tempo.

Acontece que os desenvolvedores podem fazer muitas coisas quando estão livres.

A saber: trabalhar com eles. dívida . A equipe sempre tem uma tecnologia comum. dívida com o departamento. Essas tarefas podem ser executadas e testadas. Como regra, aqueles. dívida é refatoração do sistema. O teste de regressão é necessário para essas tarefas, e o testador da equipe nem sempre deve fazer isso. O departamento de testes identificou testadores especiais que conduziram a regressão, incluindo o chefe do departamento de testes. Tarefas para aqueles. a dívida foi dada a outros funcionários para testes e nossos testadores não sofreram.

Analise tarefas da lista de pendências e esclareça os requisitos . Quando o desenvolvedor não tinha tarefas, ele olhou para o backlog, esclareceu os requisitos. No momento do planejamento, as tarefas são totalmente descritas, todas as perguntas são feitas e as decisões são tomadas. Resta esclarecer os detalhes e é isso - o testador avalia e a tarefa foi concluída.

Ajude outras equipes . Naquele momento, ainda praticávamos ajudar outras equipes, nas quais eu estava com problemas, alguém em férias ou adoecido, e o projeto estava pegando fogo. Tarefas particulares separadas podem ser executadas e auxiliadas por outras equipes.

Além disso, há sempre licença, treinamento e participação em conferências, que também precisam levar tempo para serem preparadas. Quando um funcionário tem a oportunidade de estudar algo, leia Habr, assista a um vídeo sobre o trabalho durante o horário de trabalho, a lealdade aumenta. Resolvemos esse problema e todos ficaram à vontade.

Natureza diferente de tarefas para equipes

Temos equipes de produtos que fazem algo novo. Eles têm planejamento de duas semanas, sprints, projetos longos e são lançados em 1-2 meses ou mais.

Temos equipes de marketing que trabalham de maneira mais reativa: a tarefa foi concluída, a tarefa foi concluída. Digamos que o departamento de vendas vendeu o desembarque - você precisa fazer isso rapidamente. Essas equipes também trabalharam inicialmente no Scrum e em sprints de duas semanas, mas no final do sprint as tarefas eram completamente diferentes do que no início. A insatisfação da equipe, a corrida constante, os sprints não terminam - a situação é desagradável.

Decidimos conversar com PM e negócios:

- Pessoal, temos Agile, Scrum, sprints, processos - não vamos lançar novas tarefas, mas vamos desenvolver previsivelmente.
Olha, nós vendemos um pouso, ele precisa ser feito em 3 dias. Somos pagos um milhão por isso. Quais processos? Dinheiro também deve ser ganho!

Um milhão nos convenceu. Começamos a pensar mais.

Decidimos reduzir os sprints para uma semana - para que possamos responder mais rapidamente. Também não funcionou, porque planejar naquele momento para essa equipe não funcionou.
Então decidimos não planejar sprints, mas trabalhar no Kanban em vez do Scrum : a tarefa veio, levou ao trabalho, foi liberada. Funcionou. A equipe trabalhou de forma mais produtiva, porque entendeu inicialmente que não havia planejamento, mas havia apenas tarefas a serem executadas.

Para melhorar os processos na equipe e receber feedback, começamos a realizar retrospectivas a cada 2 semanas : a equipe se reuniu, discutiu o que deu certo, o que não deu certo, quais os prós e contras e trabalhou com ele.

O surgimento de novas equipes

Naquele momento, começamos a crescer, surgiram novas equipes: conquistamos liderança, desenvolvedores, a equipe estava crescendo e as pessoas ainda não haviam se acostumado. Não estamos falando de planejamento durante esse período - as pessoas veem nosso código pela primeira vez e pode ser ruim, por exemplo, temos um pouco de bitrix. Algo tinha que ser feito com isso.

Foi possível usar o mesmo Kanban para que os desenvolvedores executem as tarefas que puderem, mas essa é uma equipe de produto, precisa ser ensinada. Decidimos - deixá-los aprender a planejar e avaliar tarefas, mas reduzimos o sprint para 1 semana .

Aumentaremos o tempo para 2 semanas em 1 a 2 meses, quando a equipe se acostumar com isso, entrar no trabalho geral do produto, estabelecerá processos e os desenvolvedores poderão avaliar as tarefas normalmente.

Troca de experiência entre equipes

Dentro da equipe, desenvolvedores e testadores se comunicam e trocam experiências, mas essa experiência não é atualizada, porque a equipe "cozinha sozinha". Nova experiência não tem de onde vir.

Começamos a pensar no que fazer com isso e introduzimos reuniões semanais da equipe. O objetivo das reuniões é transferir a experiência de uma equipe para outra através dos líderes da equipe.

As primeiras reuniões foram as seguintes:

- Olá, meu nome é Eugene, agora estamos cortando as notícias.
- Legal!

Próxima reunião:

- Olá, meu nome ainda é Eugene, continuamos a dar as notícias.
Ok.

Nada de extraordinário acontece.

Terceira reunião: Olá ... E tudo a mesma coisa.

Percebemos que precisávamos mudar o formato. Leia livros sobre reuniões e
introduziu uma agenda fixa.

Agora, temos uma página wiki com datas para as reuniões do Timlid, nas quais descrevemos problemas e tarefas para discussão durante a semana.

As vantagens desta decisão

• Os timlids estão se preparando para a reunião, porque conhecem a agenda e entendem o que será discutido.
• A página wiki está disponível para todos os desenvolvedores. Cada funcionário pode aprender o tópico da discussão, participar do processo e fazer suas perguntas. Após a reunião, fixamos a decisão nos comentários, que também estão disponíveis.
• Se um problema não tiver sido resolvido após 1-2 meses, você poderá ver no arquivo da reunião como a discussão do problema foi decidida e chutar a equipe ou o líder da equipe por falha.

Gostamos do formato das reuniões e começamos a realizá-las regularmente.

Introduzimos uma revisão de código de comando cruzado . Esse é um tipo de troca de experiência que os desenvolvedores de front-end e, mais tarde, os caras do back-end, já praticavam. Não é necessário atribuir todo o código a uma revisão de código de comando cruzado, apenas coisas importantes são suficientes, por exemplo, bibliotecas compartilhadas ou partes comuns de código. Para a revisão do código, selecionamos apenas as equipes interessadas, não houve aprovação obrigatória.
Existem situações em que uma equipe vizinha que lida com bancos pede para refinar a funcionalidade - adicione campos e lidamos com empréstimos. Você pode pedir a outra equipe, mas eles têm seu próprio plano e não está claro quando eles atenderão à solicitação, mas você não pode esperar. Nesta situação, ajudamos a equipe vizinha, mas, na revisão de código, damos outra.

Acontece que os desenvolvedores são solicitados a transferir para outra direção ou alterar a tecnologia. Por exemplo, temos um funcionário que lida com cartões de crédito há um ano e pede para mudar a área, enquanto outro quer mudar a tecnologia da interface do usuário para o Symfony. Por acordo, organizaremos a transição dos desenvolvedores entre as equipes .

Algumas empresas praticam reuniões às sextas-feiras: as pessoas se reúnem para trocar experiências, discutir algo e conversar. Também decidimos organizar reuniões de sexta-feira - começamos uma página no Wiki, onde todos que querem falar escrevem o tópico de seu relatório.

Tudo estava legal. Nas reuniões, as equipes conversavam sobre o que estavam fazendo, o que havia de novo. Por exemplo, com uma das equipes que tínhamos um mal-entendido, ninguém sabia o que ela estava fazendo. Em uma reunião de sexta-feira, a equipe falou sobre seu trabalho, mostrou análises e todos entenderam o significado de seu trabalho. Os desenvolvedores de front-end conversaram sobre o andamento da montagem, discutiram tópicos técnicos gerais, por exemplo, como usar o Depurador no PHPStorm, como a implantação ocorre.

E então os tópicos de desenvolvimento terminaram, mudamos para os psicológicos e a história começou a desaparecer. Como estimular ainda mais os desenvolvedores a dizer alguma coisa?

E então nos lembramos do KPI ! Ensinemos cada desenvolvedor a falar e incluir em seus relatórios de KPI 2 por seis meses nas reuniões de sexta-feira. Nós pensamos que a idéia era legal e todos iriam adiante.

Após a introdução do KPI, os desenvolvedores pararam de fazer relatórios. Aparições negativas surgiram para apresentações obrigatórias. Os programadores decidiram sacrificar 100% da implementação do KPI, apenas para não fazer relatórios voluntários e obrigatórios.

Conclusões

Enquanto resolvíamos problemas com eficiência, a empresa estava se desenvolvendo e novos projetos surgiram e tivemos que nos adaptar. Isto é o que entendemos disso.

• Ajuste-se às mudanças e não se concentre no que é aceito, observe as mudanças e escolha as melhores práticas para trabalhar com a equipe. Se os desenvolvedores não podem trabalhar no Scrum - trabalhe no Kanban para que todos fiquem felizes e felizes.
• Monitorar e alterar constantemente os processos . Como líderes de equipe, você deve controlar os processos na equipe. O diretor não está mais disposto e os desenvolvedores ainda não estão preparados. , , . , .

— .

. , , , : , PM, .

— , .

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

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

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
Ser filtros entre o ambiente e a equipe. Todas as informações devem ser dosadas para não desmotivar os desenvolvedores.

A coleção do programa TeamLead Conf , que será realizada nos dias 25 e 26 de fevereiro em Moscou, está na fase mais quente. Vou falar sobre os resultados aqui, quando tudo estará vinculado ao cronograma, e coleções temáticas regulares aparecerão na lista de discussão .