brand

La même personne peut-elle fonctionner comme PM et BA sur le même projet ou effort agile?

La même personne peut-elle fonctionner comme PM et BA sur le même projet ou effort agile?

Il y a dix ans, j’ai écrit un article intitulé Can Same Person Function as a PM and BA sur le même projet.

J’ai écrit qu’il nous fallait distinguer si la même personne «pouvait» (bien sûr qu’elle le pouvait, mais avec des résultats parfois douteux) et si elle «devrait». J’ai expliqué qu’il était tout à fait logique qu’une seule personne joue les deux rôles dans certaines circonstances, comme lorsqu’un projet est connu pour être «petit» ou dans des équipes performantes, autogérées et polyvalentes, lorsqu’une organisation manque de fonds. pour les deux rôles et lorsqu’une organisation ne reconnaît pas les deux rôles. J’ai dit qu’il est utile, cependant, de connaître les différences entre les rôles et de savoir quand chacun est joué.

Dix ans plus tard, je suis toujours d’accord avec ce que j’ai écrit. Cependant, il y a une autre question qui doit être mise dans le mélange — qu’en est-il d’Agile? Avant de répondre à la question d’Agile, examinons rapidement quelques différences fondamentales entre les rôles PM et BA.

D’une manière générale, il existe une différence d’objectifs inhérente entre les deux rôles. La gestion de projet concerne davantage le projet et l’analyse commerciale concerne davantage le produit. Le rôle du chef de projet est de répondre aux objectifs du projet. Le rôle du BA est d’aider les organisations à atteindre leurs objectifs en recommandant des solutions à valeur ajoutée qui résolvent les problèmes commerciaux. C’est une différence subtile mais importante. Autrement dit, les objectifs du projet aident l’organisation à atteindre ses buts et objectifs commerciaux. Le PM se concentre sur le premier; le BA sur ce dernier.

J’ai mentionné que le PM se concentre généralement sur le projet, y compris la résolution des problèmes liés au projet, la gestion des risques du projet et la mobilisation des ressources sur les activités et les tâches. Et que le BA se concentre généralement sur le produit final, comme la gestion des risques liés au produit, suscitant des questions sur un nouveau produit et spécifiant les détails du produit afin qu’il puisse être développé et livré.

Bien que le PM puisse effectuer certains travaux liés au produit et que le BA puisse effectuer des travaux liés au projet, je pense qu’il y a toujours un besoin pour les deux rôles sur la plupart des projets. Il me semble que, parce qu’il y a une focalisation et des objectifs différents, il y a souvent une traction dans des directions opposées, surtout lorsque les deux rôles relèvent de fonctions organisationnelles différentes. Les chefs de projet souhaitent, entre autres, livrer le produit dans les délais et dans les limites du budget. Les analystes commerciaux veulent s’assurer que les clients peuvent réellement utiliser le produit une fois qu’il a été mis en œuvre.
Mais attendez, qu’en est-il d’Agile?

Avec Agile, il peut y avoir ou non un BA et un PM dans l’équipe. Notre question est donc la suivante: la même personne peut-elle se concentrer à la fois sur le produit et sur la livraison de ce produit en même temps? Pour le produit, nous entendons non seulement le backlog de produit, mais les détails des fonctionnalités qui le composent. Par objectif de livraison, nous entendons quelqu’un pour protéger les processus Agiles et supprimer les obstacles afin que l’équipe puisse aller de l’avant. Quelqu’un qui peut développer des graphiques de burndown et de burnup pour savoir ce qui a été accompli et ce qui reste à faire.

Bien sûr, la réponse est oui, il est possible qu’une personne se concentre sur les deux. Bien que ce ne soit pas idéal, cela peut être nécessaire lorsqu’il n’y a pas suffisamment de ressources pour avoir un propriétaire de produit dédié et un maître de mêlée.

Il faudrait quelqu’un avec les compétences pour spécifier les fonctionnalités avec suffisamment de détails pour qu’elles puissent être estimées et construites, comme un propriétaire de produit – si, et c’est une contrainte critique -, il est autorisé à prendre des décisions commerciales. Mais quelqu’un qui se concentre également sur la livraison des fonctionnalités. Cela peut fonctionner dans de petites organisations et sur de petits projets. Il peut même fonctionner dans des organisations plus grandes lorsque l’organisation doit «se débrouiller» avec moins d’un nombre et de types de ressources idéaux. Et bien que cette approche comporte des risques inhérents, elle peut fonctionner.

Regardons un exemple réel. Une petite organisation a utilisé une ressource informatique externe pour développer un produit et un membre de l’équipe de gestion pour être le propriétaire du produit. Ce gestionnaire était non seulement capable de prendre des décisions commerciales, mais avait également à la fois un BA et une formation en développement. Les fonctionnalités ont été développées «agily» et devaient être livrées toutes les quelques semaines. Le propriétaire et développeur du produit par intérim a résolu des problèmes de conception complexes et les fonctionnalités ont été implémentées presque sans problème. Jusqu’ici tout va bien.

La difficulté était que, bien que le bon de commande et le développeur aient collaboré à merveille sur les fonctionnalités du produit, personne ne s’occupait de la livraison de ces fonctionnalités. En d’autres termes, il n’y avait personne pour soutenir ou protéger un processus Agile. Il y avait des réunions Scrum occasionnelles, mais pas de réunions quotidiennes pour examiner l’état et les problèmes. Les progrès n’ont pas été régulièrement surveillés, et des semaines se sont écoulées sans qu’aucun résultat ne soit livré et aucune idée claire du moment où la prochaine fonctionnalité serait publiée. Il n’y a pas eu de rétrospectives et pas beaucoup d’examens des fonctionnalités avec d’autres parties prenantes clés. Parce que c’était une petite entreprise et que tout le monde faisait un million d’autres tâches, ce processus a plus ou moins fonctionné. Mais le manque de concentration sur le projet s’est avéré frustrant pour presque toutes les personnes impliquées.

Enfin, je tiens à souligner à nouveau que nous parlons de concentration, pas de titres de poste. Nous parlons de quelqu’un qui a non seulement les compétences nécessaires pour se concentrer à la fois sur le projet et le produit, mais aussi sur le temps. Ainsi, même sur des projets Agile, la même personne peut-elle être à la fois BA et PM, c’est-à-dire pouvoir se concentrer à la fois sur les fonctionnalités du produit et sur la livraison de ces fonctionnalités? Bien sûr, mais lorsque l’objectif principal est le produit, la livraison peut en souffrir et vice versa. Sur des projets de toute taille, il y a moins de risques lorsque ces fonctions sont séparées.

Post Comment