Catégories
Uncategorized

Dites à vos clients ce que vous ne ferez pas!

Parmi les techniques que j’utilise les plus souvent dans mon quotidien d’analyste d’affaires, la priorisation MoSCoW de Dai Clegg est certainement la plus efficace et la plus populaire. Un acronyme qui établi la priorité des besoins d’affaires avec le client, mais peut aussi être utilisé comme outil pour établir les critères d’acceptation d’une solution.

MoSCoW c’est :

must have, c’est-à-dire ‘doit être fait’ (vital).

should have, if at all possible, c’est-à-dire devrait être fait dans la mesure du possible (essentiel).

could have, if it does not affect anything else, pourrait être fait dans la mesure où cela n’a pas d’impact sur les autres tâches (confort).

won’t have this time but would like in the future, ne sera pas fait cette fois mais sera fait plus tard (luxe, c’est votre zone d’optimisation budgétaire) – ou jamais ;).

Algèbre pour les scrum masters : M <60%, M + S <80%, C < 20%, W = 0

J’ai déjà assisté à une rencontre dans un mandat où on parlait des exclusions, et les représentants TI riaient de l’utilité de la séance.

« Pourquoi tu me parles de ce que je n’ai pas besoin de faire? »

Au contraire! Les exclusions sont vitales. Gérer les attentes clients fait parti des différentes responsabilités des responsables de produits. Vous allez entretenir une bonne relation avec vos sponsors de projets si vous gérez leurs attentes. Une priorisation MoSCoW bien faite fera la différence entre un objectif de projet réussi, et un non-accompli, car il établi dès le départ, les besoins du client dans un ordre hiérarchique.

MoSCoW n’est pas à l’abri de la critique, on pourrait simplement dire que les deux items importants sont Must et Won’t … On dit aussi que la technique est subjective et que la différence entre Must et Should est floue (voir mon tableau.) Cela dépend beaucoup de l’appartenance de l’équipe de réalisation et des priorités organisationnelles. Par exemple, une équipe agile dédiée pour un client seulement, et qui a de la capacité sur le long terme, pourra adresser les points en Should et Could dans des sprints subséquents, et le Won’t lorsque le moment sera venu. À l’inverse, si la même équipe a plusieurs clients devant prioriser ensemble leurs besoins, et que des contraintes de budget les limitent, il est fort possible que seuls les éléments en Must ne soient adressés. Pour ce qui est de la subjectivité, il est clair que cela nécessite une maturité professionnelle pour bien définir et bien prioriser les besoins. Ceci dit, c’est en faisant l’expérience à plusieurs reprises que les sponsors pourront justement acquérir cette maturité organisationnelle.

En conclusion, dites à vos clients ce que vous ferez pour eux, mais n’oubliez pas de leur dire ce que vous ne ferez pas. L’entente en sera des plus respectueuse et agréable et vous atteindrez vos objectifs intelligemment.

—-

Joins-toi à moi pour relever ensemble le défi d’aller vers l’autre!

Привіт! Мені цікава ваша думка, діліться нею в коментарях!

#innovation #leadership #transformation #management #businessanalysis #productowner #cybersecurity #digitaltransformation #бизнесаналитик #machinelearning #iiba #productmanagement

Catégories
Uncategorized

« J’ai pas touché à cette feature »

Au début de la semaine dernière, je partageais une publication de The Cyber Security Hub™ qui est on ne peut plus familière et énonce les différentes raisons que l’équipe TI peut donner quand on fait affaires avec des bogues post-mep/post-prod. Cette satire est familière, comme BA, comme PO, mais en fait aussi comme client de services informatiques. Souvent, les projets numérique peuvent se retrouver dans ces situations.

Imaginez: vous allez au garage pour faire un changement d’huile, la voiture revient avec les pneus crevés. Le garagiste vous dit « J’ai pas touché à tes pneus, ils étaient probablement crevés avant, ça te prend des nouveaux pneus »… Quelle serait votre réaction, sachant que vous avez vous même amené le véhicule en parfait état à la porte du commerce?

Deuxième mise en situation: la voiture a atteint le 100 000 km de parcourus le jour du changement d’huile. L’ordinateur de la voiture exige un changement de batterie au premier changement d’huile passé 100 000km (j’invente). Le garagiste vous dit « J’ai pas touché à ta batterie, mais le véhicule ne démarre plus, il faut une nouvelle batterie et ça coute 5000$ + installation. » Quelle serait votre réaction, sachant que vous n’avez jamais entendu parlé de cette situation, et que vous aviez un budget de 50$ (normal pour un changement d’huile)…

Une solution numérique entièrement fonctionnelle peut être brisée par une simple virgule au mauvais endroit. Je vous entends! C’est la base de faire la révision du code et de trouver l’erreur en amont. Cependant, rappelez-vous que des chirurgiens oublient des outils dans les abdomens de leurs patients… pourtant c’est évident que ça ne va pas là.

Souvent (et c’est peut-être pour ça que les représentants « affaires » sont finalement apparus dans le décor de l’Histoire des projets numérique,) on a besoin d’un peu de diplomatie et de traduction pour bien faire passer le message/la nouvelle auprès d’un client. Parfois, les systèmes informatiques sont dépendants les uns les autres. Des fois, les dépendances sont « découvertes » en ouvrant le capot, d’autres fois les incidents post-prod sont provoqués par les modifications appliquées.

Heureusement, plusieurs techniques sont appliquées pour rendre improbables les mise en situations précédentes (le code review, les livraisons en continue, les tests automatisés etc). Selon moi, le nerf de la guerre dans tout cela reste la communication du problème découvert, ET sa gestion. Le client sera compréhensif si :

il a été informé des risques et des enjeux d’appliquer sa modification.
nous lui expliquons la conséquence de manière intelligible, mais sommaire.
il est mis en confiance de la prise en charge de la problématique.
Des contournements sont mis en place pour l’aider à maintenir ses opérations en attendant un correctif (ex: voiture de courtoisie).

Pour les situations critiques, c’est la capacité à se « retourner sur un 10 ¢ » qui va faire la différence. L’agilité, ça sert aussi à ça. Il faut piler sur son orgueil et aller dire au propriétaire du véhicule, « Il y a eu un pépin, laisse moi t’aider pour remettre ça en place. »

Et vous, comment gérez-vous les incidents post-prod?

Catégories
Uncategorized

Intelligence artificielle

Gartner donne encore un 2-5 ans avant que le Deep Learning/ Machine Learning ne soit mainstream… Cela le laisse que peu de temps avant que vos compétiteurs ne prennent la relève avec assez de données 😉

Personnellement, je vois des avantages considérables à investir du temps, au moins au sujet. Si la plupart des outils que nous avons à portée de main s’en alimentent, il est pertinent pour l’analyste d’affaires d’avoir une petite idée de « qu’est-ce que ça mange en hiver du ML. »

Lorsqu’on a assez de données (c’est-à-dire, vraiment beaucoup). Les algorithmes sont en mesures de prédirent que mon visage est le mien à l’aéroport, que la prochaine publicité à te montrer est celle pour le nouveau rasoir de Gillette, que tu es à risque de problèmes de cœur, que la prochaine image Instagram que tu vas aimer sera celle de tel ou telle influenceur.e.

Aussi, le ML est capable de copier un visage ou une voix, lorsqu’il a assez d’intrants. Je vous recommande de jeter un oeil aux vidéos DeepFake de Tom Cruise et d’écouter le « Deep Audio » de Gordon Ramsay. C’est ahurissant. Cela est possible, car il existe beaucoup d’archives de leur visage, de leur voix. Ceci dit, cela prend de moins en moins de données pour que la machine apprenne convenablement.

Si ont tasse les enjeux éthiques du Deep Learning pour le moment, et qu’on se concentre sur les avantages corporatifs… Le ML peut participer à répondre à des besoins d’affaires importants comme:
-aider à la détection de la fraude en amont;
-supporter la tarification d’assurés;
-suggérer aux services à la clientèle les meilleures « phrases » pour rassurer un client;
-l’acquisition de procédures cléricales (process mining);
-traduire des documents, des conversations en temps réels;
-la liste peut s’éterniser…

Au cours de la semaine, je me suis tourné vers vous pour avoir votre (input) sur l’utilisation de la machine apprenante dans vos projets. Bon, je n’ai pas atteint le seuil scientifique de 21 répondants… mais allons-y quand même avec la conclusion que le machine learning (ML) est très peu utilisée dans les institutions financières à Québec, du moins pas dans mon réseau.

On jase. Pourquoi c’est impopulaire?
-Méconnaissance du sujet?
-Difficulté à appliquer avec les technos Mainframe?
-« on a jamais fait ça comme ça »?
-Ça fait peur?
J’aimerais vous entendre(lire)!