Le financement d'activités reliées au logiciel

Dernière modification: 2022-07-21

Dans ce blogue, nous tentons de clarifier la différence entre la gestion de projet et la gestion de produit en mettant en relief les activités liées au logiciel qui nécessitent du financement tout au long de la durée de vie d’un produit.

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.

Notre objectif est de réduire les frictions que nous avons constatées et qui rendent difficile la mise en œuvre de la gestion des produits au gouvernement.

Même si un produit n’est pas nécessairement fondé sur un logiciel, nous faisons un rapprochement entre la frénésie actuelle envers la gestion des produits et notre transition vers le numérique. Le numérique signifie que le logiciel est un moyen de prestation de services qui, en raison de ses propriétés uniques¹, permet de réduire considérablement la boucle de rétroaction entre la politique et la prestation (anglais seulement).

Pour bien comprendre la gestion des produits à l’ère numérique, nous devons cerner les « activités » exécutées sur le logiciel. Et par « activité », on entend « une tâche de travail nécessitant du financement ».

Nous pouvons classer les activités en question comme suit :

Fonctionnalité : Il s’agit de la raison d’être du produit logiciel et ce sur quoi « l’entreprise » se concentre. Il s’agit des travaux exploratoires, des recherches sur les utilisateurs et des activités de développement qui sont réalisés en vue d’obtenir un avantage.

Améliorations : Il s’agit d’éviter l’entropie en améliorant continuellement l’expérience utilisateur, le rendement des processus opérationnels et les postures de cybersécurité (p. ex., modèles de conception architecturale).

Durabilité : Il s’agit du maintien de l’actualité des logiciels et parfois des mises à jour technologiques (p. ex., passage de PowerBuilder à une pile technique plus moderne). Cela concerne particulièrement l’exigence mise à jour de la Directive sur les services et le numérique qui consiste à maintenir une valeur d’évaluation de la TI « attention minimale requise ».

Maintenance : Il s’agit de la correction logicielle (p. ex., traitement des VEC²).

Soutien : Il s’agit de la correction des bogues, de la correction des pannes, de la reprise des activités après un sinistre, du soutien du centre d’assistance et de la documentation.

Infrastructure : Il s’agit des abonnements à l’infonuagique, des serveurs gérés par Services partagés Canada (SPC), des licences exclusives de logiciels commerciaux.

Ces 6 types d’activités devraient alors permettre de prévoir un budget pour non seulement créer, mais également maintenir la valeur d’un produit pendant sa durée de vie. Il serait possible, par exemple, d’extrapoler un budget raisonnable en utilisant le nombre de serveurs utilisés, les différentes composantes technologiques, les services infonuagiques et les piles techniques qui composent le logiciel, les feuilles de route des fournisseurs si un logiciel commercial est utilisé, la taille de la base des utilisateurs finals, etc.

Si nous cartographions ces activités sur la durée de vie d’un produit, nous pouvons nous attendre à ce qu’elles fluctuent au fil du temps.

Au début de la vie d’un produit, l’accent est mis sur le développement des fonctionnalités. Mais avec le temps, les efforts consacrés aux fonctionnalités devraient diminuer, et une transition vers des améliorations continues et des activités habituellement associées à la dette technique devrait s’opérer.

La capacité d’une équipe devrait donc également fluctuer. Au début, l’équipe de produits (ou l’équipe de projet si une équipe de produits n’existe pas encore) devra augmenter temporairement sa capacité à répondre à la demande. Cela dit, après un certain temps, une réduction de la demande supposera probablement que l’équipe des produits gère plus d’un produit pour justifier son budget.

Au milieu de la figure 2, nous représentons une demande supplémentaire de fonctionnalités découlant d’un projet (p. ex., en réponse à une nouvelle modification législative). La demande pourrait justifier un renforcement temporaire de la capacité interne de l’équipe de produits à répondre à cette demande, surtout si une date de déploiement a des conséquences politiques.

Il s’agit d’un changement important de perspective entre l’accent mis sur les produits et l’accent mis sur les projets au sein du gouvernement. Les projets existent toujours, mais ils deviennent un instrument qui amène la demande aux équipes de produits et qui nécessite l’autorisation d’utiliser des fonds supplémentaires. Il revient ensuite au gestionnaire du produit de négocier avec les différents gestionnaires de projet sur ce qu’il est raisonnable pour l’équipe des produits de faire dans un horizon temporel donné. Le gestionnaire de produit veille à ce que l’équipe soit outillée pour réussir. Si l’équipe a besoin d’augmenter temporairement sa capacité, c’est le gestionnaire de produit qui obtient les fonds nécessaires pour embaucher plus d’employés (p. ex., à même les fonds qu’un projet a reçu l’autorisation d’utiliser ou en exerçant des pressions financières sur le ministère).

En ce qui concerne la création de produits, si elle est suffisamment faible, une équipe de produits existante pourrait avoir une capacité suffisante pour gérer et superviser sa création, y compris donner une assurance suffisante aux hauts fonctionnaires au sujet de la conformité aux politiques. Mais à une certaine échelle, nous prévoyons qu’un projet sera probablement nécessaire pour obtenir des engagements et fournir les assurances nécessaires aux hauts fonctionnaires. Cela s’explique par le fait que la gestion de projet est habituellement l’instrument utilisé pour obtenir des fonds supplémentaires temporaires, participer aux présentations au Conseil du Trésor (CT) et faire appel à d’autres experts fonctionnels (p. ex., architecture d’entreprise, protection des renseignements personnels, sécurité, services juridiques, accessibilité). 

Toutefois, franchir les points de contrôle imposés par le CT ne signifie pas nécessairement que nous devons utiliser une approche « en cascade »³.

À EDSC, le terme « projet d’investissement » est utilisé pour désigner les projets comportant des points de contrôle. Les grands projets (habituellement les projets de plus de 5 M$) comportent 6 étapes de prise de décision dans leur cycle de vie.

Les travaux liés aux fonctionnalités devraient être effectués aux étapes 1 et 2. Cela comprend l’exécution de travaux exploratoires comme la recherche sur les utilisateurs, l’expérimentation en bacs à sable, le prototypage et même les versions alpha. Cela signifie qu’il faut mobiliser des développeurs de produits, et pas seulement l’architecture d’entreprise, pour mieux comprendre ce vers quoi nous nous orientons.

Ces travaux exploratoires sont nécessaires pour éclairer de manière appropriée l’Évaluation de la complexité et des risques des projets (ECRP), un produit livrable du point de contrôle 2 imposé par le CT. Si l’on se penche sur l’ECRP, on constate que deux de ses sept sections représentent 51 % de la note totale.

Section	Note Max	% du Total
Caractéristiques du projet	90	28%
Risques liés à la gestion stratégique	30	9%
Risques liés à l’approvisionnement	45	14%
Risques liés aux ressources humaines	25	8%
Risques liés aux activités	25	8%
Risques liés à l’intégration de la gestion de projet	30	9%
Risques liés aux exigences du projet	75	23%
Total	320	100%

Les « caractéristiques du projet » comprennent le budget, la taille du projet, sa durée, sa portée technologique et le nombre d’intervenants.

Les « risques liés aux exigences du projet » comprennent les degrés de certitude et la complexité des exigences.

La participation de développeurs de produits qui connaissent bien le produit à l’étape de l’exploration permettra de réduire au minimum les risques du projet, de renforcer la crédibilité de la présentation au CT ou de l’analyse de rentabilisation du projet, mais surtout d’augmenter les chances de réussite du projet dans son ensemble. Pour ce faire, il faut dépenser des fonds pour le personnel des TI, et pas seulement pour l’architecture, ce avant l’étape de la planification.

Ensuite, au point de contrôle 2, nous continuons d’itérer à l’aide de la version bêta, qui est suivie des versions définitives. Les étapes de prise de décision servent toujours à déterminer si l’investissement demeure pertinent. C’est à la fin du projet que s’opère une transition vers la gestion des produits. Cela s’explique par le fait que l’accès aux fonds que le projet a autorisé prendra fin et qu’il faudra donc obtenir des fonds de source différente pour le cycle de vie à long terme du ou des produits qui résulteront du projet.

Si vous faites partie d’une équipe des produits qui effectue des travaux liés aux logiciels, vous n’observerez probablement que ces 6 activités, qu’elles fassent partie d’un projet ou non. C’est peut-être là que réside la confusion entre les projets et les produits au sein du gouvernement, car les développeurs de produits pourraient ne pas voir ou même ne pas être au courant de l’augmentation de la surveillance ministérielle et du travail de l’appareil gouvernemental.

De plus, une expertise différente sera nécessaire selon les activités réalisées, ce qui peut avoir une incidence sur la composition d’une équipe au fil du temps (p. ex., au début de la vie d’un produit, l’expertise en expérience utilisateur sera priorisée; ensuite, elle sera davantage axée sur le développement de logiciels et l’ingénierie de la fiabilité des sites, SRE en anglais).

Ces 6 activités peuvent ensuite être utilisées pour justifier la budgétisation d’une équipe de produits sur un horizon temporel.

Le financement temporaire (bonifications temporaires) provient habituellement de projets d’investissement qui ont obtenu l’autorisation d’utiliser des fonds. Le financement des services votés doit être justifié en expliquant les différents types d’activités nécessaires pour maintenir la valeur d’un produit au fil du temps et représenter les niveaux de référence d’une équipe de produits. Ces services votés sont nécessaires pour assurer la stabilité des équipes de produits et permettre la gestion des produits.

Enfin, les équipes de produits doivent être multidisciplinaires. Le modèle traditionnel du « secteur d’activité » qui transmet la demande aux « TI » comme s’il s’agissait d’une entreprise distincte offrant des services de développement de logiciels complique considérablement l’adoption de la gestion de produits. Dans un billet précédent, nous avons extrapolé la façon dont un secteur d’activité pourrait parrainer le personnel des TI afin de former une équipe de produits multidisciplinaire, et nous avons expliqué comment différentes équipes de produits interagissent les unes avec les autres en utilisant les concepts de topologie des équipes.

Espérons que ce blogue trouve écho auprès des fonctionnaires qui s’efforcent d’évoluer vers la gestion des produits. Cela dit, nous tenons à le rappeler, il faudra prendre des décisions difficiles en matière de priorisation en raison de la capacité limitée des ressources. Les équipes de produits doivent être en mesure de justifier leur budget à long terme pour pouvoir ensuite participer adéquatement à la gestion des produits.