Tecnologia
- Exija que sistemas centrais sejam reescritos ao longo de 6 a 18 meses. Culpe o CTO anterior.
- Incentive cada pessoa a usar linguagens e frameworks diferentes.
- Divida o sistema por fronteiras arbitrárias para que muitos sistemas se envolvam em cada funcionalidade.
- Crie um ambiente de desenvolvimento complexo. Faça com que rodem uma service mesh com pelo menos 12 serviços.
- Faça com que o ambiente de produção e o ambiente dos desenvolvedores sejam o mais diferentes possível.
- Faça deploy o mais raramente possível. Recomende extremo cuidado com deploys.
- Introduza processos extremamente complexos para mudanças de código e fluxos de trabalho gerais. Use como desculpa "segurança" ou "conformidade".
- Registre todo o trabalho em um rastreador de tarefas e faça com que um grupo de pelo menos 5 pessoas revise, priorize e aprove.
- Proíba qualquer coisa fora do escopo original do trabalho. Por exemplo, proíba limpeza de código ou outros tipos de melhoria.
- Construa internamente quase tudo que não seja competência central. Justifique com "para evitar dependência de fornecedor".
- Insista em adicionar uma camada de abstração a tudo. Use fornecedores abstraídos e adicione outra camada de abstração por cima.
- Recomende decisões técnicas com escala irrealisticamente otimista. Planeje para uma carga pelo menos 3 vezes maior do que a atual.
- Incentive a copropriedade dos sistemas. Faça com que ninguém sinta responsabilidade pela manutenção.
- Insista em centralizar quase tudo como "plataforma". Mantenha a equipe de plataforma com falta de pessoal e impeça que outras equipes construam o que a plataforma poderia possuir.
- Faça a equipe de plataforma iterar frequentemente as APIs e obrigue as outras equipes a refatorar o código para a versão mais recente.
- Contrate "arquitetos" e exija "revisão de arquitetura" até para pequenas mudanças.
- Exija "revisão de segurança" até para pequenas mudanças.
Produto
- Ignore métricas úteis por motivos acadêmicos. Por exemplo, chame-as de "enviesadas" ou "métricas defasadas".
- Escolha métricas de vaidade sem relação com valor de negócio. Escolha métricas cheias de ruído.
- Trate tudo como uma "grande aposta" e insista em não lançar nada até que tudo esteja completamente pronto.
- Trate todas as funcionalidades como "obrigatórias" e como parte crítica da "versão zero". Nunca faça concessões.
- Desenvolva planos "estratégicos" extremamente detalhados.
- Mude de direção com frequência.
- Descarte melhorias óbvias como "otimização local".
- Prenda recursos seguindo a moda do momento. Inicie uma "estratégia de IA" superficialmente plausível. Gaste muito com fornecedores e consultores para isso.
- Incentive gerentes de produto a passarem a maior parte do tempo com "estratégia" e "planejamento".
- Torne difícil ou impossível para engenheiros e gerentes de produto usarem o produto internamente.
- Despreze internamente os usuários como "idiotas".
Liderança
- Vincule recompensas a cargo e tamanho da equipe para incentivar inchaço.
- Fale em voz alta sobre estratégia, funcionalidades ou complexidade técnica.
- Faça aquisições caras para entrar em novas áreas de produto. Mencione "sinergia". Descontinue o produto adquirido.
- Use muitas linhas pontilhadas na estrutura de reporte.
- Faça com que o maior número possível de pessoas responda a gerentes de outras equipes, localidades ou funções. Garanta que os gerentes não consigam supervisionar seus reportes.
- Realoque com frequência pessoas de baixo desempenho para outras equipes.
- Coloque pessoas de alto desempenho em projetos de P&D muito especulativos, com entregáveis incertos.
- Exija reuniões até para decisões triviais.
- Insista que todos os "stakeholders" participem das reuniões.
Contratação
- Crie um processo de contratação que pareça objetivo, mas que na prática seja subjetivo.
- Rejeite os melhores talentos por "falta de fit cultural" ou outros critérios vagos.
- Contrate os candidatos mais fracos com base em "potencial", "atitude" ou outros critérios vagos.
- Contrate líderes seniores caríssimos com promessas de grandes aumentos de equipe.
- Use cargos inflados e funções inventadas para atrair oportunistas.
- Contrate "especialistas" extremamente especializados e depois crie projetos artificiais para que eles não peçam demissão.
- Use a especialização como justificativa para contratar outra pessoa complementar.
Gestão de projetos
- Exija estimativas extremamente detalhadas para todos os projetos.
- Incentive projetos envolvendo o maior número possível de equipes, idealmente em localidades diferentes.
- Adicione novos requisitos que dependam de trabalho realizado por outras equipes.
- Use agências caras com frequência. Deixe o escopo vago e entregue protótipos inacabados para as equipes internas finalizarem.
- Construa sistemas complexos de "autoatendimento" para stakeholders de outras equipes.
Resultado
- Reduzir a produtividade é difícil. Mas, se você cair de paraquedas atrás das linhas inimigas e conseguir um emprego como CTO, pode fazer isso acontecer.
- Para as pessoas não destrutivas: isto é sobre como extrair o máximo de produtividade de uma equipe. Produtividade é feita de pequenas coisas somadas.
- Se 100 pequenas coisas impõem cada uma um imposto de produtividade de 5%, tudo fica 131 vezes mais lento. Para manter os engenheiros felizes, você precisa rejeitar 100 pequenas coisas plausíveis e aparentemente razoáveis.
Opinião do GN⁺
- Este artigo explica de forma bem-humorada várias maneiras de prejudicar a produtividade no desenvolvimento de software. Com isso, deixa claro quais comportamentos devem ser evitados na prática.
- É importante reduzir dívida técnica e manter uma cultura de desenvolvimento eficiente. Evitar complexidade desnecessária e burocracia é o ponto principal.
- É importante criar um ambiente que aumente o moral da equipe e promova a colaboração. Isso afeta diretamente o aumento da produtividade.
- Este artigo ajuda a entender a complexidade da engenharia de software e da gestão. Em especial, oferece insights úteis para engenheiros iniciantes.
- Entre projetos semelhantes com funcionalidade parecida, há livros como "The Phoenix Project", que trata de como aumentar a eficiência em TI e DevOps.
11 comentários
Existe alguma empresa que não faça isso? buá buá
Mesmo que seja uma empresa pequena e bem-sucedida, parece que quando cresce acaba ficando assim...
Isso inclui a maioria das coisas que me mandaram fazer na empresa anterior: uso obrigatório de uma plataforma que nem dá para aproveitar... ignorar métricas padrão de desempenho... mandar refazer tarefas que já tinham sido feitas, etc.
Ué..?
Isso é totalmente tipo "Como programar de um jeito difícil de manter: você também pode ficar de boa como desenvolvedor pelo resto da vida"...
Vou optar pela rota da escalabilidade.
Ah... ah!.. aaa!!.. ah!... ah......
É triste ver algumas dessas coisas também na nossa organização. T_T
Isso me lembra o livro lendário "Como programar de um jeito difícil de manter".
Eu também, esse livro!
Talvez você pense: "Tudo isso?", mas acho que uma única pessoa ou uma única organização pode, sim, realizar tudo isso. ^^
Comentários do Hacker News
Falta confiança de que a proposta da CIA realmente tenha funcionado: nunca vi uma razão convincente de que a proposta original da CIA realmente funcionou, e as organizações tendem naturalmente a ignorar esse tipo de pessoa.
Como arruinar uma empresa: promover pessoas ruins para cargos de gestão e fazê-las otimizar coisas que não são lucrativas pode causar um grande prejuízo à empresa.
Como se tornar um CTO destrutivo: é fácil quase não fazer nada, eliminar pessoas competentes e criar uma cultura em que a responsabilidade é empurrada para baixo.
Trabalho por canais oficiais e exigência de ordens por escrito: para algumas pessoas, trabalhar por canais oficiais e exigir ordens por escrito pode ser mais produtivo.
Diferença entre a OSS e a CIA: a OSS (Office of Strategic Services) produziu um excelente livro durante a Segunda Guerra Mundial, e a CIA foi fundada em 1947.
A importância da visão: o passo mais importante é eliminar as pessoas que têm uma visão coerente de como o produto funciona como um todo ou de um futuro melhor.
A seção de contratação precisa de atualização: é necessário exigir a resolução de problemas difíceis do Leetcode em 30 minutos e não tolerar incerteza nem dúvida.
Diferença entre ambiente de produção e ambiente de desenvolvimento: em arquiteturas modernas, há tantos serviços externos que o ambiente de produção inevitavelmente difere do ambiente de desenvolvimento, o que significa que os desenvolvedores precisam estar sempre conectados à internet.
Decisões para autoproteção: muitas decisões de "sabotagem" estão relacionadas a convencer as pessoas de que se trata de uma tentativa de encobrir os próprios erros.
"Melhores práticas" na empresa: as oito regras apresentadas no início do artigo são seguidas com rigor como "melhores práticas" na empresa.
Comportamento dos consultores: muitos consultores adotam a maioria, ou até todas, essas práticas.
Problemas no setor de tecnologia: há muitas pessoas no setor de tecnologia que agem assim, e elas acreditam que estão ajudando.
Experiência em grandes empresas: minha experiência limitada em grandes empresas bate muito com o conteúdo deste texto.