Mon expérience personnelle en tant que gestionnaire de programme et retour au développement

Retour du bon côté de la force: je redeviens développeur

J’ai récemment fait la transition de Program Manager sur Microsoft Graph à Software Developer dans l’équipe Microsoft Graph SDK. Je tiens à remercier mon équipe précédente de m’avoir accueilli ces 7 derniers mois et de m’avoir permis d’expérimenter le rôle de Program Manager.

J’ai pensé partager avec vous une partie de mon expérience et de mes apprentissages en tant que gestionnaire de programme. Avant de vous lancer, gardez à l’esprit qu’il s’agit de mon expérience personnelle, qui peut différer beaucoup d’une équipe à l’autre, d’un produit à l’autre et dépendre d’autres circonstances (travail à distance, culturelles, etc.). Ne prenez pas cet article pour une source unique de vérité, il y a d’autres expériences qui ont été partagées sur le web.

Qu’est-ce qu’un gestionnaire de programme de toute façon?

Cette question m’a été posée à plusieurs reprises, soit par des amis et des membres de ma famille qui ne travaillent pas dans le domaine de la technologie, soit par des pairs de la communauté qui évaluent le fait de rejoindre Microsoft comme une prochaine étape de leur carrière. Franchement, je ne pense pas avoir très bien compris le rôle avant de commencer dans ce role. Je ferai de mon mieux pour répondre à cette question avec ma compréhension actuelle. Un gestionnaire de programme est un mélange des rôles suivants:

• Product Manager du sens «silicon valley» traditionnel. Les chefs de produit se consacrent à faire évoluer une idée en un produit à part entière en concevant la meilleure solution fonctionnelle et son expérience utilisateur. Les chefs de produit se concentrent sur la compréhension des besoins mal desservis des clients, sur l’identification des opportunités qui se cachent dans ces besoins, sur la hiérarchisation des opportunités à poursuivre, sur les exigences, sur l’expérimentation des marchés / utilisateurs et sur l’ajustement de la stratégie jusqu’à ce que le succès soit atteint (quelle que soit la définition du succès ).
• Project Manager qui se concentre sur la planification, la gestion de ressources et le rapport sur l’état d’un projet donné.
• Scrum Master qui se concentre sur l’organisation de l’équipe, la suppression de tous les bloqueurs, la gestion du backlog et la recherche d’une efficacité de travail maximale.
• Software Architect dont les responsabilités se situent entre la compréhension de problèmes complexes afin de trouver des solutions élégantes et entre la bonne compréhension par l’équipe de développement de la direction technique pour résoudre ces types de problèmes. (peut ne s’appliquer que si le “produit” sur lequel vous travaillez est technique, comme une API ou des outils de développement)
• People Manager qui a la responsabilité de motiver les troupes, de répercuter les décisions stratégiques et d’agréger les signaux afin de rendre compte. Sans aucune autorité directe sur qui que ce soit, uniquement par influence, les cibles d’influence ayant tous des dizaines d’autres personnes qui essaient de les influencer pour faire autre chose.

En fin de compte, un gestionnaire de programme est responsable d’indiquer dans quelle direction, à quel rythme et dans quelles conditions l’équipe au sens large doit aller. Les PM s’assurent que les différentes équipes comprennent pourquoi il est important d’aller dans une direction spécifique et que chaque acteur est coordonné avec le groupe.

Que fait un gestionnaire de programme?

Les PM assistent principalement aux réunions et envoient des e-mails (parfois simultanément). La conception de présentations et de spécifications est également une grande partie du rôle.

Blagues à part, je vais décrire le cycle de vie typique d’une fonctionnalité, mais gardez à l’esprit qu’un PM a plusieurs “programmes” (fonctionnalités) en cours à un moment donné, et à différentes étapes.

1. Les PM commencent par explorer un marché produit et essaient de comprendre si ce marché présente un besoin mal desservi.
2. Les PM essaient de confirmer cette «intuition» en parlant avec les clients existants.
3. Les PM essaient de confirmer cette «intuition» en explorant les données / télémétrie. (si disponible)
4. Les PM conçoivent une solution, au niveau fonctionnel. (revenez à l’étape 2 jusqu’à ce que la solution semble répondre à ce besoin sur papier)
5. Les PM essaient de comprendre et convaincre les autres des raisons pour lesquelles il est important de donner la priorité à cette fonctionnalité par rapport à tant d’autres fonctionnalités.
6. Les PM communiquent à l’équipe d’ingénierie ce qui doit être construit, équipe qui reviendra avec le comment (conceptions techniques) et quand (estimations).
7. Les PM exécutent des pilotes avec un panel sélectionné de clients pour essayer le MVP (Minimum Viable Product). (revenez à l’étape 4 jusqu’à ce que la fonctionnalité soit suffisamment mature pour un aperçu public)
8. Les PM s’assurent que la fonctionnalité est correctement documentée.
9. Les PM s’assurent que la fonctionnalité peut être prise en charge par les équipes d’assistance. (à ce stade, vous devriez être prêt à livrer un aperçu public)
10. Les PM plaident publiquement pour la fonctionnalité. (articles de blog, conférences …)
11. Félicitations! La fonctionnalité est maintenant disponible publiquement. Recommencer.

Il convient de noter qu’une grande partie de la planification stratégique et de la coordination de l’équipe suit la méthodologie objectif résultat clé. Si le poste vous intéresse, vous familiariser avec cette méthodologie vous aidera à vosu préparer.

La plupart de ces étapes impliquent des rencontres avec des personnes, de nombreux courriels / messagerie instantanée, la rédaction de documents, la gestion de backlogs, etc. Si, pour une raison quelconque, une équipe de soeur ne peut pas aider (en sous-effectif, non adaptée à cet espace de problème, autres priorités urgentes, etc.), il est probable que le travail reviendra au PM.

Avec qui les gestionnaires de programme travaillent-ils?

Cela comprend, mais sans s’y limiter:

• Équipes d’ingénierie: elles bâtissent le service et le maintiennent en vie.
• Équipes marketing: elles organisent des événements, publient des articles de blog et s’assurent que les personnes extérieures à l’entreprise connaissent le produit / la fonctionnalité.
• Équipes de support: si les clients rencontrent des problèmes avec les fonctionnalités, ils constituent la première ligne de défense.
• Équipes de documentation: elles s’assurent que la solution proposée par l’équipe est correctement documentée d’une manière facile à comprendre par n’importe qui.
• Équipes d’expérience client (CXP / CPX): comme un PM n’a pas le temps de parler à tous les clients, cette équipe est en conversation continue avec certains clients pour comprendre ce qui manque / bloque l’adoption et agréger ces informations pour le PM.
• Equipes Juridiques: elles s’assurent que les solutions en construction sont éthiques et respectent la loi.
• Équipes de sécurité: elles s’assurent que les solutions sont conçues pour que les clients et leurs données restent en sécurité.
• Autres PM: comme toute fonctionnalité doit s’intégrer à d’autres fonctionnalités / s’appuie sur des fonctionnalités de bas-niveau, les personnes en charge de la coordination doivent se coordonner entre elles.
• Management: rendre compte des progrès, planifier les trimestres à venir etc …

Mon expérience personnelle

Outre les enseignements plus génériques que j’ai décrits ci-dessus, j’aimerais partager quelques autres détails de mon expérience personnelle.

J’ai commencé en tant que gestionnaire de programme en janvier 2020. Mon équipe immédiate de responsables de programme était assez récente¹ mais elle était jumelée à des équipes d’ingénieurs qui travaillent depuis longtemps sur Microsoft Graph, certains des ingénieurs depuis le début.

Culture de bureau

Après deux semaines sur place, je suis rentré chez moi et j’ai commencé à travailler à distance. L’une des premières différences que j’ai remarquées était la forte culture du bureau en personne. Les gens avaient l’habitude d’aller à des réunions en personne, de se présenter aux bureaux des uns des autres ou simplement de discuter dans le couloir pour de nombreuses conversations. Cela m’a particulièrement surpris pour deux raisons:

1. J’avais travaillé pendant les 3 dernières années dans une entreprise qui n’avait aucun bureau, et je m’attendais naïvement à ce que travailler à distance et de manière asynchrone soit devenu la norme mondiale.
2. Nous avons plusieurs membres de l’équipe à Nairobi, au Kenya et la société est présente dans le monde. Comment une culture en personne peut-elle fonctionner dans ce contexte?

La façon de travailler en personne a changé soudainement lorsque la pandémie a commencé à la mi-février². Je pouvais voir mes collègues lutter pour s’adapter au travail à domicile tout en reconstruisant une routine familiale en même temps. Même si cela a égalisé les règles du jeu et changé la culture pour le mieux à mon avis, cela a représenté une transition abrupte pour la plupart des membres de l’équipe.

Responsabilités et réalisations

À peu près au même moment, mon équipe commençait à organiser les domaines de responsabilités et j’ai hérité des notifications de changement, suivi des modifications et limitation d’utilisation.

Pendant mon temps en tant que gestionnaire de programme, j’ai aidé l’équipe à déprécier TLS1.0 et 1.1 pour les notifications de changement, à assurer la prise en charge des notifications de changement et du suivi des modifications pour les nouvelles entités, deux fois, à faire avancer les notifications de changement contenant des données de ressources vers la disponibilité générale, à livrer en essai publique le mode de livraison Azure Event Hub, à publier des informations de limitation d’utilisation plus détaillées et co-présenté une session lors de la build.

Rétrospective

Un aspect positif du rôle de gestionnaire de programme est son impact plus important: en passant du temps à coordonner les gens au lieu de faire le travail soit-même, on accomplit beaucoup plus en équipe qu’on ne le ferait jamais seul. Cet aspect s’accompagne de deux compromis majeurs:

• Au fur et à mesure que vous vous éloignez de la production, il devient beaucoup plus difficile d’avoir l’impression d’avoir accompli quelque chose.
• La communication constante laisse peu de temps pour se concentrer sur quelque chose.

J’aime vraiment écrire du code parce qu’en faisant cela, j’arrive à être “dans la zone” pour résoudre des problèmes. À la fin de la journée, j’obtiens aussi des résultats «concrets» et un sentiment d’accomplissement.

Boire au tuyau d’incendie

En tant que responsable de programme, j’ai reçu environ 60 000 e-mails et envoyé environ 2 500 e-mails en 7 mois. Mon astuce était de déplacer tout e-mail qui n’avait pas besoin de mon attention (et qui n’aurait vraiment pas dû m’être envoyé au départ) dans un dossier temporaire. Tous les vendredis, je consacrerais le temps nécessaire à la configuration des règles automatiques allant de “déplacer le fichier vers ce dossier, le garder non lu” à “le supprimer et le marquer comme lu” m’economisant la lecture de plus de 90% des e-mails au fil du temps.

Quelques chiffres de MyAnalytics:

Pour être clair: je ne porte aucun jugement sur ces activités, passer moins de temps sur les communications et plus de temps à me concentrer correspond mieux à ma personnalité.

Conclusion

C’est la conclusion avec laquelle j’aimerais terminer: avant d’accepter un nouveau rôle, assurez-vous que ses aspects fondamentaux correspondent à votre personnalité. Il est plus facile et plus rapide d’acquérir de nouvelles compétences que de changer qui vous êtes.

J’espère que cet article répond à quelques questions de ceux d’entre vous qui ont été curieux de connaître le rôle. Je suis reconnaissant que Microsoft m’ait donné non seulement l’opportunité d’explorer le rôle de responsable de programme, mais m’ait également permis de revenir au développement.

Notes de bas de page