Quando na infância queremos nos tornar, digamos, um médico ou um investigador, mal conhecemos as especificidades da profissão. Situações semelhantes acontecem com os adultos: a idéia de um emprego dos sonhos na realidade tem pouco a ver com a realidade. Mas como descobrir com certeza onde estão escondidas as armadilhas? Uma maneira é conversar com o praticante honestamente! Convidamos
Andrei Trubitsyn , que colabora com o EPAM como arquiteto de soluções do Java Competency Center, para desmascarar mitos comuns sobre o trabalho de um arquiteto.
Mito número 1. O arquiteto da solução não lida com tarefas gerenciais em seu projeto. O negócio dele é tecnologia!
A realidade - especialmente em novos projetos ou fluxos - é frequentemente diferente. No início do projeto em que estou trabalhando, tive que ir aos Estados Unidos, ao escritório do cliente, para participar da fase de descoberta e da sessão de planejamento. Depois disso, cheguei a Kharkov, onde foram montadas duas equipes, que nunca haviam trabalhado juntas. Nessa situação
, era necessária a combinação do papel de arquiteto e analista de negócios: não apenas sugeri soluções tecnológicas, ensinei a trabalhar com microsserviços e fiz revisões de código, mas também descobri e discuti vários casos de uso e detalhes funcionais com a equipe. Juntamente com um colega, Eugene Efremov, PM e Scrum-master neste projeto, montamos o processo de trabalho na estrutura da SAF.
Além disso, devido à minha experiência e conhecimento direto com o cliente, era mais fácil prever a situação à frente, dizer à equipe a melhor forma de me comunicar com o cliente, como responder a situações difíceis, que nível de detalhe nas descrições seria suficiente (os engenheiros às vezes pecam por abusar sutilezas tecnológicas. De fato, o discurso de que "... o formato JSON que vem de um serviço de terceiros não começa com o caractere esperado e, por esse motivo, ocorre algum tipo de falha ...", por pessoa para quem trabalha toda a sua vida em outra área, será redundante).
Além disso, você precisa apoiar a equipe. No meu projeto - devido à arquitetura do microsserviço - lançamentos muito frequentes e um ritmo dinâmico de trabalho. Estamos sempre em boa forma e muitos caras gostam tanto. É ainda mais importante
agradecer aos engenheiros por sua iniciativa, apoiar o trabalho e inspirar confiança nas empresas . Se o espírito de equipe e o foco nos resultados forem fortes, depois de algumas iterações, as pessoas que apresentam bons resultados se destacam. Eu acho que alguns deles poderão se tornar arquitetos em um ano ou dois.
Além de projetos em que a situação na equipe de gerenciamento é tão complicada que a
SA é responsável por todo o processo de distribuição do produto.Mito número 2. Um arquiteto sabe tudo sobre tecnologia
Isto não é verdade. O arquiteto não sabe tudo. Mas ele realmente precisa se esforçar para aprender mais tecnologias e seus recursos do que qualquer outra pessoa técnica do projeto. E, no entanto - a SA deve olhar para o futuro, pensar nas perspectivas. Não é de admirar que digam que os engenheiros são trens de alta velocidade, e os arquitetos são os que abrem o caminho para que não fiquem presos em algum tipo de pântano.
Em geral, o arquiteto deve se envolver constantemente em autotreinamento.
Minha norma é passar pelo menos 10 horas por semana estudando tecnologias não relacionadas a projetos . Nisto, em particular, as comunidades profissionais de arquitetos da empresa ajudam. Há discussões constantemente realizadas sobre vários casos e sessões de compartilhamento de conhecimento.
Mito número 3. A postagem da SA faz de você um especialista por padrão
Como regra, quando você assume o papel de arquiteto de um cliente, o nível de confiança em você é um pouco maior que zero (e isso ocorre apenas porque eles esperam ver um homem sorridente de camisa :)).
A principal tarefa da SA - e posteriormente das equipes - é
provar ao cliente que ele pode confiar em nós . E se a princípio parecer que o cliente verifica meticulosamente todas as etapas e todas as ações que você executa, com o tempo, você terá a oportunidade de aconselhar o cliente sobre o que e como fazer. É o nível acumulado de confiança que permitiu que minha conta do projeto crescesse até 200 pessoas (70 das quais trabalham em Kharkov). E continuamos a crescer!
Em alguns meses, nossa equipe planeja usar o Kubernetes e o Istio como uma plataforma para microsserviços, então agora eu preciso me aprofundar no tópico, estudar todas as tecnologias relacionadas, para que durante a transição direta
forneça suporte técnico para as equipes e transfira conhecimento de forma rápida e eficiente
para elas . Isso é muito mais eficaz do que mergulhar em um tópico juntos do zero.
Ao mesmo tempo, o
arquiteto tem o direito de cometer um erro e deve ser capaz de reconhecê-lo, corrigi-lo e seguir em frente. A comunicação direta com os principais projetos ajuda a evitá-los. É necessário organizar os freios da equipe e considerar a solução de todos os lados para encontrar possíveis dificuldades com a introdução de determinadas tecnologias no projeto.
Sem uma equipe, um arquiteto não pode liderar um projeto para o sucesso.
Mito número 4. A equipe do projeto sempre ouve o arquiteto
O conceito de
"arquiteto em uma torre de marfim" - isto é, uma SA que fica em algum lugar alto, faz algo próprio e os engenheiros da época estão em distribuição real - não surgiu do zero.
Um arquiteto desse tipo não ajuda o projeto, sua equipe não precisa da ajuda dele.Para que o SA não seja percebido como outra pessoa que veio ao comando, é importante não ser um "sabe tudo", mas observar o que os colegas estão fazendo no projeto e ajudar. Para ajudar não apenas com conselhos, mas também com “mãos”: escreva código, quando necessário, compartilhe experiência, descubra detalhes e detalhes para ser maximizado no contexto do desenvolvimento direto.
Gradualmente, quando as equipes vêem que as ações do arquiteto são benéficas, elas começam a confiar verdadeiramente nele. Em seguida, a interação se torna o mais suave possível e permite que, com o tempo, passe para um nível mais alto de abstração, delegando tarefas de arquitetura a leads técnicos.
Em geral, um
arquiteto não precisa tomar absolutamente todas as decisões sozinho . De fato, em um grande projeto, ele não está imerso em absolutamente todos os aspectos da aplicação de uma determinada tecnologia. Somente após uma discussão detalhada com as pessoas-chave do projeto, é possível dar um passo decisivo.
Mito número 5. Um arquiteto não tem trabalho rotineiro e chato
Há uma opinião de que os arquitetos estão sempre fazendo algo novo, estão envolvidos em inúmeras atividades de P&D, trabalhando com tecnologias de ponta. Mas não.
A parte principal do trabalho do arquiteto é documentar as decisões de design e arquitetura que são usadas no projeto. Alguns podem achar isso chato. Portanto, arquitetos são pessoas que encontram nisso algo fascinante para si.
Por exemplo, me dá muito prazer desenhar diagramas e transformá-los de intrincados e complexos em muito bonitos, simples, com conexões uniformes e claras. A maior recompensa é quando o líder vê esse diagrama e diz que tudo é simples e muito claramente demonstrado nele.
De tempos em tempos, o arquiteto participa de conversas “chatas”, onde é necessário transmitir alguns detalhes da implementação ao cliente e mostrar por que é necessário fazer isso e não o contrário. Isso pode se transformar em longas linhas de correspondência, mas estou interessado nessa atividade. Quando entendo que fui capaz de provar a escolha ideal de nossa solução e isso resultou em lucro para o cliente, eu gostei.
Seja como for, o
arquiteto da
solução é um trabalho interessante . Até uma vocação. Permite que você mergulhe na tecnologia e não entre em isolamento ao mesmo tempo; faça viagens de negócios e se comunique com os clientes; desenvolver uma comunidade de engenheiros talentosos e desenvolver suas próprias competências.
Pergunte a um amigo do arquiteto se ele lamenta sua escolha de carreira. Aposto que ele diz que não? ;)
Entrevista e texto preparado por Ksenia Bai, especialista em comunicação da EPAM Ucrânia.