Au cours de mes années d’expérience en tant que chef de projet informatique et business analyst (BA), j’ai eu l’opportunité de lire de nombreux ouvrages. Dans cet article, j’en rapporte cinq qui ont vraiment eu un impact sur ma façon de travailler et de percevoir mon environnement. Présentation.
Pourquoi avoir retenu ces cinq livres spécifiquement ? Parce qu’ils m’ont aidé à comprendre différentes manières de penser, de travailler et de collaborer. J’ai notamment appris à décoder les différences culturelles lors de la collaboration avec des équipes interactionnelles, à gérer des projets et des personnes dans des environnements hybrides (tels que ceux qui adoptent un mélange de méthodologies agiles et en cascade), et à aborder les choses avec une vision systématique et holistique.
J’espère que ces ouvrages pourront également vous aider en tant que business analyst (et peut être même pour d’autres rôles comme product owner, product manager ou project manager) dans votre vie professionnelle.
1. The Culture Map: Breaking Through the Invisible Boundaries of Global Business
Le premier livre que je recommande est The Culture Map d’Erin Meyer. C’est un livre formidable pour ceux qui ont des interactions dans une organisation et/ou un environnement multiculturel. Le livre met en lumière la manière dont les dirigeants, les collègues et toute personne immergée dans un environnement multiculturel peuvent améliorer leur collaboration et leur compréhension.
Il entend ainsi aider les dirigeants et les équipes à identifier et à décoder les actions et les gestes à travers les cultures, en analysant le positionnement des cultures les unes par rapport aux autres selon huit échelles :
- Communiquer : comment la communication est-elle effectuée, de façon explicite ou implicite ?
- Évaluer : comment les feedbacks sont donnés et reçus, en allant directement au but ou en atténuant les commentaires négatifs avec beaucoup de commentaires positifs ?
- Persuasion : comment la persuasion est-elle effectuée, selon les principes d’abord ou les applications d’abord ?
- Leadership : quel est le style de leadership en place, plus égalitaire ou hiérarchique ?
- Décider : comment les décisions sont-elles prises, de manière consensuelle ou selon une approche top-down ?
- Confiance : comment la confiance est-elle établie, en fonction d’un niveau personnel et émotionnel, ou selon un niveau professionnel et de performance ?
- Désaccord : comment les conflits sont-ils gérés, de façon frontale ou en évitant la confrontation grâce à une série de techniques ?
- Planification : comment le temps peut-il être flexible ?
Ce que m’a apporté The Cultural Map
Les BA sont parfois amenés à travailler dans une équipe multiculturelle. Soit les collègues peuvent provenir de différents pays, soit la moitié de l’équipe est basée à l’étranger. Connaître les différences et les similitudes culturelles est fondamental pour une collaboration efficace.
Sur une note personnelle, comprendre les différences culturelles m’a beaucoup aidé dans la conduite de certains de mes projets. Dans une organisation, j’étais dans une équipe où nous étions tous sur place, mais tout le monde était de nationalité différente. Dans une autre organisation, la moitié de l’équipe était basée en Inde et l’autre en France, mais nos utilisateurs finaux, eux, étaient au Portugal, aux États-Unis et à Singapour.
Ainsi, au sein de cet environnement multiculturel dans lequel nous travaillons, collaborons et évoluons, il est fondamental de comprendre quand vous êtes drôle ou offensant, en retard ou trop en avance, perçu comme un dictateur ou un leader bâclé, et ainsi de suite.
En tant que BA, communiquer de manière explicite et cohérente avec les différentes parties prenantes (utilisateurs, développeurs, responsables produits, managers, directeurs, etc.) est crucial pour spécifier les exigences fonctionnelles d’un produit. Il est également important de calibrer toute communication, décision ou rétroaction auprès du public concerné.
Plus d’informations sur dans le lien ci-contre : The Cultural Map
2. A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
Le deuxième ouvrage que je vous présente est A Guide to the Project Management Body of Knowledge (PMBOK® Guide), proposé par le Project Management Institute (PMI). Actuellement, il en est à sa septième édition, mais la sixième édition est toujours d’actualité et très utile.
Pourquoi lire le PMBOK® Guide ?
En réalité, les deux éditions sont parfaitement complémentaires car elles capturent les fondements et l’état de l’art des pratiques de gestion de projet. La dernière version apporte une vision plus détaillée des processus tandis que la précédente permet de réfléchir davantage sur les principes de la gestion de projet.
Pour un BA, les compétences en gestion de projet sont précieuses. En effet, les BA peuvent être amenés à rendre compte du projet, à suivre les activités du projet, des epics, des work packages ou même à gérer un projet entier. Les compétences en gestion de projet seront sollicitées en fonction du type d’approche de développement du projet concerné.
Exemple d’application
Par exemple, une organisation souhaite créer une application web pour vendre des jouets pour enfants. Pour ce faire, ils adoptent une approche Agile (c’est-à-dire une approche itérative et incrémentale).
Après avoir défini le périmètre et identifié les rôles et responsabilités des membres de l’équipe, un BA est alors identifié comme responsable d’une epic concernant la gestion de la Product Detail Page (PDP). Le BA doit alors rassembler les exigences avec les parties prenantes potentielles (principalement le(s) product owner, les utilisateurs clés et le management) pour établir un ensemble de user stories, de sous-tâches et de leurs relations.
En outre, le BA sera également chargé de soutenir et de suivre le développement des stories avec l’équipe de développement. Ainsi, la collecte d’informations, les exigences, la gestion et le suivi des travaux de projet (stories) et, dans certains cas, la gestion des personnes constituent autant de compétences en gestion de projet qu’un BA doit avoir et mettre en œuvre.
Par conséquent, le PMBOK est une source fiable de connaissances et d’inspiration. Un autre avantage du PMBOK est qu’il ne s’agit pas d’une méthodologie stricte mais d’un guide qui peut être adapté en fonction de l’environnement, de la culture et du contexte sociotechnique de l’entreprise.
Plus d’informations sur dans le lien ci-contre : PMBOK Guide
3. The Scrum Guide
Le troisième livre n’est pas vraiment un livre. Il s’agit du Scrum Guide proposé par Ken Schwaber et Jeff Sutherland. Ce guide présente le framework Scrum pour les projets agiles. Il décrit les rôles, les artefacts et les cérémonies à adopter et à suivre pour développer des logiciels de manière itérative et incrémentale.
Notez qu’il ne prescrit ni une méthode, ni une méthodologie mais un cadre que l’organisation peut utiliser pour la conception et la maintenance de ses produits.
Que retenir du Scrum Guide ?
Pour un BA, le Scrum Guide est une excellente introduction au monde Agile. Il est clair et concis, mais inclut les notions et concepts essentiels pour être agile dans le développement logiciel.
En effet, cela aide à définir les rôles et les responsabilités des membres de l’équipe ainsi que le niveau d’autorité de chacun. De nombreuses organisations ont appliqué Scrum tel que décrit dans le guide ou l’ont adapté en fonction de leurs besoins.
Cependant, comme le dit Scrum Guide : « Scrum est immuable. Bien que l’implémentation de certaines parties de Scrum soit possible, le résultat n’est pas Scrum. Scrum n’existe que dans son intégralité et fonctionne bien comme un conteneur pour d’autres techniques, méthodologies et pratiques ». Néanmoins, l’organisation peut adapter Scrum et fusionner d’autres concepts, artefacts et techniques qui sont proposés par d’autres cadres et modèles tels que l’Extreme Programming, Kanban et autres.
Comment l’appliquer au BA ?
Dans un contexte agile, le BA doit être conscient des différentes phases, itérations et incréments du produit/projet. En général, le BA peut assumer un rôle de product owner mandataire en affinant et en transformant les exigences métier en spécifications fonctionnelles. La priorisation du backlog produit se fait en collaboration avec les autres BA s’il y en a plusieurs. S’il n’y a pas de Scrum Master délégué, le BA peut alors aider à faciliter et à soutenir les développeurs tout au long de leur travail.
Plus d’informations sur dans les liens ci-contre : Scrum Guide et Le Manifeste Agile
4. SPRINT: How to Solve Big Problems and Test New Ideas in Just Five Days
Le quatrième livre est le SPRINT de Jake Knapp, John Zeratsky et Braden Kowitz. Légèrement différente du sprint du Scrum Guide, la méthodologie Design Sprint explorée dans ce livre se concentre sur le design thinking et l’innovation.
Elle décrit une approche d’apprentissage basée sur un prototypage rapide et des tests effectués avec les clients pour valider les incréments d’une solution potentielle. En ce sens, l’ouvrage transforme l’habituel « apprendre et tester » en une approche de type test and learn (tester et apprendre).
De quoi parle SPRINT ?
En effet, l’apprentissage et le test habituels se concentrent sur la réalisation de benchmarks, la recherche de marché et la mise en place de groupes de discussion pour recueillir des informations et essayer d’identifier des idées pour de nouveaux produits et solutions.
Cependant, l’approche test and learn de Sprint se concentre sur le prototypage de solutions basées sur l’expérience et l’empathie, en les évaluant avec les utilisateurs, puis en apprenant par leurs commentaires.
L’approche SPRINT en cinq jours
L’approche est divisée en cinq jours d’activités (mieux vaut commencer un lundi). Elle prend la forme d’un atelier collaboratif mais directif, et se définit comme le Design Sprint. L’équipe participant à l’atelier ne peut dépasser sept personnes. Certains rôles clés devraient également être répartis entre les participants : un seul décideur, un seul facilitateur, des experts, et des personnes motivées et compétentes.
Les principales activités de ces cinq jours sont :
1. Lundi : il s’agit d’une série de conversations structurées pour construire les bases du sprint. Le résultat de la journée est une feuille de route pour atteindre l’objectif défini, y compris les plus grands risques et opportunités en cours de route.
2. Mardi : il s’agit de résoudre le problème. Chacun esquisse individuellement des solutions potentielles pour un problème donné selon l’objectif défini.
3. Mercredi : il est consacré aux décisions. Parmi les solutions esquissées de la veille, une doit être sélectionnée pour être prototypée et évaluée. Une méthode appelée Sticky Decision est proposée pour sélectionner les solutions les mieux adaptées. À la fin, le décideur décide s’il y a égalité entre deux ou plusieurs solutions.
4. Jeudi : c’est le jour du prototypage. L’équipe construira un prototype réaliste de la solution sélectionnée. Il n’a pas besoin d’être techniquement parfait, mais le plus proche de la vraie vie concernant les fonctionnalités de base et la conception (graphique ou physique).
5. Vendredi : c’est l’heure des tests ! L’équipe montrera le prototype à cinq vrais clients pour recueillir leurs commentaires et leurs données. Objectif : valider leurs hypothèses et la solution proposée.
Quel intérêt pour un Business Analist ?
Pour un BA, ce type d’approche peut servir d’inspiration pour susciter de nouvelles exigences commerciales ou valider des hypothèses données par la direction. En effet, il peut prendre en charge le processus de conception d’une solution potentielle avec l’aide de l’équipe de développement.
En général, ces approches sont utilisées sur des projets de construction de solutions innovantes, ou d’ajout / de mise à jour d’une fonctionnalité importante au produit existant.
Plus d’informations sur dans le lien ci-contre: SPRINT
5. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
Le cinquième et dernier ouvrage est un roman portant sur le DevOps. Cela peut sembler un peu bizarre, mais ce roman est vraiment une source d’inspiration intéressante.
The Phoenix Project est un livre écrit par Gene Kim, Kevin Behr et George Spafford. Le roman illustre divers aspects du monde informatique. Il présente comment la politique du lieu de travail, les objectifs commerciaux contradictoires, les défis informatiques et les contraintes de ressources sont interdépendants et peuvent influencer le résultat d’un projet / produit.
Que raconte The Phoenix Project ?
L’histoire se concentre sur le quotidien d’un responsable informatique qui a été chargé de suivre et de gérer un projet essentiel pour l’avenir de son organisation. Cependant, le projet dépasse largement le budget et est en retard. Le personnage principal, avec l’aide de ses collègues, a quatre-vingt-dix jours pour réajuster le tir, sinon tout son département sera externalisé.
Au cours de l’histoire, les auteurs présentent quatre types de travail qui peuvent exister dans une organisation et qu’un responsable informatique, comme le personnage principal du roman, doit considérer :
- Projet d’entreprise : il génère des revenus ou de la valeur stratégique pour l’organisation.
- Projet interne : il aide les clients internes de l’organisation à devenir plus efficaces et productifs.
- Changements programmés : il stabilise et améliore la sortie d’origine des deux catégories ci-dessus.
- Travaux non planifiés : tout ce qui perturbe les trois types de travaux planifiés ci-dessus.
La philosophie DevOps
De plus, le livre explore également une philosophie qui permet d’optimiser la mise en œuvre de DevOps. Une telle philosophie est basée sur The Three Ways (les Trois Voies) :
- System Thinking : permet de voir l’ensemble du système, ses parties et ses relations.
- Retour d’information (feedback) : raccourcir le retour d’information de la production / de l’exploitation au développement.
- Amélioration continue : apprendre des résultats, des échecs, de l’expérimentation et des idées pour améliorer les produits et services.
Pour un BA, comprendre ces types de travail et savoir les identifier est fondamental pour prioriser et gérer des ressources limitées. Les Trois Voies sont également une philosophie à considérer dans un environnement en évolution rapide.
Vous souhaitez en apprendre davantage sur le DevOps ? Découvrez notre livre blanc « 6 facteurs clés pour réussir sa démarche DevOps »
Conclusion
Lire et relire mais aussi pratiquer les connaissances acquises sont essentiels pour maintenir ses connaissance à jour et évoluer dans sa carrière de business analyst. Or la littérature du monde IT aujourd’hui est vaste et éclectique. Elle s’étend de la gestion de projets informatiques aux langages de programmation, en passant par le développement personnel. Un BA, ou toute autre fonction, doit se tenir informé et veiller à développer de nouvelles méthodes, techniques et technologies pour en tirer profit. La liste des livres présentés ici n’est pas exhaustive. Il s’agit plutôt d’un aperçu de la littérature moderne qui a pu m’aider en tant que business analyst.
Pas encore de commentaires