Composition des équipes techniques du projet : Architecte de solutions

En tant que chef de projet (PM), l’une de mes principales préoccupations lorsque je m’engage dans un nouveau projet est de comprendre l’étendue du travail. Ensuite, quelles sont les compétences nécessaires pour soutenir et fournir la portée du travail à accomplir ? De nombreuses considérations entrent dans cette découverte, mais l’une des toutes premières ressources que je préfère avoir assignée est le rôle d’architecte de solutions (SA).

Bienvenue dans ma nouvelle série de blogs ; La composition des équipes techniques du projet. Suivez ce parcours en me concentrant sur la façon dont chaque rôle fonctionne aux côtés du chef de projet pour assurer le succès sur différents types et échelles de projets. Commençant par un rôle fondamental, l’architecte de solutions doit être identifié tôt et amené à jeter les bases de la réussite du projet. Au début de tous les projets, je m’assure de définir les rôles et les responsabilités, mais obtenons le point de vue de quelques SA, eux-mêmes, sur la façon dont ils se sont préparés pour un nouveau projet et comment ils s’attendent à travailler aux côtés du PM pour assurer une solution réussie. Poursuivez votre lecture pendant que je discute de diverses situations de projet avec divers architectes qui, collectivement, ont plus de 22 ans d’expérience dans ce rôle.

PM : En tant que PM, j’aime définir les rôles et les responsabilités tôt. Quelles sont les activités de gestion de projet typiques couvertes par votre chef de projet qui vous sont utiles pour un projet donné ?

SA1 : Le PM est la personne qui connaît vraiment la vue d’ensemble de haut niveau de l’ensemble du projet, les objectifs que nous essayons d’atteindre et comment les tâches individuelles mènent à la réalisation des objectifs. Dans une équipe Agile, chacun devrait être responsable de son propre travail, mais j’apprécie que le PM qui a une vue d’ensemble de l’image complète reste concentré sur les choses qui sont importantes. Les tâches de Scrum Master sont également importantes pour un PM si elles ne sont pas remplies autrement.

SA2 : La gestion du conseil d’administration est une aide précieuse pour un architecte. Pour s’assurer que nous gardons un œil sur ce qui est en cours, sur quoi nous prenons du retard, pour un architecte, ne pas avoir à se soucier du tableau est formidable. En outre, s’appuyer sur le PM pour gérer la communication avec le client à moins qu’une communication technique ou de résolution ne soit nécessaire. L’architecte ne devrait pas avoir à s’inquiéter des communications quotidiennes avec le client.

SA3 : Exécuter des standups, s’assurer que le backlog est aussi complet que possible avant le début du projet, garantir un accès approprié aux systèmes et outils dont l’équipe de développement a besoin, en s’assurant que rien n’est bloqué. Vous ne pouvez pas vraiment démarrer un projet tant que vous n’avez pas un architecte, un backlog et un plan de projet. Au-delà de cela, la gestion du backlog, des bugs et du budget est la première ligne de défense du client.

Cela ressemble à une réponse retentissante de scrum master et d’intermédiaire client ! Dans un blog ultérieur, je discuterai du chevauchement des tâches de Scrum et de la façon dont, si un projet est doté de ressources avec un analyste commercial, souvent Business Analyst et PM partagent les tâches de Scrum, mais nous y reviendrons dans un article ultérieur. Cependant, en parlant de chevauchement de tâches…

PM : Comment préférez-vous gérer le chevauchement dans les rôles de SA et de développeur ? Idéalement, un architecte devient simplement architecte, mais souvent (selon le projet) s’engage également dans des tâches de codage. Les pensées?

SA1 : Si le SA travaille à temps plein sur le projet, il est logique d’avoir également une certaine bande passante pour les tâches de développement, mais s’il n’est qu’à temps partiel sur le projet, le SA est plus précieux en tant que guide pour le reste de l’équipe de développement. L’objectif d’un SA doit être la résolution de problèmes, le guidage, l’aide à l’intégration/la configuration de la machine locale. En fin de compte, la SA devrait être de niveau supérieur pour aider l’ensemble du projet à avancer (gestion du code, gestion du pipeline, gestion du déploiement, recherche pour prendre en charge des tâches plus importantes, etc.).

SA3 : SA ne devrait pas faire de codage quotidien, pratique. Au lieu de cela, SA devrait revoir ce qui a été fait. Parfois, SA intervient pour aider dans des tâches plus complexes ou aide au quotidien aux côtés de l’équipe de développement. Il est important de tenir compte de ces tâches plus complexes dans le plan de projet pour tenir compte du temps de l’AS. Essentiellement, SA fait le contour de l’image globale tandis que le développeur colorie tout.

Nous avons tous une idée de notre rôle dans un projet donné, mais comme nous le savons, ces responsabilités changent parfois de projet en projet. Par conséquent, il est si important d’identifier les rôles et les responsabilités tôt et de les vérifier souvent. Comment tirer le meilleur parti des atouts des ressources dont nous disposons avec une utilisation plus efficace du budget ? Merci aux architectes de solutions d’avoir discuté avec moi des sujets ci-dessus. Il y a tellement plus à couvrir! Parlant d’utilisation efficace du budget, je serai bientôt de retour pour vous faire part de perspectives supplémentaires concernant les communications, les interactions avec les clients et les rencontres avec nos architectes de solutions. Restez à l’écoute!