Comment communiquer avec les ingénieurs logiciels

Au cours de mes aventures à la tête d’équipes d’ingénierie et en tant que leurs avocats, j’ai appris l’importance d’être un traducteur compétent. Même dans le monde des startups technologiques, il n’est pas rare de trouver des personnes qui ne comprennent pas vraiment «ce logiciel». Ce n’est pas surprenant. Au fur et à mesure que notre monde avance, nous ajoutons des couches d'abstraction entre le biologique et le technologique, au point où la technologie avec laquelle nous interagissons n'est remarquée que lorsqu'elle échoue.

Les gens remarquent vraiment quand ça échoue! Nous nous appuyons sur les logiciels dans de nombreux aspects de la vie, et quand ils ne fonctionnent pas comme prévu, c’est douloureux. Si Alexa ne joue pas la chanson que vous avez demandée, vous pouvez la supprimer. Toutefois, lorsque le développeur à quelques bureaux de vous prend une décision - ou une erreur - qui coûte de l’argent ou du temps à la société, il est difficile de rester calme.

Pour les non-initiés, comprendre comment travailler efficacement avec des ingénieurs peut être un défi, et des obstacles sur la route sont inévitables. Je vais vous faire part de quelques idées qui vous aideront à éviter les brouillards et à collaborer efficacement avec les équipes d'ingénierie.

Apprendre les ficelles

Ned Ludd, technophobe notable et colocataire de Robin Hood

La collaboration commence par l'empathie. Vous allez avoir besoin de vous équiper avec une compréhension des principes fondamentaux pour faire preuve d'empathie avec vos collègues techniques. Cela ne veut pas dire que vous devez suivre un cours et commencer à coder (bien que ce soit une option, si cela vous intéresse). L'important est d'être ouvert à l'apprentissage et de rester curieux.

Les gens aiment parler de choses pour lesquelles ils sont doués, y compris les développeurs. Posez des questions et montrez un intérêt quand vous le pouvez. Cela vous aidera à vous informer progressivement et à établir une relation.

Être Luddite n’est pas un badge d’honneur. Le mouvement original a pris fin pas plus d'un an après son lancement et tous les membres restants de ce mouvement technophobe ont été envoyés en Australie. Être «old school» peut être une source de réconfort à la maison, mais il est essentiel d’accepter les progrès pour réussir dans les affaires.

Ne construisez pas de murs

Le développement de logiciels est encore un domaine relativement nouveau et le jargon technique n’est que le début. La manière dont les projets sont organisés, les indicateurs de performance et la hiérarchie des équipes sont également différentes des autres fonctions. Les gens traitent parfois les ingénieurs différemment de leurs collègues, et les mauvais stéréotypes ne manquent pas. Combattez la tendance à traiter ou à considérer l’équipe technique comme une équipe à part.

Alors que le développement de logiciels est un processus collaboratif axé sur l’équipe, les ingénieurs passent souvent une grande partie de leur temps en tête à tête basse et en écouteurs. Ne confondez pas le silence pour un manque d’enthousiasme. La plupart des développeurs sont plus qu'heureux d'aider, de lancer des idées ou d'écouter. À tel point que nous avons besoin de stratégies pour nous assurer que les développeurs peuvent rester sur la tâche tout en identifiant rapidement les demandes entrantes qui méritent une attention immédiate. Le logiciel Help Desk peut jouer un rôle déterminant dans l’équilibrage de la charge, la définition des priorités et le suivi des réponses apportées aux problèmes rencontrés.

J’ai reçu beaucoup de larmes et de plaintes lorsque j’ai mis en place des systèmes de billetterie pour demander l’aide d’un développeur. Je sympathise car cela me semble être un processus trop long et cela risque de créer encore plus d'obstacles à la communication. D'autre part, ne pas avoir de système pour hiérarchiser les tâches et leur affectation n'est pas viable à grande échelle. Les dirigeants techniques doivent utiliser les processus comme un moyen de se protéger contre le gaspillage (de temps et d’efforts), mais cela doit être complété par un plaidoyer constant pour des lignes de communication ouvertes.

Supposer bonne intention

Capitaine Hindsight, pour une réunion post mortem

Même lorsque les lignes de communication sont fortes, des situations stressantes peuvent survenir. Les gens font des erreurs, oublient des choses et disent des choses blessantes sans réfléchir. Cela peut être source de confusion et de frustration lorsque la même personne qui a passé la nuit à construire votre fonctionnalité oublie de la déployer le matin.

Je ne peux pas exagérer le pouvoir de la positivité. Essayez de tenter une explication (dans le domaine de la réalité) où la personne avait les meilleures intentions sans faire de mal. Pouvez-vous penser à une explication réaliste? Au lieu de connaître tous les détails, supposez le meilleur. Une fois que vous serez de l’autre côté de la situation, vous aurez le temps de déterminer la véritable source de la panne.

Un comportement médiocre ou peu fiable ne doit pas être toléré, mais la négativité en période de crise ne peut que vous porter préjudice. Gardez le capitaine Hindsight à distance jusqu'à la réunion post-mortem. Prévoyez toujours du temps pour la réunion post-mortem. La franchise radicale sera un outil précieux une fois que vous êtes là.

Il est également important de reconnaître qu’il existe des domaines d’expertise pour lesquels vous ne possédez peut-être pas l’image complète ou l’expérience nécessaire pour étayer vos opinions. En plus de présumer de bonnes intentions, construisez une relation de confiance avec vos coéquipiers et posez des questions pour prouver ou réfuter vos hypothèses.

Éviter les icebergs

Tous les développeurs ont entendu: «Ce changement ne devrait prendre que cinq minutes!». Parfois, l’évaluation est correcte et parfois, elle est erronée. Une horloge cassée a raison deux fois par jour. Astuce: Si vous êtes tenté de dire ces mots, envisagez de le reformuler comme une question.

Je ne dis pas que les ingénieurs en logiciel doivent avoir leur ego touché à tout moment. En réalité, même nos estimations sont très souvent erronées. Voici une raison pour laquelle.

La pointe de l'iceberg, estimée

Les gens savent bien estimer en fonction de quantités connues. Vous voulez une fonctionnalité, vous devez donc le dire au développeur. Ils écriront probablement du code et, une fois terminé, ils expédieront la fonctionnalité. Facile!

Le reste de l'iceberg, estimé

Voici la réalité dans un environnement d’équipe. Le développeur faisait autre chose, il doit donc en sortir et répondre à votre demande. En supposant qu'aucune planification n'est requise et qu'aucune dépendance n'existe, ils écrivent du code. L’équipe a pour politique d’examiner les modifications afin d’éliminer le «facteur bus» et de respecter le code et les directives de conception. L’équipe a également pour politique de faire tester la fonctionnalité par l’Assurance qualité avant de l’envoyer. Ensuite, il doit être déployé. En fonction de la plate-forme, ce processus peut varier énormément - du processus sans douleur / instantané à un processus de révision de plusieurs jours, avec la permission de Apple. Maintenant, la fonctionnalité est à l'état sauvage. Le développeur: “Qu'est-ce que je faisais encore?”

Vous pensez peut-être: «Cela semble excessif. Je voulais juste que le texte soit d'une couleur différente. "C'est vrai. Tout laisser tomber pour changer la couleur du texte coûte incroyablement cher en temps. C’est pourquoi nous avons créé des systèmes pour mettre en file d'attente et hiérarchiser les tâches. Scrum fait cela en empaquetant le travail dans des itérations ou des sprints. Kanban résout le problème en contrôlant le nombre de tâches en cours. Les deux utilisent une file d'attente, ou backlog, pour permettre au travail d'être trié par priorité.

Interrompre un travail prévu pour injecter une autre tâche constitue essentiellement un changement de priorité très brutal. Si vous changez beaucoup de priorités - en particulier en interrompant un autre travail - il sera utile de déterminer pourquoi.

Ne pas pirater d'habitude

Il y a de bons hacks et de mauvais hacks. Lorsque Zappos a commencé, le fondateur a pris des photos de chaussures en vente au centre commercial local et les a répertoriées en ligne. Quand un achat arrivait, il retournait les chercher et les expédiait. C'était un bon bidouillage, car cela prouvait le concept. C'était aussi un mauvais coup parce qu'ils perdaient de l'argent à chaque transaction.

C’est la définition du hack dont je parle ici: Modifier rapidement le code pour patcher un programme informatique, souvent un programme qui, tout en étant efficace, est inélégant ou rend le programme plus difficile à maintenir (from: wiktionary).

Utilisez des hacks pour prouver le concept. Si cela fonctionne, résistez à l'envie d'en faire une habitude et intégrez le bidouillage à une solution permanente et reproductible.

Pourquoi? Ce n’est pas simplement une autre formalité; les hacks ont un coût. Ils demandent souvent aux développeurs de les prendre en charge, ce qui signifie que vous allez nous attendre. Il interrompt le travail normalement prévu (voir section précédente) et le processus peut avoir été coupé, ce qui peut être risqué.

C’est vraiment difficile d’arrêter de faire quelque chose qui fonctionne. Si la solution piratée génère des ventes ou permet de gagner du temps, renoncer à cette solution sera un défi. Si vous avez besoin d’aide pour sortir de cette habitude, envisagez de vous réunir pour trouver de meilleures solutions en groupe et n’oubliez pas d’inclure les parties prenantes de l’ingénierie et des produits.

Stratégies

En matière de communication interne, choisissez le bon support. Quel type de réponse est souhaité, synchrone ou asynchrone? Si votre demande nécessite une réponse immédiate, alors parlez en personne ou téléphonez. Par contre, s’il s’agit d’un message non urgent ou informatif, envisagez d’envoyer un courrier électronique. Si vous ne craignez pas de voir votre message oublié par accident, Slack ou GChat sont probablement la voie à suivre.

Pensez à qui vous devez contacter. Ne «vaporisez pas et priez» en envoyant un courrier électronique à une douzaine d’ingénieurs. Si vous ne savez pas à qui parler, adressez-vous à un responsable technique ou à un responsable produit. Si un système est en place pour atteindre le développeur sur appel, utilisez-le. Si vous hésitez à le faire parce que cela a été inefficace, prenez le temps de parler à la personne qui l’a instituée et collaborez avec elle pour trouver des moyens d’améliorer la solution.

Vous ne devriez pas avoir à marcher sur des œufs avec les développeurs. Demande ce que tu veux. Si cela est urgent, demandez si cela peut être fait plus tôt. Veillez simplement à ne pas minimiser les efforts des autres dans le processus. Rappelez-vous l’exemple «c’est juste un changement de texte». Une telle formulation est une erreur facile à commettre - on me fait appeler de temps en temps.

Les ingénieurs en logiciel sont des humains (pour le moment), et il y a de fortes chances que vous le soyez aussi. J'espère que certains de ces conseils vous aideront à collaborer plus efficacement avec eux. Fin de ligne.