Epígrafe:
O marido, olhando para os filhos sujos, diz à esposa: bem, vamos lavá-los ou dar à luz novos?
Abaixo do corte está a segunda parte de um artigo do nosso líder de equipe, bem como do Diretor de Desenvolvimento de Produto RAS, Igor Marnat, sobre as peculiaridades de motivar programadores. A primeira parte do artigo pode ser encontrada aqui -
Na primeira parte do artigo, abordei os dois níveis inferiores da pirâmide de Maslow: necessidades fisiológicas, necessidades de segurança, conforto e constância e passei para o próximo, terceiro nível, a saber:
III - Necessidade de pertencimento e amor
Eu sabia que a máfia italiana se chamava “Cosa Nostra”, mas fiquei muito impressionado quando descobri como se traduz “Cosa Nostra”. “Cosa Nostra” traduzido do italiano significa “Nosso Negócio”. A escolha do nome faz muito sucesso para a motivação (deixemos de lado a ocupação, neste caso só nos interessa a motivação). Uma pessoa geralmente quer fazer parte de uma equipe, fazer algum negócio grande e comum.
É dada grande importância à satisfação da necessidade de pertencimento e amor no exército, na marinha e em quaisquer grandes formações paramilitares. E, como vemos, na máfia. Isso é compreensível, porque é preciso forçar pessoas que têm pouco em comum, que inicialmente não formam uma equipe de pessoas com ideias semelhantes, que são reunidas por recrutamento (não voluntariamente), que têm diferentes níveis de escolaridade, diferentes valores pessoais , para literalmente dedicar suas vidas, com risco mortal, a alguma causa comum, confiar sua vida a um camarada de armas.
Esta é uma motivação muito forte; para a maioria das pessoas é extremamente importante sentir que pertencem a algo maior, saber que fazem parte de uma família, de um país, de uma equipa. No exército, uniformes, vários rituais, desfiles, marchas, estandartes e assim por diante servem a esses propósitos. Praticamente os mesmos fatores são importantes para qualquer equipe. Símbolos, marca corporativa e cores corporativas, parafernália e souvenirs são importantes.
É importante que os eventos significativos tenham uma forma de realização visível à qual possam ser associados. Hoje em dia é normal que uma empresa tenha mercadorias próprias, jaquetas, camisetas, etc. Mas também é importante destacar a equipe dentro da empresa. Muitas vezes lançamos camisetas com base nos resultados de um lançamento, que são entregues a todos os envolvidos no lançamento. Alguns eventos, celebrações conjuntas ou atividades com toda a equipa são outro importante fator de motivação.
Além dos atributos externos, vários outros fatores influenciam o sentimento de pertencimento a uma equipe.
Em primeiro lugar, a presença de um objetivo comum que todos compreendam e partilhem uma avaliação da sua importância. Os programadores geralmente querem entender que estão fazendo algo legal e que estão fazendo isso juntos, como uma equipe.
Em segundo lugar, a equipa deve ter um espaço de comunicação em que toda a equipa esteja presente e que pertença apenas a ela (por exemplo, um chat no messenger, sincaps periódicos da equipa). Além de questões de trabalho, comunicação informal, às vezes discussão de eventos externos, conversas leves - tudo isso cria um senso de comunidade e equipe.
Em terceiro lugar, destaco a introdução de boas práticas de engenharia na equipa, a vontade de elevar os padrões face aos aceites na empresa. Implementar as melhores abordagens aceitas na indústria, primeiro na equipe, e depois na empresa como um todo, dá à equipe a oportunidade de sentir que está à frente dos demais de alguma forma, liderando o caminho, isso cria um sentimento de pertencimento para uma equipe legal.
O sentimento de pertencimento também é influenciado pela participação da equipe no planejamento e na gestão. Quando os membros da equipe estão envolvidos na discussão dos objetivos do projeto, planos de trabalho, padrões da equipe e práticas de engenharia, e entrevistando novos funcionários, eles desenvolvem um senso de participação, propriedade compartilhada e influência no trabalho. As pessoas estão muito mais dispostas a executar decisões tomadas e expressas por elas mesmas do que aquelas propostas por outros, mesmo que estejam praticamente em sintonia.
Aniversários, datas comemorativas, acontecimentos marcantes na vida dos colegas - uma pizza conjunta, um pequeno presente da equipe proporcionam um caloroso sentimento de envolvimento e gratidão. Em algumas empresas, é costume dar pequenas placas memoriais aos 5, 10, 15 anos de trabalho na empresa. Por um lado, não creio que isso me motive tanto 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 facto desmotiva e não a sua presença motiva. Concordo, pode ser uma pena se o LinkedIn te lembrar pela manhã e te parabenizar pelo seu 10º aniversário no seu local de trabalho, mas nenhum colega da empresa te parabenizou ou se lembrou de você.
Claro, um ponto significativo é a mudança na composição da equipe. É claro que mesmo que a chegada ou saída de alguém da equipa seja anunciada com antecedência (por exemplo, numa newsletter da empresa ou da equipa, ou numa reunião de equipa), isso não motiva particularmente ninguém para novas conquistas. Mas se um belo dia você vir uma pessoa nova ao seu lado, ou não ver uma antiga, pode ser uma surpresa, e se você for embora, totalmente desagradável. As pessoas não deveriam desaparecer silenciosamente. Especialmente em uma equipe distribuída. Principalmente se o seu trabalho depende de um colega de outro escritório que subitamente se levantou e desapareceu. Definitivamente, vale a pena informar a equipe com antecedência sobre esses momentos.
Um fator importante, que em inglês é chamado propriedade (a tradução literal de “posse” não reflete totalmente o seu significado). Este não é um sentimento de propriedade, mas sim um sentimento de responsabilidade pelo seu projeto, aquele sentimento quando você se associa emocionalmente ao produto e o produto a você mesmo. Isso corresponde aproximadamente à oração do fuzileiro naval no filme “Full Metal Jacket”: “Este é meu rifle. Existem muitos desses rifles, mas este é meu. Minha espingarda é minha melhor amiga. Ela é minha vida. Devo aprender a possuí-lo da mesma forma que possuo minha vida. Sem mim, meu rifle é inútil. Sou inútil sem meu rifle. Devo atirar direto com meu rifle. Tenho que atirar com mais precisão do que o inimigo que está tentando me matar. Tenho que atirar nele antes que ele atire em mim. Deixe ser assim… ".
Quando uma pessoa trabalha em um produto por muito tempo, tem a oportunidade de assumir total responsabilidade por sua criação e desenvolvimento, de ver como uma coisa funcional surge do “nada”, como as pessoas a utilizam, surge esse sentimento poderoso. Equipes de produto que trabalham juntas por muito tempo em um projeto geralmente são mais motivadas e coesas do que equipes que são montadas por um curto período de tempo e trabalham em linha de montagem, passando de um projeto para outro, sem total responsabilidade por todo o produto. , do começo ao fim.
XNUMX. Necessidade de reconhecimento
Uma palavra gentil também agrada o gato. Todos são motivados pelo reconhecimento da importância do trabalho realizado e pela sua avaliação positiva. Converse com programadores, dê-lhes feedback periódico, comemore um trabalho bem executado. Se você tem uma equipe grande e distribuída, as reuniões periódicas (chamadas de um a um) são perfeitas para isso; se a equipe é muito pequena e trabalha junta localmente, essa oportunidade geralmente é fornecida sem reuniões especiais no calendário (embora periódicas). para um é tudo. Ainda é necessário, mas você pode fazer isso com menos frequência). Este tópico é bem abordado em podcasts para gerentes em manager-tools.com.
No entanto, vale a pena ter em mente as diferenças culturais. Algumas abordagens familiares aos colegas americanos nem sempre funcionarão com as russas. O nível de polidez aceito na comunicação diária nas equipes dos países ocidentais parece inicialmente excessivo para os programadores da Rússia. Alguma franqueza característica dos colegas russos pode ser percebida como grosseria pelos seus colegas de outros países. Isso é muito importante na comunicação em uma equipe interétnica, muito se escreveu sobre esse assunto, o gestor dessa equipe deve se lembrar disso.
Demonstrações de recursos, onde os programadores mostram recursos desenvolvidos durante um sprint, são uma boa prática para atender a essa necessidade. Além de ser uma excelente oportunidade para desobstruir canais de comunicação entre equipes, apresentar novos recursos aos gerentes de produto e testadores, é também uma boa oportunidade para os desenvolvedores mostrarem os resultados de seu trabalho e indicarem sua autoria. Bem, e aprimore suas habilidades de falar em público, é claro, o que nunca é prejudicial.
Seria uma boa ideia celebrar a contribuição significativa de colegas particularmente ilustres com certificados, sinais memoriais (pelo menos uma palavra amável) em reuniões conjuntas de equipas. As pessoas geralmente valorizam muito esses certificados e placas memoriais, levam-nos consigo quando se mudam e geralmente cuidam deles de todas as maneiras possíveis.
Para marcar uma contribuição mais significativa e de longo prazo para o trabalho da equipe, experiência e conhecimento acumulados, um sistema de notas é frequentemente usado (novamente, uma analogia pode ser feita com o sistema de patentes militares no exército, que, além para garantir a subordinação, também serve esse propósito). Freqüentemente, os jovens desenvolvedores trabalham duas vezes mais para conseguir novas estrelas em seus ombros (ou seja, passar de desenvolvedor júnior para desenvolvedor em tempo integral, etc.).
Conhecer as expectativas do seu pessoal é fundamental. Alguns são mais propensos a serem motivados por uma nota alta, pela oportunidade de serem chamados, digamos, de arquiteto, enquanto outros, ao contrário, são indiferentes a notas e títulos e considerarão o aumento de salário um sinal de reconhecimento da empresa . Comunique-se com as pessoas para entender o que elas querem e quais são suas expectativas.
Uma demonstração de reconhecimento, um maior nível de confiança por parte da equipa, pode ser dada dando mais liberdade de ação ou envolvimento em novas áreas de trabalho. Por exemplo, após adquirir certa experiência e alcançar determinados resultados, um programador, além de implementar suas funcionalidades de acordo com a especificação, pode trabalhar na arquitetura de coisas novas. Ou envolva-se em novas áreas que podem não estar diretamente relacionadas ao desenvolvimento – automação de testes, implementação de melhores práticas de engenharia, ajuda no gerenciamento de versões, palestras em conferências, etc.
V. A necessidade de cognição e autorrealização.
Muitos programadores concentram-se em diferentes tipos de atividades de programação em diferentes fases de suas vidas. Algumas pessoas gostam de aprender máquinas, desenvolver novos modelos de dados, ler muita literatura científica para trabalhar e criar algo novo do zero. Outra está mais próxima da depuração e do suporte a um aplicativo existente, no qual você precisa se aprofundar no código existente, estudar logs, rastreamentos de pilha e captchas de rede por dias e semanas e quase não escrever nenhum código novo.
Ambos os processos exigem grande esforço intelectual, mas o seu resultado prático é diferente. Acredita-se que os programadores estão relutantes em apoiar soluções existentes; eles estão bastante motivados para desenvolver novas soluções. Há um grão de sabedoria nisso. Por outro lado, a equipa mais motivada e unida com quem já trabalhei dedicou-se a apoiar um produto existente, encontrando e corrigindo bugs após a equipa de suporte os contactar. Os caras viviam literalmente para esse trabalho e estavam prontos para sair aos sábados e domingos. Certa vez, lidamos com entusiasmo com outro problema urgente e complexo, seja na noite de 31 de dezembro ou na tarde de 1º de janeiro.
Vários fatores influenciaram essa alta motivação. Em primeiro lugar, era uma empresa com grande nome no setor, a equipa associava-se a ela (ver “A Necessidade de Afiliação”). Em segundo lugar, eles eram a última fronteira, não havia ninguém por trás deles, não havia equipa de produto naquela altura. Entre eles e os clientes havia dois níveis de suporte, mas se o problema os atingisse, não havia para onde recuar, ninguém os apoiava, toda a corporação estava em cima deles (quatro jovens programadores). Em terceiro lugar, esta grande empresa tinha clientes muito grandes (governos nacionais, empresas automobilísticas e de aviação, etc.) e instalações de grande escala em vários países. Como resultado, problemas sempre complexos e interessantes, problemas simples foram resolvidos com o apoio dos níveis anteriores. Em quarto lugar, a motivação da equipa foi muito influenciada pelo nível profissional da equipa de suporte com quem interagiu (eram engenheiros muito experientes e tecnicamente capazes), e estivemos sempre confiantes na qualidade dos dados que prepararam, nas análises que realizaram , etc. Em quinto lugar, e acho que esse é o ponto mais importante - o time era muito jovem, todos os caras estavam no início da carreira. Eles estavam interessados em estudar um produto grande e complexo, resolvendo problemas sérios que eram novos para eles em um novo ambiente, buscavam se equiparar profissionalmente ao nível das equipes, dos problemas e dos clientes ao redor. O projeto acabou sendo uma excelente escola, todos depois fizeram uma boa carreira na empresa e se tornaram líderes técnicos e gerentes seniores, um dos caras hoje é gerente técnico da Amazon Web Services, o outro acabou migrando para o Google, e todos deles ainda se lembram deste projeto com carinho.
Se esta equipe consistisse de programadores com 15 a 20 anos de experiência, a motivação seria diferente. A idade e a experiência não são, obviamente, factores 100% determinantes, tudo depende da estrutura da motivação. Neste caso específico, a vontade de conhecimento e crescimento dos jovens programadores rendeu excelentes resultados.
De forma geral, como já mencionamos diversas vezes, você deve conhecer as expectativas dos seus programadores, entender quais deles gostariam de expandir ou mudar seu ramo de atuação, e levar em consideração essas expectativas.
Além da pirâmide de Maslow: visibilidade de resultados, gamificação e competição, sem besteira
Há mais três pontos importantes relativos à motivação dos programadores que definitivamente precisam ser mencionados, mas atraí-los para o modelo de necessidades de Maslow seria demasiado artificial.
A primeira é a visibilidade e proximidade do resultado.
O desenvolvimento de software geralmente é uma maratona. Os resultados dos esforços de I&D tornam-se visíveis após meses, por vezes anos. É difícil chegar a uma meta que está muito além do horizonte, a quantidade de trabalho é assustadora, a meta está longe, não é clara e não é visível, “a noite é escura e cheia de horrores”. É melhor dividir o caminho em partes, fazer um caminho até a árvore mais próxima que seja visível, acessível, os contornos sejam claros e não esteja longe de nós - e vá até esse objetivo próximo. Queremos fazer um esforço de vários dias ou semanas, obter e avaliar o resultado e depois seguir em frente. Portanto, vale a pena dividir o trabalho em pequenas partes (sprints em ágil atendem bem a esse propósito). Concluímos parte do trabalho - registramos, exalamos, discutimos, punimos os culpados, recompensamos os inocentes - podemos iniciar o próximo ciclo.
Esta motivação é, até certo ponto, semelhante à que os jogadores experimentam quando completam jogos de computador: recebem periodicamente medalhas, pontos, bónus à medida que completam cada nível; isto pode ser chamado de “motivação dopamina”.
Ao mesmo tempo, a visibilidade do resultado é literalmente importante. Um recurso fechado na lista deve ficar verde. Se o código for escrito, testado, lançado, mas não houver alteração no status visual visível ao programador, ele se sentirá incompleto, não haverá sensação de conclusão. Em uma das equipes do 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 na revisão de código, o patch foi mesclado. Cada estágio foi marcado visualmente com uma marca verde ou uma cruz vermelha. Depois que um dos desenvolvedores reclamou que a revisão do código demorava muito, os colegas precisaram acelerar, os patches ficaram suspensos por vários dias. Eu perguntei, o que isso realmente muda para ele? Afinal, quando o código é escrito, o build é montado e os testes são aprovados, ele não precisa ficar atento ao patch enviado se não houver comentários. Os próprios colegas irão revisá-lo e aprová-lo (se, novamente, não houver comentários). Ele respondeu: “Igor, quero receber meus três carrapatos verdes o mais rápido possível”.
O segundo ponto é a gamificação e a competição.
Ao desenvolver um dos produtos, nossa equipe de engenharia tinha como objetivo assumir uma posição de destaque na comunidade de um dos produtos de código aberto, para entrar 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 poderia afirmar (e periodicamente afirmava) que era o contribuidor número um, mas não havia uma maneira real de comparar as contribuições dos participantes. entre si, para avaliar sua dinâmica no tempo. Dessa forma, não havia como definir uma meta para a equipe que pudesse ser medida em alguns papagaios, avaliar o grau de seu cumprimento, etc. Para resolver este problema, nossa equipe desenvolveu uma ferramenta para medir e visualizar a contribuição de empresas e colaboradores individuais . Do ponto de vista motivacional, acabou sendo apenas uma bomba. Não foram apenas engenheiros e equipes que monitoraram constantemente seu progresso e o progresso de seus colegas e concorrentes. A alta administração de nossa empresa e todos os principais concorrentes também começaram o dia com stackalytics. Tudo ficou muito transparente e visual, todos puderam acompanhar atentamente o seu progresso, comparar com os colegas, etc. Tornou-se conveniente e fácil para engenheiros, gerentes e equipes definirem metas.
Um ponto importante que surge ao implementar qualquer sistema de métricas quantitativas é que assim que você as implementa, o sistema automaticamente se esforça para priorizar o alcance dessas métricas quantitativas, em detrimento das qualitativas. Por exemplo, o número de revisões de código concluídas é usado como uma das métricas. Obviamente, a revisão de código pode ser feita de diferentes maneiras, você pode gastar várias horas em uma revisão completa e verificação de um patch complexo com testes de verificação, executá-lo em seu banco, verificar a documentação e obter mais uma revisão em seu carma, ou clique cegamente em algumas dúzias de patches em alguns minutos, dê +1 a cada um e ganhe mais vinte em carma. Houve casos cômicos em que os engenheiros clicaram nos patches tão rapidamente que deram +1 aos patches automáticos do sistema de CI. Como brincamos mais tarde, “vá, vá, Jenkins”. No caso dos commits, também houve muitas pessoas que percorreram o código com ferramentas de formatação de código, editaram comentários, trocaram pontos por vírgulas e, assim, aumentaram seu carma. Lidar com isso é bastante simples: usamos o bom senso e, além das métricas quantitativas, utilizamos também as essenciais, qualitativas. O grau de utilização dos resultados do trabalho da equipe, o número de colaboradores externos, o nível de cobertura dos testes, a estabilidade dos módulos e de todo o produto, os resultados dos testes de escala e desempenho, o número de engenheiros que receberam o ombro do revisor principal correias, o fato de os projetos terem sido aceitos na comunidade de projetos principais, o cumprimento dos critérios das diferentes etapas do processo de engenharia - todos esses e muitos outros fatores devem ser avaliados juntamente com métricas quantitativas simples.
E finalmente, o terceiro ponto – Sem besteira.
Os desenvolvedores são pessoas muito inteligentes e extremamente lógicas em sua linha de trabalho. Eles passam de 8 a 10 horas por dia construindo cadeias lógicas longas e complexas, para que vejam vulnerabilidades nelas instantaneamente. Ao fazer algo, eles, como todo mundo, querem entender por que estão fazendo aquilo, o que vai mudar para melhor. É extremamente importante que as metas que você definiu para sua equipe sejam honestas e realistas. Tentar vender uma má ideia para uma equipe de programação é uma má ideia. Uma ideia é ruim se você mesmo não acredita nela ou, em casos extremos, não tem o estado interno de discordar e se comprometer (não concordo, mas farei). Certa vez, implementamos um sistema de motivação em uma empresa, um dos elementos do qual era um sistema eletrônico de feedback. Investiram muito dinheiro, levaram gente para a América para treinamento, em geral investiram ao máximo. Certa vez, em conversa após o treinamento, um dos gestores disse aos seus subordinados: “A ideia não é ruim, parece que vai dar certo. Eu não vou lhe dar feedback eletrônico, mas você o dá ao seu pessoal e exige dele.” É isso, nada poderia ser implementado mais. A ideia, claro, não deu em nada.
Fonte: habr.com