Quand, dans l'enfance, nous voulons devenir, disons, médecin ou enquêteur, nous connaissons à peine les spécificités de la profession. Des situations similaires se produisent avec les adultes: l'idée d'un travail de rêve en réalité n'a pas grand-chose à voir avec la réalité. Mais comment savoir avec certitude où se cachent les pièges? Une façon est de parler honnêtement au pratiquant! Nous avons invité
Andrei Trubitsyn , qui collabore avec EPAM en tant qu'architecte de solution du Java Competency Center, à démystifier les mythes courants concernant le travail d'un architecte.
Mythe numéro 1. L'architecte de la solution ne s'occupe pas des tâches de gestion de son projet. Son métier, c'est la technologie!
La réalité - en particulier sur les nouveaux projets ou flux - est souvent différente. Au début du projet sur lequel je travaille actuellement, je devais me rendre aux États-Unis, au bureau du client, pour participer à la phase de découverte et de planification. Après cela, je suis arrivé à Kharkov, où deux équipes étaient réunies, qui n'avaient jamais travaillé ensemble auparavant. Dans cette situation
, la combinaison du rôle d'un architecte et d'un analyste commercial était nécessaire: j'ai non seulement suggéré des solutions technologiques, appris à travailler avec des microservices et effectué des revues de code, mais j'ai également découvert et discuté de divers cas d'utilisation et détails fonctionnels avec l'équipe. En collaboration avec un collègue, Eugene Efremov, PM et Scrum-master sur ce projet, nous avons mis en place le processus de travail sur le cadre SAF.
De plus, en raison de l'expérience et de la connaissance directe du client, il m'a été plus facile de prédire la situation à venir, de dire à l'équipe comment communiquer au mieux avec le client, comment répondre aux situations difficiles, quel niveau de détail dans les descriptions serait suffisant (les ingénieurs pèchent parfois cet abus En fait, la tirade que "... le format JSON qui provient d'un service tiers ne commence pas par le caractère attendu, et pour cette raison une sorte d'échec se produit ...", pour personne à qui travaille toute sa vie dans un autre domaine, sera redondant).
De plus, vous devez soutenir l'équipe. Sur mon projet - du fait de l'architecture microservice - des sorties très fréquentes et un rythme de travail dynamique. Nous sommes toujours en forme et beaucoup de gars aiment tellement. Il est d'autant plus important
de remercier les ingénieurs pour leur initiative, pour soutenir le travail, pour inspirer confiance dans les entreprises . Si l'esprit d'équipe et la concentration sur les résultats sont forts, alors après quelques itérations, les personnes qui affichent de bons résultats se démarquent. Je pense que certains d'entre eux pourront devenir architectes dans un an ou deux.
À part les projets où la situation dans l'équipe de direction est si compliquée que
SA est responsable de l'ensemble du processus de distribution des produits.Mythe numéro 2. Un architecte sait tout sur la technologie
Ce n'est pas vrai. L'architecte ne sait pas tout. Mais il doit vraiment s'efforcer d'apprendre plus de technologies et de leurs fonctionnalités que toute autre personne technique sur le projet. Et pourtant - SA doit regarder vers l'avenir, penser aux perspectives. Pas étonnant qu'ils disent que les ingénieurs sont des trains à grande vitesse, et les architectes sont ceux qui ouvrent la voie afin qu'ils ne soient pas coincés dans une sorte de marais.
En général, l'architecte doit constamment s'engager dans une auto-formation.
Ma norme est de passer au moins 10 heures par semaine à étudier des technologies non liées au projet . Pour cela, en particulier, les communautés professionnelles d'architectes de l'entreprise aident. Il y a constamment des discussions sur divers cas et des séances de partage des connaissances.
Mythe numéro 3. SA post fait de vous un expert par défaut
En règle générale, lorsque vous arrivez au poste d'architecte pour un client, le niveau de confiance en vous est légèrement supérieur à zéro (et c'est uniquement parce qu'ils s'attendent à voir un homme souriant en chemise :)).
La tâche principale de SA - puis des équipes - est
de prouver au client qu'il peut nous faire confiance . Et si au début on a l'impression que le client vérifie méticuleusement toutes les étapes et toutes les actions que vous prenez, alors au fil du temps vous aurez l'opportunité de conseiller au client quoi et comment faire. C'est le niveau de confiance accumulé qui a permis à mon compte de projet d'augmenter jusqu'à 200 personnes (dont 70 travaillent à Kharkov). Et nous continuons de grandir!
Dans quelques mois, notre équipe prévoit d'utiliser Kubernetes et Istio comme plate-forme pour les microservices.Je dois donc maintenant approfondir le sujet, étudier toutes les technologies connexes, de sorte que pendant la transition directe, je
fournirai un soutien technique aux équipes et leur transférerai des connaissances rapidement et efficacement. C'est beaucoup plus efficace que de plonger dans un sujet ensemble à partir de zéro.
En même temps, l'
architecte a le droit de faire une erreur et doit être capable de la reconnaître, de la corriger et de passer à autre chose. La communication directe avec les projets pilotes permet de les éviter. Il est nécessaire d'organiser les freins d'équipe et d'envisager la solution de tous les côtés pour trouver des difficultés potentielles avec l'introduction de certaines technologies sur le projet.
Sans équipe, un architecte ne peut mener à bien un projet.
Mythe numéro 4. L'équipe projet écoute toujours l'architecte
Le concept d '
«architecte dans une tour d'ivoire» - c'est-à-dire, un SA qui se trouve quelque part en hauteur, fait quelque chose qui lui est propre, et les ingénieurs à cette époque sont en réelle distribution - n'est pas né de zéro.
Un architecte de ce type n'aide pas le projet, son équipe n'a pas besoin de son aide.Pour que SA ne soit pas perçu comme une autre personne qui est arrivée au commandement, il est important de ne pas être un connaisseur, mais d'observer ce que les collègues font sur le projet et d'aider. Pour aider non seulement avec des conseils, mais aussi avec des «mains»: écrire du code, si nécessaire, partager des expériences, découvrir des détails et des détails afin d'être maximisé dans le contexte du développement direct.
Petit à petit, lorsque les équipes voient que les actions de l'architecte sont bénéfiques, elles commencent à lui faire vraiment confiance. L'interaction devient alors aussi fluide que possible et permet au fil du temps de passer à un niveau d'abstraction plus élevé, de déléguer des tâches architecturales à des responsables techniques.
En général, un
architecte n'a pas à prendre absolument toutes les décisions seul . En effet, sur un grand projet, il n'est pas immergé dans absolument tous les aspects de l'application d'une technologie particulière. Ce n'est qu'après une discussion détaillée avec des personnes clés sur le projet qu'une étape décisive peut être franchie.
Mythe numéro 5. Un architecte n'a pas de travail de routine ennuyeux
Il y a une opinion que les architectes font toujours quelque chose de nouveau, sont impliqués dans des activités de R&D sans fin, travaillant avec des technologies de pointe. Mais non.
L’essentiel du travail de l’architecte consiste à documenter la conception et les décisions architecturales utilisées sur le projet. Certains peuvent trouver cela ennuyeux. Par conséquent, les architectes sont des gens qui trouvent dans ce quelque chose de fascinant pour eux-mêmes.
Par exemple, cela me donne beaucoup de plaisir de dessiner des diagrammes et de les transformer de complexes et complexes à très beaux, simples, avec des connexions égales et claires. La plus grande récompense est lorsque le responsable voit ce diagramme et dit que tout est simple et très clairement démontré dedans.
De temps en temps, l'architecte participe à des conversations «ennuyeuses», où il est nécessaire de transmettre certains détails de la mise en œuvre au client et de montrer pourquoi il est nécessaire de le faire et non autrement. Cela peut se transformer en longs fils de correspondance, mais je suis intéressé par cette activité. Quand je comprends que j'ai pu prouver le choix optimal de notre solution et que cela a généré un profit pour le client, je l'apprécie.
Quoi qu'il en soit, l'
architecte de la
solution est un travail intéressant . Même une vocation. Il vous permet de vous immerger dans la technologie et de ne pas vous isoler en même temps; partir en voyage d'affaires et communiquer avec les clients; pour développer une communauté d'ingénieurs talentueux et pomper leurs propres compétences.
Demandez à un ami de l'architecte s'il regrette son choix de carrière. Je parie qu'il dit non? ;)
Entretien et texte préparés par Ksenia Bai, experte en communication à EPAM Ukraine.