Comment appelle-t-on quelqu'un qui écrit du code comme métier ? Un développeur ? Un programmeur ? Un ingénieur ? Un architecte ? Un codeur ?

De nombreuses personnes dans la fonction publique effectuent le même travail de base avec des titres très différents. Il serait bon qu'ils se retrouvent ensemble pour comparer leurs notes et leurs meilleures pratiques. Contrairement au secteur privé (où il n'est pas possible de partager des informations exclusives ou de la propriété intellectuelle avec ses pairs), le gouvernement devrait encourager le partage. Lorsque deux personnes qui travaillent sur la même chose se rencontrent, elles peuvent trouver des moyens de collaborer et s’aider mutuellement.

Lors de notre premier FWD50, une participante enthousiaste m'a dit qu'elle avait rencontré quatre personnes travaillant sur la même chose dans quatre autres ministères. Aucune d'entre elles n'avait la moindre idée de l'existence des autres et, à l'époque, elles n'auraient même pas pu voir les calendriers des autres pour coordonner une réunion si elles l'avaient su.

Pourtant, les rencontres fortuites de ce type ont toujours été exceptionnelles, fruits du hasard ou d'une conversation spontanée dans la file d'attente du déjeuner. Cette année, nous allons essayer d'organiser un peu plus ces heureux hasards par le biais de ce que nous appelons « Job Jobs » (le nom est inspiré par la question des gens qui demandent « ok, cela est votre titre, mais quel est votre réel travail ? » (what’s your job job?))

 

Une hiérarchie des professions

George E. P. Box a dit que « tous les modèles sont faux, mais certains sont utiles ». Il en va ainsi de tout système qui tente de classer la nature nuancée des emplois en un ensemble gérable de groupes. Nous pourrions définir les emplois par ancienneté, par ministère ou par diplôme universitaire. Aucune de ces définitions ne serait parfaite, mais elles pourraient être utiles. Aussi, lorsque j'ai entrepris de concevoir l'activité Jobs Jobs pour le FWD50 de cet automne, je savais que de nombreuses personnes auraient des opinions sur la question.

J'ai choisi un modèle de cycle de vie d'un produit, basé sur l'idée que tout ce qui est fait dans le gouvernement numérique implique une recherche et une planification initiales, la prestation du service et son exploitation. Cela fonctionne assez bien pour la plupart des types de services.

Prenons l'exemple d'un restaurant :

• La planification implique de rechercher les tendances et les lieux de la restauration, de trouver du personnel et un chef, et de concevoir un modèle financier qui inclut les coûts des aliments, le loyer et les bénéfices.
• La mise en oeuvre signifie la conception de la cuisine et des sièges, l'impression des menus, l'embauche des cuisiniers et des serveurs, la création d'un site web et de réseaux sociaux, l'achat de publicités, l'obtention des permis et licences nécessaires, la conception du menu et l'essai des recettes.
• L'exploitation signifie produire des repas, faire payer les clients, verser les salaires, calculer les chiffres, modifier le menu et, finalement, développer d'autres restaurants ou fermer.

Il en va de même pour un programme de financement, un site Web de passeport ou un immeuble d'habitation : la planification, la mise en œuvre et l'exploitation. Chacune de ces fonctions a des fonctions subordonnées, qui peuvent être classées selon un calendrier approximatif : la mise en œuvre consiste à gérer les personnes, les projets et l'argent ; l'exploitation consiste à gérer les données, le code, les personnes et la plateforme ou l'infrastructure physique.

J'ai représenté tout cela dans le schéma suivant :

Puis, parce que c'est la meilleure méthode pour découvrir rapidement toutes les façons dont on se trompe, je l'ai publié sur Twitter pour voir comment je pourrais l'améliorer.

Je n'ai pas été déçu.

 

Ce que nous avons appris de l’échange

Je vais résumer ci-dessous les points les plus importants de ces échanges, puis j'expliquerai comment nous allons organiser Job Jobs en fonction de ces commentaires. Sans aucun doute, certaines personnes n'aimeront pas ce que nous faisons, mais la carte n'est pas le territoire, et j'espère que l'activité sera utile pour une bonne partie des personnes qui y participeront, autant en personne et qu’en ligne.

 

La réalisation et les opérations ne sont pas des choses distinctes

Le diagramme est excessivement simplifié sur un point important : la mise en œuvre et les opérations se chevauchent en fait davantage dans la technologie moderne. Le domaine du DevOps (un mot-valise formé par les termes « développement » et « opérations ») en est la preuve. En effet, contrairement à un bien physique, un logiciel peut être constamment mis à jour et modifié, et le comportement d'un logiciel est intrinsèquement lié aux plateformes, aux systèmes d'exploitation et aux réseaux sur lesquels il fonctionne. La séparation entre la « mise en œuvre » et la « réalisation » est une fiction dans les environnements de développement logiciel matures qui adoptent les méthodologies Lean Startup et Agile.

 

Ce n'est pas une ligne, c'est un cycle

Pour remédier à cela, le diagramme nécessite en fait un cycle de développement, de mesure, d'apprentissage et d'amélioration. Mais comme cela rend l'illustration trop complexe, nous ne l'inclurons pas ici. Sachez simplement que la correction d'un bogue et l'implémentation d'une fonctionnalité sont souvent indissociables et réalisées par la même personne.

 

La stratégie est ignorée

Comme l'a souligné Jacky Tweedie, la stratégie et la planification sont deux choses différentes. « La stratégie définit les priorités et les résultats souhaités. La planification met en place les ressources et les personnes nécessaires afin d'entreprendre les activités qui permettront d'atteindre les résultats escomptés ». Elle a suggéré cet excellent survol du professeur Roger Martin de Rotman.

La phrase la plus intéressante de ce dernier est « la stratégie a une théorie sur la façon de gagner » (strategy has a theory about how to win).

 

Mettre l'accent sur les résultats

David Pepin a suggéré d'envisager un modèle basé sur les résultats : dresser une liste des résultats à atteindre, tels que la fonctionnalité ou la réduction des coûts, puis réunir des personnes axées sur ces résultats. Il a fait référence au diagramme de Pavel Samsonov qui compare cette approche aux modèles axés sur les résultats.

 

L’état actuel par rapport à l'état souhaité

Pia Andrews a déclaré que le diagramme reflète l'état actuel, mais pas celui que nous voulons. La politique, la prestation et l'exploitation devraient être un continuum, faisant partie d'un plus grand cycle de vie du produit. Plusieurs personnes ont fait référence à l'exposé de Neil Bouwer sur l'élaboration et la transformation des politiques, enregistré lors du Sommet du secteur public de 2022.

Neil expose le modèle actuel d'élaboration des politiques : recherche, options et conseils menant à une décision, qui déclenche ensuite la mise en œuvre et l'évaluation. Ce modèle présente plusieurs limites importantes :

• C'est compartimenté et lent.
• Le changement n'est pas assez rapide pour tirer parti des analyses en temps réel et des technologies modernes.
• Il est impossible de prévoir tous les résultats d'une politique, et plutôt que de s'entêter lorsqu'un problème est découvert, les politiques devraient pouvoir s'adapter.

Un cadre de politique intégré publié officiellement par l'École de la fonction publique du Canada décrit ce cycle, qui transforme l'« entonnoir » de l'élaboration des politiques en une boucle sans fin d'instigation et d'approbation.

 

Un filtre imparfait

Plusieurs personnes m'ont envoyé des messages privés, parfois avec inquiétude, pour me dire qu'elles n'arrivaient pas à se positionner sur le schéma. Il y a une raison à cela : le diagramme est très fonctionnel, et axé sur la prestation. Il ne montre pas les concepteurs, les communicateurs et les agents de liaison qui assurent souvent le bon fonctionnement d'une organisation. D'autres ont suggéré que nous considérions la classification nationale des professions, qui est le système canadien de description des professions (saviez-vous qu'il existe une taxonomie des compétences, des connaissances, des attributs personnels, des intérêts et autres, créée par le gouvernement ?)

Les sept catégories de la Taxonomie canadienne des compétences et capacités.

 

Le diagramme reconfiguré

J'ai modifié le diagramme initial en le divisant en phases distinctes de stratégie et de mise en œuvre. Pour ce faire, j'ai fusionné le modèle de Neil avec l'approche Double Diamond du Design Council du Royaume-Uni du Design Council du Royaume-Uni.

• Le côté gauche concerne la stratégie : Que pourrions-nous faire, et que ferons-nous ? Pourquoi est-ce l'approche gagnante, et quels résultats attendons-nous ?
• Le côté droit concerne l'exécution : Maintenant que nous savons ce que nous allons faire, comment pouvons-nous l'accomplir ? Et comment le ferons-nous ?
• Il y a un processus de contrôle (« approbation ») au cours duquel le budget et le personnel sont affectés à l'initiative. Il existe également une étape d'évaluation au cours de laquelle nous décidons de mettre à jour et d'itérer ce que nous fournissons, d'ajuster la politique sur la base de nouvelles preuves ou de mettre fin au projet.

Celui-ci n'est pas parfait, mais aucun modèle ne l'est.

 

Ce que nous allons faire

Sur la base de ce modèle, nous allons poser trois questions aux participants pour les classer :

• Travaillent-ils sur la stratégie (à gauche) ou sur la prestation (à droite) ?
• Quel est le « verbe " de leur travail (des mots comme « approuver », « construire » et « analyser ») ?
• Quel est le « nom » de leur travail (des mots comme « personnes », « logiciel », et  « conformité ») ?

Les participants pourront répondre à ces questions en scannant un code QR, puis en naviguant dans un sondage menant à un nombre compris entre un et dix. Nous les dirigerons ensuite vers l'une des dix zones. Dans le monde physique, il s'agira d'un ensemble de dix tables dans notre espace pour les ateliers. En ligne, il s'agira de zones sur la plateforme de réseautage spatial Wonder.me.