Dans de nombreux domaines cependant, le client type est:
- Intéressé par les préoccupations opérationnelles quotidiennes - tactiques à courte portée ... pas stratégie;
- Seulement préoccupé par la solution immédiate;
- Penseurs généralement unidimensionnels et non abstraits;
- Principalement intéressé à «faire le travail» plutôt qu'à trouver une solution durable et de qualité.
Et pour être franc, ils ont généralement de bonnes raisons de penser comme ça. Tout d'abord, ils dirigent une entreprise qui devrait générer des revenus aujourd'hui et demain, pas dans un avenir lointain. Deuxièmement, ils ne sont pas des experts techniques - ils ne savent pas ce qui est possible et ce qui ne l'est pas, et quelles sont les conséquences de choix architecturaux / de conception / de mise en œuvre spécifiques. Voilà ce que nous savons.
La réponse est donc - ce n'est pas surprenant - la communication .
Vous devez beaucoup communiquer, vous éduquer, vous faire comprendre le point de vue de l'autre partie au moins à un niveau basique. Vous devez leur expliquer les conséquences à court et à long terme des alternatives possibles. Et vous devez utiliser un langage qu'ils comprennent .
- Si vous dites "ce serait un hack, ce qui rend le code moins lisible et extensible" , ils disent "oui, peu importe" .
- Si vous dites "ce serait une solution à court terme, qui rendrait le développement et la maintenance à plus long terme plus coûteux et augmenterait le risque d'introduire des bogues" , ils disent "a ha, considérons" .
- Et si vous dites "cette solution vous coûterait 100 $ maintenant, mais introduit 500 $ de dette technique que vous êtes tenu de rembourser tôt ou tard avec intérêt; OTOH cette autre solution vous coûte maintenant 400 $ et ne laisse aucune dette technique; choisissez celle que vous veulent " , ils disent " maintenant nous parlons! " .
OTOH, ils peuvent nous apprendre une ou deux choses sur la perspective commerciale. Les entreprises veulent être utilisables et suffisamment bonnes - pas parfaites - solutions. Et ils savent probablement mieux que quiconque que "le parfait est l'ennemi du bien". Vous devez donc garder à l'esprit que notre travail consiste à fournir des solutions aux problèmes de nos clients, plutôt que de produire des logiciels techniquement parfaits. Parfois, ces deux convergent vers le même, mais le plus souvent non. Cela peut sembler triste à beaucoup, mais c'est une réalité commerciale. Pour moi, si j'ai réussi à résoudre le problème de mon client, et que je vois que cela lui a visiblement facilité la vie, je suis aussi heureux qu'eux. OTOH si j'ai réussi à mettre en œuvre le design parfait que j'avais en tête, mais que l'entreprise fait faillite la semaine suivante, ce n'est guère une victoire pour personne, n'est-ce pas?
Un propriétaire d'entreprise sensé comprendra - si vous lui expliquez en utilisant son propre langage - pourquoi est-il important de garder le logiciel propre, d'écrire des tests unitaires, de refactoriser etc. Même si ceux-ci ne semblent rien apporter directement à court terme, ils sont essentiels pour l'entretien à long terme. Et les clients sensés se soucient de la maintenabilité à long terme de leur entreprise, donc ils sont sûrement prêts à y investir quand ils voient la valeur que leur investissement génère. Cependant, leurs ressources et votre temps sont limités, vous devez donc établir des priorités et vous concentrer sur les choses les plus importantes. Mais ce n'est important que s'il est important pour vous deux .
Vous voudrez peut-être refactoriser le module A parce que le code qu'il contient est tout simplement horrible, et vous avez une idée formidable comment refactoriser le code pour être concis, élégant et propre, en utilisant un modèle de conception que vous venez de lire. Cependant, si ce module n'a pas été touché depuis des années et qu'il fonctionne de manière fiable, vous feriez probablement mieux de vous concentrer sur le module B, qui sera étendu la semaine prochaine avec une nouvelle fonctionnalité très importante, et il contient des tonnes de bogues. déjà.