Epígrafe:
O marido, olhando para as crianças sujas, diz à esposa: Bem, o que, lavamos essas ou novas?Sob o corte da discussão de nosso líder de equipe, bem como Igor Marnat, diretor de desenvolvimento de produtos RAS, sobre os recursos de motivação do programador.
O segredo do sucesso na criação de produtos de software interessantes é bem conhecido - leve uma equipe de programadores legais, dê uma idéia legal à equipe e não interfira no trabalho da equipe. Desenvolvedores legais são caras raros e procurados. Alguns recrutadores até dizem que têm a impressão de que dar à luz um programador legal é mais fácil do que contratá-lo no mercado. Além das dificuldades com a contratação, a experiência de cada desenvolvedor específico, o conhecimento de um produto existente e o histórico de seu desenvolvimento são muitas vezes insubstituíveis ou são reabastecidos por muito tempo. Portanto, se você tiver sorte e já tiver uma equipe legal de programadores, é importante trabalhar com a motivação deles. Contratar, treinar novos desenvolvedores, formar uma equipe com eles é quase tão difícil e longo quanto dar à luz e criar filhos.
Considere os principais fatores que motivam os programadores (equipes de programadores), usando a pirâmide de Maslow para maior clareza e estruturação da apresentação. Se de repente você não ouviu falar da pirâmide de Maslow - essa não é uma teoria incontestável, mas muito popular e óbvia do psicólogo americano Abraham Harold Maslow, que propôs uma teoria da motivação da personalidade baseada em uma hierarquia de necessidades humanas (veja a figura abaixo).
Maslow organizou as necessidades do indivíduo em uma ordem hierárquica, das necessidades fisiológicas à necessidade de desbloquear o potencial e a auto-realização. Uma suposição chave na teoria de Maslow é: "Uma pessoa não pode experimentar as necessidades de um nível superior até que suas necessidades de um nível inferior sejam satisfeitas". Por exemplo, uma pessoa não pode ser motivada pela necessidade de conhecimento ou necessidades estéticas, se não dormiu ou comeu por três dias.
Antes de nos aprofundarmos nos detalhes, vamos nos debruçar sobre o fato óbvio - a equipe é formada por pessoas, todas as pessoas são diferentes, cada uma com sua própria estrutura de motivação. Além do fato de que cada pessoa é movida por interesses diferentes, cada pessoa também está em diferentes condições de vida. Alguém está no início de uma carreira e está pensando em como construí-la, alguém vai se casar e alguém quer aprender uma nova área de assunto. O que é importante para um é completamente sem importância para o outro, e amanhã tudo mudará novamente. Para entender corretamente esse contexto, existe um meio simples - você precisa pensar sobre isso e trabalhar com ele. O mais importante é a comunicação.
Certifique-se de conversar com sua equipe sobre algo que não seja trabalho, construa um relacionamento informal.
Então, agora vamos examinar a pirâmide de Maslow e considerar seus níveis aplicados ao gerenciamento de uma equipe de programadores.
I: Necessidades fisiológicas e biológicas:Por falar em motivação, muitos, em primeiro lugar, costumam pensar em salário. Nesse caso, quero dizer por salário a parte constante do pacote de remuneração, que não depende dos resultados. Isso não se aplica a bônus, bônus e promoções da empresa. Eu atribuiria o salário ao nível de "necessidades fisiológicas" em nosso caso. Bônus, bônus de acordo com os resultados do trabalho, opções e ações da empresa - tudo isso eu me referiria a outros níveis.
Na minha opinião, por incrível que pareça, o salário pode ser mais um fator
desmotivador do que motivador. A peculiaridade de trabalhar com programadores é que todos são pessoas, primeiramente, muito inteligentes (uma característica da profissão) e, em segundo lugar, profundamente e / ou amplamente instruídos. Normalmente, os programadores, além de sua profissão, são versados em uma ou mais áreas de assunto para as quais eles criam produtos. Além disso, bons programadores estão interessados e bem cientes do histórico de programação, algoritmos, padrões etc. O mesmo se aplica à área de assunto. Para pessoas desse nível, o salário geralmente não é o principal fator motivador.
Ao mesmo tempo, a falta de um salário justo para os programadores desmotiva e desmotiva fortemente. Ter um salário justo é a norma. O salário é muito maior que a norma (mercado) - também, curiosamente, o fator é bastante desmotivador. Certa vez, um colega me contou sobre uma equipe de programadores em uma das grandes empresas americanas de animação que, por várias razões, recebeu salários de duas a três vezes o mercado. Como ele disse, nunca havia visto programadores mais cansados, preguiçosos e desmotivados em sua vida. O fato de um aumento salarial poder motivar a curto prazo, mas após alguns meses, um novo salário se torna a norma e deixa de motivar. Em geral, eu diria que para os programadores no início de uma carreira, o fator salário é mais importante, à medida que crescem profissionalmente e se desenvolvem - sua importância diminui e outros fatores começam a prevalecer.
O segundo ponto importante é a presença de um equilíbrio justo no nível de salários da equipe. Se a equipe achar que a contribuição de um dos participantes é notavelmente mais baixa, mas o nível de remuneração não for diferente, isso desmotivará toda a equipe. Às vezes, os gerentes são tentados a inundar o fogo com dinheiro - para manter uma pessoa esgotada ou desmotivada, elevando seu salário acima da norma. Isso geralmente cria apenas problemas a longo prazo - a motivação da pessoa em si não irá crescer especialmente, ou crescerá em alguns meses, mas a motivação do resto da equipe diminuirá. Nessas situações, vale a pena procurar outras abordagens, a menos que, é claro, seja um especialista único que precise ser mantido a todo custo, mesmo por um curto período de tempo.
II A necessidade de segurança, conforto, constância das condições de vida:
Há 70 anos, a presença de um fogão em um carro poderia ser um fator motivador na escolha de um carro, então estava acima da norma, era um sinal de luxo. Agora, mesmo a ausência de um ar-condicionado é um absurdo, e sua presença não será um fator motivador na escolha de um carro. Então, há 10 a 15 anos, um escritório conveniente, bom ferro, café delicioso, boa forma, horário flexível, etc. podem ser bons fatores motivadores, mas agora é a norma para um bom programador trabalhar. Ao mesmo tempo, a ausência deles desmotivará novamente.
Um importante fator desmotivador é a falta de capacidade de concentração, um ambiente de trabalho barulhento. O trabalho de um programador requer silêncio e concentração. Se o espaço do escritório não oferecer a oportunidade de fornecer aos desenvolvedores um local de trabalho isolado, é necessário garantir pelo menos uma colaboração confortável entre colegas que não interferem entre si. É melhor unir camaradas energéticos e barulhentos entre si, possibilitando que aqueles que precisam se concentrem.
O custo do tempo do programador agora é visivelmente mais alto que o custo do ferro no qual ele trabalha. Dois ou três monitores, computadores potentes, um local de trabalho conveniente para cada desenvolvedor - devem ser a norma em qualquer empresa. Este tópico está bem divulgado em um dos artigos de Joel Spolsky "
O teste de Joel: 12 etapas para codificar melhor".O componente físico do conforto é o mais básico e simples, agora vamos falar sobre o resto.
Em muitas empresas, a norma para os programadores trabalharem é um horário de trabalho flexível e falta de código de vestimenta. Isso é bom e correto se os recursos da equipe permitirem (por exemplo, não há reuniões com clientes, políticos ou banqueiros).
Um ponto importante é a presença de uma janela de tempo específica, quando toda a equipe trabalha em conjunto localmente, para que as pessoas possam se comunicar e resolver os problemas pessoalmente. O programador, de fato, não sai do trabalho, mesmo depois do trabalho. Normalmente, momentos de trabalho rolam em sua mente, independentemente de sua presença no escritório, e boas decisões geralmente saem dele. Dada a necessidade de ser bom (sobre o qual nos referimos abaixo), o controle mesquinho é prejudicial. Não apenas desmotiva, mas também reduz o desempenho. Como mostra a prática, na ausência de controle, é provável que uma equipe motivada trabalhe mais do que o necessário. Com controle, os desenvolvedores podem sentar no teclado das nove às seis, mas o resultado, eu acho, será pior. Como se costuma dizer, uma pessoa pode levar um cavalo a um local de rega, mas nem uma centena o fará beber se não quiser.
Na descrição desse nível de necessidades, a liberdade de ansiedade e medo, a ausência de caos, a necessidade de estrutura e ordem também são mencionadas. Esses também são pontos extremamente importantes que afetam bastante a atmosfera da equipe.
Em primeiro lugar, a ausência de caos, estrutura e ordem - a equipe deve entender quem é responsável por quê, como as funções são alocadas, o que fazer, quem, quando, quais requisitos estão no coração do produto, quais são as expectativas dos chefes e dos clientes ... A maioria disso deve formalmente descrito, tudo deve ser discutido periodicamente. Sem discussão e uso periódico, as descrições não funcionam. É uma boa prática revisá-los e atualizá-los periodicamente após a análise post-mortem após o lançamento.
Em segundo lugar, uma atmosfera calma e amigável. Todos passamos a maior parte do tempo no trabalho e queremos fazê-lo sem estresse, conflito ou medo. A equipe de desenvolvimento já costuma trabalhar sob pressão do cronograma e dos clientes. Ninguém precisa de estresse adicional de colegas e superiores. A atmosfera na equipe, em geral o próprio fato de um grupo de desenvolvimento poder ser chamado e ser uma “equipe”, é de responsabilidade direta e importante do gerente, uma das tarefas mais importantes de médio e longo prazo. Portanto, é importante que o gerente trabalhe, em particular, com conflitos na equipe, para não deixar o desenvolvimento à deriva. O gerenciamento de conflitos é um tópico separado que merece um estudo separado.
Existem duas maneiras principais de influenciar o estado emocional de uma equipe, o comportamento dos colegas (se alguém adicionar nos comentários, tudo ficará bem). O primeiro é o seu próprio comportamento. Um exemplo pessoal é super importante para o gerente e a equipe. Como se costuma dizer, o que é pop, é a paróquia. Comporte-se como você espera que seus colegas se comportem. O segundo é a promoção do comportamento correto e, por assim dizer, a promoção do errado. Comunique-se com as pessoas, dê-lhes feedback, existem muitas maneiras de fazer isso. Em geral, o feedback é um tópico para outra discussão, é uma parte grande e importante do trabalho com motivação.
Outra observação sobre a atmosfera, que pode parecer incomum, mas na prática é importante. Na maioria das vezes, há menos meninas na equipe de desenvolvimento do que homens. Muitas vezes, as equipes são completamente masculinas. Em tais condições, também sob carga, o vocabulário às vezes obsceno começa a ser usado na equipe. A prática mostra que isso afeta negativamente a atmosfera, a comunicação gradualmente se torna rude. Você deve evitar usá-lo e não incentivar o uso em equipe.
As equipes de desenvolvimento são freqüentemente chamadas de P&D (pesquisa e desenvolvimento), e a pesquisa é uma parte significativa do trabalho. Essa é a parte que geralmente é difícil de programar e planejar, caso contrário não seria pesquisa. É importante que a equipe tenha o direito de cometer um erro, de tomar a iniciativa, de experimentar diferentes opções que podem terminar em sucesso ou não. Erros são uma parte normal do trabalho, não podem ser evitados, mas você pode estudar, analisar, aprender com eles para o futuro e seguir em frente. O princípio 5 do porquê, originário da Toyota, ajuda a chegar à causa raiz do problema. Punir erros é uma ótima maneira de criar uma atmosfera de medo e insegurança. A única exceção é quando, de acordo com os resultados da análise, verifica-se que o erro é causado por uma atitude não profissional em relação ao trabalho; nesse caso, pode ser necessário tomar decisões de pessoal.
A atmosfera na equipe é muito influenciada por suas expectativas, pelo estado emocional antes do início da conversa. Antes de iniciar uma discussão difícil, é importante algum tipo de discussão ou apenas uma conversa emocional, sua atitude, a atitude com a pessoa com quem você vai conversar. Eu sempre penso por padrão e ajo com base no que uma pessoa sinceramente tentou fazer o melhor. Se você perceber que esse não é o caso, precisará descobrir com calma e profundidade o contexto e entender o que ele fez de certo, por que ele achou que estava certo e onde nossas expectativas divergem. Geralmente acontece que eles realmente não divergem, apenas a visão dele do contexto é mais completa ou nova e você não sabia de nada. Ou, pelo contrário, ele não sabia de nada. Isso é especialmente importante em uma equipe distribuída, quando as pessoas têm menos probabilidade de se comunicar pessoalmente, usam correio e mensagens instantâneas. Isso é ainda mais crítico em uma equipe composta por programadores de diferentes países e distribuídos entre diferentes fusos horários. Aqui, as diferenças culturais começam a desempenhar um grande papel.
Em uma situação difícil, mover-se rapidamente é simples, muito simples, mas é difícil recuar e o sedimento permanece por um longo tempo. Vou dar um exemplo simples de experiência recente. Um dos gerentes da equipe precisava urgentemente de comentários sobre o problema de um cliente de um gerente de uma equipe adjacente de outro país. Ele enviou um ping para um colega no messenger, esperou 15 minutos, pingou novamente e, 15 minutos depois, entrou em um grande bate-papo no qual havia outros gerentes, e encontrou um colega com uma expressão como: “já que você não se digna de me responder, talvez , e a pergunta não é tão urgente? ”. Como resultado, verificou-se que nosso mensageiro corporativo era um pouco chato e o colega não viu a pergunta. Eu tive que me desculpar. Em geral, é melhor começar do bem. É sempre possível cometer um erro e atropelar mais tarde, não há problemas com isso (embora você não deva fazer isso). Em geral, por mais de 20 anos de trabalho em nossa indústria, conheci um colega realmente malicioso apenas uma vez! Felizmente, terminamos muito rapidamente. A suposição de que os colegas desejam o melhor, da melhor maneira que eles têm em relação ao contexto, é correta na grande maioria dos casos.
Sua tarefa como gerente é garantir a sincronização de contextos, um entendimento comum das expectativas, requisitos e prazos adotados pela equipe de padrões. Pode parecer insignificante, mas a atmosfera na equipe é construída precisamente a partir de insignificantes. Do ponto de vista de uma equipe distribuída, uma das tarefas importantes é garantir a comunicação pessoal periódica dos membros da equipe. Ouvi muitas vezes de programadores que depois que, por exemplo, os engenheiros da equipe de suporte os procuravam e trabalhavam juntos, eles permaneciam felizes no trabalho para ajudar em um caso difícil pessoalmente a Pasha, que os visitou recentemente, embora anteriormente Pasha era apenas um ícone no messenger, e ninguém se demoraria por causa do ícone.
Aliás, falei sobre a equipe de suporte e lembrei de um exemplo canônico para mim. De alguma forma, um dos clientes na América teve um problema com o produto, um dos engenheiros da equipe de suporte que trabalhou em sua implementação (enviada da Rússia) permaneceu após o trabalho para ajudar, mas o problema não foi resolvido e não foi resolvido. Em geral, ele permaneceu e ficou lá quase até a manhã. Nesse momento, os gerentes de clientes escalaram o problema, identificaram sua importância para eles e deixaram o trabalho à noite. O processo de escalação já estava ganhando força em outro fuso horário, os gerentes de suporte na Rússia começaram a tentar ajudar, devido a certas dificuldades de comunicação com o escritório do cliente (VPN, problemas de comunicação, dificuldades com chamadas entre países, ...) eles não sabiam que o cara já estava sentado no escritório e resolve o problema, e tentou encontrá-lo. Encontrado apenas pela manhã (americano), quando o problema já estava praticamente resolvido por ele e o produto conquistado. Eles começaram a correr para a pedreira, que diabos, o cliente tem uma escalada tão grande, nada funciona, onde ele carrega você, não podemos encontrá-lo, etc. Escusado será dizer que, como resultado de tal comportamento, o cara estava muito desmotivado. Organizar uma equipe distribuída é um grande tópico separado, mas há duas coisas a serem lembradas. Primeiro de tudo, a comunicação, a atmosfera é muito importante, o sucesso do trabalho depende disso. Em segundo lugar, isso não funciona por si só, deve ser tratado separadamente e em profundidade.
Outro ponto importante relacionado a esse nível de necessidades é o salário novamente. Não o tamanho do salário, como tal, mas a existência de uma certa ordem de mudança. A empresa deve ter uma abordagem para determinar os requisitos para posições em diferentes níveis. Cada desenvolvedor deve poder discutir as expectativas de seu trabalho com a empresa, para entender como ele e quando seus esforços podem afetar seu salário. Reuniões periódicas com o gerente, certificações semestrais ou anuais atendem a esse objetivo. Novamente, esse é um daqueles momentos cuja presença não motiva explicitamente, mas sua ausência motiva fortemente.
Da necessidade de ordem e da disponibilidade de regras, segue-se a necessidade de cumprir essas regras, de seguir as regras adotadas pela equipe, formais e informais. Geralmente, eu a chamava de necessidade de "ser bom". A presença dessa necessidade confirma que não é necessário um microgerenciamento, é prejudicial. É o suficiente para fornecer a uma pessoa tudo o que é necessário para o trabalho, dar-lhe conhecimento do contexto, prioridades e liberdade de ação e tomada de decisão em seu nível. , , .
, — , . . . , , . , , . — , , , . “
Google — Site Reliability Engineering ”, , , , , .
Para continuar ...