Business : Se salir les mains: pourquoi être «pratique» est un must pour chaque chef de produit

Après mon MBA, j’ai reçu une offre pour rejoindre en tant que Product Owner à Bangalore (The IT Hub of India). J’étais dans ma phase de « lune de miel » avec peu ou pas de travail au bureau pendant les premiers mois de mon arrivée, passant la plupart de mon temps à jouer au baby-foot, au tennis de table, à lire des articles et à parler aux gens.

Au cours de la 7e semaine de mon adhésion, j’ai reçu un courrier de mon directeur offshore basé aux États-Unis, me disant que je serais copropriétaire d’un projet qui sera développé et livré par le bureau de l’Inde. Dans les quinze minutes qui suivent l’envoi du courrier, je suis cinglé par l’équipe de développement pour la portée du projet, quelles histoires à reprendre, quand commencer le projet! C’était tout simplement écrasant! J’ai été entraîné dans un projet où je n’avais aucune information sur la tête ou la queue du système. Je n’avais jamais vu le portail qui devait être amélioré, sans parler de la portée. Je ne savais pas par où commencer. J’ai contacté quelques-uns des membres de mon équipe pour leur demander s’ils savaient comment fonctionnait le portail ou s’il y avait des documents que je pouvais lire pour avoir un sens. Hélas, cela n’a donné aucun résultat.

C’était presque l’heure du déjeuner et je suis allé à la cantine abattu. Tout en récupérant ma nourriture, mon directeur se tenait à côté de moi et m’a demandé pourquoi j’avais l’air si maussade? Nous nous sommes assis sur une table et je lui ai expliqué la situation et à quel point je me sentais impuissant. Il m’a donné un seul conseil: «Commencez à vous salir les mains». Ici, je mange ma nourriture (avec les mains – attention, c’est de la nourriture indienne!) Et les conseils semblaient ironiques à ce moment-là.

J’ai décidé de suivre les conseils et j’ai commencé. J’ai demandé des identifiants de test à l’équipe de développement et j’ai commencé le voyage de «se salir les mains».

Voici quelques aperçus de cet exercice:

Bien que l’environnement d’aujourd’hui pour PM s’attende à ce qu’ils soient techniquement compétents, savoir comment écrire du code n’est pas une compétence indispensable à mon avis. Si vous comprenez comment les choses fonctionnent au niveau du système, vous n’êtes pas techniquement handicapé. Cela signifie que visualiser comment les données circulent d’un système à un autre, avoir une compréhension de base de l’architecture du système et de ce que les composants individuels font et fonctionnent, est un excellent moyen d’avoir un aperçu de certains problèmes système ou techniques.

Chaque jour, je m’asseyais avec un de mes amis développeurs et je leur demandais d’expliquer le système dans un langage simple. Je retournerais ensuite chez moi, lirais beaucoup plus profondément le sujet sur Internet et le comprendrais beaucoup mieux en raison des connaissances qui m’ont été transmises par mes développeurs. Parfois, je revenais le lendemain avec des questions de suivi après avoir lu ces articles ou blogs pour dissiper mes doutes et améliorer ma compréhension.

Cela se poursuivrait pendant quelques semaines après que j’effectue une session inverse de «transfert de connaissances» avec mon équipe de développement. Dans le cadre d’un transfert de connaissances inversé, je préparerais un organigramme dans Visio de l’architecture du système et je leur expliquerais comment les choses fonctionnent au niveau du système. Cet exercice a renforcé ma confiance dans la compréhension d’un peu plus de spécifications techniques. Cela m’a non seulement aidé à long terme à parler dans une langue qui est comprise par mon équipe de développement, mais a également aidé à déboguer certains des problèmes du système en analysant, en indiquant le lieu de l’échec, ce qui à son tour a permis de gagner du temps pour l’équipe .

Essais exploratoires: Cem Kraner, qui a inventé le terme en 1984, définit les tests exploratoires comme «un style de test logiciel qui met l’accent sur la liberté personnelle et la responsabilité du testeur individuel d’optimiser en permanence la qualité de son travail en traitant l’apprentissage lié au test, la conception du test, le test l’exécution et l’interprétation des résultats des tests en tant qu’activités de soutien mutuel qui se déroulent en parallèle tout au long du projet. »

Lorsque j’ai obtenu la connexion de l’équipe de développement pour explorer le système de test, je ne connaissais pas la définition de «test exploratoire» ou «test de singe». Je lisais des articles de connaissances sur l’aide en ligne pour avoir une idée de ce que font ces fonctionnalités, puis je passais des heures à faire des tests, à rédiger mes observations et à réfléchir à la raison pour laquelle il avait été conçu de cette façon. Avec ces observations, je contacterais ma PME qui aiderait alors à dissiper beaucoup de doutes. Cet exercice s’est avéré être la chose la plus fructueuse de tous les temps car:

une. J’ai compris le fonctionnement du système

b. J’ai compris les cas d’utilisation commerciale

c. J’ai compris les personnages qui utilisaient le système

ré. J’ai compris les points faibles du système actuel

e. Je pouvais co-relier et imaginer en coulisses comment les données étaient stockées, récupérées, manipulées.

F. Et surtout, je connaissais les moindres détails du système au niveau microscopique.

Se salir les mains signifie également faire sa propre analyse de données. Si vous craignez les données, vous ne découvrirez jamais la vérité complète. Pour compléter ma compréhension holistique du système et me familiariser avec les choses, j’ai commencé mon voyage pour recueillir des données sur les caractéristiques du système. Salesforce, les systèmes de BI, les journaux système étaient quelques-uns des endroits que j’ai commencé à explorer. Non seulement cet exercice m’a aidé à chiffrer et à tirer des enseignements de l’utilisation du système et des points de défaillance, mais j’ai également appris à utiliser ces nouveaux outils!

La compréhension et l’exploration des données étaient pour moi le gâteau. Je suis devenu beaucoup plus confiant dans mon apprentissage au cours des dernières semaines et j’étais maintenant dans une situation où je connaissais une bonne partie des «réalités du terrain».

Sans vous familiariser avec la pratique, vous pourrez peut-être gérer certaines conversations dans un projet, mais un propriétaire / gestionnaire de produit qui s’est sali les mains aurait toujours un avantage!

Le conseil de «me salir les mains» m’aide toujours à traverser différents projets, organisations en ma qualité de responsable Produit et j’espère qu’il vous sera utile aussi!