In many domains though, the typical customer is:
- Interested in daily operational concerns--short-range tactics ... not strategy;
- Only concerned with the immediate solution;
- Generally one-dimensional, non-abstract thinkers;
- Primarily interested in "getting the job done" as opposed to coming up with a lasting, quality solution.
E per essere sinceri, di solito hanno buone ragioni per pensare in questo modo. Prima di tutto, gestiscono un'impresa, che dovrebbe generare entrate oggi e domani, non in un futuro lontano. In secondo luogo, non sono esperti tecnici: non sanno cosa è possibile e cosa no, e quali sono le conseguenze di specifiche scelte architettoniche / di progettazione / implementazione. Questo è ciò che noi conosciamo.
Quindi la risposta è - difficilmente sorprendente - comunicazione .
Devi comunicare molto, educarti a vicenda, far capire a vicenda il punto di vista dell'altra parte almeno a un livello base. Devi spiegare loro le conseguenze a breve e lungo termine delle possibili alternative. E devi utilizzare il linguaggio che comprendono .
- Se dici "questo sarebbe un trucco, il che rende il codice meno leggibile ed estensibile" , dicono, "sì, qualunque sia" .
- Se dici "questa sarebbe una correzione a breve termine, che renderebbe più costoso lo sviluppo e la manutenzione a lungo termine e aumenterebbe il rischio di introdurre bug" , si dice "a ha , consideriamo ".
- E se dici "questa soluzione ti costerà $ 100 ora, ma introduce $ 500 di debito tecnico che dovrai restituire prima o poi con interesse; OTOH questa altra soluzione ti costa $ 400 ora e non lascia alcun problema tecnico debito, scegli quello che vuoi ", loro dicono " ora stiamo parlando! ".
OTOH possono insegnarci una o due cose sulla prospettiva del business. Business vuole utilizzabile e abbastanza buono - difficilmente perfetto - soluzioni . E sanno probabilmente meglio di chiunque altro che "perfetto è il nemico del bene". Quindi è necessario tenere presente che il nostro compito è fornire soluzioni ai problemi dei nostri clienti, piuttosto che produrre software tecnicamente perfetto. A volte questi due convergono allo stesso, ma più spesso no. Questo può essere visto come triste da molti, ma è la realtà aziendale. Per me, se sono riuscito a risolvere il problema del mio cliente, e vedo che ha reso la loro vita visibilmente più facile, sono felice come loro. OTOH se sono riuscito a realizzare il design perfetto che avevo in mente, ma la compagnia va in bancarotta la settimana seguente, non è quasi una vittoria per nessuno?
Un sensibile imprenditore capirà - se le spieghi usando la sua lingua - perché è importante tenere pulito il software, scrivere test unitari, refactoring ecc. Anche se questi non sembrano contribuire direttamente a qualcosa nel breve termine, sono essenziali per la manutenzione a lungo termine. E i clienti sensibili si preoccupano della manutenibilità a lungo termine della loro attività, quindi sono sicuramente disposti a investire su di essa quando vedono il valore generato dal loro investimento. Tuttavia, sia le risorse che i tempi sono limitati, quindi è necessario dare la priorità e concentrarsi sulle cose più importanti. Ma è importante solo se è importante entrambi di te.
Potresti voler rifattorizzare il modulo A perché il codice è semplicemente orribile, e hai una stupenda idea di come rifattorizzare il codice per essere conciso, elegante e pulito, usando un modello di design di cui hai appena letto. Tuttavia, se quel modulo non è stato toccato per anni, e funziona in modo affidabile, è molto meglio concentrarsi sul modulo B, che verrà esteso la prossima settimana con una nuova funzionalità molto importante, e contiene un sacco di bug già.