Em muitos domínios, porém, o cliente típico é:
- Interessado em preocupações operacionais diárias - táticas de curto alcance ... não estratégia;
- Preocupado apenas com a solução imediata;
- Pensadores geralmente unidimensionais e não abstratos;
- Principalmente interessado em "fazer o trabalho", em vez de encontrar uma solução duradoura e de qualidade.
E para ser franco, eles geralmente têm boas razões para pensar assim. Antes de tudo, eles estão administrando um negócio, que deve gerar receita hoje e amanhã, não em um futuro distante. Em segundo lugar, eles não são especialistas técnicos - eles não sabem o que é possível e o que não é e quais são as consequências de escolhas específicas de arquitetura / design / implementação. Isto é o que sabemos.
Portanto, a resposta é - não surpreende - a comunicação .
Você precisa se comunicar muito, educar-se, fazer-se entender o ponto de vista da outra parte, pelo menos até um nível básico. Você precisa explicar a eles as conseqüências de curto e longo prazo de possíveis alternativas. E você precisa usar a linguagem que eles entendem .
- Se você disser "isso seria um hack, o que torna o código menos legível e extensível" , eles dizem "sim, tanto faz" .
- Se você disser "isso seria uma correção de curto prazo, o que tornaria o desenvolvimento e a manutenção de longo prazo mais dispendiosos e aumentaria o risco de introdução de bugs" , eles dizem "a ha, vamos considerar" .
- E se você disser "essa solução custaria US $ 100 agora, mas introduz US $ 500 em dívidas técnicas que você deverá pagar com juros mais cedo ou mais tarde; a OTOH esta outra solução custa US $ 400 agora e não deixa nenhuma dívida técnica; escolha a que você querem " , eles dizem " agora estamos conversando! " .
OTOH eles podem nos ensinar uma coisa ou duas sobre a perspectiva do negócio. As empresas querem soluções utilizáveis e boas o suficiente - dificilmente perfeitas -. E eles sabem provavelmente melhor do que ninguém que "perfeito é o inimigo do bem". Portanto, você deve ter em mente que nosso trabalho é fornecer soluções para os problemas de nossos clientes, em vez de produzir software tecnicamente perfeito. Às vezes, esses dois convergem para o mesmo, mas mais frequentemente não. Isso pode ser visto como triste por muitos, mas é a realidade dos negócios. Para mim, se eu consegui resolver o problema do meu cliente e vejo que isso tornou a vida deles visivelmente mais fácil, fico tão feliz quanto ele. OTOH, se eu conseguisse implementar o design perfeito que eu tinha em mente, mas a empresa faliu na semana seguinte, dificilmente será uma vitória para alguém, é?
Um proprietário sensato da empresa entenderá - se você os explicar usando seu próprio idioma - por que é importante manter o software limpo, escrever testes de unidade, refatorar etc. Mesmo que eles pareçam não contribuir diretamente com nada no curto prazo, eles são essenciais para manutenção a longo prazo. E os clientes sensatos se preocupam com a manutenção de longo prazo de seus negócios, de modo que certamente estão dispostos a investir nele quando virem o valor que seu investimento gera. No entanto, tanto os recursos quanto o tempo são limitados, você precisa priorizar e se concentrar nas coisas mais importantes. Mas é importante apenas se for importante para vocês dois .
Você pode refatorar o módulo A porque o código é horrível e você tem uma idéia estupenda de como refatorar o código para ser conciso, elegante e limpo, usando um padrão de design que você acabou de ler. No entanto, se esse módulo não for tocado há anos e funcionar de maneira confiável, é mais provável que você se concentre mais no módulo B, que será estendido na próxima semana com um novo recurso muito importante e contém muitos erros já.