Como as estratégias chinesas ajudam no trabalho

Nosso trabalho diário costuma ser como uma série de confrontos. Nós "brigamos" com clientes e outras equipes, com testadores e colegas, e departamentos da empresa competem entre si. Lutamos por salários, tomando decisões técnicas convenientes, prazos e milhares de outras coisas. Nesta série de conflitos, o líder da equipe é o líder de uma pequena unidade de combate, a equipe. Ele conhece os pontos fortes e fracos de cada "comum", coordena e organiza seu trabalho para atingir objetivos com o mínimo de perdas.

Se você observar o trabalho do líder de equipe desse ponto de vista, é importante o planejamento estratégico e o trabalho posicional dentro e fora da equipe. Ao mesmo tempo, não se esqueça das táticas. Inesperadamente, o conhecimento das antigas estratégias chinesas ajuda a planejar uma estratégia e reagir taticamente.



Alexey Zolotykh ( zolotyh ) - líder da equipe no Infobip. Alexey usa em seu trabalho as regras de guerra da China antiga. Em um artigo baseado em seu relatório no Saint TeamLead 2019 , você aprenderá como os estratagemas ajudam na vida de um líder de equipe: como fazer as pazes com um desenvolvedor dentro de uma equipe, como ganhar credibilidade entre colegas, como defender sua opinião, por que sacrificar uma ameixa, repreender uma acácia, fingir ser louco e bater na grama.

Estratagemas

Uma estratagema é uma sequência calculada de ações destinadas a resolver um problema específico.

São regras, movimentos estratégicos e táticas para alcançar objetivos diferentes. Estratagemas foram usados ​​em hostilidades. Basicamente, eles são descritos nos livros "Trinta e seis estratagemas" e "A arte da guerra", atribuídos a Sun Tzu. Esse estrategista e pensador chinês viveu cerca de 500 aC. Mas o conceito de “estratagema” vive na cultura da China há 3.000 anos, então podemos assumir que o autor dos tratados é todo o povo chinês.

Mas surge a pergunta - somos Timlids, de onde vem a guerra? Não lutamos, não lutamos com ninguém e não capturamos, por que precisamos de estratagemas?

Sistema de freios e contrapesos

No livro de Ray Dalio “Principles”, há uma ideia importante: qualquer empresa ou equipe é um sistema de freios e contrapesos. Uma empresa está congelada de conflitos e confrontos.

Vou explicar com um exemplo. A empresa "Abstract" possui dois departamentos: testadores (QA) e desenvolvedores. O objetivo dos desenvolvedores é chegar à produção o mais rápido possível e liberar o produto no prazo, porque eles têm KPI para isso. Os testadores têm prioridades diferentes: é importante que eles encontrem o maior número possível de erros, porque eles têm KPI de qualidade. Dois departamentos abstratos de uma empresa abstrata estão constantemente entrando em conflitos e confrontos abstratos.

Uma situação semelhante existe entre o RH e os proprietários da empresa. Simplificando, o objetivo do RH é contratar o maior número possível de pessoas. Mas, para isso, você precisará aumentar o orçamento, porque agora as pessoas em TI são caras. Os proprietários da empresa querem contratar pessoas mais baratas. Mais uma vez, conflito e confronto.

Conflitos nas empresas entre diferentes departamentos, funcionários, equipes, gerência e subordinados ocorrem constantemente no formato de comícios, diálogos e discussões. Eles podem ser considerados como uma espécie de confronto militar, e conselhos sobre a guerra serão apenas úteis.

Vejamos os estratagemas que podem usar timlids. Os estratagemas são escritos em linguagem poética, e isso não é coincidência, pois são fáceis de lembrar.

O general é lento porque está considerando a vitória

É necessário se preparar para todos os comícios. Capitão Evidence aparece aqui, mas não, espere ...

“Não é quem sabe jogar de acordo com todas as regras. O vencedor é quem sabe como abandonar todas as regras na hora certa, impor suas próprias regras no jogo que são desconhecidas pelo inimigo e, quando necessário, abandoná-las. ” Esta é uma explicação do estratagema de um livro sobre eles. Se aplicado à TI, diz que quem define as regras no início do rali e vence .

Em 2017, falei em uma conferência. Um dos objetivos da minha apresentação era "vender" a linguagem Dart para o público. Este é um YP bastante estranho, não popular, mas eu o amo muito. É claro que o público da conferência não está pronto para ele, então criei um "truque militar".

Chamei um “júri” de três pessoas para o palco para expressar certas características do JavaScript, TypeScript e Dart e comparar essas três linguagens. Mas eu próprio defini o formato da competição e propus as regras. Como líder e principal no palco, eu disse:
- De acordo com minhas estimativas, no TypeScript a digitação é de 5 pontos em 10, no JavaScript não é de todo e no Dart é de 10 em 10.

Quem, além de Chuck Norris, ainda escolheria o TypeScript com esses argumentos? Isso não é lógico, ninguém quer ser "não como todos os outros". Portanto, o júri simplesmente não teve a oportunidade de escolher um vencedor de forma diferente do que eu pedi. Previsivelmente nesta "batalha" Dart derrotou porque eu me preparei.

Sozinho espere um inimigo cansado

Um ótimo estratagema ilustrado por duas histórias.

"Vamos reescrever tudo em ..."

Como líder de equipe, tenho relativa liberdade na escolha de tecnologias; portanto, meus colegas de equipe costumam vir até mim (não uso a palavra "subordinados", acho que isso está errado). Geralmente eles dizem algo assim:
- Vamos lançar o TypeScript e reescrever tudo no Flow!

Ou:
- Há uma coisa legal - GraphQL. Você fez um relatório sobre ela e está fazendo campanha por ela. Vamos implementá-lo!

Saí dessa situação de maneira muito simples:
Eu realmente gosto de GraphQL. Mas vamos escrever um plano de implementação por seis meses, levando em consideração as duas dúzias de serviços que já implementamos e depois fazer um relatório sobre isso?

Temos um formato de apresentação às sextas-feiras. Curiosamente, acontece às quartas-feiras, porque carregar colegas com algo novo na sexta-feira não é muito bom.

Se uma pessoa é responsável, motivada e segura de que está certa, é mais provável que ela termine o projeto. Mas se ele quiser apenas conversar e argumentar, nem olhará nessa direção: ele terá que se comunicar com alguém, pesquisar, preparar uma apresentação e trabalhar adicionalmente.

Então eu mato dois coelhos com uma cajadada:

• Não calo uma pessoa e nem ouço em todas as manifestações sobre o GraphQL como ele resolverá todos os nossos problemas e assim por diante;
• se uma pessoa, no entanto, concluir o projeto, ele se tornará um bom líder de equipe no futuro e teremos algo novo e legal.

"Estou com preguiça de escrever, vamos lá em voz"

Esse truque da vida me disse um bom amigo. Imagine que você recebe uma solicitação de recebimento e precisa realizar uma revisão, encontre alguns erros. Você entende que nesta solicitação de pull a raiz do mal é profunda: o desenvolvedor absolutamente não entende o que está fazendo, então tudo está escrito incorretamente e você o denuncia. O desenvolvedor não concorda (o esperado), chega até você e diz: "Escute, estou com preguiça de escrever, vamos discutir assim".

Não aceite isso! Se as pessoas vierem falar com você, então "conversar" é gratuito. Você pode dizer uma hora e não custa nada. Temos toda a correspondência em inglês e, quando você precisa responder, às vezes é mais rápido refazer do que usar o Google Tradutor. Há menos disputas: a pessoa já está cansada, não está interessada em lutar.

Sacrifique uma ameixa para salvar um pêssego

Há situações em que você pode dar algo pequeno em troca da coisa principal. Portanto, antes de iniciar as negociações, é importante entender o que é importante para nós e o que é secundário.

Chegamos às negociações com uma posição preparada.

Scrum cerebral

Existem duas opiniões condicionais no Infobip: alguns dizem que Scrum e Agile são legais, enquanto outros sugerem escrever mais código e menos conversas. Nas reuniões, a segunda posição é expressa no fato de uma pessoa levar um laptop com ele e esbarrar nele - nada pode ser ganho com ele.

Nesse caso, nos comunicamos com o funcionário:
- Vamos fazer desta maneira: você pode não participar de uma reunião do Scrum, mas precisa conhecer os resultados. Mas se você ainda veio, remova o laptop e trabalhe conosco.

Uma pessoa entende que, se perder a reunião, terá que se atualizar e ninguém saberá sua opinião. Eu sacrifiquei a presença de um funcionário, e isso machuca o orgulho e, no final, ele chega de qualquer maneira. O problema está resolvido.

Apontando para uma amoreira, repreenda a acácia

Grigory Bakunov tem um bom relatório no qual ele sugere que qualquer desenvolvedor esteja no processo criativo característico de crianças de 5 a 7 anos. Segundo ele, qualquer desenvolvedor de 5 a 7 anos (condicionalmente), e ele precisa conversar com ele como uma criança .

Eu tenho um filho, ele tem quase um ano e meio. Eu li livros especializados sobre pais e filhos. Em um dos livros, aprendi a “enganar” um homenzinho a comer mingau: conte a um conto de fadas que há estômago, e ele se sente mal quando sua boca não lhe dá mingau, e tudo isso é como exemplo de menino. .

Como aplicá-lo nos desenvolvedores? Anteriormente, quando eu queria dar um feedback a alguém, eu dizia diretamente:
- Oleg, aqui e aqui você está errado. Para melhorar as coisas amanhã, faça isso e aquilo.

Na maioria dos casos, isso prejudica a auto-estima: uma pessoa dá desculpas e diz por que está certa ou por que não poderia fazer o contrário. Agora eu vou do outro lado:
- Imagine que você é um líder de equipe e tem uma situação dessas. O que você vai fazer?

Coloquei-o no meu lugar e perguntei o que ele faria nessa situação. O orgulho do desenvolvedor está em ordem, e ele está se acostumando com o papel de líder de equipe e está procurando maneiras de resolver o problema.

Finja ser louco, mantendo sua mente

Fingir ser um tolo minha vida favorita hackear. O princípio é simples: se você tiver uma pergunta técnica, pergunte. Não conheço você, mas não sou a pessoa mais inteligente da equipe e estou bem ciente disso.

Fazer perguntas é normal.

Em uma das minhas empresas anteriores, uma pessoa trabalhou em uma posição bastante alta de vice-presidente de engenharia (CTO). Ele continuou repetindo:
"Não entendo suas coisas técnicas, explique-as em russo."

Ou:
- Isso levará à confusão do código. E com o que isso nos ameaça? Porque Como

CTOs como eu têm mais 30 pessoas. A única maneira de entender o que está acontecendo é perguntar repetidamente.

Quando uma pessoa responde à sua pergunta "estúpida" em palavras simples, você entende onde há lacunas na lógica dele. Nesse momento, você faz perguntas esclarecedoras e descobre onde algo está errado: o eufemismo entre os argumentos, os possíveis problemas que podem ser disparados. Portanto, não tenha medo de fazer perguntas estúpidas.

Se você acha que dessa maneira perde sua “autoridade” e “cara profissional”, lembre-se de Richard Feynman . Este é um ganhador do Nobel, co-autor da teoria da eletrodinâmica quântica, um dos desenvolvedores da bomba atômica, um artista e quebrador de cofres. Na década de 1960, Feynman proferiu suas palestras na Caltech, que mais tarde foram publicadas em três volumes das Feynman Lectures on Physics. Até agora, essa é uma das explicações mais compreensíveis e populares dos fenômenos físicos, da mecânica à física quântica.

Segundo as regras, parece que esta é uma pessoa respeitável e séria. Mas, pelo contrário, ele não tinha medo de parecer estranho. Uma das características de Feynman é uma mente animada e uma auto-ironia. Ele constantemente fazia perguntas estúpidas , não tentava parecer "sólido" e tentava explicar coisas complexas em palavras simples. Uma de suas citações: "Se você é um físico quântico e não pode explicar brevemente a uma criança de cinco anos o que está fazendo, você é um charlatão".

Se os ganhadores do Nobel podem parecer estúpidos, ainda mais.

Atrair para o telhado e remover as escadas

Encontrei um problema na equipe: há um grande recurso que leva um tempo indefinido. Os gerentes estão sempre me perguntando quando o recurso será concluído, e os desenvolvedores não sabem o "quando" porque não podem determinar os requisitos. Em algum momento, eu disse:

Pare! O que você precisa para entender o tempo?
- Isso, isso e aquilo.
- Em seguida, realizaremos um comício em 1º de outubro. Vamos entender a essa altura se estamos a tempo ou não.
"Mas e quanto?" Talvez o furacão comece, o ônibus não chegue, alguém fique doente - como levar isso em consideração?
"Sim, e Godzilla atacará ... Vamos simplificar a tarefa: decidimos que não encontraremos nada e, se encontrarmos, apenas contaremos à gerência sobre isso." Mas até 1º de outubro, isso deve ser feito.

Mais importante, perguntei a todos se ele concorda com a data de 1º de outubro. Se eu não concordar, sugeri sugerir uma data diferente, justificando-a e dizendo até o topo. Resumidamente, o estratagema é descrito em uma frase.

Tire as rotas de fuga.

Se você quiser pegar alguma coisa, primeiro solte

Dê a oportunidade de salvar a cara

Eu vim com um líder de equipe para uma equipe já estabelecida. Naturalmente, a primeira coisa que decidi fazer foi "vender" minha autoridade.

Em uma das revisões de código, tive uma grande discussão com um desenvolvedor sobre arquitetura. Decidi descobrir quem está certo e quem não está: pedi a todos os líderes do setor uma opinião objetiva sobre o código sobre o qual estávamos discutindo. Todos que eu estava interessado em avaliar confirmaram que eu estava certo.

Apresentei todos esses resultados ao meu "rival" na esperança de que ele estivesse ciente de seu erro e que tudo se acalmasse. Mas tudo acabou de forma diferente. Meu oponente percebeu que estava perdendo credibilidade. Agora ele não está interessado no produto e, de qualquer maneira, quem está certo e quem não está é importante para salvar a cara. Depois disso, todas as minhas decisões foram repudiadas. O desenvolvedor não pensou no projeto, pensou em como mostrar que é mais inteligente. Tudo terminou com uma dolorosa transferência de uma pessoa para outra equipe (demissão). Eu estava certo, mas não deixei a pessoa salvar seu rosto. Eu ainda me arrependo.

Dê ao inimigo a oportunidade de sair da situação com dignidade.

Mesmo se você estiver completamente certo - o oponente deve manter sua dignidade. Se você pisar no calo, ganhará o inimigo.

Local como um tomate

Eu ouvi outro exemplo engraçado em uma palestra de Ludwig Bystronovsky, diretor de arte do Lebedev Studio. Imagine um designer que se oferece para criar um site como um tomate. Não está claro como isso ficará, e o mais importante, por quê? Mas o designer gosta e ele promove sua "ideia" apenas porque ele a criou.

Obviamente, não se deve concordar com essas idéias. Devolva o homem à terra:
- Entendo que você é um ótimo designer, mas essa ideia não é você, não funciona agora.

Esse é o mesmo princípio da conservação do rosto, mas no caso em que uma pessoa associa sua decisão a si mesma. Isso também precisa ser levado em consideração e trabalhar com ele.

Infelizmente, isso acontece não apenas em um ambiente criativo. Eu já vi casos em que os desenvolvedores se associavam ao GraphQL ou ao MongoDB, por exemplo. Tente separar idéias da pessoa, eu já me queimei com isso.

Bata a grama para assustar a cobra

Quando você recebe um grande projeto de longo prazo, aconselho a implementar o MVP: um projeto mínimo com todos os chips, problemas, bugs, o que ajuda a avaliar adequadamente a linha do tempo. Se o MVP simples criar duas semanas condicionais, ficará claro o que acontecerá a seguir.

Este é um bom conselho e funciona em qualquer lugar. Agora, oponho-me a uma abordagem diferente, já que nessa questão recebi um calo. Permita que o desenvolvedor faça melhor o MVP e algo específico pelo código do que funcione em um grande projeto de alguma maneira diferente.

Escape é o melhor estratagema

Evitar conflitos não é uma perda.

Como Sun Tzu disse, existem três opções.

• Faça um compromisso. Esta é uma decisão tímida: ambos ganham e perdem.
• Reconheça a derrota.
• Para sair. Mas isso não é uma perda, mas uma chance de retornar e corrigir.

Não se intrometa em conflito! Melhor não lutar, mas viver em paz.

“Lutar uma centena de vezes e ganhar uma centena de vezes não é o melhor dos melhores. O melhor dos melhores é conquistar um exército alienígena sem lutar. ”

Sun tzu

Tudo o que foi discutido no artigo até o último estratagema é manipulação. Nem todo mundo quer entrar em contato com eles, mas você precisa conhecê-los por dois motivos: às vezes você ainda precisa usar manipulações no seu trabalho , infelizmente, e é sempre melhor saber quando você está sendo usado do que não saber.

Tente menos conflito e não se deixe manipular.

Nesta nota positiva, lembro que você pode enviar uma solicitação de relatório para a próxima conferência para líderes de equipe até o final da semana, ou seja, 22 de dezembro. E uma semana depois, dentre centenas (eu suspeito que haverá ainda mais) de aplicativos, escolhemos os palestrantes do TeamLead Conf de fevereiro para que você não duvide mais da necessidade de comprar um ingresso para a conferência.