Olá tudo bem Aqui é Fernando dezimiecom eu tô aqui com meu amigo Gabriel coaching arquiteto e consultor na eximia tudo bom Gabriel tudo bom Fernanda E aí pessoal bom dia boa tarde boa noite para todos que nos ouvem nessa aqui tarde ensolarada no Rio Grande do Sul Gabriel o seguinte a gente na última conversa com elemar falando sobre liderança técnica a gente falou sobre o modelo de competências para tecidos conjunto de habilidades de comportamentos de atitudes que se espera por um técnico de alta performance dentro dessas habilidades a gente falou bastante sobre as hards quais
competências técnicas mesmo aquelas que a gente consegue demonstrar melhor às vezes até comprovar através de diploma formação essas rádios que a gente falou bastante sobre quais são essas Artes que os necessários e uma delas é a Skill de arquitetura e uma das dúvidas que sempre se levanta é o technid precisa ser um arquiteto eu queria começar essa conversa e te fazendo essa pergunta na sua visão um técnico de pesquisa assim um arquiteto não poderia ser promoções a gente começar mas vamos lá é como sempre Depende mas na minha opinião eu acho que conhecer algumas práticas
de arquitetura é muito bom para crise eu acho que eleva o nível de quem tá exercendo esse papel com excelência a precisa ser um arquiteto realmente arquiteto talvez não Mas algumas práticas é importante principalmente se a gente começa a olhar mais a fundo o que que é o papel do arquiteto né Porque talvez os dois papéis eles acabam tendo coisas que vão se sobrepor em algumas atividades na nossa visão exímia de arquiteto né papel do arquiteto a gente sempre comenta que o arquiteto na maior parte das vezes ele tem uma visão mais de amplitude aonde
que ele tá orquestrando as coisas dentro do time fazendo que as coisas fazendo com que as decisões sejam tomadas e não tomando as decisões necessariamente então eu vejo que coincide muito com que algum técnico acaba fazendo também claro que tem uma diferença que um tec-lídio um bom técnico acaba tomando algumas decisões Para justamente direcionar o time mas muitas vezes também acaba conduzindo orquestrando coisas para o time fazer o seu trabalho com excelência né e decisões do dia a dia claro não envolvem arquitetura mas daqui a pouco tem funcionalidades tem coisas no dia que acabam impactando
em decisões arquiteturais acabam impactando em atributos de qualidade e por que não se um técnico de conhecer algumas práticas consegue auxiliar inclusive vamos lá em empresas menores em companhias menores aonde que não existe um papel formal do arquiteto sim porque não o tecnid não não apoiaram um pouco algumas práticas arquiteturais o Gabriel uma coisa que eu acho que a gente pode dizer que eu acredito que você concorda também é o seguinte primeiro é ele pode ser um arquiteto Ou seja pode ser um Tech Lead que o background dele já vem forte de arquitetura é até
razoavelmente como um às vezes um tecnico pela ceneuridade dele técnica ele tem um background de arquitetura também bom mas não necessariamente ele vai ser o arquiteto do time né E aí você colocou um ponto que eu acho que é bem interessante é o seguinte ele não necessariamente precisa tomar decisões tomar decisão de arquitetura ele por si só mas você precisa garantir que ela seja tomada que pode ser ele mesmo pela experiência competência dependendo se não tem outra pessoa no time se ele tem um arquiteto que apoia ele não seja no time de reforma do time
ele pode ser o cara que conduz para que a decisão seja tomada seja bem justificada e que está endereçando os objetivos que ele tem dentro do time né Faz Sentido para você faço todo sentido e Inclusive eu acho que tem uma outra vertente que eu tenho visto mais recorrente no nos últimos meses do último ano que é eventualmente o técnico de levantar a mão Quando surge algo que possa impactar em questões de arquitetura porque nem sempre mundo real né Fernando nem sempre as decisões passam por um fluxo por um processo de engenharia adequado onde que
realmente temos um arquiteto que tá pensando em trade Office daquela decisão para tomar decisão da forma correta justificar documentar e assim por diante dia a dia decisões vão sendo tomadas talvez até de forma mais rápida do que a gente do que a gente pensa então porque não não de dentro do seu papel olhando o time como um todo consiga levantar a mão para arquitetura dizendo Opa para porque isso aqui pode impactar arquitetura de uma forma digamos assim gerar uma erosão arquitetural dentro do sistema sim então se existe esse conhecimento Eu acho que isso é uma
vantagem importante novamente times aonde que daqui a pouco empresas pequenas que realmente não tem um arquiteto dedicado não tem hora dedicado não é dedicado mas no arquiteto Full Time exercendo o papel de time dentro da empresa né Gabriel teve uma experiência que eu tive bem interessante que foi o seguinte criou-se uma estrutura onde tinha um arquiteto separado e aí a cultura era Ah se precisarem de ajuda eles falam com arquiteto Só que tem um ponto né que são os desconhecidos desconhecidos né que é aqueles aquelas coisas que você nem sabe que você precisava né é
interessante o técnico de ter um conhecimento de arquitetura porque ele precisa às vezes não ser especialista para poder dar solução final mas ele precisa ter conhecimento suficiente para perceber o que você chamou de erosão natural né perceber que olha aquilo vai cobrar um preço logo ali na frente se eu não tomar certas decisões exatamente endereçar o problema de forma correta né porque fica muito Daí a gente vai entrar entra numa num debate grande que é o que é arquitetura como que um desenvolvedor no dia a dia que tá desenvolvendo Toma decisões no seu dia a
dia sabe que eventualmente uma decisão é relacionada a arquitetura não é arquitetura Qual o impacto com a grandeza é difícil é um é uma coisa que não não é muito claro para os times e dependendo do contexto ainda pode ficar mais nervoso ainda então se nós temos um técnico que tem essas competências eu tenho eu acredito que sim ele vai conseguir endereçar melhor esse tipo de situação inclusive aí é uma hipótese porque a gente acaba tendo tanta se fala tanto em dívida técnica sabe no meu ver é justamente essas decisões que são tomadas no dia
a dia não por uma fé né Por mãe mas porque poxa essa decisão ela era uma decisão arquitetural que teria um trade Offices importantes a ser considerados e ela foi tomada como sendo exatamente uma decisão do dia a dia que não se sabe o impacto de futuro ah mas eu gerei dívida até e novamente né dívida técnica que tenha uma conversa com arquitetura não é aquela Dívida técnica o meu código poderia ser um pouco melhor escrito Ah eu poderia trocar o if por Não não é essa dívida dívida que realmente está pagando cobrando juros no
futuro no período de tempo e Gabriel correndo risco de ser simplista em tentar dar uma resposta dentro de uma tal que nem mais para também não ficar sem resposta acho que uma recomenda que a gente pode dar qualquer tipo de conhecimento em arquitetura um tecnico precisa ter eu acho que esse material que a gente costuma usar bastante quando a gente está falando em arquitetura para os nossos clientes que é como a gente percebe a arquitetura né ele ajuda a ilustrar coisas importantes que tem que estar na cabeça do technicid obviamente do arquiteto também né entender
que arquitetura ela é composta por duas vertentes né uma estrutural onde se reflete os componentes as responsabilidades de cada componente o relacionamento entre eles e uma outra de estratégia e na estratégia a gente tem um ponto que tem que ter uma atenção especial do tecnide que ele precisa conseguir ter isso aqui na cabeça dele bem definido não precisa ser ele a trazer as respostas igual a gente falou na verdade ele pode contar com apoio do time dele o time dele mais sénior o próprio os arquitetos da companhia mas ele tem essa visão estratégica que são
aquelas integrações ou seja tá claro para mim onde eu vou precisar integrar como que tipo de protocolo o que que eu vou usar a gente né Gabriel vê na prática como que muito ecossistema de aplicações de gringola na hora de integrar né é alguém que fica lento e que deixa na mão Pode falar não é o cenário que normalmente é deixado de lado integrações é visto eu não tenho integrações não ela soubesse não tem integrações tu não conversa com outros sistemas ou com Outras aplicações empresas maiores moda squads Ou micro serviços digamos assim integração como
e tudo isso falou Qual que é o protocolo eu tenho eu tenho retentativa tenho que ter tentativa é simples enfim tem n questões que impactam em cima disso exatamente na sequência que que são restrições que são aquelas restrições que o seu projeto precisa respeitar né então a gente já viu na prática por exemplo adotasse um modelo distribuído de aplicação depois descobri que tinha uma restrição para adotar determinado broker de mensageria E aí começou a adotar estratégias de alta acoplamento compartilhando o banco de dados porque tinha uma restrição que não foi uma piada né isso caso
real que a gente vivenciou também então declara essas restrições né ultimamente também eu tenho aí é discutível mas eu tenho eu tenho visto que em muitos casos tá se fala mas não se deixa explícito restrições a nível de custo sim verdade a gente pode falar em nuvem né exatamente a gente pode ver por dois por dois duas formas a gente pode ver que pode ser eu às vezes Trato como atributo de qualidade que a gente fala um pouco mais à frente que pode ser o seguinte Ah não para cada mil usuários para cada sem usuários
da minha aplicação eu permito que a minha infraestrutura cresça tanto para não ter um crescimento descontrolado de infraestrutura ou como restrição Olha o meu Band ou o que eu posso que podemos gastar com infraestrutura ou com licenciamento ou concurso social total da solução é tanto e isso no dia a dia não só para arquiteto E aí a gente cai de novo para o técnico decisões do dia a dia Daqui a pouco tem uma decisão do dia a dia que está impactando diretamente nisso né Exatamente exatamente isso direciona decisões por exemplo vou utilizar uma solução mais
simples SAS que já tá dentro da nuvem ou por exemplo vou colocar algo bem sócio que não tem curso de licenciamento mesmo que eventualmente demora um pouco mais e isso a restrição pode nortear decisões arquiteturais muito relevantes né exato exatamente decisões assim ó vamos tentar trazer para o dia a dia tipo o time de engenharia decide usar uma biblioteca um framer que qualquer será que esse framer que está adequado dentro das restrições que a gente tem da companhia exatamente eventualmente pode ter alguma restrição que diga Olha esse essa biblioteca esse framer que não não rola
exatamente nas sequência né Gabriel a gente fala sobre os atributos de qualidade né é aqui Gabriel você tem você tem uma visão sobre sobre os três doses de vários atributos de qualidade que é bem interessante né Se quiser compartilhar eu acho que é bem legal porque mostra um aspecto que o técnico precisa orquestrar junto com arquiteto e junto com o time dele né consegue trocar aí Fernanda consigo puxar ali aí o que que a gente tem que imaginar sempre vamos lá primeiro atributos de qualidade O que que a gente tá falando é performance segurança disponibilidade
escalabilidade confiabilidade todos os essas essas trocas Mas o importante é que dependendo do contexto dependendo do sistema alguns atributos de qualidade são mais importantes que outros então não que todos os sistemas vão ter todos os atributos de qualidade com a sua mesma importância mesma relevância então pode ser que para um sistema a gente dê prioridade para performance outro sistema eu preciso mais segurança e sempre quando a gente acaba priorizando um outro a gente tem três de ossos nisso aqui porque o que que vai acontecer se para uma empresa segurança é mais importante como atributo de
qualidade no sistema quer dizer o quê que eu não posso por exemplo focar em disponibilidade aumentando o número de componentes que eu tenho no meu sistema porque eu tô aumentando minha superfície de ataque então normalmente os atributos de qualidade e exatamente então eu dar valor para performance e eventualmente eu posso estar pensando que disponibilidade não vai ser o atributo principal na hora que você coloca mais segurança o sistema fica mais chato de usar o cara tem que ter uma senha maior Então se sacrifica os habilidade para aumentar a segurança né dependendo do tipo de aplicação
Talvez ele é mais sensível a usabilidade do que segurança exatamente Então é isso claro é importante ter isso muito bem explícito para o time e para o Tech lide é importante porque Ah mas eu nasci no sistema não preciso mais me preocupar não precisa porque com o passar do tempo funcionalidades vão ser introduzidas E essas funcionalidades elas podem impactar nesses atributos de qualidade quantas vezes que uma introdução de uma funcionalidade nova deixou o desempenho gerou uma erosão arquitetural em termos de desempenho na aplicação seja por uma consulta Não também escrita ou por um código que
eventualmente tem algum algum bug ou simplesmente porque da gente tá fazendo algum processamento introduziu alguma complexidade que aquele objetivo de performance que era prioridade não é mais verdade nesse tempo e Aí surge uma dívida técnica para ser paga em algum momento do tempo e aqui tem um papel também importante do technic Gabriel que é o seguinte se a gente foi ingênuo e não tiver habilidade de comunicação certa a gente chega para o negócio e pergunta assim qual indisponível tem que ser o sistema aí ele fala 100% importar ele nunca isso provavelmente não te responde nada
se você perguntar fala assim quanto de segurança você precisa ele vai falar assim ele precisa ser e hackear ele precisa ser perfeito do ponto de segurança Essas são as respostas para nós se você não conseguir modular essas perguntas para extrair o que você realmente quer por exemplo um disponibilidade você poderia perguntar no lugar e falar assim cara quanto tempo é o máximo que você entende que a gente poderia ficar fora do ar se a gente quebrar se a primeira pergunta que fala assim cara você quebrar você traz um extremo que aí você consegue falar assim
pô tá cara se eu ficar um dia inteiro fora do ar Cara cara eu vou perder tantos milhões de vendas e tal aí você começa a extrair informações do negócio que são relevantes quanto tempo eu posso ficar fora para corrigir esse depor errado Exatamente exatamente Quanto custa ficar fora o outro uma outra perspectiva de disponibilidade que a gente não é tão comum ver para o negócio talvez não é não é tão binário o negócio Ah não zero Ah não eu estou no ar não estou no ar mas por exemplo talvez por um negócio eu responder
tal requisição ou tal processo de negócio acima de tanto tempo é como se o sistema tivesse disponível então por exemplo Ah eu tenho que responder 90% ou 98% das minhas requisições de taling de point ou de tal área de negócio de tal processo de negócio abaixo de sei lá dois segundos se eu responder acima de dois segundos quer dizer que para o negócio nós estamos indisponíveis exatamente E aí as coisas começam a ficar a trazer um pouco mais de sentido para inclusive que nem tu comentaste para comunicação Como que tu vai comunicar isso para o
time que a gente coloca a disponibilidade ou escalabilidade e esse é um grande um grande inimigo né o Gabriel a gente subestimar a necessidade de fazer isso de maneira mais formal a gente com agilidade pregou-se muita ideia de que documentação não serve para nada né tipo documentação não é nada e tal e na verdade é se fazia um uso muito indiscriminado de documentação que às vezes não servia para nada gerava curso sem gerar valor mas o outro extremo de Não documentar na verdade são dois aspectos é o exercício da documentação que é o processo de
modelar aquela solução formalmente que se você não coloca no papel no PowerPoint se acaba não fazendo e o segundo é aquilo que precisa de fato ficar imobilizado ali que servir de referência para auxiliar a comunicação com o time aqui eu acho que tem um ótimo exemplo porque assim a gente já pegou em números projetos que o grande defeito dele foi ele ser construído como se fosse um blog para acessar mil pessoas mas na verdade ele precisa cortar 60 mil e aí quando você vai ver a aplicação ela funciona funciona só que ela bate no teto
dela muito rápido porque porque não foi planejado os requisitos não funcionais aqui os atributos de qualidade não foram pensados nisso e é muito fácil mesmo pessoas sênio subestimar que já sabe mas na hora que ele coloca aqui primeiro tem primeiro exercício de colocar aqui ele vai fazer ele refletir o segundo vai fazer ele gerar consenso que é na hora que ele chegar para o negócio e falar assim cara assim atende vocês então por exemplo a gente trabalhou e você inclusive a gente trabalhou num cliente que tinha um grave problema de disponibilidade e uma das coisas
que eles estavam fazendo é fazer toda a aplicação construindo ela na tecnologia nova a gente a gente vai fazer uma reunião e falou assim cara então como a gente sabe que essa aplicação performance que a outra na prática é está mapeado atributo de qualidade performance como ele deve se comportar ao longo do tempo né falando um pouco mais técnicamente e a resposta foi um belo de um silêncio da reunião e que ah a gente está fazendo ele em outnetcore sabe tipo cara isso não garante nada né E aí Pensa como que pode ser subestimado E
aí entra o papel obviamente do arquiteto mas o Tec ID de olhar para isso e ver se os objetivos de negócio estão sendo atingidos e provocar o time técnico dele para garantir que essas coisas estão acontecendo que os traidófilos estão sendo adequadamente posicionado Exatamente porque o no dia a dia OK às vezes a gente acaba pintando o mundo tão bonito e abstrato que tenha documentação tem tem n artefatos que seriam lindos de temas no dia a dia às vezes isso passa e esse é o problema porque daqui a pouco tem um desenvolvedor no meio do
time que no olhar dele Poxa eu vou fazer um serviço novo ou eu vou pegar aquele legado que tá lá escrito uma linguagem vou escrever numa Linguagem Nova que vai ser muito melhor mas será que vai ser muito melhor na perspectiva de negócio na perspectiva de estratégia Esse é o ponto não é só porque a gente está escrevendo novo ou usando tecnologia nova que vai ser melhor é verdade e aí comentasse de documentação eu acho que aí é o ponto pelo menos assim no olhar de teclad que eu vejo alguns artefatos algumas práticas que encaixam
para o técnico de pensar eu deixei tu consegue compartilhar o outro slide ali que eu acho que essas três pensasse Até que a gente conseguir pensar isso aqui a nível de arquitetura tá não é pensar definir mas se ele conseguir entender e comunicar muitas coisas começam a ficar mais fáceis no dia a dia do time evidenciar lembrando documentação é comunicação eu não vou documentar para deixar engavetado na gaveta e só por dizer que a gente documentou não documentação tem que ser útil e normalmente documentação é uma ferramenta para comunicação Então ela tem que ser utilizada
para comunicação tem que ser e comunicação é repetição se a gente não continuar repetindo a gente não tá comunicando o que desejamos então tem dúvida sempre que eu tenho dúvida Gabriel Sua documentação é útil eu provoco o pessoal fala assim quem vai usar e quando ele vai usar tem que estar previsto no processo que é o momento e tem que estar previsto quem usa senão Provavelmente tem chance de ser uma documentação que fica na gasolina exatamente e aqui essas três coisas eu acho que a gente pode usar como artefatos como centro de utilidades do Batman
para conseguir em reuniões alinhamento buscar esse tipo de ação ou seja pessoal a gente continua entregando essa estratégia que foi definida Lembrando que a estratégia restrições integrações atributos de qualidade objetivos de negócio pessoal essa aqui é a nossa estrutura atual é nosso modelagem atual com as nossas propriedades ainda é válido tá todo mundo ainda na mesma página tá ok e o mais importante todas as decisões que a gente está tomando tem a gente está registrando o porquê da decisão não é a decisão mas é o porquê da decisão porque porque decidimos colocar um fazer essa
integração entre esses dois componentes assim porque não é o que o porquê Qual que é o trade dessa decisão tá claro para todo mundo para que o nosso eu do Futuro um dia vem dizer uma porque raios vocês fizeram isso aqui assim para no seu negócio exigia que fosse assim exatamente então Exatamente exatamente E aí a gente pode ter algumas algumas coisas por exemplo que é o próprio haicai é um artefato que eventualmente o tecnid consegue trabalhar de forma bem interessante sim seja ele fazendo ou solicitando ao time dele para que seja feito exatamente e
refletir e explicitar muitas vezes tem que ser dito a gente tem que falar e deixar explícito algumas coisas então um breve um breve repositório do projeto já consegue buscar alinhamento com time já consegue trazer o time para a mesma página para que a gente consiga tomar as decisões de forma mais coerente e nisso um outro ponto que eu acho interessante também é como que o teclad pode se comportar usando documentação arquitetural em todas as fases de liderança porque vamos lá se a gente está numa fase com o time onde que a gente está o técnico
está direcionando mais o time ele tem que ter mais firmeza no que está sendo feito a documentação ou seja conhecer um pouco mais de arquitetura e ter fatos de arquitetura mais explícitos vai trazer muito mais clareza para o time do que tem que ser feito sai daquela zona do não mas era só para fazer isso não não aqui tá um pouco mais detalhado momento que o time começa a trabalhar e ter mais subir um pouco mais autonomia e o técnico ele começa a ter um comportamento mais de Coaching O que que a gente consegue utilizar
Olha eu utilizo esses Artefatos de documentação para receber em sites do time Poxa eu tô aí estamos estamos compartilhando estamos trocando ideia momento que eu tô suportando eu tô aí o teclinge tá o time tá muito maduro tá praticamente andando sozinho eu só tenho que eventualmente dar uma visão ou dizer o que que eu tô pensando eu posso usar esses adefatos para simplificar e por fim quando eu tô simplesmente delegando como é que tu vai e aí a diferença de delegar e de largar né não se eu vou delegar como que eu vou propagar os
resultados que eu espero atingir o que que é resultado exato e esse esse conceito esse conceito de liderança situacional que você traz né Gabriel ele é interessante também para nortear atuação do líder técnico sobre o quão a parte técnica dele precisa adentrar em intervir no time né intervir demais com time muito experiente que já está no nível de delegação gera frustração é aquele cara que fica querendo te ensinar como você tem que fazer o seu trabalho sendo que você já sabe fazer Talvez até melhor que ele né então a gente não pode correr o risco
de ser esse Líder ao mesmo tempo no outro extremo quando se trata no nível de direção você não pode pegar e querer delegar para alguém que não tem condição e não tem nem informação ainda às vezes não é só questão de ser realidade mas alguém acabou de chegar na empresa ele precisa de direcionamento Então você precisa estar mais próximo e intervir um pouco mais né isso quando a gente fala de documentação é bem interessante para a gente saber como a gente usa a documentação com o time e o conceito de liderança situacional de maneira geral
também é super interessante para liderança técnica exatamente e todos eu vejo que todos eles o fato de arquitetura conhecer a arquitetura auxilia Para justamente ou eu tô direcionando e eu tenho que ter o líder técnico quando tá direcionando ele tem que ter um controle entre aspas ele precisa dar mais clareza inclusive sobre coisas de arquitetura para que a construção desse sistema não seja olha na planta tava lindo mas na hora de construir não erramos a planta é justamente para evitar esse tipo de coisa é verdade é verdade e na sequência Gabriel dos atributos de qualidade
Talvez o mais importante é ter clareza Se os seus objetivos de negócio estão sendo atingidos né então isso implica em conhecer os objetivos de negócio e implica em conseguir conectar esses objetivos de negócio as decisões técnicas que estão sendo tomadas né Uma das coisas que o líder técnico geralmente tem mais facilidade dentro de mim para fazer que os outros integrantes é essa comunicação com o negócio conseguir perceber e extraído negócio de maneira mais clara onde se quer chegar e fazer essa ponte junto com o time técnico para garantir que tudo está sendo endereçado né perfeitamente
então e a dica que eu deixaria o seguinte principalmente atributos de qualidade de objetivos de negócio se a gente conseguir quantificar eles melhor quantificar no sentido se a gente está trabalhando no sistema pegar uma fintech por exemplo que a gente trabalha como Gate de pagamento objetivo de negócio transacionar pagamentos com cartão de crédito por exemplo Ok Esse é o meu objetivo de negócio tá Mas qual que é a expectativa do negócio quantas transações em quanto tempo quando você espera crescer os nossos três anos exatamente qual que é isso muda muda muito a forma de pensar
e como tomar essas decisões no sistema no dia a dia que vão a gente sabe que Poxa eu tô transacionando totalmente livre Quais são as partes críticas do sistema e traz aquela coisa comprometimento do time para que aquilo para que atinge os objetivos de negócio mesmo vamos dar os exemplos práticos Gabriel de que a gente vê por exemplo se performance é um atributo de qualidade crítico que tá mapeado se a gente ao definir esse atributo como crítico a gente copiou e falou assim olha eu tenho expectativa de ter 10 mil usuários online ao mesmo tempo
e a minha expectativa que a cada seis meses esse número por exemplo dobre então eu vou ter 20 mil daqui seis meses e tal dado a criticidade disso vou dar um outro exemplo ainda mais mais real esse esse primeiro a gente venceu agora um segundo que a gente não vivenciou eu tô fazendo uma aplicação que vai funcionar como título de eleitor Quantas pessoas tem que ter online qual dia Quantos eleitores existem no Brasil que você imagina que vai usar uma solução online no dia da eleição nem um outro dia que foi projetado para funcionar naquele
dia então ah mas o pessoal vai se planejar e baixar não vai acontecer isso vocês vão baixar no dia provavelmente na hora de votar então eu já tenho um planejamento significa que no processo de desenvolvimento teste de carga vai ser o imperativo estratégico daquele time quando tiver fazendo Deploy no ambiente de homologação dele ele já precisa estar fazendo teste de carga porque esse atributo de qualidade é crítico do Sucesso dele se não é implementar um negócio feito com todo o custo tudo que precisava para no dia que precisa funcionar o único tipo precisa funcionar não
funcionar e aí entra teste de carga não vira só um Ah vamos fazer uma vez começa a fazer parte do processo de engenharia como todo porque talvez talvez Claro essas de cargas testes de performance ainda tem custo eles gera custo para companhia mas somente talvez porque a cada deproe não executar um teste de carga para garantir que aquele atributo de qualidade que é o mais importante que é performance continua sendo verdade dentro dos limites dos das roads que foi combinado com o time com o negócio desculpa exato então Gabriel coisas em sites importantes que a
gente acaba construindo aqui né O primeiro é o tec-líder ele precisa trabalhar muito junto ao arquiteto sabe porque muito do Sucesso do time do entregava do time vai ser influenciado pelas decisões de arquitetura essas decisões de arquitetura precisam ser tomadas seja pelo arquiteto ou seja por alguém do time seja pelo próprio técnico tem essa responsabilidade de saber fazer as perguntas certas estimular o time na direção para que essas decisões sejam tomadas consegui fazer as críticas para que elas sejam bem justificadas e eu acho que acima de tudo é o cabeltech Lead a comunicação dessas decisões
arquiteturais isso envolve comunicação com os diferentes takeholders de negócio próprio time sensibilizar o time de que talvez o jeito dele desenvolver pode mudar de acordo com alguma dessas decisões né existe uma zona de sombra Gabriel então do tecnid com arquiteto concorda existe e talvez aí é o perigo para as empresas de confundir os papéis dar peso para mais um papel ou menos o outro e essa e para o técnico de quem está exercendo esse papel conseguir diferenciar quando precisa de um quando precisa de quando precisa ser o papel de arquiteto quando precisa exercer o papel
de teclad exatamente então conhecendo algumas práticas conhecendo um pouco do papel do que que um arquiteto faz eu acredito que vai ajudar muito para saber distinguir quando precisa tirar um chapéu e colocar outro chapéu para trabalhar com time Ah estou trabalhando em minha empresa tem um arquiteto então Vai facilitar comunicação com arquiteto Vai facilitar levantar a mão para te dizendo olha Estamos correndo um risco existe um ponto de atenção o que que a gente corre o risco de gerar erosão eleitoral vamos conversar isso Possivelmente vai gerar uma Dr de decisão de arquitetura dizendo olha precisamos
mudar o sistema tem esse trem de office e vai ser tomado essa decisão sim sim exatamente e essa sensibilidade de o que que vale é para ser construído um ADR né olha essa isso é relevante suficiente para ter um ADR que a Dr alinhando todos arquitector decision recorde que é um documento que consolida algumas decisões arquiteturais importantes daquele time né Gabriel exato exatamente e são coisas às vezes assim a gente pode parecer complexo mas são simples é o meu ver é muito muito mesmo é comunicação sim existem hards que os que de conhecimento mas eu
acho que é melhor são mais fáceis de conseguir eventualmente o técnico não precisa ter todo o conhecimento de arquitetura background de estilos arquiteturais e enfim toda uma bagagem nesse nível mas se conhecer um pouco da prática de arquitetura vai auxiliar muito o dia a dia do time e atingir objetivos de negócio mais rápido para as empresas excelente Gabriel ótimas considerações sobre o que que um tecnico precisa ter de conhecimento em arquitetura Gabriel antes de se trazer considerações finais ali vou fazer como meu amigo ele é um momento blogueirinha aqui né que faz e a gente
concluiu essa conversa beleza pessoal é essa essa é uma série de conversa que a gente está fazendo sobre liderança técnica envolvendo diferentes pessoas diferentes perfis do nosso time aqui se você quer receber sempre a notificação quando tiver uma nova postagem de conversa como essa se inscreve no nosso canal ativa o Sininho para você receber as notificações e não deixe de compartilhar seus feedbacks falar o que que a gente falou de errado aqui para a gente poder corrigir inclusive compartilha sua experiência conosco O que que você tem visto na prática também a gente gosta bastante de
trazer a visão prática do que que a gente vê dentro dos projetos Nada melhor do que o mundo real né e é isso Gabriel suas considerações Deixa aquele like Deixa aquele like esquecido o like se inscreva no canal para receber as notificações que é isso aí você temos temos conteúdo novo toda semana e eu disse o seguinte você quem tá estudando tá se preparando para ser um técnico dê atenção um pouco para essa parte de arquitetura conheça um pouco sobre práticas de arquitetura e lembre-se arquitetura num olhar de orquestração não o arquitetar eu tenho que
dominar Climar que tem que dominar Microsoft tem que dominar padrões não não nesse viésimo assim como que algumas práticas de arquitetura conseguem auxiliar O Dia a Dia do técnico para comunicar melhor para o time dos seus objetivos comunicar para o time que a gente eventualmente decisões podem afetar tributos de qualidade e vão gerar erosão arquitetura ao que por consequência vai ser uma dívida técnica que talvez não esteja nem mapeada e vai cobrar juros isso no futuro e conhecer o negócio conheceu o negócio falando isso da gente falou da estratégia de restrições atributos de qualidade de
objetivos de negócio vai fazer que vocês conheçam um pouco melhor e talvez Tire algumas alguns pesos que a gente vê muito no dia a dia por exemplo estamos construindo ou vamos estamos estrangulando todo um sistema monolito porque a gente precisa estrangular porque já não tá atendendo escala e coisa e tal e todo um esforço gigante E aí começa a quebrar esses atributos de qualidade começa a se fazer as perguntas para o negócio e daí vai se entender que o sistema Tem que atender sei lá 300 requisições por minuto Será que a gente precisa de todo
o movimento técnico gigante para fazer isso então se o técnico tem isso em mãos tem na cabeça com certeza a condução do dia a dia vai ser muito muito mais fácil com o time e perfeito estamos aí sempre para ajudar e vai ser sempre um prazer bater um papo aí com todos aí que estão assistindo muito obrigado Gabriel prazer Um abraço para todo mundo
