Isso se resume ao que eu comecei a pensar como "O Conflito Eterno" (entre negócios e engenharia). Não tenho a solução, pois é um problema que nunca desaparece, mas você pode fazer coisas para ajudar a mitigar.
O que as pessoas geralmente não percebem é que, como engenheiros, estamos apenas assumindo que o problema de "negócios de sucesso" é sempre um dado. Queremos que nosso código seja agradável, limpo e de fácil manutenção, para que possamos adicionar novos recursos e ajustar os existentes rapidamente e com um mínimo de clientes fazendo o controle de qualidade, descobrindo casos bizarros que poderiam ser prejudicados por um código melhor. Manter os clientes e manter uma vantagem competitiva com recursos e requinte que ninguém mais pode produzir com rapidez suficiente são as duas vitórias nos negócios em que um bom código contribui diretamente e informa muito sobre a razão pela qual queremos um código melhor em primeiro lugar.
Então soletre. "Queremos fazer o X em nossa base de código porque, se não o fizermos, impactará negativamente os negócios devido a Y" ou "... porque aumentará nossa capacidade de permanecermos competitivos, melhorando nossa capacidade de ativar novos aprimoramentos e recursos mais rapidamente . "
E faça o seu melhor para tentar obter evidências tangíveis de que as melhorias estão funcionando. Se a melhoria de algum subconjunto de um aplicativo resultou em um recurso / aprimoramento mais rápido, verifique qualquer ferramenta de lista de pendências que você esteja usando para obter evidências disso e aponte-o nas reuniões apropriadas.
- Coloque a equipe na mesma página
Os egos costumam ser um problema. Uma coisa que as equipes de engenharia precisam muito é estabelecer o valor de ter algum tipo de abordagem consistente e acordada para resolver certos tipos de problemas em relação a todos que fazem seu próprio copo de Kool Aid d'jour porque sabem melhor. Não há problema em acreditar que a preferência do outro cara é pior que a sua, mas valoriza a consistência em ser mais correto se a abordagem dele for viável e for um argumento que você não pode vencer. O compromisso por uma questão de consistência é fundamental. Quando as coisas são consistentes, é mais difícil fazê-las erradas, pois a maneira consistente estabelecida geralmente também será a maneira mais rápida.
- Escolha as ferramentas certas
Existem duas escolas de estruturas / conjuntos de ferramentas / bibliotecas / o que for. "Defina 99% disso para mim, então eu tenho que saber / fazer muito pouco" vs. "ficar fora do meu caminho quando não quero você lá, mas me ajude a fazer bricolage de maneira muito rápida e consistente com as coisas que eu realmente quero para usar na cenoura, em vez de usar o princípio da vara. " Favorecer o segundo. A flexibilidade e o controle granular nunca devem ser sacrificados no altar da recuperação rápida, porque, para começar, "não podemos fazer isso porque nossas próprias ferramentas não nos permitem" nunca é uma resposta aceitável e a pergunta sempre será feita por não- engenharia de produto trivial / descartável. Na minha experiência, ferramentas inflexíveis quase sempre são abertas ou trabalhadas de maneira deselegante e fazem uma grande bagunça gigante e inatingível. Mais frequentemente do que não, as soluções flexíveis / mais fáceis de modificar são tão ou quase tão rápidas quanto no curto prazo, independentemente. Rápido, flexível e sustentável são possíveis com as ferramentas certas.
- FFS, se os engenheiros não decidirem, pelo menos, obtenha informações do engenheiro sobre a escolha das ferramentas
Tenho a sensação de que essa é uma pergunta da perspectiva do desenvolvedor, mas já estive em muitas situações em que as decisões de tecnologia foram tomadas com zero entrada de engenheiro. Que diabo é isso? Sim, alguém precisa finalmente fazer a chamada final, mas obtenha algumas opiniões qualificadas se você for um gerente não técnico, não o que algum vendedor ou site de demonstração diz sobre seus próprios produtos. Qualquer coisa prometendo poupar dinheiro porque as pessoas não precisam ser tão inteligentes ou porque protege os desenvolvedores de si mesmas é uma mentira suja e suja. Contrate talentos nos quais possa confiar. Diga a eles o que você quer de uma pilha ou de outra solução tecnológica e leve a sério as informações antes de decidir em qual onda da tecnologia usar.
- Concentre-se no design e na implementação
As ferramentas são para implementação e, como tal, podem ajudá-lo, mas a primeira prioridade deve ser a arquitetura, independentemente do conjunto de brinquedos que você tiver para construir essa arquitetura. No final do dia, o KISS e o DRY e todas as excelentes filosofias que se estendem a partir delas importam mais do que em .NET ou Java ou talvez em algo que é gratuito e não é ruim.
- Registre suas preocupações
Quando o lado da empresa insistir para que você faça isso da maneira errada, salve esse email, especialmente a parte em que você disse por que isso custaria. Quando todas as suas previsões se tornam realidade e surgem sérios problemas que prejudicam os negócios, é aí que você tem uma grande pilha de argumentos para levar as preocupações dos engenheiros mais a sério. Mas tempo as coisas com cuidado. No meio do inferno ardente, é um momento ruim para um "eu te disse" seguindo o código de incêndio. Apague o fogo e leve sua lista de preocupações anteriormente ignoradas para uma reunião / conversa retrospectiva e tente manter o foco nas preocupações de engenharia expressas e ignoradas e o raciocínio que você entendeu por que elas estavam sendo ignoradas, não os nomes das pessoas reais tomando a decisão de ignorar. Você é engenheiro. Fique nos problemas, não nas pessoas. " Expressamos preocupação com o X porque temíamos que isso levasse a problemas em Y. Foi-nos dito que Z e adiamos lidar com isso ".