Product Owner pour une équipe infra

Suite de mes aventures infra, aujourd’hui le Product Owner pour une équipe infra !

Un peu de contexte pour commencer

Drôle de question d’ailleurs, un Product Owner pour une équipe infra, car celles-ci n’ont pas de produit à part entière. D’ailleurs, commençons par préciser le travail réalisé par ces équipes. Il y a le travail planifiable :

• Support pour les projets pour le business
• Support ou acteurs pour les projets pour l’IT
• Le flux de « change » : changement d’un nouveau PC, arrivée d’un nouveau collaborateur, achat d’un nouveau serveur au lancement d’un projet, ….

Et la partie non planifiable

• Les incidents et autres

Quelques constats

La partie projet pourrait être gérée en Scrum. Une des équipes accompagnées avait commencé par cette méthode. Problème : il y a plusieurs demandeurs pour ces projets, et les sujets sont vraiment très diversifiés. Il est a priori difficile d’imaginer un seul Product Owner pour cette partie-là. Le flux de « change » est perçu comme un flux de travail non planifiable, alors qu’il peut et devrait être planifié également. Mais essayer de le planifier sur la même cadence que celle des projets, disons toutes les deux ou trois semaines, ça ne le fait pas. Une cadence de quelques jours serait plus adaptée. Autre problème, lié au précédent, lorsque le flux de change est cumulé au flux des incidents, la bande passante à leurs réserver représente une capacité important de l’équipe, la partie projet devient vite secondaire. Scrum est alors naturellement abandonné au profit de kanban. Et comme le flux est important, on bascule dans le mode réactif plus que pro actif. On résume :

• Des projets pouvant être pilotés en Scrum sur des sprints de quelques semaines mais avec des Product Owners différents
• Un flux planifiable mais sur une cadence plutôt courte, quelques jours, une semaine
• Un flux non planifiable
• Le tout plutôt piloté en Kanban subit en flux

La place d’un Product Owner pour une équipe infra

Dans ce contexte, pourquoi parler de Product Owner ?

Parce que, tout simplement, quelques questions opérationnelles restent ouvertes :

• Une part des projets pour l’IT sont des projets « auto alimentés » par l’infra, est-on sûr de leur retour sur investissement ?
• Le flux de « change » est subit comme du non planifiable, avec changement de priorité & co ? Est-ce normal ?
• Comment décider de l’allocation de bande passante pour chaque type de travail ?
• Et là question de fond, qui doit/peut répondre à ces questions ?

Du coup, la question d’un Product Owner est revenu sur le tapis, bien que le nom ne soit pas approprié. C’est la personne qui va prendre la responsabilité de maximiser la création de valeur ajoutée par l’équipe infra.

Allocation de capacité des bandes passantes

Pour répondre à la dernière question, ce sont les managers ou décideurs qui justement ont la responsabilité du cadre à l’intérieur duquel les équipes s’auto-organisent ; L’allocation de capacité pour chaque flux fait partie de ce cadre à définir pour les équipes kanban. Donc un des rôles du Product Owner va consister à décider des bandes passantes allouées, projets, businees, IT, Change, support, d’abord sur la base de l’historique de l’équipe, puis de l’ajuster par rapport au vrai besoin.

Il priorise le flux des tâches ?

A mon sens, aucun besoin d’aller dans le détail des changes ou des incidents, sauf à suivre les changes à risques, et les incidents critiques. Pour ces deux flux, ce sont les équipiers qui prennent les décisions au quotidien, plus qu’un product Owner. Mais il doit expliciter la notion de risques, de criticité avec l’équipe.

Et la partie projet ?

Il doit prioriser la partie projet. Ok. Mais une fois que l’on a dit cela, tout reste à faire car la valeur ajoutée est difficilement perceptible côté infra, on est loin des utilisateurs, les demandeurs sont nombreux … Prenons le cas du renouvellement du parc de PC des collaborateurs tous les 3 ans par exemple. Si c’est bien anticipé, il n’y a même pas de demande liée à cette tâche. C’est du récurrent long terme. Les demandeurs ne sont mêmes plus vraiment tangibles, c’est l’organisation elle-même. Et le ressenti de l’équipe est de s’auto alimenter en travail. La présence d’un Product Owner va être bénéfique pour prendre un peu de recul et réfléchir justement au modèle de valeur ajouté et définir les priorités.

Le modèle du coût du délai

Le modèle proposé par Kanban basé sur le coût du délai est alors d’une grande utilité pour le Product Owner d’une équipe infra. N’ayant pas d’utilisateur sous la main, le principe de ce modèle consiste à se poser la question des impacts économiques/business/organisation si on ne réalise pas la tâche pour la date prévue mais pour le lendemain ? Ou pour la semaine suivante ? le mois suivant ? Des catégories de réponses peuvent être identifiées. Ces catégories sont appelées des classes de service. Elles servent à catégoriser les demandes en leur associant une priorité. Le modèle classique du coût du délai s’appuie sur les classes d’urgence – standard – date fixe – intangible. Bien sûr, vous pouvez créer les vôtres. Puis le rôle du Product Owner consistera à allouer de la capacité par classe de service pour aider l’équipe à prendre des décisions au quotidien. Ce modèle est à construire sur la base de l’historique de l’équipe, à l’image du travail réalisé ici.

En résumé, le rôle du Product Owner pour une équipe infra

• Ajuster l’allocation de capacité des bandes passantes des flux de travail
• Prioriser la partie projet
• En définissant un modèle de valeur ajoutée adaptée à l’infra
• Pouvant s’appuyer sur un modèle basé sur le coût du délai

Ceci n’est ni exhaustif ni figé, cela représente l’état de mes réflexions et expérience d’aujourd’hui. En espérant que cela vous aide comme à moi.