🚙 👨🏽‍🚒 👩🏿‍🏭 Maus conselhos ao desenvolvedor: o que fazer para "agradar" a gerência ⛑️ 🔙 👷🏻

Como prometido no artigo anterior , estamos virando a situação na direção oposta. Por acaso, eu não era apenas um desenvolvedor, mas também um líder em diferentes níveis. Já mencionei que ultimamente tenho tido sorte de equipes e colegas. Mas durante todo o tempo tudo aconteceu.

(Grigory Oster)

Vamos falar sobre com quais desenvolvedores a gerência sonha. Desta vez, atuarei como gerente abstrato ...

No início de qualquer projeto ...

Você sabia que a maior habilidade de um gerente é tomar decisões com o mínimo de informações iniciais. Líderes, não nos impeçam de treinar essa habilidade. Siga estas táticas:

Nomeie as datas nebulosas, mas não fale sobre elas.
Quando perguntarmos se as melhorias propostas não quebrarão os módulos existentes, fique em silêncio, faça uma pitada, faça uma expressão facial misteriosa!
Falando sobre os próximos problemas do projeto, nunca ofereça suas soluções, lembre-se de que precisamos de pessoas - perguntas, não pessoas - opções - soluções.
— , , ? 48- , 10 , .
— , .

Se no estágio de definição da tarefa, você foi admitido no cliente para fazer perguntas esclarecedoras, aprenda com os ataques DDoS - dê o melhor de si. O cliente espera de você pelo menos 50 mensagens com perguntas, de preferência em detalhes - ele apreciará sua atuação no gênero epistolar. Você não precisa anexar capturas de tela ou vídeos. Deixe-os descriptografar sua mensagem, mesmo que ela contenha apenas "Olá!" e um longo "digitando ...".

Lembre-se: o cliente e o usuário final são pessoas diferentes. Nunca se comunique com os usuários finais e não tente imaginá-los! Se a tia Masha, no caixa, vir 25 linhas de texto no monitor, coloque-as com calma, sem observar o tamanho da tela. Deixe a lente de aumento tirar se ela não gostar.

Nunca nos diga quais tarefas específicas serão resolvidas no projeto. Fale apenas sobre métodos de solução. E é desejável em todos os detalhes - de que outra forma o CTO dormirá em paz hoje à noite?

Na sua história, nunca mencione dinheiro, tempo ou outras métricas que os outros entendam. Afinal, até a secretária do diretor pode traduzir histórias sobre as estruturas abstratas usadas em cenários de usuários e a quantidade exata de lucro que obtemos. Portanto, ao avaliar tarefas, use o sistema de quantidades mais abstrato. Lembre-se, 1 jibóia é 38 papagaios!

Colha o máximo de surpresas possível. Além de tempo para resolver o problema, também serão necessárias assinaturas ou ferramentas pagas, sobre as quais não saberemos até o último momento. Adoramos as armadilhas e ficaremos felizes em procurar uma maneira de sair do impasse antes do lançamento. Meu cliente e eu adoramos aumentar o orçamento alocado semanalmente, coordenando-o constantemente em todas as instâncias. Conduza Ivan Tsarevich por uma nova iteração desde o início do conto após cada atualização de informações sobre o local onde a morte de Koscheev está armazenada.

Código perfeito ...

Tente escrever apenas o código perfeito para o código perfeito. Não é necessário fazer isso pela primeira vez. Se estiver com pressa, escreva rapidamente, refaça-o e depois novamente. Lembre-se: a repetição é a mãe do aprendizado. Se o código foi reescrito três vezes e pelo menos um pouco diferente do ideal, inicie a refatoração com urgência como parte de uma pequena tarefa que não se aplica a isso. Melhor ainda, transfira seu código para outra biblioteca ou estrutura. Deixe o código estar na moda e jovem. O principal é que, em nenhum caso, todos esses processos podem ser formulados como tarefas separadas. E, de repente, achamos que algo não era ideal no projeto? É melhor fazer coisas assim antes do lançamento. Neste momento, toda a equipe está trabalhando muito mais rápido!

Falando em refatoração. Ele funcionará com mais eficiência se você alterar simultaneamente os mecanismos no código - para não subir duas vezes lá. Lembre-se de que esses processos devem afetar o maior número possível de componentes. Por que gastar tempo escolhendo módulos individuais? Só assim você acabará parecendo um herói que salvou a todos! Outros desenvolvedores terão prazer em descobrir as surpresas dos novos mecanismos quando eles atirarem no pé deles.

O código perfeito deve ser formatado corretamente. Tente criar arquivos de tamanho máximo, ocupando muitas telas e contendo vários componentes ao mesmo tempo. Seguindo esse estilo de design, você pode superar heroicamente os conflitos de mesclagem e por um longo tempo concordar com colegas cujas edições foram mais importantes. O código deve se parecer com o macarrão mais longo, sem necessidade de perder tempo criando arquivos pequenos e insignificantes. Por uma única função, crie um nome de arquivo - o que poderia ser mais doloroso?

O código perfeito que você criou não é necessário para cobrir os testes. Você só pode falar sobre a necessidade de aumentar a cobertura para 100%, mas, na realidade, 10% é suficiente. Para acompanhá-lo, adicione alguns testes que, de fato, não verificam nada e não precisam ser atualizados.

Se de repente acontecer que uma solução rapidamente escrita não funciona ou não funciona conforme o esperado, fique à vontade para culpar o arquiteto do sistema, a API, o administrador do servidor etc. por tudo. É claro que seu código ideal não pode deixar de funcionar. Lembre-se do principal: nós, como você, sabemos que um programador ideal só pode trabalhar no vácuo em condições ideais. E se você estiver distraído, não forneça informações a tempo, escreva TK incompreensível, geralmente não será responsável pelo fato de o módulo implementado não cumprir a tarefa de negócios. Bem, certo, o negócio é nossa responsabilidade. É aconselhável manter todos os nomes dos fatores culpados até o prazo, eles serão necessários mais tarde, agora não distraia os líderes.

Quando falamos sobre a necessidade de liberar rapidamente o MVP, fique à vontade para ignorar nossas tentativas de acelerar o projeto em detrimento da qualidade e da velocidade. No entanto, eles sabem que, com uma boa ideia, você pode começar no mercado a qualquer momento. O tempo não desempenha nenhum papel. Deixe os concorrentes cagarem, e quando você escrever o código perfeito, nosso MVP aumentará em 5 anos. E todos esses anos, os investidores terão prazer em pagar pela criação de uma obra-prima com seu dinheiro.

A ordem no projeto ...

Sua tarefa é sua personalidade. Bagunça criativa irá adicionar peso aos nossos olhos. A capacidade de construir uma bagunça e mantê-la em um estado bastante caótico é tão valiosa que até transferimos projetos de mão em mão para aumentar o grau de desordem. Assim que o caos atingir o seu máximo, nós o recompensaremos com um novo projeto!

Se você entender que uma bagunça completa se formou no projeto, mas ainda não foi realocado, comece a cavar suas dívidas técnicas com as patas ou peça outro projeto por conta própria. Talvez não tenhamos acompanhado a situação.

Tudo o que acontece dentro da equipe deve passar por nós. Mesmo que você decida sair para fumar com o testador, não deixe de concordar com ele através do gerente de projeto, mas é melhor envolver o CTO nisso. Sentimos-nos desnecessários se ninguém reclama dos nossos colegas, não se vira para resolver disputas dentro do grupo de trabalho ou para introduzir algumas regras de trabalho.

Em questões de design, é aconselhável escrever apenas no PM. Isso ocultará todos os vestígios de nossa atividade da alta gerência e, ao mesmo tempo, nos forçará a recontar as soluções elaboradas para outros participantes do processo. Nós amamos tanto!

Solução de problemas ...

Depois de resolver o problema ou corrigir o bug, em nenhum caso, verifique sua solução. Grite "Hurrah" e fuja do local de trabalho o mais rápido e mais longe possível! Então, você entregará a tarefa mais rapidamente e encontrará uma lição para a equipe na primeira metade do próximo sprint - você corrigirá os batentes da tarefa que acabou de ser entregue. O que é importante, você também não priva o trabalho de seus colegas testadores. Um conjunto de bugs causados pela nova muleta na solução é o melhor presente na sexta-feira à noite! Verifique no seu código apenas um caso de sucesso, você é otimista.

A sequência correta de ações ao resolver um problema:

leia TK, ignorando notas,
fume para esquecer os detalhes,
rapidamente e sem hesitação, implemente apenas as funções básicas,
passar a tarefa tão rapidamente
Obtenha revisões com descriptografia clara de notas TK não lidas,
assim seja, corrija o problema em 3-4 iterações.

Sem refatoração na sequência, sem pentear o código. Deixe que as variáveis sejam chamadas como sua perna esquerda queria no momento do insight, e o código permanece mal lido. Não é para você entender isso mais tarde! Bem, treine para levar seu código para revisão imediatamente - você é um cara bom, mas sensível.

Nesse estágio, é impossível criar qualquer evidência de que a tarefa foi concluída (caso contrário, às vezes eles aparecem com um vídeo para gravar como o módulo é iniciado ...). Talvez o testador não note discrepâncias com o TOR, ou a tarefa será enviada para outra, enquanto, por enquanto, você pode relaxar em uma nova tarefa.

Se houver momentos ambíguos na tarefa, por exemplo, não se sabe se o campo de entrada deve aceitar apenas letras em inglês ou russo ao mesmo tempo, sinta-se à vontade para responder você mesmo às perguntas, de acordo com seus gostos e experiência de vida. Como não está escrito na declaração de trabalho, isso deve ser óbvio para todos!

E nunca teste hipóteses em uma pequena parte da tarefa; caso contrário, seus colegas acharão que você está em dúvida!

Se você estiver com pressa em executar uma tarefa para a liberação e entender que algumas funcionalidades precisarão ser concluídas posteriormente, não será necessário gastar tempo definindo a tarefa no sistema de gerenciamento de projetos. É melhor fazer uma anotação diretamente nos comentários do código e não contar a ninguém sobre isso. Portanto, será ainda mais interessante captar dívidas técnicas. Haverá a sensação de que existem muitos deles e você ainda é muito necessário no projeto.

Mantenha não mais que metade dos arquivos no repositório do projeto! Não é de admirar que tantos locais de armazenamento diferentes tenham sido inventados no mundo. É importante colocar os arquivos restantes igualmente entre os repositórios pessoais dos funcionários e, por exemplo, a documentação (nem mesmo necessariamente para o projeto atual). Portanto, o "conhecimento secreto" sobre o projeto será dividido igualmente na equipe e todos serão insubstituíveis. E então, algum recém-chegado ao projeto chegará e descobrirá rapidamente o que já foi implementado. Algo que você não pode resistir em seus lugares - todos serão substituídos instantaneamente por jones mais baratos.

Todo projeto deve ter um conhecimento secreto que é passado de boca em boca. Somente dessa maneira você pode tirar um suspiro de uma foto e, cuspir, dizer: "Oh, esses meses estão funcionando há uma semana, mas eles não sabem nada sobre o projeto. Afaste-se, faça você mesmo!

Se você se comprometeu a executar qualquer tarefa da Jira, não é absolutamente obrigatório marcá-la. Somos médiuns - adivinharemos o que você está fazendo agora, mas, ao mesmo tempo, adivinharemos o estado atual do projeto. A propósito, podemos fazer isso com o tempo gasto - não precisamos escrever nada em nenhum lugar, descobriremos o número de horas trabalhadas e calcularemos seu salário.

Comunicação sobre o projeto ...

Você já ouviu falar sobre omnichannel? A comunicação sem se dividir em diferentes canais é a última tendência. Estar na moda! Para qualquer dúvida, escreva PM para algum mensageiro, é melhor pessoal, não trabalhador - para que ele saiba que você não está por trás das últimas tendências deste mundo. Mas as equipes de projeto no Slack e em outros mensageiros são mais usadas para enviar fotos engraçadas com gatos e conversas pessoais.

Atrase-se para reuniões regulares de 15 a 20 minutos. Melhor ainda, mantenha um microfone da era soviética e Wi-Fi fora do local de trabalho. Deixe todo mundo ouvir o seu coaxar, é como pinturas abstratas - todo mundo ouve o que ele quer ouvir. E no Daily, você pode fazer todas as perguntas que tiver no projeto. Se não houver problemas de design suficientes, adicione mais tópicos. Na pior das hipóteses, você sempre pode perguntar algo abstrato. Um exemplo tão bom reflete melhor por que você não gosta de telefonar e por que não atende.

Bem, não se esqueça, toda pessoa tem bluetooth de alta velocidade na cabeça. Portanto, se você já imaginou tudo em sua cabeça, basta transferir esta imagem. As palavras podem explicar apenas pequenos detalhes que não eram visíveis na figura. Deixe-os tentar entender você, esse é o trabalho deles.

A propósito, vale a pena chegar atrasado ao escritório se você trabalha em nosso território. Essa é a única maneira de criar uma impressão de sua importância. E nunca avise sobre chegar atrasado. Isso mostrará que você estava com pressa, ou seja, estrague sua imagem de um guru calmo.

Se você sair do local de trabalho, não precisará se preocupar com a organização dos status no Slack ou em outros mensageiros instantâneos. Qualquer pessoa que escrever na sua ausência (e iniciar uma notificação) dará uma razão para uma longa e ponderada maldição de que você está sendo distraído no seu tempo pessoal. Onde mais você encontraria esse motivo? E deixe que gerentes e colegas aprendam a acumular suas perguntas rápidas antes do início do seu dia útil de trabalho (haverá algo a discutir no dia).

A troca de experiências é supérflua. Portanto, se você postar um link para um artigo ou estrutura no canal Educação no Slack, não precisará fornecer nenhuma descrição para ele. Que seja uma busca pelos colegas. Eles querem novos conhecimentos - deixe-os se esforçar e entender o que você jogou para eles. E não importa que essa não seja a área deles. E, em nenhum caso, não compartilhe suas observações do projeto, decisões interessantes, erros e conclusões instrutivas. Desenvolvedor para desenvolvedor wolf. Você deve competir e não desenvolver uma experiência de equipe comum! E sim, eu quase esqueci! Se você encontrar um artigo longo, não leia você mesmo, apenas exponha a seus colegas, talvez eles estejam interessados.

O trabalho de outros desenvolvedores pode e deve ser criticado. Você tem que encontrar falhas em todas as pequenas coisas. Só não confunda críticas e críticas. É necessário criticar extensivamente e com bom gosto (e de preferência o mais abstrato possível, por exemplo: “Seu código é terrível”), mas faça a revisão o mais rápido possível - clique na marca de seleção verde sem olhar para o código e sem deixar comentários. E então algumas razões construtivas de insatisfação terão que ser formuladas.

Transfira para nós toda a responsabilidade por sua motivação e treinamento avançado. Já estamos descansando para você, até fotos de capacete de diferentes resorts. Vamos também criar uma motivação para você. É claro que no projeto todas as tarefas são interessantes e, somente por danos, encontramos uma rotina para você. E organizamos pressa de propósito, porque você trabalha melhor nesse modo. No entanto, não o inscrevemos em cursos por danos. Você transfere todas as suas necessidades para nós via bluetooth, que é incorporado ao seu cérebro, nós as recebemos, mas as ignoramos. Não há necessidade de transformá-los em palavras, nós os sentimos de qualquer maneira.

No final do projeto ...

Quando pedimos que você mostre o projeto ao cliente, em nenhum caso, não se prepare para a demonstração com antecedência. É claro para todos: se o projeto começou no seu laptop, significa que ele está 100% funcionando e começará em qualquer lugar. Todos temos sorte!

Se, de acordo com os resultados da demonstração, o cliente estiver descontente, você sentirá um conflito iminente, deverá enviar o cliente para o inferno. Ele simplesmente não entende nada. E não há necessidade de informar o gerente. A propósito, um conflito com um cliente é a melhor razão para pedir-nos mais dinheiro. Teremos o prazer de concordar!

A data de lançamento é uma ficção. Adoramos marcar essas datas no calendário. De fato, os gerentes, especialmente no controle remoto, realmente não têm comunicação. E adiar as datas de lançamento é a melhor maneira de convocar rapidamente 3-5 reuniões nas quais as pessoas não se recusam a participar.

Quando a situação do projeto está esquentando, é hora de dissolver os rumores de que tudo entrará em colapso em breve. Dedique o máximo de colegas possível às suas suposições, espalhe mais negatividade. Se os rumores são justificados, sua distribuição nos motiva a corrigir a situação com o aceno de uma varinha mágica. E se não for justificado, estamos felizes por você ainda estar em boa forma.

A propósito, se os rumores não ajudarem, comece a entrar em pânico em coro. Esta é a solução mais construtiva. Nesse ponto, você pode começar a falar coisas desagradáveis sobre a empresa, não apenas por dentro, mas também por fora (por exemplo, em entrevistas). Definitivamente, isso ajudará a equilibrar a situação financeira e a conseguir colegas fortes em seus colegas!

No final do projeto, você pode deixá-lo em voz alta e eficaz, articulando a razão de sair com um salário muito baixo, apesar do fato de você estar no projeto há tantos anos e, para o nosso bem, não tocarmos em novas tecnologias. Sinta-se livre para ir para os concorrentes - eles vão gostar. Nossa missão favorita é procurar novos especialistas uma semana antes do lançamento. Quando você partir para outra empresa, não se esqueça de nós.

Diga a todos sobre um lado do problema. Fique em silêncio sobre suas "façanhas", conte-nos sobre quais gerentes são injustos. Não tente nos entender, conte para quem está de fora. NDA veio com covardes!

Todas as armadilhas devem ser relatadas apenas como último recurso - se o projeto não puder ser colocado em produção. Essa é a melhor formação de equipe quando a equipe "apaga o fogo" na noite anterior a um lançamento importante ou já em produção. Não prive você e a equipe deste prazer!

Se você ainda teve um lançamento na equipe e algo deu errado, poderá colocar com segurança bugs na produção no final da fila. Eles devem ter a mesma prioridade que todos os outros. Deixe-os entrar na fila!

Bem, e saiba que na noite após o desenvolvedor ser designado para o posto de serviço, metamorfoses profundas ocorrem com ele. Ele esquece todas as necessidades dos desenvolvedores, torna-se míope, autoritário, estúpido e inacessível. Portanto, nós - gerentes, gerentes e estações de serviço - entendemos tão mal vocês, os desenvolvedores.

Autor do artigo: Eugene Wetsel (imater)

PS Como na última vez , minha história tem apenas coincidências fantasmagóricas com a realidade. E a moral é esta: vamos levar em conta todo esse sarcasmo, construindo relacionamentos na equipe.

PPS Publicamos nossos artigos em vários sites de Runet. Assine nossas páginas no VK, FB, Instagram ou no canal Telegram para aprender sobre todas as nossas publicações e outras notícias do Maxilect.