Transitionner vers la gestion des produits en suivant le Guichet emplois

Dernière modification: 2022-02-04

Dans ce blogue, nous continuons d’extrapoler sur la façon dont la gestion des produits peut être mise en œuvre au sein du gouvernement fédéral, particulièrement dans l’espace numérique.

Nous examinerons comment le Guichet-Emplois¹ effectue la transition de projet à produit en s’appuyant sur la structure environnementale nécessaire pour y parvenir. Nous pouvons établir un lien avec les résultats souhaités du programme.

Remarque : ce blogue renferme des liens qui renvoient à des documents internes d’EDSC, qui ne sont malheureusement accessibles que sur le réseau ministériel d’EDSC.

Emploi et Développement social Canada (EDSC) est un ministère de services, tout comme la grande majorité des ministères du gouvernement du Canada. EDSC offre ses services dans le cadre de 50 programmes visant à améliorer le niveau et la qualité de vie de tous les Canadiens. L’un de ces programmes est le Guichet-Emplois.

C’est ainsi que nous relions le produit au service, puis aux programmes.

Les programmes fournissent des services. Un consommateur de services ne se soucie pas des coûts et des risques liés à l’exploitation du service, mais un service utilise pour sa livraison des produits qui ONT un coût. La gestion des produits s’inscrit dans la gestion des complexités internes pour soutenir ces produits et leur incidence sur le niveau de service. Le passage au numérique signifie que certains de ces produits seront exposés au consommateur de services (p. ex., un site Web, une appli).

Les mots « Guichet-Emplois » ramènent à trois choses distinctes :

• un programme;
• des services pour les chercheurs d’emploi et les employeurs, dont le rendement est ultimement mesuré au moyen du profil d’information sur le rendement du programme (PIR);
• une famille de produits – plus particulièrement les onze produits qui forment le site Web du Guichet-Emplois, qui est exposé aux clients et consommé par eux dans le cadre de la prestation des services du Guichet-Emplois.

Les interactions avec le site Web ont une incidence directe sur le rendement du service (p. ex., la capacité de naviguer et de chercher des emplois pertinents, d’être correctement jumelé à un emploi) et donnent rapidement une rétroaction pour apporter des améliorations, car les interactions avec le logiciel génèrent de grandes quantités de données. C’est l’une des nouvelles possibilités qui s’offre à nous à l’ère du numérique : la capacité d’agir rapidement en se fondant sur cette rétroaction, en prenant des décisions axées sur des données probantes. Tout cela est fait dans le but d’améliorer les résultats.

Dans le cadre du lien qui unit habituellement les programmes et les services internes, les TI disposent à peine suffisamment de fonds pour « faire tourner la roue » et les projets sont utilisés lorsque les programmes veulent mobiliser le personnel des TI pour apporter des modifications logicielles. Cela peut créer un décalage inutile quand vient le temps d’apporter des améliorations mineures, mais indispensables.

Dans le monde numérique, une « équipe » de produit ministériel, comme le Guichet-Emplois, devrait intégrer le personnel des fonctions opérationnelles et de TI. Toutefois, étant donné que les politiques du Conseil du Trésor (CT) qui réglementent les programmes et les organismes² confient à deux personnes distinctes les fonctions relatives aux TI et aux programmes, ces deux personnes voudront naturellement que le personnel en charge de l’exécution de leur fonction figure dans leurs organigrammes respectifs.

Qui peut les blâmer! Si votre emploi (et votre prime comme cadre) est en jeu pour la fonction X, vous voudrez bien sûr superviser tous les travaux portant sur cette fonction. Le personnel du programme Guichet-Emplois fait partie de la Direction générale des compétences et de l’emploi (DGCE), tandis que le personnel de la TI fait partie de la Direction générale de l’innovation, de l’information et de la technologie (DGIIT). L’équipe du programme Guichet-Emplois lance des projets à la DGIIT lorsqu’elle a besoin de personnel de TI pour modifier les logiciels utilisés dans la prestation du programme Guichet-Emplois.

C’est là que nous voulons différencier les améliorations des projets.

Le financement des activités d’EXÉCUTION continue de servir à « faire tourner la roue ».

Les projets, qui existent toujours dans le domaine de la gestion des produits, servent à coordonner des changements importants, comme la transformation de l’entreprise ou la nécessité de coordonner des changements touchant plusieurs produits.

Toutefois, il demeure possible d’apporter des changements rapides et mineurs aux logiciels, à des fins d’amélioration continue. Habituellement, de telles améliorations sont apportées à des processus opérationnels existants, afin d’améliorer l’expérience des utilisateurs et de gérer constamment les risques de cybersécurité.

Certains rôles, compétences et structures spécifiques sont nécessaires pour permettre de telles améliorations continues.

Les différents types de travaux qui touchent un produit donné sont essentiellement des exigences qui alimentent l’arriéré de ce produit. Les équipes de produits exécutent leurs propres activités d’amélioration et de maintenance, tandis que les projets externes leur apportent du travail.

Notre système de pensions constitue un bon exemple de cela. Il est bombardé de projets (qu’il s’agisse d’améliorations opérationnelles, du redressement de la dette technique, de correctifs logiciels, de mandats législatifs ou d’initiatives de transformation). Ces changements proviennent de plusieurs cadres supérieurs, car le programme des pensions n’est pas lié à un seul fonctionnaire qui supervise son exécution. Il n’est pas réaliste de demander aux TI d’agir seules pour gérer et coordonner des engagements d’une telle ampleur. Surtout lorsqu’il s’agit de composer avec les comportements territoriaux que certains projets peuvent manifester (p. ex., « MA principale priorité, c’est MON budget, ce sont MES ressources »).

Pour gérer toute cette demande, on fait appel au gestionnaire de produit. C’est un rôle stratégique qui examine la question sur un horizon de plus de six mois. Un gestionnaire de produit utilise la feuille de route du produit comme outil de communication et de négociation. Ce rôle collabore avec les différents gestionnaires de projet sur ce qu’il est raisonnable de faire dans un horizon temporel. Un gestionnaire de produit veille également à ce que l’équipe de produit soit bien outillée pour répondre aux demandes, comme la planification des finances, des RH et de l’architecture. Nous considérons le rôle de gestionnaire de produit comme étant essentiel et non comme une fonction parallèle, qui doit être acquitté du côté du programme.

Un responsable de produit joue un rôle plus tactique, examinant la question sur un horizon de six mois. Un responsable de produit travaille en étroite collaboration avec les gestionnaires de produit et avec la feuille de route du produit pour planifier les versions, et a le pouvoir de prendre des décisions définitives en ce qui concerne le produit. Ce rôle collabore avec l’équipe des produits pour élaborer des exigences plus détaillées à partir des exigences de haut niveau de la feuille de route et peut mobiliser d’autres professionnels des TI au besoin (p. ex., sécurité des TI). Comme pour un gestionnaire de produit, nous pensons que le rôle de responsable de produit doit également être acquitté du côté du programme, compte tenu de l’aspect décisionnel qui en découle.

L’équipe de produit est composée de membres interfonctionnels compétents, issus de plusieurs directions. Il s’agit de l’espace où l’on peut intégrer les méthodologies Agiles et DevSecOps. Le rythme plus rapide de diffusion nécessaire pour éviter d’obstruer le processus de prestation favorise leur adoption. Les équipes de produits doivent être bien formées sur les méthodologies Agiles, sinon le chaos risque de s’incruster et de nuire à leur rendement ou – pire encore – la haute direction pourrait en déduire que les « méthodologies Agiles ne fonctionnent pas ». La discipline de la gestion de projet est encore activement utilisée ici, en particulier par le gestionnaire de produit, sans nécessairement être reconnue officiellement au niveau du ministère ou de la direction générale.

Dans cet espace, il est normal que certains professionnels de la TI ne puissent pas voir au-delà de l’arriéré et n’aient pas une appréciation suffisante de tout le travail de planification effectué par les projets pour alimenter l’arriéré (p. ex., obtenir les autorisations nécessaires du Conseil du Trésor, évaluer les répercussions sur la protection des renseignements personnels, gérer le changement organisationnel).

Nous croyons aussi que certains autres rôles sont nécessaires, comme celui de champion de la sécurité des TI. Cela s’explique par le fait que le rythme du changement attendu et les risques associés même aux plus petites modifications logicielles justifient l’intégration d’une expertise en sécurité à l’équipe de produit. Cela permet de mieux outiller les équipes de produits et de déléguer certaines décisions architecturales aux équipes de produits, car ce sont elles qui subissent les conséquences des choix technologiques.

Voici comment nous proposons de financer les équipes regroupant des membres de plusieurs directions.

Un responsable de programme doit établir le budget et déterminer la source de financement des travaux de TI. Ce n’est pas un travail à faire par les services internes. Si un responsable de programme d’EDSC cherche à obtenir des fonds auprès du DPI, il est essentiellement en concurrence avec 49 autres programmes d’EDSC pour obtenir une part de ce budget limité.

Un responsable du programme doit plutôt se rendre à la source. Pour le Guichet-Emplois, il s’agit de la Commission de l’assurance-emploi du Canada. Dans le cadre du renouvellement périodique des présentations au Conseil du Trésor, le Guichet-Emplois doit déterminer le montant du financement nécessaire non seulement pour payer le personnel de programme, mais aussi pour les travaux de TI.

Une fois que le financement de la TI est mentionné dans la présentation au CT et approuvé, il peut être transféré à la DGIIT et utilisé pour financer le personnel des TI affecté à ce programme (des employés qui demeureront à la DGIIT). Nous considérons l’utilisation de protocoles d’entente (PE) entre le DPI et le responsable de programme comme étant un moyen approprié de consolider ces ententes.

Nous nous attendons toutefois à ce que ces fonds soient assortis de conditions. Par exemple, les fonds doivent être dépensés pour produire des résultats, donc… il vaut mieux travailler sur les versions des logiciels plutôt que sur des documents de planification (cette tâche revient aux projets).

Nous ne nous attendons pas non plus à ce que le conseil d’examen de l’architecture intégrée (CEAI) participe au processus d’approbation ou d’autorisation de ce type de financement. Cela s’explique par le fait que le CEAI concentre ses efforts au niveau organisationnel et que l’amélioration d’un produit existant a des effets négligeables sur l’organisation. Le CEAI participe aux projets.

Ces conditions et le niveau de confiance accordé aux équipes de produits peuvent être gérés grâce aux conséquences de non-conformité découlant d’une directive, comme l’ajout de couches de gouvernance pendant le cycle annuel de financement d’une équipe de produit.

Il convient de souligner que le processus d’affectation par projets demeure nécessaire pour coordonner le travail entre les équipes de produits et leur confier une charge de travail.

Pour accroître la capacité d’une équipe de produit, des instruments de pression financière existants sont utilisés (p. ex., si une équipe de produit qui bénéficie d’un budget de 2 M$ par année n’est pas en mesure de répondre à la demande pour une année donnée, les pressions financières du ministère peuvent être utilisées pour augmenter le budget à 4 M$ par année). Dans le cas d’une équipe regroupant plusieurs directions et financée par un responsable de programme, cette pression financière doit être exercée dans la direction du responsable de programme.

Cette équipe n’exerce toutefois pas ses activités en solitaire. Elle collabore avec d’autres équipes TI.

Les concepts de la topologie des équipes sont utilisés pour expliquer ses interactions.

Il existe quatre types d’équipes qui interagissent. L’équipe « axée sur le volet » est celle que le responsable de programme finance. Son crédit infonuagique et ses coûts de main-d’œuvre peuvent être directement affectés au programme.

Les trois autres types d’équipes ne peuvent être directement affectés à un seul programme; leurs coûts sont essentiellement partagés, constituant l’espace des « services ministériels de TI ». Leurs membres relèveront très probablement de l’organisation TI, mais il peut arriver qu’une équipe ait des membres de plusieurs directions générales. Leur financement et leur viabilité nécessitent la mise en commun des fonds dans le budget du DPI. À moins qu’elles puissent fournir des services sur demande, par exemple au moyen d’une IPA, leurs engagements devront peut-être être affectés à des projets, car les équipes axées sur les volets se disputeront essentiellement leur temps.

Les équipes spécialisées fournissent une expertise considérable dans certains domaines. Par exemple, le rendement des bases de données relationnelles, la modélisation avancée des données, les mathématiques et les calculs. Habituellement, ces équipes sont d’abord mobilisées dans le cadre de projets, puis elles poursuivent leurs activités en fournissant des services (p. ex., en créant un produit commercial d’intelligence d’affaires (IA) pour l’équipe axée sur un volet, puis en les laissant gérer les rapports d’IA).

Les équipes habilitantes aident les autres équipes à surmonter les obstacles. Elles les encadrent et les orientent jusqu’à ce qu’elles aient acquis une expertise suffisante, après quoi elles se retirent. Les équipes habilitantes sont éphémères de nature. L’exemple ci-haut est le bureau d’accessibilité.

Les équipes de plateforme fournissent des produits et des services internes pertinents pour accélérer la prestation des services par les équipes axées sur un volet. Par exemple, le Guichet-Emplois utilise un service DocUpload qui permet aux clients de télécharger des documents, puis de les soumettre à une analyse antivirus et de les stocker en toute sécurité. La réutilisation de ce service permet aux organisations d’économiser temps et argent.

Conclusion

Bien entendu, nous n’avons pas couvert tout ce que comporte la gestion des produits, comme l’établissement de la vision, la recherche auprès des utilisateurs et les différentes phases du cycle de vie d’un produit. Ces sujets sont bien documentés, notamment sur les sites PMI.org et PDMA.org.

L’équipe du Guichet-Emplois a atteint sa maturité dans l’application de la philosophie de gestion des produits. Par exemple, elle peut effectuer une analyse d’impact de la diffusion lui permettant d’évaluer, à l’aide de données empiriques, si une diffusion donnée l’a rapprochée d’un objectif particulier et si des correctifs sont nécessaires.

Le Guichet-Emplois n’est pas seulement un produit unique, mais aussi une famille de produits. Nous pourrions augmenter le niveau de granularité en décomposant chaque produit en sous-produits et au niveau atomique : une bibliothèque logicielle. Mais nous nous disputerions ensuite sur les produits externes par rapport aux produits internes…

Le présent blogue visait à expliquer comment nous nous efforçons de créer l’espace nécessaire pour permettre aux gens d’interagir en équipe, même s’ils proviennent de différentes directions générales, ainsi que d’éviter les obstacles inutiles à la collaboration dont ils ont grandement besoin.

Nous officialisons la façon dont une telle transition pourrait se faire au moyen d’un cadre pilote pour la gestion de produits (anglais seulement, comprenant une directive et un ensemble de normes).

Le cadre est actuellement en révision, car nous souhaitons l’utiliser pour deux projets pilotes : l’un avec le Guichet-Emplois, l’autre avec l’appli MonEDSC.