Comment expliquer clairement la technologie à des décideurs non développeurs [Traduction]

1. Souligner que le rôle de l’ingénieur qui apporte de la clarté technique dans l’organisation est absolument central.

   • La clarté technique désigne une situation dans laquelle des responsables non développeurs comprennent suffisamment les changements apportés à un système logiciel pour prendre des décisions rationnelles.

2. Pourquoi la clarté technique est rare au sein d’une organisation et difficile à obtenir.

   • Les logiciels sont extrêmement complexes, et même les ingénieurs ont du mal à comprendre entièrement leurs propres systèmes.
   • Les responsables non techniques disposent de peu de temps et de connaissances de base limitées.

3. Exemples de questions techniques concrètes.

   • Questions représentatives qu’un responsable non technique doit absolument connaître lors du déploiement d’une nouvelle fonctionnalité :
     1. Peut-on proposer en toute sécurité une fonctionnalité payante à des utilisateurs gratuits ?
     2. Un déploiement progressif est-il possible ?
     3. En cas de problème, peut-on effectuer un rollback en toute sécurité ?
     4. Peut-on accorder un accès anticipé ?
     5. En cas de problème de capacité, peut-on prioriser les utilisateurs payants ?

4. Le sens des conseillers techniques formels/informels et leur importance.

   • Un staff engineer ou un senior engineer joue le rôle d’un « mandataire » pour les responsables non développeurs, en abstrahant la complexité du système pour l’expliquer simplement.
   • Les ingénieurs qui fournissent bien cette clarté technique gagnent la confiance de l’organisation et sont affectés aux projets majeurs.

5. L’incertitude vécue par les ingénieurs et l’équilibre à trouver.

   • Les ingénieurs conservent toujours une légère inquiétude et une certaine vigilance à propos de leur propre expertise, et n’ont le plus souvent qu’un niveau de certitude de 95 %.
   • Face à des responsables non développeurs, il ne faut pas exposer ces inquiétudes ni tous les détails techniques ; il faut transmettre clairement l’essentiel.

6. Montrer l’incertitude n’est pas toujours la bonne réponse.

   • Si un ingénieur fournit des informations techniques excessivement détaillées au point de diluer la clarté — c’est-à-dire une compréhension simplifiée —, le décideur aura du mal à prendre la bonne décision.
   • Il faut communiquer clairement uniquement les recommandations essentielles et les facteurs de risque.

7. Les 3 principes pour transmettre la clarté technique.

   • (1) L’intuition permettant de distinguer ce qu’il faut mentionner et ce qu’il faut omettre.
   • (2) Une compréhension technique profonde du système (coder soi-même et mener des projets).
   • (3) Présenter avec assurance une vision simplifiée à l’encadrement.

[ng0301]

En réalité... même si on comprend ça, il y a beaucoup de choses qui vont au-delà...

[geekgig]

Je ne sais pas si c’est un commentaire qui correspond à l’intention de cet article...

C’est une différence de point de vue, mais au final je pense que la volonté du décideur est ce qu’il y a de plus important.

Il ne veut pas savoir, il veut seulement entendre que ça marchera à coup sûr, et il veut entendre qu’on s’en chargera.

Du coup, expliquer reviendrait sans doute à dire des choses désagréables pour celui qui a le pouvoir de décision.

ps. On dirait que tout cela repose sur le présupposé que le décideur a raison, non ? Si le décideur = l’arbitre n’aime pas ça, je pense que, de toute façon, aucune méthode ne sera utile.