La pipeline des caractéristiques du Nuage de talents : En équipe, nous avons utilisé une boucle de rétroaction de renforcement en cinq étapes afin de développer et d’adapter les différentes caractéristiques de la plateforme.
Pour construire un produit numérique moderne, vous avez besoin de l’appui de personnes avec de nombreux et différents ensembles de compétences, qui, au gouvernement, sont classés comme appartenant à différents groupes professionnels. En même temps, vous n’avez pas le temps de trouver des personnes à l’externe et de les encadrer dans le contexte spécifique de votre produit. Trop de choses dépendent des détails de ce que vous construisez pour que des experts externes qui ne disposent pas d’une connaissance intime du produit puissent y contribuer de manière significative. (À ne pas confondre avec la mobilisation des utilisateurs, qui est un effort constant de sensibilisation et de mobilisation.) Cela signifie que pour construire un produit de haute qualité et dans les délais impartis, votre équipe doit être dotée de cette expertise.
Dans la pratique, notre équipe jongle constamment avec les idées et le travail entre politique, fonctionnement du projet, conception, développement et services à la clientèle. Les concepteurs se concertent périodiquement avec l’équipe stratégique afin de veiller à ce que ce qu’ils proposent fonctionne du point de vue des politiques. Les opérations liées aux projets doivent se concerter périodiquement avec les développeurs pour obtenir des détails sur les nouvelles fonctionnalités qui seront disponibles. Notre cycle de développement du produit est une boucle constante qui passe entre les mains de plusieurs groupes professionnels. Il s’agit d’une collaboration quotidienne, qui nécessite les ressources spécialisées de différents groupes professionnels travaillant ensemble dans un cycle continu de rétroaction de création et d’itération.
Cette collaboration multidisciplinaire entre les membres de l’équipe est au cœur de ce que nous faisons et nous en bénéficions constamment. Pour que les choses continuent à évoluer à un rythme suffisamment rapide pour qu’un produit conserve sa pertinence dans un monde en constante évolution, nous pensons que c’est la seule façon de fonctionner (du moins pour ces types de produits basés sur les services où conception, développement et tests utilisateur entrent en jeu). Essentiellement, la structure de l’équipe permet à la fois au responsable du produit (qui décide de ce qui doit être construit) et à l’équipe du produit (qui réalise le construit à proprement dit) de fonctionner dans le cadre de la même équipe, améliorant ainsi le flux pour une itération rapide et novatrice du produit.
Bien que le gouvernement du Canada ait publié un bulletin à l’intention des responsables des ressources humaines confirmant que les politiques ne constituent pas un empêchement à des équipes multidisciplinaires, dans la pratique, il demeure difficile de regrouper ce genre d’équipes, surtout dans le cas d’unités plus petites. Cela est particulièrement vrai dans les cas où un modèle d’équipe hautement efficace exigerait une supervision à classification croisée. Dans une structure hiérarchisée comme celle d’un gouvernemental traditionnel, cela serait rarement nécessaire. Mais cette structure n’a rien d’exceptionnel dans les équipes agiles multifonctionnelles du secteur privé en raison de la nature du travail, ce qui exige que les concepteurs, les développeurs, les anthropologues et les services clients travaillent ensemble pour livrer un produit. Quand les gouvernements veulent construire ainsi, en appliquant des méthodes agiles, cela signifie que des équipes comme celle-ci seront de plus en plus nécessaires. Grâce à un travail minutieux de classification et au recours souple à des conventions à caractère provisoire « à durée déterminée », Nuage de talents a permis de mettre cela en place, mais il n’est pas garanti que d’autres équipes pourront faire de même.
Affirmer qu’une équipe utilise « agile » dans le gouvernement ajoute à la controverse en raison de la multitude des interprétations que donnent les équipes et les dirigeants à ce mot. Alors que sa soudaine popularité est évidente (à la limite de l’omniprésence), peu s’entendent sur une définition concrète, ou minimalement commune, qui légitimerait son usage dans la pratique. Néanmoins, nous partageons certains des concepts d’« agile » que nous employons au cours de notre cycle de sprints de deux semaines.
(Pour une vue réelle de cela, veuillez consulter notre code et contenu sur GitHub.)
Comme c’est souvent le cas dans les construits agiles, nous utilisons des points de récit pour parler de la difficulté ou de la complexité de quelque chose pour l’équipe de développement. Avant de décider de travailler sur une tâche précise, les développeurs estiment le nombre des points de récits qu’il faudra pour terminer; peu importe qu’un point de récit prenne habituellement une heure du temps d’un développeur ou toute une journée. Ce qui est important, c’est que le point de récit devienne un moyen utile de communiquer au reste de l’équipe à quel point quelque chose sera complexe (et peut-être long) à implémenter.
Par exemple, nous avons examiné une fonctionnalité qui interrompt une personne qui remplit une demande d’emploi lorsque la date limite pour la soumettre est échue. Sans cette interruption, vous risquez de perdre du temps à remplir une demande, mais lorsque vous cliquez sur le bouton Envoyer, un message d’erreur indiquant que la date limite de soumission est échue s’affiche. Il s’agit d’une caractéristique souhaitable, même si ce n’est qu’une infime fraction des utilisateurs qui en bénéficierait. Les développeurs ont estimé cela à 8 points de récit. Dans un sprint intense, nous ne pouvons accomplir que trois tâches de cette complexité. Et étant donné que si peu d’utilisateurs bénéficiaient de cette fonctionnalité, l’équipe a pu argumenter que ce n’était pas la peine de la construire. Le temps des développeurs a plutôt été consacré à l’implémentation de fonctionnalités de plus grande valeur qui bénéficieraient à un plus grand nombre d’utilisateurs. Mais si le « coût » de cela avait été d’un ou de deux points de récit, nous aurions pu faire un autre choix.
Pour notre équipe virtuelle, la réunion informelle quotidienne est devenue centrale dans notre façon de travailler. Chaque jour à 11 h, l’équipe de développement et les concepteurs se joignent dans le cadre d’un appel sur Zoom et décrivent succinctement :
Nous avons réussi à tenir ces réunions informelles en moins de 15 minutes, même avec plus de neuf personnes. Lorsqu’une réunion informelle donne lieu à des discussions, nous pouvons généralement demander aux gens de rester en ligne après la réunion, de sorte de conclure leurs échanges et de passer à autre chose. L’idée de tenir des réunions informelles est géniale, car elles permettent de veiller à ce que tout le monde travaille sur les bonnes choses. La présence des concepteurs permet aussi d’augmenter l’interaction entre eux et les développeurs; voilà un aspect que nous avons tenté d’améliorer.
Alors que de nombreuses personnes travaillent de la maison, une réunion informelle est parfois la seule interaction directe que vous aurez avec d’autres êtres humains au cours de la journée de travail. Le format de la réunion informelle est simple : chacun raconte brièvement ce sur quoi il a travaillé depuis la réunion précédente, ce sur quoi il compte travailler jusqu’à la réunion suivante et sur les blocages (s’il y en a) qui l’empêcherait de progresser. Cela contribue également à augmenter les interactions humaines en permettant à l’équipe de signaler quand deux personnes devraient discuter de leur travail. Il faut toujours trouver le juste milieu entre la participation de tous à ce qui se fait et le temps nécessaire pour que chacun se concentre sur son propre travail.
À la fin de chaque sprint de 2 semaines, l’équipe de développement dirige une séance de démonstration où elle montre ce qu’elle a accompli. Cependant, comme nous ne construisons pas vraiment pour un client en particulier, au début d’un sprint, nous n’insistons pas trop sur ce que nous engageons à faire. Au lieu de cela, les développeurs travaillent d’arrache-pied à faire avancer les choses autant qu’ils le peuvent. Si quelque chose n’est pas terminé, il est possible de la tenir en réserve pour la prochaine revue de sprint. Sauf circonstances particulières, les développeurs n’ont pas à faire des heures supplémentaires pour terminer des tâches.
Pour que tous soient sur un pied d’égalité, ce n’était donc pas toujours aux développeurs de présenter leur travail et ils pouvaient ainsi se mettre au parfum de ce que le reste de l’équipe faisait; nous avons commencé en faisant une revue de sprint de l’« équipe stratégique » toutes les deux semaines en alternance avec la revue de sprint des développeurs. (À des fins d’information, l’« équipe stratégique » est le volet recherche, politique et interaction avec la clientèle de Nuage de talents, qui utilise un tableau Trello pour suivre le travail, et a tendance à avoir des échéanciers et des pressions différents de ceux de l’équipe du développement.) Nous sommes encore en train d’itérer le format exact de la revue de sprint de l’équipe stratégique, mais l’objectif est de donner à chacun une idée des questions épineuses auxquelles l’équipe stratégique a dû faire face récemment et de rappeler à tout le monde que nous nous dirigeons vers une vision à plus long terme. Habituellement, nous tentons de choisir un ou deux artéfacts que l’équipe a achevés ou sur lesquels elle a accompli d’importants progrès et de faire en sorte que la personne qui a travaillé dessus les présente à tout le monde. Par exemple, des prototypes de conception, des présentations (dossiers), des recherches, des rapports ou d’autres travaux théoriques compliqués comme notre dixième version du cadre des compétences au cœur du modèle de recrutement.
L’équipe Nuage de talents est une équipe virtuelle depuis 2017, dont les membres sont répartis dans différentes villes canadiennes, dont Halifax, Toronto, Montréal et Edmonton. Cela signifie également que les membres de l’équipe du bureau principal à Ottawa ont toujours pu travailler à domicile à leur discrétion, y compris notre Liaison avec les communautés autochtones, qui travaille à mi-temps depuis sa communauté plus au nord.
En mars 2020, alors que les bureaux ont été fermés et que les gouvernements du monde entier se dépêchaient de s’adapter à la nouvelle réalité avec la COVID-19, les membres de notre équipe ont emporté leur ordinateur chez eux un vendredi et travaillent depuis ce temps à domicile. Chacun a pu continuer son travail sans interruption (à l’exception peut-être de ceux avec des enfants qui ne pouvaient pas aller à l’école, faisant du grabuge en arrière-plan).
C’est intéressant, car dans les faits, le travail des équipes virtuelles est devenu plus facile, puisque l’on n’avait plus à rassembler autant de gens dans un même endroit. Avec seulement une ou deux personnes en dehors du bureau, il est facile de maintenir le cap sur les pratiques centrées sur le bureau comme option par défaut, tandis que les gens dans les régions travaillent aux marges et s’ajustent comme ils le peuvent (une habitude que notre équipe a passé beaucoup de temps à tenter consciencieusement de casser). Mais quand plus de la moitié des membres de l’équipe travaillent à distance, on n’a tout simplement pas le choix.
Les outils numériques deviennent hyperimportants quand on travaille au sein d’une équipe dispersée géographiquement. Dans le cas de nos développeurs, c’est GitHub qui leur a permis de collaborer sur des sprints de développement de codes et de plans. Quant à nos concepteurs, ils ont utilisé Adobe Creative Cloud pour construire et partager des conceptions, tandis que tout le monde a collaboré sur des documents à l’aide de Google Drive.
Mais le plus important, c’est une application de messagerie fiable, parce qu’elle devient le principal mode de communication et pôle d’échanges culturels pour l’ensemble de l’équipe. Le partage de photos, d’hyperliens et des pensées au petit bonheur la chance remplace les conversations devant la machine à café. Un émoji remplace l’esquisse d’un sourire aux lèvres de vos collègues.
Les plateformes de messagerie permettent également d’améliorer la productivité, car les membres de l’équipe peuvent « s’absenter » pour effectuer un travail exigeant de la concentration, puis revenir à la conversation dont l’historique a été conservé dans son intégralité, permettant ainsi de s’y replonger rapidement sans avoir perdu le fil. Elles permettent également de faire un suivi des décisions prises et des motifs invoqués, en particulier dans le cas d’éléments clés de la conception où plusieurs options ont été prises en compte, notamment lorsque les applications de messagerie sont jumelées à des outils comme Trello pour suivre les tâches et les progrès.
