Epígrafe:
O marido, olhando para os filhos sujos, diz à esposa: bem, vamos lavá-los ou dar à luz novos?
Abaixo do corte está a discussão do líder de nossa equipe, bem como do Diretor de Desenvolvimento de Produto RAS, Igor Marnat, sobre as peculiaridades de motivar programadores.
O segredo do sucesso na criação de produtos de software interessantes é bem conhecido - reúna uma equipe de programadores interessantes, dê à equipe uma ideia interessante e não interfira no trabalho da equipe. Desenvolvedores legais são raros e muito procurados. Alguns recrutadores chegam a dizer que têm a impressão de que é mais fácil produzir um programador bacana do que contratar um do mercado. Além das dificuldades de contratação como tal, a experiência de cada desenvolvedor específico, seu conhecimento do produto existente e do histórico de seu desenvolvimento, muitas vezes é insubstituível ou difícil e demorado de reabastecer. Portanto, se você tiver sorte e já contar com uma equipe bacana de programadores, é importante trabalhar a motivação deles. Contratar e treinar novos desenvolvedores, formar uma equipe com eles é quase tão difícil e demorado quanto dar à luz e criar filhos.
Consideremos os principais fatores de motivação dos programadores (equipes de programadores), utilizando a pirâmide de Maslow para maior clareza e estruturação da apresentação. Se você ainda não ouviu falar da pirâmide de Maslow, não é uma teoria indiscutível, mas muito popular e ilustrativa do psicólogo americano Abraham Harold Maslow, que propôs uma teoria da motivação pessoal baseada na hierarquia das necessidades humanas (veja a imagem abaixo).
Maslow organizou as necessidades do indivíduo em uma ordem hierárquica, desde as necessidades fisiológicas até a necessidade de desenvolvimento potencial e autorrealização. Uma suposição fundamental na teoria de Maslow é que "uma pessoa não pode experimentar necessidades de nível superior até que suas necessidades de nível inferior sejam satisfeitas". Por exemplo, uma pessoa não pode ser movida pela necessidade de conhecimento ou por necessidades estéticas se ao mesmo tempo não dorme nem come há três dias.
Antes de entrar em detalhes, vamos nos concentrar em um fato óbvio: uma equipe é formada por pessoas, todas as pessoas são diferentes, cada uma tem sua própria estrutura de motivação. Além de cada pessoa ser movida por interesses diferentes, cada pessoa também se encontra em condições de vida diferentes. 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 dominar uma nova área temática. O que é importante para um é completamente sem importância para outro, e amanhã tudo mudará novamente. Para entender corretamente esse contexto, existe um remédio simples - você precisa pensar e trabalhar com ele. O mais importante é a comunicação.
Não deixe de conversar com sua equipe sobre algo além do trabalho, construa relacionamentos informais.
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, biológicas:
Quando se fala em motivação, muitas pessoas costumam pensar primeiro em salário. Neste caso, por salário entendo uma parte permanente do pacote de remuneração, que não depende de forma alguma dos resultados. Isto não se aplica a bônus, bônus e promoções da empresa. É o salário que eu atribuiria ao nível de “necessidades fisiológicas” no nosso caso. Bônus, bônus por desempenho, opções e ações da empresa – eu classificaria tudo isso em outros níveis.
Na minha opinião, por mais estranho que possa parecer, o salário poderia ser bastante desmotivador um fator motivador e não um fator motivador. A peculiaridade de trabalhar com programadores é que todos são pessoas, em primeiro lugar, muito inteligentes (uma característica da profissão) e, em segundo lugar, profundamente e/ou amplamente instruídas. Normalmente, os programadores, além de sua profissão, possuem um conhecimento profundo de uma ou mais áreas para as quais criam produtos. Além disso, bons programadores estão interessados e conhecem bem a história do desenvolvimento de programação, algoritmos, padrões, etc. O mesmo se aplica à sua área temática. Para pessoas deste nível, o salário geralmente não é o principal fator de motivação.
Ao mesmo tempo, a falta de um salário justo para os programadores, no seu entendimento, desmotiva e desmotiva muito. Ter um salário justo é a norma. O salário é muito superior ao normal (de mercado) - também, curiosamente, um fator bastante desmotivador. Certa vez, um colega me contou sobre uma equipe de programadores de uma das grandes empresas de animação americanas que, por uma série de circunstâncias, recebia salários duas a três vezes superiores aos do mercado. Como ele disse, nunca tinha visto programadores mais entediados, preguiçosos e desmotivados em sua vida. O fato do aumento salarial pode motivar no curto prazo, mas depois de alguns meses o novo salário passa a ser a norma e deixa de motivar. De forma geral, eu diria que para programadores em início de carreira o fator salário é mais importante, pois à medida que crescem e se desenvolvem profissionalmente, sua importância diminui e outros fatores passam a prevalecer.
O segundo ponto importante é a presença de um equilíbrio justo no nível salarial da equipe. Se uma equipe sentir que a contribuição de um membro é visivelmente menor, mas o nível de remuneração é o mesmo, isso desmotivará toda a equipe. Às vezes, os gerentes ficam tentados a alimentar o fogo com dinheiro - para reter uma pessoa esgotada ou desmotivada, aumentando seu salário acima do normal. Isso geralmente só cria problemas no longo prazo - a motivação da própria pessoa não aumentará muito, ou aumentará por alguns meses, mas a motivação do restante da equipe diminuirá. Nessas situações, vale a pena buscar outras abordagens, a menos, é claro, que se trate de um especialista único que precise ser contratado a qualquer custo, mesmo que por pouco tempo.
II. Necessidade de segurança, conforto, consistência das condições de vida:
Há 70 anos, a presença do fogão no carro podia ser um fator motivador na hora de escolher um carro, então estava acima do normal e era um sinal de luxo. Agora até a ausência de ar condicionado é um absurdo, e sua presença, claro, não será um fator motivador na hora de escolher um carro. Então, há 10-15 anos, um escritório conveniente, bom hardware, café delicioso, fitness, horários flexíveis, etc. poderiam ser bons fatores de motivação, mas agora esta é a norma para o trabalho de um bom programador. Ao mesmo tempo, a sua ausência será novamente desmotivadora.
Um importante fator desmotivador é a falta de capacidade de concentração e um ambiente de trabalho barulhento. O trabalho de um programador exige silêncio e concentração. Se o espaço de escritório não oferece a oportunidade de fornecer aos desenvolvedores um espaço de trabalho isolado, é necessário pelo menos garantir uma colaboração confortável entre colegas que não interfiram uns com os outros. É melhor unir camaradas enérgicos e barulhentos, dando oportunidade de concentração a quem precisa.
O custo do tempo de um programador é agora significativamente maior do que o custo do hardware no qual ele trabalha. Dois ou três monitores, computadores potentes, um local de trabalho confortável para cada desenvolvedor – deveria ser a norma em qualquer empresa. Este tópico é bem abordado em um dos artigos de Joel Spolsky “O Teste Joel: 12 etapas para um código melhor.”
A componente física do conforto é a mais básica e simples, agora falemos do resto.
Em muitas empresas, a norma para programadores é um horário de trabalho flexível e nenhum código de vestimenta. Isto é bom e correto se as especificidades do trabalho da equipa o permitirem (por exemplo, não há reuniões com clientes, políticos ou banqueiros).
O importante é ter um intervalo de tempo específico onde toda a equipe trabalhe em conjunto localmente para que as pessoas possam se comunicar e resolver problemas cara a cara. Um programador, em essência, não sai do trabalho mesmo depois do trabalho. Normalmente, as questões de trabalho se repetem em sua mente, independentemente de sua presença no escritório, e as boas decisões geralmente vêm de fora do escritório. Dada a necessidade de ser bom (que discutiremos abaixo), o controle mesquinho é prejudicial. Além de desmotivar, também reduz a produtividade. Como mostra a prática, na ausência de controlo, é mais provável que uma equipa motivada trabalhe mais tempo do que o necessário. Se houver controle, os desenvolvedores podem ficar sentados diante do teclado das nove às seis, mas o resultado, creio eu, será pior. Como se costuma dizer, uma pessoa pode levar um cavalo até a água, mas mesmo cem não o forçarão a beber se ele não quiser.
A descrição deste nível de necessidades também menciona a ausência de ansiedade e medo, a ausência de caos e a necessidade de estrutura e ordem. Esses também são pontos extremamente importantes que afetam muito o clima da equipe.
Em primeiro lugar, a ausência de caos, estrutura e ordem - a equipa deve compreender quem é responsável por quê, como os papéis são distribuídos, o que precisa ser feito, para quem, quando, quais os requisitos subjacentes ao produto, quais são as expectativas da gestão e o cliente... A maior parte disso deve ser descrito formalmente, tudo deve ser discutido periodicamente. Sem discussão e uso periódico, as descrições não funcionam. É uma boa prática discuti-los periodicamente e atualizá-los com base nos resultados da análise post mortem após a liberação.
Em segundo lugar, uma atmosfera calma e amigável. Todos nós passamos a maior parte do tempo no trabalho e queremos fazê-lo sem estresse, conflito ou medo. A equipe de desenvolvimento geralmente trabalha sob pressão de cronogramas e clientes. Ninguém precisa de estresse adicional de colegas e superiores. O clima na equipe, em geral o próprio fato de um grupo de desenvolvedores poder ser chamado e ser uma “equipe” é responsabilidade direta e importante do gestor, uma das tarefas mais importantes de médio e longo prazo. Por isso, é importante que um gestor trabalhe, principalmente, com os conflitos na equipe, e não deixe o desenvolvimento deles seguir seu curso. A gestão de conflitos é um tópico separado que merece estudo separado.
Existem duas formas principais de influenciar o estado emocional da equipe e o comportamento dos colegas (se alguém acrescentar nos comentários, seria ótimo). O primeiro é o seu próprio comportamento. O exemplo pessoal é super importante para um gestor e uma equipe. Como se costuma dizer, assim como o padre, assim é a chegada. Comporte-se da maneira que você espera que seus colegas se comportem. A segunda é encorajar o comportamento correto e, por assim dizer, desencorajar o comportamento errado. Comunique-se com as pessoas, dê-lhes feedback, há muitas maneiras de fazer isso. Em geral, o feedback é um tópico para uma discussão separada; é 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 raparigas na equipa de desenvolvimento do que homens. Muitas vezes os grupos são inteiramente masculinos. Nessas condições, também sob carga de trabalho, às vezes linguagem obscena começa a ser utilizada na equipe. A prática mostra que isso tem um impacto negativo na atmosfera: a comunicação torna-se gradualmente rude. Você deve evitar usá-lo sozinho e desencorajar seu uso em sua equipe.
As equipes de desenvolvimento são frequentemente chamadas de P&D (pesquisa e desenvolvimento), com a pesquisa constituindo uma parte significativa do trabalho. Esta é a parte que normalmente é difícil de programar e planear, caso contrário não seria investigação. É importante que a equipe tenha o direito de errar, de tomar iniciativas, de tentar diferentes opções que podem ou não terminar em sucesso. Os 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 dos 5 Porquês, que se originou na Toyota, é uma boa maneira de chegar à causa raiz de um problema. Punir os erros é uma ótima maneira de criar uma atmosfera de medo e incerteza. A única exceção é quando, com base nos resultados da análise, se constata que o erro foi causado por uma atitude pouco profissional em relação ao trabalho, neste caso pode ser necessário tomar decisões de pessoal.
A atmosfera na equipe é muito influenciada por suas expectativas e estado emocional antes do início da conversa. Antes de iniciar uma discussão difícil, algum tipo de interrogatório ou apenas uma conversa emocional, é importante seu humor e atitude em relação à pessoa com quem você vai conversar. Por padrão, sempre acredito e ajo com base no que a pessoa sinceramente tentou fazer de melhor. Se pela sua posição parece que não é assim, você precisa conhecer com calma e detalhes o contexto e entender o que ele fez de certo, por que achou que estava certo e onde nossas expectativas divergem. Geralmente acontece que eles realmente não divergem, apenas que a visão dele do contexto é mais completa ou atual, e há algo que você não sabia. Ou, inversamente, ele não sabia de algo. Isto é especialmente importante em uma equipe distribuída, quando as pessoas se comunicam pessoalmente com menos frequência e usam e-mail e mensagens instantâneas. Isto é ainda mais crítico numa equipa composta por programadores de diferentes países e distribuídos por diferentes fusos horários. É aqui que as diferenças culturais começam a desempenhar um grande papel.
Numa situação difícil, dirigir em movimento é fácil, muito fácil, mas depois voltar é difícil e o sedimento permanece por muito tempo. Deixe-me dar um exemplo simples de experiência recente. Um dos gerentes de equipe precisava urgentemente de comentários sobre algum problema com um cliente de um gerente de uma equipe relacionada em outro país. Ele pingou um colega no messenger, esperou 15 minutos, pingou novamente, depois 15 minutos depois foi para um grande chat em que os outros gerentes também estavam, e atacou levemente o colega, com uma frase do tipo: “já que você não dignou-se a me responder, talvez, e a pergunta não é tão urgente? No final, descobriu-se que nosso mensageiro corporativo estava um pouco enfadonho e o colega nem percebeu a pergunta. Eu tive que me desculpar. Em geral, é melhor começar com o que é bom. É sempre possível cometer um erro grave e ter problemas mais tarde; não há problema com isso (embora você não deva fazer isso). Em geral, em mais de 20 anos de trabalho em nosso setor, encontrei um colega verdadeiramente malicioso apenas uma vez (!). Felizmente, terminamos muito rapidamente. Acontece que, na grande maioria dos casos, é correto presumir que os colegas querem o melhor, na medida do seu melhor entendimento do contexto.
Sua tarefa como gestor é garantir a sincronização de contextos, um entendimento comum de expectativas, requisitos, prazos e padrões aceitos na equipe. Podem parecer pequenas coisas, mas o clima na equipe é construído justamente a partir dessas pequenas coisas. Do ponto de vista de uma equipe distribuída, uma das tarefas importantes é garantir que os membros da equipe tenham comunicação presencial periódica. Já ouvi mais de uma vez de programadores que depois, por exemplo, engenheiros da equipe de suporte vieram até eles e trabalharam juntos pessoalmente, eles ficaram felizes no trabalho para ajudar pessoalmente Pasha, que os havia procurado recentemente, em um caso difícil, embora antes Pasha fosse apenas um ícone no mensageiro, e ninguém teria parado por causa do ícone.
Falando em equipes de suporte, lembrei-me de um exemplo clássico. Certa vez, um cliente nos Estados Unidos teve um problema com o produto. Um dos engenheiros de suporte que trabalhava na implementação (cedido da Rússia) ficou depois do expediente para ajudar, mas o problema simplesmente não era resolvido. Ele ficou até tarde, quase de manhã. Enquanto isso, os gerentes do cliente escalaram o problema, identificaram sua criticidade e foram embora naquela noite. O processo de escalonamento ganhou impulso em um fuso horário diferente, e 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 conexão, dificuldades com chamadas internacionais, etc.) Eles não sabiam que o rapaz já estava no escritório resolvendo o problema e tentaram encontrá-lo. Só o encontraram de madrugada (horário americano), quando ele já havia praticamente resolvido o problema e o produto estava funcionando. Imediatamente, começaram a importuná-lo, dizendo: "Que droga, o cliente está exigindo mais de nós, nada funciona, onde você está? Não conseguimos te encontrar", e assim por diante. Desnecessário dizer que esse comportamento deixou o rapaz extremamente desmotivado. Organizar uma equipe remota é um assunto extenso e à parte, mas é importante lembrar duas coisas. Primeiro, a comunicação e o ambiente de trabalho são cruciais; o sucesso do trabalho depende deles. Segundo, isso não funciona sozinho; precisa ser tratado separadamente e em profundidade.
Outro ponto importante relacionado com este nível de necessidades é novamente o salário. Não o tamanho do salário em si, mas a presença de um determinado procedimento para alterá-lo. A empresa deve ter uma abordagem para determinar os requisitos para cargos em diferentes níveis. Cada desenvolvedor deve ser capaz de discutir as expectativas de seu trabalho com a empresa, entender como e quando seus esforços podem afetar seu salário. Reuniões periódicas com o gestor, avaliações de desempenho semestrais ou anuais atendem a esse propósito. Este é, novamente, um daqueles momentos cuja presença não motiva explicitamente, mas a sua ausência é muito desmotivante.
Da necessidade de ordem e da presença de regras decorre a necessidade de cumprir essas regras, de seguir as normas aceites na equipa, tanto formais como informais. De modo geral, eu chamaria isso de necessidade de “ser bom”. A presença desta necessidade confirma que o microgerenciamento não é necessário, mas sim prejudicial. Basta dotar uma pessoa de tudo o que é necessário para o trabalho, dar-lhe conhecimento do contexto, das prioridades e proporcionar liberdade de ação e tomada de decisão ao seu nível. Nessas condições, ele sentirá confiança, a oportunidade de tomar suas próprias decisões, assumir a responsabilidade por elas e poderá revelar seu potencial.
Outro ponto importante que deve ser atribuído à necessidade de ordem e à ausência de caos é a capacidade de concentração em uma tarefa, a ausência de mudanças frequentes de contexto. Ser programador requer tempo e foco. Os programadores realmente não gostam de desistir urgentemente de uma tarefa e mudar para outra. Uma parte necessária do trabalho de um programador geralmente não é apenas o desenvolvimento real do código, mas também a correção de bugs e assistência no processamento de solicitações de clientes. Vale a pena planejar essas coisas com antecedência, de forma a permitir que o programador conclua com calma e completamente o trabalho em uma tarefa antes de passar para outra. A melhor opção é dar a si mesmo a oportunidade de planejar seu trabalho, identificando antecipadamente prioridades e tarefas futuras, alocando longos períodos de tempo para trabalhar em um tipo de tarefa. Este tópico está bem descrito no livro “Google – Engenharia de confiabilidade do site”, que descreve bem as abordagens de planejamento do trabalho de equipes que garantem a operação e o desenvolvimento de sistemas grandes, altamente carregados e tolerantes a falhas, bem como de engenheiros cuja ocupação combina desenvolvimento de software e seu suporte.
Para ser continuado ...
Fonte: habr.com
