O desenvolvedor é uma pessoa entusiasmada comum; há pouco sentido em discutir isso. Objetivamente, devido ao fato de que aprender programação com jovens exige muito tempo e esforço, muitos desenvolvedores se parecem um pouco com ursos. E agora vou explicar o porquê.
Um urso é geralmente um animal único. A hibernação de inverno sozinha é uma questão de respeito. Adicione a isso o tamanho, a onívora e o habitat, e obteremos o predador mais alto que não possui inimigos naturais. Qualquer zoólogo lhe dirá que o urso é um animal solitário. E apenas no estilo de vida como solitário reside o principal problema de interação com o urso:
ele praticamente não possui um sistema de sinal de imitação . Apenas outro urso pode causar danos a um urso na natureza, mas eles simplesmente divergem em direções diferentes, preferindo uma retirada tática a uma batalha sangrenta. Ou seja, o nível de emocionalidade dessa fera pode ser comparado com a emocionalidade de Chuck Norris, veja por si mesmo:
Entre os desenvolvedores, existem muitos desses "ursos" diretos. O problema é que, com essa franqueza, o "urso" perde qualquer chance de reconhecer dicas e meios-tons, pelo menos sem uma experiência triste e extensa. Portanto, nesta publicação, falaremos sobre vários "métodos" básicos que as pessoas más usam para espremer um funcionário que lhes é censurável da empresa.
Métricas. Muitos e diferentes
A primeira maneira de pressionar uma pessoa é revisar as métricas de sua eficácia na direção da complicação e aumentar seu número. Como diz um ditado: “Não importa como eles votem. O principal é o que eles pensam. ” De fato, o trabalho pode se tornar maior, simplesmente será considerado de maneira diferente. Quanto mais métricas e mais confusas forem, maior a probabilidade de o especialista cometer algum erro e entender mal os requisitos da gerência.
Esses erros desamarram as mãos do oponente e o oponente começa a pressioná-lo. Pode ser de qualquer natureza: desde arrastões públicos em comícios matinais / coffee breaks até depremização. A essência da complicação das métricas é uma: tirar uma pessoa de um estado de equilíbrio profissional.
Ao mesmo tempo, a traseira é coberta de forma confiável. O mal-intencionado pode preparar um extenso banco de dados na forma de um fluxo de trabalho prescrito, realizar correspondência tediosa por correio e envolver outros métodos de "artigos de papelaria e crochê sujos" para complicar a vida de uma pessoa. Na maioria das vezes, as vítimas dessa fraude são pessoas que gozam da autoridade da equipe, mas, ao mesmo tempo, podem, no futuro, se candidatar a uma posição de liderança. De fato, essa é a eliminação dos concorrentes no estilo do confronto dos anos 90.
Como lidar com isso? Primeiro de tudo, absolutamente todas as métricas não podem ser inequívocas. Se o gerente disser que a interação por correio deve ser alocada em 10% do tempo de trabalho e você gastou 12% ou 15%, já que você teve que entrar em contato, por exemplo, com o front-end, isso não pode ser um motivo para o processo. Além disso,
o supervisor direto deve ser responsável por todas as métricas expostas . No Crossover, em caso de discrepância severa entre as métricas definidas pelo gerenciamento, os resultados dos desenvolvedores são igualmente solicitados ao gerenciamento. Se o trabalho foi concluído e o processo de trabalho está indo na direção certa, portanto, um erro foi cometido pelo gerente que expôs métricas irrealistas ou incorretas.
Infelizmente, na maioria das empresas, o princípio da responsabilidade bilateral pela implementação de métricas não é respeitado e o desenvolvedor não tem a oportunidade de iniciar o processo de avaliação de sua adequação, o que libera as mãos da gerência e permite que ele se envolva em tal "assalto". Na maioria das vezes, métricas inadequadas são de natureza local; se você se depara com a descida do "impossível" desde o topo, esses são problemas estruturais globais sobre os quais falamos no texto sobre
gerentes "eficazes" .
A introdução da responsabilidade coletiva pela punição
Muitas cópias já foram quebradas sobre o tema da responsabilidade coletiva. Geralmente, essa ferramenta é praticada para os chamados relacionamentos de confiança de construção dentro da equipe. A mensagem leve é: "ajude-se, corrija e explique os erros aos seus colegas e você se tornará uma grande equipe".
Na execução adequada, essa abordagem permite que você "puxe" rapidamente os recém-chegados, elimina a necessidade de nomear mentores "por baixo do bastão" e todos os outros mecanismos coercitivos.
De fato, a responsabilidade coletiva geralmente se transforma em uma ferramenta repressiva para exercer pressão sobre a equipe e seus membros individuais. O postulado de bônus coletivos por um trabalho bem-sucedido é omitido e todas as explorações de trabalho da equipe são desvalorizadas com a expressão "você deve trabalhar 100% de qualquer maneira". Por outro lado, quaisquer erros que sejam questionáveis à liderança de uma pessoa levam a sanções coletivas contra toda a equipe.
Como resultado, o "culpado" das sanções é retirado da equipe: quem tem o prazer de perder bônus e bônus devido aos erros de outra pessoa? Se o departamento não tiver unidade suficiente, muito rapidamente um funcionário questionável se torna um pária, após o que ele começa a mudar de emprego.
Pressão sobre a auto-estima profissional
Outra técnica que uma pessoa pode tentar sobreviver do seu local de trabalho é expressa ao exercer pressão sobre a auto-estima profissional do empregado. O que poderia ser mais importante do que a auto-estima profissional? Para muitos profissionais de TI, o nível de auto-estima pessoal se correlaciona diretamente com o nível de profissional. As realizações no campo profissional nos dão força para o desenvolvimento e crescimento pessoal, mostram que somos capazes de ser melhores do que poderíamos contar.
Em suma, a auto-estima profissional é um ponto muito, muito sensível, sobre o qual você não deve pressionar. Mas como exatamente isso é afetado? Existem algumas maneiras simples: definir tarefas borradas e dúvida pública de competência. Normalmente, esses "truques" são usados em conjunto.
O especialista que eles querem espremer da empresa recebe tarefas tão vagas quanto possível, principalmente por via oral, para não deixar vestígios. Se os regulamentos da empresa exigirem que você corresponda e defina tarefas detalhadas - não hesite em entender o que está escrito, você terá que ressuscitar Turing e toda a equipe que trabalhou com a descriptografia das mensagens do Enigma. Se o desenvolvedor não procurou explicações - bem, tudo bem, isso significa que
ele certamente entenderá tudo errado e poderá arranjar uma tragada, pelo menos por sua iniciativa e pela ordem errada na tomada de decisões.
Se o desenvolvedor considera que está jogando alguns jogos com ele e adota o princípio de "a eficácia e a qualidade do trabalho realizado dependem da clareza da tarefa" e continua a esclarecer a tarefa, ele cai na próxima armadilha nesta cadeia.
O principal é que, na hora de colocar a pergunta "Que tipo de lixo é esse na minha tarefa?" havia tantos espectadores leais quanto possível. Então, quando a pergunta é dita, os olhos são arredondados e a contra-pergunta no estilo da Terra Prometida é feita o mais alto possível: “Bem, como um desenvolvedor tão experiente e habilidoso não pode lidar com a tarefa mais simples do junho verde?!”. Bem, o teor da chamada pode ser qualquer coisa, o objetivo é humilhar publicamente uma pessoa.
O problema do desenvolvedor é que ele percebe coisas como "Deus, por que tenho que trabalhar com idiotas", isto é, com frequência, garantido. De fato, ele cai em uma armadilha cujo objetivo é humilhá-lo como profissional aos olhos de seus colegas e dar um golpe em sua própria auto-estima. Como se essas situações forem repetidas sistematicamente, mesmo a pessoa "mais forte" começará a pensar pelo menos em uma mudança de emprego e, no mínimo, a perder o interesse no projeto, ou seja, ela terá problemas reais, em vez de absurdos, com produtividade. O que nossos oponentes só precisam.
Como lidar com esse terror
O objetivo de todas as manipulações desse tipo é o mesmo - afrouxar a equipe e derrubar pessoas potencialmente perigosas e / ou poderosas. Mas isso acontece quando você simplesmente "não gosta do rosto". Por que fazemos isso, omitiremos, porque essa já é uma questão para um artigo sobre ética corporativa e ela se cruza diretamente com o tema da gestão "eficaz". De fato, mencionamos apenas alguns dos exemplos mais impressionantes de exercer pressão sobre os desenvolvedores, cujo objetivo é forçá-los a sair. De fato, existem muitos outros truques "sujos", que vão desde fofocas na cozinha do escritório até a sabotagem direta do trabalho.
A primeira maneira de se proteger contra essas ações é interagir em caso de disputas com a liderança um passo mais alto. Em empresas adequadas, um funcionário sempre pode recorrer diretamente ao "chefe de seu chefe". Mas existem dois grandes "MAS". Primeiro: se tudo isso acontecer com a sanção de gerentes superiores, livrar-se da pressão não funcionará. Segundo: o líder deve estar pronto para agir como árbitro, o que nem sempre acontece.
A segunda maneira é através de uma fixação clara de cada etapa e tarefas do gerenciador de tarefas, a fim de evitar reclamações formais e arrastar o conflito para um plano prático, onde os desenvolvedores tenham uma vantagem. Esta é uma guerra posicional - quem sobreviverá e quem quebrará. O problema com esse método de contração é que os erros não podem ser cometidos aqui e o lado defensor está em uma posição conscientemente perdida, uma vez que as “regras da guerra”, isto é, as tarefas, geralmente são determinadas pelo atacante.
Ainda existe uma terceira via mítica, quando uma equipe se une a uma vítima de pressão e não permite que uma pessoa sobreviva de seu local de trabalho. Nesse caso, o conflito entra em uma fase prolongada do confronto e, muito provavelmente, levará a uma mudança de liderança (porque é mais fácil e mais barato do que abandonar toda a equipe e recrutar uma nova). A principal condição é a eficiência no plano de trabalho.
Mas esse é um cenário quase fantástico, porque não foi à toa que mencionei a natureza emocional "de baixa" das pessoas de TI. Quando percebemos que um colega precisa de nossa ajuda, ele já assina documentos com mais freqüência por sua própria dispensa e o convida para uma reunião de despedida em um bar próximo.