Quando você trabalha como desenvolvedor, vê o tempo todo como os líderes de equipe atendem a um monte de chamadas, são responsáveis por tudo, escrevem tanto código quanto você e, ao mesmo tempo, não têm mais dinheiro. Tanto ideológicos quanto idiotas vão atrás disso.
Não sou um idiota, minhas ideias não giram em torno de valores empresariais, então você não me subscreve. Mas nem sempre somos questionados sobre isso. Primeiro, fui contratado como o primeiro e único desenvolvedor em uma startup renascida, então eles me disseram para contratar mais pessoas, e então me vi encarregado de três desenvolvedores, dois testadores e um analista.
Em suma, tudo é ainda pior do que parecia de fora.
Seis pessoas todos os dias esperam que você diga a elas o que fazer, então você lhes dirá como fazer e então também avaliará se se saiu bem. A sétima pessoa no final do dia também perguntará o que você fez. No sentido de que você se codificou, e o que fez cada uma das pessoas por quem você é responsável.
Certa vez, reclamei aqui que o toque é uma muleta que permite que você controle sem se aprofundar, e agora estou mais uma vez convencido de que estava certo. Eles vêm até mim com uma pergunta - e não tenho ideia do que responder. Ligamos um para o outro e uma pessoa obtém uma resposta de meu infeliz cérebro sem minha participação. Também não estou pronto para formular minhas perguntas - não tenho ideia do que fazer. Então eu apenas ligo e vejo como tudo se resolve. E ainda melhor - eu faço com que eles se telefonem, sem mim. Já faz um mês que não consigo encerrar uma tarefa bastante simples, pois meu cérebro está exausto de deveres administrativos e, principalmente, de não saber como executá-los.
Eu pensei, ok, é assim que deve ser. Não estudei para ser gerente. Então olhei para o meu passado, lembrei-me de todas as minhas pistas e de repente percebi - ninguém estudou! Nenhum deles sabia como administrar. Eles também o mascararam com intermináveis telefonemas e procrastinação. Eles não sabiam o que responder, não sabiam para onde estávamos indo, não sabiam o que estava acontecendo e quem estava fazendo o quê.
Quando eu fiz uma tarefa simples por dois meses e todos os dias menti que tinha grandes dificuldades e havia um problema sério - e então fiz uma solicitação de pull de quatro arquivos que foram esboçados durante a noite - ninguém me repreendeu, não porque eles estavam arrependidos. Eles simplesmente não tinham ideia do que eu estava fazendo lá. E eles olharam meu código linha por linha - para chegar ao final da nomenclatura e encontrar antipadrões interessantes - mas não se aprofundaram nele. Porque não há tempo para aprofundar, eu não quero, e não está claro o porquê.
Todos os meus chefes anteriores abraçaram e idolatraram o ágil - é um grande conjunto de muletas, um jogo que ajuda um monte de pessoas que não têm ideia do que está acontecendo, fingir que está tudo bem e estamos seguindo em frente.
Trabalhei com líderes de equipes locais, que em equipes sérias nem seriam admitidos no layout, trabalhei com gerentes de desenvolvimento bacanas de grandes empresas estrangeiras, trabalhei com pessoas que alguém considerava verdadeiros gênios da programação.
E todos eles, quando se tratava de gestão, sentavam na bunda. Aprendi as regras deste jogo no meu primeiro trabalho com o Agile. Ligávamos um para o outro todas as manhãs e todos diziam o que haviam feito, estavam fazendo e estariam fazendo. No primeiro telefonema, tive a idéia de relatar e provar que não estou comendo meu pão em vão. Comecei um longo, muito longo discurso sobre minha tarefa, expliquei em detalhes por que ela ainda não estava pronta e com o que estou lutando agora. Eu fui cortado no meio: “Phil, você quer alguma coisa de nós? Não? Ok, todos nós descobrimos quem é o próximo? "
A pessoa que nos controlava precisava saber apenas uma coisa - se eu lançaria problemas para ele por hoje ou não. Ele tem que ficar comigo hoje. Antes de eu começar a falar, ele já tinha o discurso perfeito na cabeça para mim: “everithin gous akordin that plan”. Qualquer outro desenvolvimento de eventos para ele é puro mal.
Existe outra opção. Quando o problema foi trazido a ele não por mim, mas por outras partes do sistema, o agile agile está estragado e agora ele não pode dizer em sua reunião para leads que tudo está indo conforme o planejado - e também se torna o problema de alguém. Isso automaticamente me torna o problema dele, e ele bate no PM.
Começamos a discutir algo e ambos entendemos - precisamos encontrar uma maneira de deixar de ser problemas. Não tem nada a ver com o produto ou projeto. Temos uma porra de um ingresso que precisamos mover. E nós o movemos - da maneira mais simples possível. Nós corrigimos com o código, colocamos no norepro, colocamos o rótulo “bloqueado por” - tanto faz. Neste momento, não nos importamos absolutamente com o produto, nosso ticket está pegando fogo. Ou muitos ingressos.
Em qualquer equipe onde trabalhei, havia duas realidades. Uma realidade é um produto real e pessoas reais que o melhoram porque querem. E então havia jira, que existe absolutamente paralelo a tudo isso. E a única pessoa que pode sincronizar o estado real do projeto com os cartões é o líder da equipe.
Todos os líderes de equipe com quem trabalhei não sabem como fazer isso - e eles não querem. Eles trabalham como trabalham e usam o jiru para considerar cumpridas suas responsabilidades administrativas. Afinal, as pessoas que avaliam os líderes de equipe olham para Jira, não para o produto. E quem olha o produto só consegue gerar novos tickets para o jira. Eles não podem avaliar os programadores. Mas jira não afeta nada! Já vi produtos horríveis que tinham o quadro kanban em perfeitas condições e ótimos produtos que tinham tíquetes na coluna “no trabalho” por três meses com o título “faça um projeto”.
O argumento “Eu vi” não é muito bom, mas servirá, porque tenho quase certeza de que você também viu.
Em um sentido amplo, um líder de equipe deve certificar-se de que as pessoas que realmente desejam trabalhar não tenham problemas. E pessoas que não querem nem dar o fora nem passar para a primeira categoria. Toda a dor do gerenciamento está no segundo - há muitos mais. E ninguém faz nada com eles. Somente um desenvolvedor pode determinar adequadamente se um desenvolvedor funciona bem. Esta é uma história muito compreensível - você precisa revisar completamente suas solicitações de pull e se aprofundar em suas tarefas, e há um problema - consome tanto tempo quanto custaria para fazer tudo sozinho. Em suma, não é uma opção.
Portanto, foram puros gerentes, não desenvolvedores, que decidiram identificar os desenvolvedores ruins. Eles criaram vários sistemas com tickets, gráficos, todos os tipos de avaliações de desempenho e esse chapéu. E até funcionaria, em alguns burros. Mas mesmo os piores desenvolvedores são inteligentes o suficiente para enganar este sistema. Bem, você sabe como é feito. Eles medem tudo em tickets, certo? Legal. Vou decompor o "redesenhar a interface do formulário X" em dez tarefas no estilo "corrigir o rótulo no botão Y". A mesma quantidade de trabalho, mais ingressos. O líder da equipe me chutaria na cara por essas fintas.
Mas no sistema atual, ele nunca fará isso. Afinal, em primeiro lugar, quanto mais tickets são fechados, menos problemas ele tem. Em segundo lugar, ele é carregado o suficiente para examinar meus ingressos e meu código. Em terceiro lugar, ele mesmo faz isso - por causa de seus deveres de liderança, ele também não tem força para ter um bom desempenho. E em quarto lugar, e isso é o mais importante, ele pode muito bem ser uma daquelas pessoas que não quer trabalhar.
Esta é a minha experiência, a experiência de todos os meus conhecidos - mas tem exceções. Existem empresas onde o processo de desenvolvimento funciona muito bem. Vou te dizer por quê - eles ganharam na loteria. Eles acabaram tendo muito mais pessoas que querem trabalhar - com pessoas que não administram, tudo correrá bem. Eles até usam ouropel gerencial com quadros de negócios, e seu desempenho é claramente visível tanto por jir quanto por métricas intuitivas. E quando seus gerentes não desenvolvidos atrapalham, eles têm um ótimo produto por trás deles que lhes dá o direito de mandar essas cabeças falantes para o inferno.
Essas equipes são autorreplicantes - durante o processo de contratação, elas aprovam intuitivamente apenas pessoas como elas e têm peso suficiente na empresa para não dar palavras decisivas aos RHs que estão jogando suas “métricas” e psicologia.
Mas essa equipe é uma sorte fantástica. E o que geralmente acontece é isso. Para dez pessoas, você tem duas que querem trabalhar. Um deles é líder de equipe e o outro desiste. O desenvolvimento funciona mal e os gerentes vêm para consertá-lo. E daquele momento em diante, não haverá mais chance. Os gerentes construirão um processo em torno de jira, assumirão o controle de coisas que eles não entendem absolutamente. Eles vão construir uma contratação de pessoas cujo trabalho eles não sabem absolutamente nada, eles vão começar a convidar os desenvolvedores existentes lá que vão divertir o ChSV, registrar desta vez no relatório de tempo e dar feedback aleatório. E então eles decidem quem contratar - também aleatoriamente. As pessoas que desejam trabalhar, de vez em quando, entrarão nessas equipes, onde se transformarão em preguiçosos ou não criarão raízes.
Não quero dizer que os gerentes sejam idiotas e não possam fazer nada. Eles ainda sabem como administrar. Mas não por desenvolvedores. Os desenvolvedores só podem ser controlados por um desenvolvedor que realmente saiba como gerenciar. Tal pessoa fixará a equipe com qualquer proporção de vontade e má vontade de trabalhar.
A única pena é que quase não existem. Para se tornar um bom desenvolvedor, você precisa ser inteligente e aprender muito. Para se tornar um bom gerente, você precisa ter talento e muito aprendizado. E então qual é a chance de uma pessoa combinar essas duas qualidades? É o mesmo. Ao mesmo tempo, a maioria dos líderes de equipe na indústria se tornou eles, porque, bem, alguém deveria. Absolutamente aleatório.
Acho que você precisa aprender a compreender que o desenvolvimento é uma habilidade, o gerenciamento é a segunda habilidade e o gerenciamento do desenvolvimento é a terceira habilidade que inclui partes da primeira. E isso deve ser estudado separadamente. E de forma muito metódica e eficiente. Até que façamos isso, teremos desenvolvedores que não podem gerenciar desenvolvedores e gerentes que não podem gerenciar desenvolvedores.
Publicidade
Muitos clientes já apreciaram os benefícios dos servidores épicos da Vdsina .
Estes são VDS baratos com processadores AMD EPYC, frequência de núcleo de CPU de até 3,4 GHz. A configuração máxima permitirá que você realize quase qualquer ideia - 128 núcleos de CPU, 512 GB de RAM, 4000 GB de NVMe. Você também pode pedir!
