Faire développer un logiciel métier sans Product Owner dédié
Un expert métier ou un directeur technique peut porter un projet sans être affecté à temps plein à son pilotage fonctionnel. Le prestataire prépare les propositions ; le client garde les arbitrages. Des situations concrètes pour organiser les rôles, la disponibilité et les décisions.
Terrain
Sur un projet lié aux analyses de sûreté, notre interlocuteur était un expert métier. Il connaissait les données dont son équipe avait besoin et les difficultés de son travail. Il avait peu de connaissances en informatique et n'était pas affecté à temps plein au pilotage du projet.
Ce qui lui a permis de le porter, c'est la perspective de ce qui deviendrait possible avec un nouvel outil et des données mieux organisées. Il s'est rendu disponible de manière régulière. Au fil des échanges, il s'est emparé des questions d'organisation et des processus de son équipe. Nous avons pris en charge une grande partie du travail de compréhension, de formalisation et de proposition.
Faire développer un logiciel métier sans Product Owner dédié en interne est possible dans cette configuration. Il faut un interlocuteur côté client qui connaît l'activité, s'intéresse au changement et peut décider ou obtenir les arbitrages nécessaires. Le prestataire peut préparer ce travail. Les décisions qui engagent l'organisation doivent pouvoir trouver leur responsable.
Sans Product Owner dédié, qui porte le projet côté client ?
Les responsabilités de compréhension des besoins et de priorisation existent, même lorsqu'aucun poste de Product Owner n'est prévu. Dans les projets dont nous parlons ici, elles sont réparties entre notre équipe et les personnes qui portent déjà le métier ou les enjeux du projet côté client.
Nous parlons donc de l'absence d'une personne dédiée à ce travail en interne. Le client conserve un interlocuteur responsable des priorités et des arbitrages. Sa disponibilité et son mandat doivent être organisés, quel que soit l'intitulé de son poste.
L'expert en sûreté évoqué plus haut n'avait pas besoin de devenir développeur. Il devait nous expliquer son activité, réagir aux propositions et relier les choix à ce que son équipe voulait obtenir. L'organisation de la donnée est devenue un sujet essentiel : il pouvait en apprécier les conséquences sur le travail de ses collègues.
Sur un autre projet, notre interlocuteur était le directeur technique, ou CTO, du client. La difficulté était différente. Il connaissait l'informatique, mais devait aussi s'occuper d'enjeux internes à son entreprise. Il nous a délégué des responsabilités pour alléger sa charge, tout en choisissant de participer à toutes les réunions.
Ces deux profils ont un point commun : un intérêt fort pour le résultat et une présence régulière. Cette continuité nous permet de reprendre les décisions précédentes, de corriger notre compréhension et d'avancer avec une personne qui connaît progressivement les propositions.
Le prestataire formalise et propose, le client arbitre
Les équipes métier n'ont pas toujours le temps de transformer leurs difficultés en descriptions fonctionnelles détaillées. Nous prenons en charge ce travail à partir des échanges, des documents et des outils existants. Nous reformulons le besoin, préparons des options et proposons des priorités au regard des objectifs que nous avons compris.
Le client peut ainsi discuter de propositions concrètes. Il n'a pas à préparer seul toutes les réponses avant de nous rencontrer. Mais nous ne connaissons pas nécessairement tous les enjeux de son organisation. Les priorités internes et les changements de processus demandent des décisions de sa part.
| Sujet à faire avancer | Ce qu'Improba prépare | Ce qui reste côté client |
|---|---|---|
| Compréhension du besoin | Étudier les documents, dialoguer et reformuler les usages. | Apporter la connaissance du métier et corriger ce qui a été compris. |
| Priorités fonctionnelles | Présenter les options, leurs conséquences et une proposition de priorisation. | Arbitrer selon les enjeux métier et les contraintes internes. |
| Réalisation et déploiement | Construire les fonctionnalités et coordonner les échanges techniques avec la DSI et les intervenants concernés. | Faire intervenir les responsables habilités lorsque des décisions dépassent le projet. |
| Essais et appropriation | Faire les démonstrations et préparer des essais guidés. | Essayer l'outil dans le contexte réel, faire des retours et porter les changements auprès des utilisateurs. |
Ce partage doit être explicite dès le début. Nous pouvons porter les propositions et la réalisation ; le projet a besoin d'une personne capable de représenter le client. Les éléments utiles au démarrage d'un logiciel métier incluent justement l'accès à la stratégie et aux personnes qui connaissent le terrain.
Quand plusieurs équipes métier ne veulent pas la même chose
Dans un contexte associatif, des attentes différentes ont conduit à un arbitrage. Nous avons préparé les options et formulé une recommandation à partir des enjeux stratégiques dont nous avions connaissance. Nous avons aussi précisé que nous ne connaissions pas forcément toutes les raisons internes de choisir une voie plutôt qu'une autre.
Le responsable côté client a tranché. Il n'a pas suivi notre recommandation. Il avait ses propres raisons, liées à ses enjeux, et nous nous sommes adaptés. Le projet s'est bien poursuivi.
Ce moment est révélateur de la répartition des responsabilités. Notre travail consiste à éclairer les choix, y compris à proposer une direction. Le responsable client doit pouvoir prendre une décision différente. La confiance fonctionne dans les deux sens : il nous fait confiance pour préparer les options, nous lui faisons confiance pour assumer les décisions de son organisation.
Le client n'a pas à formaliser seul toutes les fonctionnalités. Il doit pouvoir décider de ce qui compte pour son organisation.
Identifier les décisions qui dépassent le représentant métier
Il arrive qu'une personne connaisse très bien le métier sans avoir le mandat nécessaire pour une décision particulière. Nous cherchons à repérer cela dès la conception. Nous en parlons avec elle du point de vue du projet : quel arbitrage manque, et qui peut le faire ?
Sur un projet dans un contexte d'ingénierie, nos choix allaient orienter le déploiement de l'intelligence artificielle dans l'infrastructure du client. Ni notre équipe ni le responsable métier ne pouvaient décider seuls. Il fallait faire intervenir sa hiérarchie.
Nous avons préparé une présentation intelligible pour cette personne, puis organisé une discussion à trois : le responsable projet Improba, le responsable métier et son supérieur. La décision n'a pas été prise pendant la réunion. Nous lui avons laissé du temps pour réfléchir et pour échanger de nouveau avec le métier en interne. L'arbitrage est arrivé ensuite par message.
Nous n'avons pas eu besoin de changer l'équipe projet. Il fallait faire intervenir la bonne personne sur la bonne décision. Préparer cet échange fait partie du travail de pilotage : le représentant métier ne doit pas avoir à reformuler seul tout le sujet pour sa hiérarchie.
Une information qui n'arrive pas peut signaler une dépendance
Lorsqu'une question reste sans réponse ou qu'une décision est régulièrement repoussée, nous examinons ce qui manque réellement. L'équipe métier peut ne pas disposer de l'information. Elle peut attendre une réponse de la DSI, elle-même très occupée, ou un arbitrage qui dépasse son mandat.
Dans ces situations, nous avons souvent pu réorganiser les lots. Une partie prévue plus tard peut avancer pendant que le sujet bloquant est reporté. Cela suppose de vérifier que le travail déplacé peut être réalisé sans la décision manquante. Nous rendons la dépendance visible et adaptons la séquence du projet. Cette souplesse se discute dans le cadre des engagements au forfait et par lots.
Cette marge de manœuvre dépend de la taille et de la nature du projet. Sur les petits produits, nous cadrons davantage le périmètre en amont. Le temps disponible laisse moins de place pour découvrir puis réorganiser de grands ensembles fonctionnels.
La présence régulière de l'interlocuteur reste donc nécessaire. Elle ne lui donne pas automatiquement toutes les réponses, mais elle permet de repérer ce qu'il faut faire remonter et d'organiser les échanges avec les autres responsables.
Quelle disponibilité prévoir sans Product Owner dédié ?
Dans nos configurations habituelles, nous prévoyons deux à trois heures d'échange hebdomadaire au démarrage. C'est un repère pour les réunions, pas la totalité de la contribution du client. Il faut aussi retrouver des documents, consulter des collègues et essayer l'outil.
Lorsque les premières versions arrivent, nous faisons des démonstrations et fournissons un cahier de recette guidé. Si les premiers essais n'ont pas pu être faits, nous pouvons les réaliser ensemble pendant les ateliers. L'objectif est de faciliter l'entrée dans l'outil, puis de rendre les utilisateurs plus autonomes. Nous décrivons ce passage, notamment sur un projet ASNR, dans notre article sur le temps à prévoir pour les équipes métier.
L'absence d'un Product Owner dédié ne supprime donc pas la participation du client. Elle conduit à l'organiser avec un interlocuteur qui a déjà d'autres responsabilités, en préparant les échanges et en rendant les décisions aussi concrètes que possible.
Préparer la continuité après la livraison
À la livraison, l'équipe métier a appris à utiliser l'outil et à exprimer ses besoins dans ce nouveau contexte. La maintenance prend ensuite le relais. Sur nos projets, elle peut être reprise par une entreprise spécialisée, notamment pour l'exploitation et le maintien des infrastructures.
Le code appartient au client. La documentation technique et fonctionnelle est remise avec les sources, dans le dépôt et sous forme de PDF. Cette matière permet à d'autres intervenants de reprendre le travail. Nous restons disponibles pour répondre raisonnablement aux questions, et une passation avec des ateliers peut être prévue et budgétée.
La préparation de cette continuité compte autant pour les personnes que pour la technique. Le métier s'est approprié le sujet, les décisions ont laissé des traces et les nouveaux intervenants disposent d'une base pour poursuivre. Changer de prestataire demande néanmoins de transmettre le contexte et de construire de nouvelles habitudes de travail.
Les trois points à vérifier avant de lancer le projet
Vous n'avez pas de Product Owner dédié ? Commencez par identifier une personne qui connaît le métier et veut porter le changement. Vérifiez ensuite qu'elle pourra participer régulièrement. Enfin, précisez les décisions qu'elle peut prendre et les interlocuteurs à solliciter pour les autres arbitrages.
De notre côté, nous devons pouvoir étudier la matière métier, préparer les propositions et coordonner la réalisation. Un premier lot de cadrage permet de commencer à construire cette organisation, avec les personnes qui vont travailler ensemble.
Notre prestation de développement de logiciels métier sur mesure repose sur ce partage. Si votre projet attend faute d'une personne dédiée au pilotage fonctionnel, regardons qui pourrait le porter chez vous et quel travail nous pouvons prendre en charge.