Avant que le logiciel devienne ma carrière, je pensais devenir musicienne. Je programmais depuis l’enfance, mais la musique était ce que je poursuivais assez sérieusement pour commencer mes études universitaires en musique. Pendant une période, je pratiquais environ huit heures par jour simplement pour suivre le rythme.
Beaucoup de ce que j’ai appris pendant ces années m’est resté. La pratique rend certaines décisions disponibles sur le moment parce qu’on a déjà passé des centaines d’heures à apprendre ce qui se produit quand on les prend. La théorie donne davantage de choix une fois qu’on la comprend assez bien pour ne plus avoir à y penser consciemment.
La leçon à laquelle je reviens le plus est une phrase que j’ai entendue sous différentes formes à cette époque : on ne peut pas enfreindre les règles avant de les connaître. En musique, on entend la différence entre quelqu’un qui tombe sur une note parce qu’il a perdu l’harmonie et quelqu’un qui joue volontairement en dehors de celle-ci parce qu’il sait ce qu’il veut en faire.
Il faut entendre la musique autour pour faire cette distinction. La note peut sembler étrange au moment où elle arrive et devenir logique un instant plus tard à cause de l’endroit où le musicien l’emmène. Je ne m’attendais pas à ce que cette distinction devienne aussi utile une fois passée au logiciel.
Apprendre le cadre fait partie de l’apprentissage du travail
J’ai commencé ma carrière en logiciel pendant l’époque des dotcoms, alors j’ai eu beaucoup de temps pour voir des méthodologies apparaître et disparaître. Certaines sont réemballées sous de nouveaux noms. D’autres deviennent des pratiques standard assez longtemps pour que quelqu’un finisse par faire carrière en promettant de les réparer.
Les cadres m’ont beaucoup appris. Une méthode commune donne accès à ce que d’autres ont appris sans obliger tout le monde à répéter les erreurs qui ont produit ce savoir. Elle donne aussi à une équipe une façon de parler du travail quand ses membres arrivent avec des expériences différentes.
Les choses deviennent étranges quand le cadre est plus facile à évaluer que le travail qu’il devait soutenir. Une équipe peut garder son tableau à jour et présenter ses indicateurs pendant qu’une décision importante attend depuis des semaines. Tout le monde peut voir l’état du travail sans que personne ne règle ce qui le bloque.
Quelque chose marqué comme terminé peut quand même être inutilisable de la façon dont tout le monde l’avait supposé. L’équipe a satisfait le Process, mais quelqu’un doit maintenant trouver comment livrer ce qui était réellement nécessaire. J’ai travaillé dans des startups et dans des entreprises valant des milliards, et j’ai vu des versions de ce problème dans les deux. Après assez de temps à le voir, un compte rendu bien rangé du travail ne suffit plus à me convaincre que le Process aide les gens à le faire.
L’expérience change ce qu’on remarque
Au début d’une carrière, suivre une règle de près est souvent le choix raisonnable parce qu’on ne sait pas encore de quel échec elle nous protège. J’ai fait assez d’erreurs pour avoir un respect sain pour des conventions qui semblaient inutiles jusqu’au moment où j’ai compris pourquoi quelqu’un les avait introduites.
L’expérience fournit aussi des exemples dans l’autre sens. Une mesure de protection peut survivre longtemps après que le risque a changé. Un Process conçu pour un type d’équipe est reproduit dans une autre organisation parce que les gens reconnaissent son nom, même si les conditions qui le rendaient utile ne sont pas présentes. Savoir l’implanter ne dit pas s’il a sa place là.
Le logiciel offre des versions sans fin de ce problème. Une abstraction peut rendre un système plus facile à raisonner, puis être appliquée avec tant d’enthousiasme que comprendre la chose simple en dessous devient plus difficile que nécessaire. Le principe était utile; en appliquer davantage n’a pas nécessairement aidé.
Je m’intéresse davantage maintenant à ce qu’une méthode est censée aider à accomplir dans une situation précise. Deux personnes expérimentées peuvent comprendre le même cadre et ne pas être d’accord sur le fait de l’utiliser. Elles doivent quand même expliquer ce qu’elles s’attendent à ce qu’il aide à faire et ce que son utilisation coûtera. Connaître la méthode leur donne quelque chose avec quoi travailler, mais ne prend pas la décision à leur place.
Les entreprises ont des règles que personne ne se souvient d’avoir choisies
Les entreprises héritent d’hypothèses d’une façon semblable. La croissance est généralement présentée comme de l’expansion, de sorte qu’un propriétaire qui veut une entreprise plus petite peut se retrouver à devoir expliquer son ambition. L’efficacité veut souvent dire produire davantage avec la même quantité de travail, avec peu de discussion sur ce que le temps économisé pourrait rendre possible autrement.
Je suis devenue moins disposée à accepter un objectif d’affaires familier sans demander pourquoi nous le poursuivons. La croissance peut donner à une entreprise les ressources nécessaires pour faire quelque chose qu’elle ne pouvait pas se permettre auparavant. C’est une raison d’envisager l’expansion. Nous devons tout de même comprendre ce que le propriétaire veut faire de ces ressources et s’il veut prendre l’engagement que représente la gestion d’une entreprise plus grande.
La standardisation mérite le même examen. Réduire la variation peut rendre un Process plus fiable, mais certaines variations existent parce que les gens font face à des circonstances différentes. Avant d’exiger que tout le monde travaille de la même façon, je veux savoir à quoi servent ces différences. Connaître une pratique ne répond pas à cette question.
L’AI et l’automatisation rendent certains de ces choix plus difficiles à ignorer. Nous pouvons automatiser une tâche administrative répétitive et redonner plusieurs heures par semaine à quelqu’un. Nous pouvons aussi augmenter la quantité de travail attendue de cette personne parce que la tâche prend maintenant moins de temps. L’automatisation peut fonctionner exactement comme prévu dans les deux cas. « C’est juste les affaires » peut mettre fin à une conversation qui sonnerait très différemment si nous disions clairement ce que cette décision demande à la personne touchée.
ShanVic est venu après avoir appris beaucoup de réponses des autres
ShanVic est né d’un travail que nous faisions déjà ensemble. À ce moment-là, nous avions passé assez de temps dans différentes entreprises et structures de gestion pour savoir que les problèmes qui nous intéressaient restaient rarement à l’intérieur des frontières que ces structures leur imposaient.
Un problème logiciel se révélait être un Process que personne n’avait reconsidéré. Examiner ce Process pouvait révéler une décision que personne n’avait l’autorité de prendre. Changer seulement le logiciel laisserait l’équipe attendre la même réponse dans une nouvelle interface, tandis que les personnes responsables du logiciel pourraient raisonnablement dire qu’elles avaient fait ce qu’on leur avait demandé.
The Cubed Method™ nous a donné une façon de travailler directement avec ces relations. People, Processes et Products se modifient constamment les uns les autres. Nous devons comprendre assez bien ces relations pour voir quand une amélioration proposée laissera un problème non résolu ou créera davantage de travail ailleurs.
Cette approche doit beaucoup aux cadres et disciplines qui l’ont précédée. Des années à les utiliser nous ont aidées à reconnaître quand une méthode donnait aux gens une façon utile de travailler et quand ils la suivaient surtout parce que c’était attendu. Les personnes expérimentées faisaient souvent déjà des ajustements que le Process formel ne reconnaissait pas, et nous voulions une façon d’examiner ces décisions comme faisant partie du travail.
Savoir pourquoi donne plus de choix
Une chose que j’aimais dans la théorie musicale, c’est qu’en apprendre davantage ne rendait pas la musique plus petite. Cela me donnait plus de façons de comprendre ce que j’entendais et plus de choix sur ce que je pouvais faire ensuite. Je pense que de bonnes pratiques d’affaires devraient faire la même chose.
Un cadre devrait m’aider à comprendre assez bien les conséquences d’une décision pour la prendre délibérément. Quand nous nous écartons de ses recommandations, nous devrions pouvoir expliquer ce que nous espérons gagner et quels risques nous acceptons.
Il y a des règles que je suis contente qu’on m’ait enseignées avant que j’aie assez d’expérience pour les apprécier. J’ai aussi suivi des règles jusqu’à ce que je comprenne assez bien pour voir pourquoi elles ne correspondaient plus au travail devant moi. La musique m’a donné une façon de penser à cela bien avant que j’aie une entreprise ou une méthodologie, et j’y reviens encore quand une règle familière nous donne une réponse qui ne correspond pas tout à fait à ce que nous essayons de construire.