Sur la base de toutes les preuves que j'ai vues (versions à peine fonctionnelles, lianes de ruban adhésif, « tests? Quels tests ? », « à faire… », « nous le nettoierons plus tard »), voici ce que je suppose que la plupart des programmeurs pensent devoir produire lorsque le produit et l'ingénierie se rencontrent :
Produit : J'ai besoin que vous construisiez X, Y, Z.
Ingénierie : OK.
Produit : Vous avez jusqu'à la fin de ce trimestre.
Ingénierie : OK. [marmonnant pour eux-mêmes, à peine audible :] merde.
Le produit indique quoi et (quelques fois) quand ; Tandis que les ingénieurs s’inquiètent du comment.
J’ai entendu des gens dire que parmi ces trois éléments : Quoi, Quand et Comment, vous devez en choisir deux. Vous pouvez dire construisez-moi X (Quoi) jusqu'à cette date (Quand), mais vous ne pouvez pas dire Comment c'est construit, car c'est le travail de l'ingénierie. Ou vous dites que vous voulez que X (Quoi) soit construit exactement comme ceci (Comment), mais vous ne pouvez pas décider quand.
L’idée d’en choisir deux est utile, car elle montre clairement qu’essayer de choisir les trois équivaut à agiter une baguette magique : un vœu pieux. Mais je pense aussi que ce n’est pas assez nuancé.
D'après mon expérience, les relations les plus productives entre l'ingénierie et le produit reposaient sur la compréhension de la nécessité de négocier, de faire des compromis, de se rencontrer sur les trois fronts : quoi, quand et comment. Parce qu'ils sont tous liés les uns aux autres et en choisir deux proprement sans toucher au troisième fonctionne à peine dans la pratique.
Idéalement, les conversations se déroulent comme ceci :
Produit : voici ce que je veux – X, Y, Z – pouvez-vous le construire ?
Ingénierie : Jusqu’à quand ?
Produit : Fin de trimestre.
Ingénierie : Impossible, mais je peux vous donner X et Z d’ici là.
Produit : Je vois. Mais Y est plus important pour moi que Z. Pouvons-nous d’une manière ou d’une autre intégrer X et Y ? Je suis heureux de laisser tomber Z.
Ingénierie : Nous pourrions intégrer X mais Y uniquement en petit, y.
Produit : Ça me va. De toute façon, le petit y est la partie importante. Quand arriveras-tu à Z ?
Ingénierie : Juste après.
Produit : Parfait.
Les deux parties doivent engager la conversation en sachant qu’elles n’ont qu’une moitié du tableau et que la conversation est un moyen de voir l’autre moitié : la conversation est un moyen d’apprendre, de comprendre les contraintes et les compromis impliqués.
Après tout, c’est ça l’ingénierie, n’est-ce pas ? Construire des choses pour résoudre des problèmes, compte tenu d’un ensemble de contraintes.
Imaginez que vous êtes un ingénieur dans le domaine de la physique et que vous êtes chargé de construire un pont.
Produit : Construisez-moi un pont.
Ingénierie : D’accord. [marmonnant pour eux-mêmes, à peine audible :] merde.
Tout cela est mauvais, n'est-ce pas ? Un ingénieur qui travaille avec des trucs réels (vous savez : sable, pierre, fer, etc.) ne se contenterait pas de construire un pont, il découvrirait quelles sont les contraintes réelles afin de résoudre le problème.
Produit : Construisez-moi un pont.
Ingénierie : Jusqu’à quand ? De quels matériaux disposons-nous ? Quel est le budget ? Combien de personnes traverseront ce pont ? Véhicules? Pendant combien de temps? Combien chaque jour ? Quel est le trafic aux heures de pointe ?
Ensuite, en fonction des réponses du produit, l’ingénierie peut construire différentes choses :
Produit : Le pont est seulement pour aujourd'hui. Il faut que 5 personnes traversent cette rivière, vite.
L'ingénierie va installer une tyrolienne.
ou:
Produit : Le pont doit transporter un millier de véhicules cette semaine. Il n’est pas nécessaire de le garder plus longtemps que cela. Le budget est serré.
L'ingénierie va installer un pont en bois.
ou:
Produit : Le pont doit transporter tout le trafic qui se trouve actuellement sur l'autre pont, car celui-ci sera fermé. Il ne peut pas s’agir d’un pont en acier car c’est interdit ici.
L'ingénierie va construire un pont en pierre.
Vous voyez l'idée : le Quoi, le Quand et le Comment sont tous liés et quand le produit et l'ingénierie accomplissent leur tâche, vous découvrez à quel point ils sont liés – lequel vous pouvez modifier, de quelle manière et comment, cela influence les autres.
Parce que si le produit dit quoi et quand et que l'ingénierie le mange et s'effondre sur son comment, ce n'est tout simplement pas de l'ingénierie.
Merci de m’avoir lu!