Composition des équipes techniques du projet : Architecte de solutions (Pt. 2)

Content de te revoir! La dernière fois, nous nous sommes arrêtés avec nos architectes de solutions pour discuter de la meilleure façon de définir les responsabilités et les attentes de ce rôle dès le début d’un nouveau projet. J’ai trouvé parmi de nombreux projets qu’une autre responsabilité importante d’un chef de projet est d’évaluer le temps de réunion. Combien de réunions, combien d’heures, quelle est l’efficacité ou la productivité ? C’est quelque chose que je couvrirai également dans tous mes futurs entretiens de rôle, mais concentrons-nous sur nos architectes en ce moment, car celui-ci peut entraîner une zone grise.

PM : Parmi le nombre de réunions que nous avons au cours d’une semaine donnée, en ce qui concerne les réunions spécifiques à un projet, quel type de réunions liées à un projet trouvez-vous important en tant qu’architecte ?

SA1 : Je suis d’accord qu’il y a plusieurs réunions auxquelles l’AS n’a pas besoin d’assister. Il est beaucoup plus précieux de passer mon temps à faire le travail qui aide à faire avancer l’équipe. Considérez les stand-ups, par exemple; c’est une réunion très importante, mais au cours d’une semaine donnée, cela peut durer en moyenne deux heures et demie par semaine. En tant que SA, je veux aider chacun à faire son travail, donc mon statut quotidien est générique « J’aide l’équipe » ou « contactez-moi si vous avez besoin d’aide pour mettre en œuvre la tâche sur laquelle vous travaillez ». Il s’agit d’un rôle important d’un SA, mais ne nécessite pas une présence quotidienne debout et cette utilisation des heures. Réunions face au client, je pense que le SA devrait avoir une forte présence auprès du client car il / elle est responsable de la prise de nombreuses décisions concernant la résolution de problèmes et que vous essayez de résoudre des problèmes, vous devez être en mesure de prendre ces options retour au client pour discuter des avantages et des inconvénients. Le SA doit être en mesure de devancer l’équipe de développement pour aider à repousser le client si nécessaire pour des raisons techniques.

SA2 : Tout ce qui est technique. Tout ce qui concerne l’infrastructure. Depuis le tout début. La vue à 10 000 pieds de toutes les pièces et pièces. Si je ne suis pas celui qui fait le travail d’infrastructure, j’ai besoin de savoir comment il est mis en place et où se situera le chevauchement entre l’équipe d’infrastructure et l’architecte.

SA3 : Souvent, les AS ne sont pas suffisamment impliqués dans les interactions avec les clients. Il est important que nous soyons investis dans le projet et cela signifie également dans les interactions avec le client. Il est important d’être conscient de la perte de temps pour un SA; par exemple, l’état du budget ne serait pas suffisant pour qu’un AS assiste à une réunion, bien qu’il doive être conscient des risques budgétaires généraux si nécessaire. Les réunions comme les stand-ups dépendent de la portée et de l’équipe de développement complète. SA a une bonne opportunité avec une bonne équipe d’avoir des check-ins avec des responsables de développement et des check-ins avec l’équipe complète, pas nécessairement obligés d’assister à des standups quotidiens.

PM : Parlons de l’établissement des bases d’une relation de confiance et de communication entre les chefs de projet. Comment préférez-vous que cela soit configuré lorsque vous vous engagez dans un nouveau projet ?

SA1 : J’ai une configuration de chat avec uniquement les chefs de projet (PM, EM, SA) et incluant également un responsable du développement ou un responsable offshore (selon le cas). C’est un endroit où nous pouvons avoir des discussions de planification d’équipe, où nous pouvons avoir des discussions de plus haut niveau auxquelles l’équipe qui fait le travail au quotidien n’a pas besoin de participer, mais qui les impactera plus tard. Les sujets peuvent être les ressources, les risques, etc. Cette discussion s’est avérée très importante et utile. Pour moi, établir un lien personnel avec tous les membres de l’équipe contribue grandement à la réussite d’un projet (tous les rôles, onshore et offshore). Si vous vous sentez à l’aise de parler aux gens, cela facilite grandement les bonnes ou les mauvaises conversations. Je trouve toutes ces connexions précieuses, il devrait donc appartenir à tous les chefs de projet d’entretenir cette connexion, pas seulement au PM.

PM : Quelles décisions de projet devons-nous confier à un architecte de solutions ?

SA1 : En tant qu’architecte, je prendrais des décisions sur les pipelines, les référentiels, où réside le code. En fin de compte, la plupart des décisions sont collaboratives. Chacun devrait jouer les points forts de son rôle dans le projet. En tant que SA, je ne m’attendrais PAS à prendre des décisions sur des choses comme la structure du backlog board ou quoi que ce soit lié à la mêlée.

SA2 : En tant qu’architecte, je veux comprendre la portée, le but et les objectifs du projet en cours. Mon travail est commentje guiderai donc les décisions sur la manière dont le champ d’application est mis en œuvre.

SA3 : L’équipe de développement doit-elle utiliser docker ? Des décisions techniques comme celle-ci. Les PM doivent être conscients de ces décisions, mais pas les prendre. Il existe de nombreux cas où SA et PM doivent prendre des décisions ensemble, comme où le temps des ressources doit être dépensé et quand.

Merci aux architectes de solutions qui ont pris le temps de s’asseoir et de discuter avec moi de ce sujet. En tant que chefs de projet, nous avons la possibilité de vraiment profiter de l’expertise des membres de nos équipes. Prendre le temps de comprendre sur qui compter pour ce qui n’est que la première étape. Nous devons également établir la confiance, la relation de travail et les attentes tôt et vérifier souvent. Revenez bientôt dans la prochaine partie de la série alors que nous plongeons dans un autre rôle d’une équipe de projet technique.