Gerenciamento de uma equipe de programadores: como e como motivá-los corretamente? Parte dois

Epígrafe:
O marido, olhando para as crianças sujas, diz à esposa: Bem, o que, lavamos essas ou novas?

Sob o corte, a segunda parte do artigo de nosso líder de equipe, bem como o diretor de desenvolvimento de produtos RAS - Igor Marnat, sobre os recursos de motivação do programador. A primeira parte do artigo pode ser encontrada aqui - habr.com/en/company/parallels/blog/452598




Na primeira parte do artigo, toquei nos dois níveis mais baixos da pirâmide de Maslow: necessidades fisiológicas, segurança, conforto e constância e passe para o terceiro nível seguinte, a saber:

III - A necessidade de afiliação e amor



Eu sabia que a máfia italiana se chama “Cosa Nostra”, mas fiquei muito impressionada quando aprendi a traduzir “Cosa Nostra”. "Cosa Nostra" na tradução do italiano - "Our business". A escolha do nome é muito bem-sucedida para a motivação (deixe de lado a ocupação, neste caso, estamos interessados ​​apenas em motivação). Uma pessoa geralmente quer fazer parte de uma equipe, fazer grandes e comuns negócios.

É dada grande importância ao atendimento da necessidade de pertencimento e amor no exército, na marinha, em quaisquer grandes formações militarizadas. E, como vemos, na máfia. Isso é compreensível, porque você precisa forçar pessoas que têm pouco em comum, que inicialmente não formam uma equipe de pessoas afins, reunidas em apelo (não voluntariamente), têm diferentes níveis de educação, diferentes valores pessoais, literalmente dedicam suas vidas, com risco mortal, a alguma causa comum confia a vida a um camarada de armas.

Essa é uma motivação muito forte, para a maioria das pessoas é extremamente importante sentir vontade de pertencer a algo mais, saber que você faz parte de uma família, país, equipe. No exército, esses objetivos são a forma, vários rituais, desfiles, marchas, faixas e assim por diante. Sobre os mesmos fatores são importantes para qualquer equipe. Símbolos, uma marca corporativa e cores corporativas, atributos e lembranças são importantes.

É importante que eventos significativos tenham uma modalidade visível à qual eles possam ser associados. Agora, a empresa tem seus próprios atributos, jaquetas, camisetas, etc. - e sim a norma. Mas também é importante destacar uma equipe dentro da empresa. Em geral, emitimos camisetas com base nos resultados da versão, que são emitidos para todos os envolvidos nesta versão. Quaisquer eventos, celebrações conjuntas ou eventos de toda a equipe são outro fator importante de motivação.

Além dos atributos externos, mais alguns fatores influenciam o sentimento de pertencer a uma equipe.
Primeiro, a existência de um objetivo comum que todos entendem é compartilhada por uma avaliação de sua importância. Os programadores geralmente querem entender o que fazem de legal, e fazem isso legal juntos, como uma equipe.
Em segundo lugar, uma equipe deve ter um espaço de comunicação no qual exista uma equipe inteira e que pertença a ela (por exemplo, um bate-papo no messenger, sincronizações periódicas da equipe). Além das questões de trabalho, a comunicação informal, às vezes discutindo eventos externos, é um ponto de partida - tudo isso forma um senso de comunidade e equipe.
Em terceiro lugar, destacaria a introdução de boas práticas de engenharia dentro da equipe, o desejo de elevar os padrões em comparação com os adotados pela empresa. A implementação das melhores abordagens adotadas no setor, primeiro na equipe e depois na empresa como um todo, dá à equipe a oportunidade de sentir que está à frente dos outros de alguma maneira, fica na cabeça, isso cria um sentimento de pertencer a uma equipe legal.

A propriedade da equipe no planejamento e gerenciamento também afeta o senso de propriedade. Quando os membros da equipe estão envolvidos na discussão dos objetivos do projeto, do plano de trabalho, dos padrões e das práticas de engenharia da equipe, entrevistando novos funcionários, eles têm um sentimento de participação, propriedade conjunta, influência no trabalho. As pessoas estão muito mais dispostas a tomar decisões tomadas e expressadas por elas mesmas do que as propostas por outros, mesmo que sejam praticamente consoantes.

Aniversários, aniversários, eventos significativos na vida dos colegas - uma pizza em conjunto, um pequeno presente da equipe, proporcionam uma sensação calorosa de envolvimento e apreço. Em algumas empresas, é costume dar pequenos sinais comemorativos por 5, 10, 15 anos de trabalho na empresa. Por um lado, não acho que seja tão motivador para novas conquistas. Mas, obviamente, quase todo mundo ficará satisfeito por não ter esquecido dele. Este é um daqueles casos em que a ausência de um fato motiva bastante a sua presença. Concordo, pode ser uma pena se, pela manhã, o linkedin o lembrou e o parabenizou por seu 10º aniversário no local de trabalho, e nem um único colega da empresa parabenizou ou lembrou.

Obviamente, um ponto significativo é a mudança na composição da equipe. É claro que, mesmo que a chegada ou a saída de alguém da equipe seja anunciada com antecedência (por exemplo, em uma lista de discussão de uma empresa ou equipe ou em uma reunião de equipe), isso não motiva particularmente ninguém a realizar novas conquistas. Mas se um dia você vê uma nova pessoa ao seu lado ou não vê uma antiga, isso pode ser uma surpresa e, se você sair, é realmente desagradável. As pessoas não devem desaparecer silenciosamente. Especialmente em uma equipe distribuída. Especialmente se o seu trabalho depende de um colega de outro escritório que atendeu e desapareceu repentinamente. Tais momentos valem claramente uma comunicação separada dentro da equipe com antecedência.

Um fator importante, chamado de propriedade em inglês (a tradução literal de "propriedade" não reflete totalmente seu significado). Este não é um sentimento de propriedade, mas um senso de responsabilidade pelo seu projeto, um sentimento quando você se associa emocionalmente ao produto e ao produto consigo mesmo. Isso corresponde aproximadamente à oração do fuzileiro naval do filme “Full Metal Shell”: “ Este é o meu rifle. Existem muitos rifles, mas este é meu. Meu rifle é meu melhor amigo. Ela é a minha vida. Devo aprender a ser dono da maneira como sou dono da minha vida. Meu rifle é inútil sem mim. Eu sou inútil sem o meu rifle. Eu tenho que atirar no meu rifle adequadamente. Eu tenho que atirar com mais precisão do que o inimigo que está tentando me matar. Eu tenho que atirar nele antes que ele atire em mim. Que assim seja ... ".

Quando uma pessoa trabalha em um produto por um longo tempo, ela tem a oportunidade de assumir total responsabilidade por sua criação e desenvolvimento, para ver como uma coisa funciona surge do "nada", como as pessoas a usam, esse sentimento poderoso surge. As equipes de produto que trabalham juntas por um longo tempo em um projeto geralmente são mais motivadas e unidas do que as equipes montadas por um curto período de tempo e trabalhando no modo de linha de montagem, com a mudança de um projeto para outro sem total responsabilidade por todo o produto, do início ao fim.

IV Necessidade de reconhecimento

Boa palavra e agradável para o gato. Todos são motivados pelo reconhecimento da importância de seu trabalho, sua avaliação positiva. Converse com os programadores, dê feedback periódico, marque um trabalho bem feito. Se você possui uma equipe grande e distribuída, as reuniões periódicas (o que é chamado de um para um) são ótimas para isso, se a equipe é muito pequena e trabalha em conjunto localmente, esse recurso geralmente é fornecido sem reuniões especiais no calendário (embora uma a uma periódica seja tudo igualmente necessário, você pode gastá-lo com menos frequência). Este tópico é bem abordado nos podcasts de gerente em manager-tools.com.

Ao mesmo tempo, vale lembrar as diferenças culturais. Algumas abordagens familiares aos colegas americanos nem sempre funcionam com as russas. O nível de polidez aceito na comunicação diária em equipes nos países ocidentais parece inicialmente excessivo para programadores da Rússia. Alguma característica direta dos colegas russos pode ser vista como grosseria por colegas de outros países. Isso é muito importante na comunicação em uma equipe internacional, muito foi escrito sobre esse tópico, o gerente de uma equipe como essa deve se lembrar definitivamente disso.

A demonstração de recursos nos quais os programadores mostram recursos desenvolvidos para correr é uma boa prática para atender a essa necessidade. Além de ser uma ótima oportunidade de limpar os canais de comunicação entre as equipes, de apresentar aos gerentes e testadores de produtos novos recursos, também é uma boa oportunidade para os desenvolvedores mostrarem os resultados de seu trabalho e indicar sua autoria. Bem, e aperfeiçoe as habilidades de falar em público, é claro, o que nem sempre é prejudicial.

Seria uma boa idéia anotar a notável contribuição de colegas particularmente ilustres com cartas, memorabilia (pelo menos com uma palavra gentil) nas festas conjuntas da equipe. As pessoas geralmente apreciam essas cartas e sinais comemorativos, carregam consigo quando se deslocam e geralmente cuidam delas de todas as maneiras possíveis.

Para marcar uma contribuição mais significativa e de longo prazo para o trabalho da equipe, a experiência e a especialização acumuladas, elas costumam usar um sistema de notas (novamente, é possível fazer uma analogia com o sistema de classificação militar do exército, que, além de garantir a subordinação, também serve a esse propósito). Muitas vezes, os jovens desenvolvedores injetam uma vingança para obter novas estrelas nas alças (ou seja, passam do desenvolvedor júnior para o desenvolvedor em tempo integral, etc.).

É imperativo conhecer as expectativas do seu povo. Alguém é bastante motivado por uma nota alta, a capacidade de ser chamado, digamos, de arquiteto, enquanto alguém, pelo contrário, é indiferente a notas e títulos e considerará um aumento no salário um sinal de reconhecimento pela empresa. Comunique-se com as pessoas para entender o que elas querem, quais são suas expectativas.

Uma demonstração de reconhecimento, uma manifestação de um nível mais alto de confiança por parte da equipe pode servir para proporcionar maior liberdade de ação ou envolvimento em novas áreas de trabalho. Por exemplo, com o acúmulo de certa experiência, a obtenção de determinados resultados, o programador, além de implementar seus recursos de acordo com a especificação, pode trabalhar na arquitetura de coisas novas. Ou envolva-se no trabalho em novas áreas que podem não estar diretamente relacionadas ao desenvolvimento - automação de teste, implementação das melhores práticas de engenharia, assistência no gerenciamento de releases, palestras em conferências etc.

V. A necessidade de conhecimento e auto-atualização.

Muitos programadores são orientados em diferentes estágios de suas vidas para diferentes tipos de atividades em programação. Alguém gosta de se envolver em aprendizado de máquina, desenvolver novos modelos de dados, enquanto lê muita literatura científica para o trabalho, criando novos do zero. A depuração e o suporte de um aplicativo existente estão mais próximos de outro, no qual você precisa se aprofundar no código existente, estudar logs, empilhar trilhas e captchas de rede por dias e semanas e dificilmente escrever um novo código.

Ambos os processos exigem grandes esforços intelectuais, mas a saída prática é diferente. Acredita-se que os programadores sejam relutantes em oferecer suporte às soluções existentes, e provavelmente mais motivados a desenvolver novas. Há um grão saudável nele. Por outro lado, a equipe mais motivada e unida com a qual trabalhei foi especificamente apoiar o produto existente, encontrar e corrigir erros após entrar em contato com a equipe de suporte. Os caras literalmente viveram esse trabalho, estavam prontos para ir aos sábados e domingos. Certa vez, resolvemos de bom grado outro problema urgente e complexo, na noite de 31 de dezembro ou na tarde de 1º de janeiro.

Essa alta motivação foi influenciada por vários fatores. Em primeiro lugar, era uma empresa com um grande nome no setor, a equipe se associou a ela (consulte “Necessidade de afiliação”). Em segundo lugar, eles eram a última fronteira, não havia ninguém atrás deles, a equipe do produto já havia sumido naquele momento. Entre eles e os clientes, havia dois níveis de suporte, mas se o problema os atingisse, não havia para onde recuar, atrás de ninguém, toda a corporação estava neles (quatro jovens programadores). Em terceiro lugar, essa grande empresa tinha clientes muito grandes (governos nacionais, preocupações com automóveis e aviação etc.) e instalações em grande escala em vários países. Como resultado, sempre problemas complexos e interessantes, problemas simples foram resolvidos com o suporte dos níveis anteriores. Quarto, a motivação da equipe foi muito influenciada pelo nível profissional da equipe de suporte com a qual eles interagiram (havia engenheiros muito experientes e tecnicamente legais), e sempre tínhamos certeza da qualidade dos dados que eles preparavam, das análises que realizavam etc. Quinto, e acho que este é o momento mais importante - a equipe era muito jovem, todos os caras estavam no início de sua carreira. Foi interessante para eles estudar um produto grande e complexo, para resolver novos problemas sérios para eles em um novo ambiente para eles, eles procuraram atingir profissionalmente o nível das equipes, problemas e clientes circundantes. O projeto acabou sendo uma excelente escola, então todos fizeram uma boa carreira na empresa e se tornaram líderes técnicos e gerentes seniores, um deles agora é gerente técnico da Amazon Web Services, o outro mudou para o Google ao longo do tempo e todos ainda se lembram desse projeto com entusiasmo .

Se essa equipe consistisse de programadores com 15 a 20 anos de experiência, a motivação seria diferente. É claro que idade e experiência não são 100% fatores determinantes, tudo depende da estrutura da motivação. Nesse caso em particular, o desejo de conhecimento e crescimento de jovens programadores deu um excelente resultado.

Em geral, como mencionamos repetidamente, você deve conhecer as expectativas de seus programadores, entender quais deles gostariam de expandir ou alterar o escopo das atividades e levar em conta essas expectativas.

Fora da pirâmide de Maslow: visibilidade, gamificação e competição, sem besteira

Há outros três pontos importantes em relação à motivação dos programadores que devem ser mencionados, mas atraí-los para o modelo de necessidades de Maslow seria artificial demais.

O primeiro é a visibilidade e proximidade do resultado.

O desenvolvimento de software é geralmente uma maratona. Os resultados dos esforços em pesquisa e desenvolvimento tornam-se visíveis após meses, às vezes anos. É difícil chegar a um objetivo que está muito além do horizonte, a quantidade de trabalho é aterrorizante, o objetivo é longe, não é claro e não é visível ", a noite está escura e cheia de horrores". É melhor dividir o caminho em partes, pavimentar o caminho para a árvore mais próxima, que é visível, realizável, a forma é clara e não fica longe de nós - e vá para esse objetivo próximo. Queremos fazer um esforço de alguns dias ou semanas, obter e avaliar o resultado e seguir em frente. Portanto, o trabalho deve ser dividido em pequenas partes (os sprints em ágil atendem bem a esse propósito). Eles fizeram parte do trabalho - gravaram, expiraram, discutiram, puniram os culpados, premiaram os não convidados - você pode começar o próximo ciclo.

Essa motivação é, em certa medida, semelhante à vivida pelos jogadores quando jogam no computador: eles recebem periodicamente medalhas, pontos, bônus ao passar por cada nível, isso pode ser chamado de "motivação da dopamina".

Além disso, a visibilidade do resultado é literalmente importante. Um recurso fechado da lista deve ficar verde. Se o código for escrito, testado, contaminado, mas não houver alteração no status visual visível para o programador, ele sentirá incompletude, não haverá sensação de conclusão. Em uma das equipes em nosso sistema de controle de versão, cada patch passou por três estágios sucessivos - a compilação foi montada e os testes foram aprovados, o patch passou o código de revisão e o patch foi esgotado. Cada estágio foi marcado visualmente com uma marca verde ou cruz vermelha. Uma vez, um dos desenvolvedores reclamou que o código de revisão dura muito tempo, os colegas precisam acelerar, os patches penduram por vários dias. Perguntei o que, em essência, está mudando para ele? Afinal, quando o código é escrito, a compilação é montada e os testes são aprovados, ele não precisa prestar atenção ao patch enviado se não houver comentários. Os colegas farão a revisão eles mesmos e os manterão em baixa (se, novamente, não houver comentários). Ele respondeu: "Igor, quero receber minhas três marcas de verificação verdes o mais rápido possível."

O segundo ponto é gamificação e competição.

Ao desenvolver um dos produtos, nossa equipe de engenharia teve o objetivo de assumir uma posição de destaque na comunidade de um dos produtos de código aberto, entrando no top 3. Naquela época, não havia uma maneira objetiva de avaliar a visibilidade de alguém na comunidade, cada uma das grandes empresas participantes podia declarar (e declarar periodicamente) que era o colaborador número um, mas não havia uma maneira real de comparar a contribuição dos participantes entre si, para avaliar sua dinâmica em hora. Consequentemente, não havia como estabelecer uma meta para a equipe, que pudesse ser medida em alguns papagaios, avaliar o grau de conquista, etc. Para resolver esse problema, nossa equipe desenvolveu uma ferramenta para medir e visualizar a contribuição de empresas e colaboradores individuais www.stackalytics.com . Em termos de motivação, acabou sendo apenas uma bomba. Não apenas os engenheiros e as equipes monitoravam constantemente seu progresso e o progresso de colegas e concorrentes. A alta gerência de nossa empresa e todos os principais concorrentes também começaram o dia com stackalytics. Tudo ficou muito transparente e claro, todos puderam monitorar cuidadosamente seu progresso, comparar com colegas etc. Tornou-se conveniente e fácil estabelecer metas para engenheiros, gerentes e equipes.

Um ponto importante que surge ao introduzir qualquer sistema de métricas quantitativas é que, assim que você as implementa, o sistema procura automaticamente priorizar a realização dessas métricas quantitativas, em detrimento das qualitativas. , . , -, , , , , , +1 . , , +1 CI . , “go, go, jenkins”. , , , . : , . , , , , scale performance , , core reviewer, core projects , — .

, — No bullshit.

— , . 8-10 , . -, , , , , . , , , . — . , , , , disagree and commit ( , ). - , . , , , . - : « , , . , , ». , . , , .