quando a gente vai falar de objetivo, você tem que fazer algumas perguntas. Quais são os problemas que a gente quer resolver? Quando a gente está falando de um sistema que já existe, é mais fácil você responder isso, porque você já tem um sistema para olhar para trás. O que esse sistema gerava de problema? Qual era o impacto que estava no dia a dia? Por que estamos mexendo nele? Se a gente está falando assim, cara, eu tenho um sistema no dia a dia, está tudo bem? Ah, mas ele está em uma linguagem velha. Tá bom, qual é o problema que ele traz? Sei lá, a gente vai ter mais mão de obra no mercado para mexer? Pode ser um problema. Ah não, a gente tem um tempo de resposta demorado? É outro problema. O que a gente quer resolver? Se a gente não souber o que a gente quer resolver, a gente vai estar fazendo só por ego. A gente baita de um programador diferenciado e que fez uma coisa bacana. Isso é legal? É, mas sendo bem honesto, não é isso que vende, não é isso que paga a conta. A gente precisa ganhar dinheiro também. Então, todo mundo aí que está trabalhando tem que pensar também como aquilo vai retornar para o seu cliente uma experiência diferenciada. Se não vai retornar isso, cara, se você não vai mudar em nada, se você não vai ter nada. Pensa direitinho. Segundo objetivo, segunda pergunta do objetivo que eu gosto de fazer é onde a gente quer chegar com isso aqui. Porque a gente pode até falar, beleza, eu quero resolver o problema do tempo de resposta, beleza. Vai, ficou 36 milissegundos, bacana, bate palma, beleza. E é onde a gente vai chegar com isso aqui. Eu quero que esse cara seja consumido por quem, eu quero que ele apareça em quais jornadas, o que eu quero chegar no final do dia? No final do dia, aquela minha arquitetura ideal, minha arquitetura futura, vai ser o quê? Eu preciso saber onde eu quero chegar, senão eu vou fazer um desejo de arquitetura e não vou chegar a lugar nenhum. Eu não vou falar porque já é piegas, mas é como dizia lá o Alice no País das Maravilhas, você não sabe onde você quer chegar, qualquer caminho serve. É pegas, mas é real. O que a gente já sabe, tá? Olha para trás, isso é uma coisa que também a gente tem o costume de não fazer. Normalmente a gente, que tem menos tempo ali com aquele sistema, a gente tem o costume de chegar e ser aquele engenheirão de obra pronta. A gente chega e fala, puta, sistema horrível, foi feito há 50 anos atrás, segurou até hoje as contas, pagou tudo, funcionou por 50 anos, e a gente chega e fala, que sistema horrível. Até para a gente pensar aqui, quantos sistemas vocês desenvolveram, quantos sistemas eu desenvolvi que durou 50 anos? Não tem. Acho que o sistema que eu um sistema que durasse 50 anos, a gente tem quatro em palma. Os caras sabiam o que estavam fazendo. Eles fizeram sistemas que foram extremamente complexos e parrudos e que seguraram a bronca por muito tempo. O que essa galera tem para contar para a gente? O que eles passaram? O que eles já sabem que não funciona? O que eles sabem que funciona? É importante perguntarar o que a gente é capaz de inferir sobre o futuro, putz, no futuro vou te dar um exemplo a gente tem pagamento via Pix, será que a gente vai ter pagamento via Bitcoin, será que a gente vai ter pagamento via alguma outra ideia maluca que está por vir o que a gente pode pensar já inferir sobre métodos e meios de pagamento para já deixar mais ou menos pronto. E aqui é uma é uma é uma conversa bem complicada, porque se você for viajar muito, você vai trazer muita complexidade para o sistema. Mas se você não pensar nem um pouquinho no que tem por vir, seu sistema vai virar legado em pouquíssimo tempo. Então é bacana você já pensar mais ou menos o que você consegue inferir no futuro. E para falar sobre isso, nada melhor do que chamar quem manja de negócio do business que você está falando para a mesa. Então, putz, eu vou construir um sistema de marketplace. Pô, traz quem sabe, traz a galera que manja aí. A galera que fala aqui de sistemas de marketplace deve ter várias ideias. Putz, o que tem de diferente? Como é que a gente vai fazer pra falar com parceiros? Como que a gente vai fazer pra fazer uma venda mais rápida? A gente vai ter um tracking de produto diferenciado no futuro? Eu não sei. Vai vender, vai entregar via drone? Às vezes o cara já tem que ir pensando sobre isso pra criar a plataforma dele. Stakeholders. A gente sempre fala stakeholders como uma figura etérea que a gente não sabe quem são é bacana a gente pensar em quem são os principais interessados de verdade quem está comprando com você quem vai ser o cara que vai chegar no final do dia e vai te dar parabéns tem que ter esses caras muito mapeados e eles tem que estar interessados tem tudo o que está acontecendo e você tem que trazer conforto para eles. Porque pensa nisso, é uma galera que está investindo no seu sistema, está pagando para você fazer diferente do que estava sendo feito até agora. Então, meu, mapeie os caras, traz para eles o que está acontecendo, o que está funcionando, o que não está funcionando. Eu também já fali com isso, já teve momentos que eu fiz coisas incríveis, mas não conversei direito, não trouxe direito o que estava acontecendo. E depois ficava bravo porque a galera não entendia o que eu estava fazendo. Se você não fala, fica difícil de entender, né? Então é bacana você trazer sempre essa visão do que está rolando no dia a dia, as coisas que estão acontecendo, quais são os objetivos alcançados, o que vocês estão aprendendo no dia a dia para os stakeholders. Por quê? Cara, um stakeholder que começa a não acreditar mais no seu plano, ele pode acabar com ele. Porque ele pode chegar e falar, putz, já cansei de investir nisso aqui, não está trazendo resultado, não estou acreditando mais, vou embora, vamos fazer outra coisa. Não está dando certo. É bacana você sempre ter esse casamento de expectativa. Contexto. Eu falei um pouco do contexto já com vocês, vou só repetir aqui algumas coisas, pensem nas fronteiras de contexto façam caso de uso, putz, vamos fazer um testezinho aqui, se eu tiver um contexto de pagamento separado de um contexto de trazer valor presente faz fazer sentido? não vai fazer sentido? os times vão conseguir se falar no dia a dia, a gente consegue ter uma fronteira bem declarada, bem definida disso, eu consigo postar uma mensagem para o outro cara ler e depois me responder. Como é que vai ser essa relação dos contextos? Faz um exemplozinho no dia a dia. Uma coisa existe sem a outra. Eu gosto muito de pensar nisso para fechar um pouco de contexto. O meu contexto existe sozinho? Ele consegue se manter? Ele é uma informação forte o suficiente para se manter sozinho? Se não for, não tem problema, mas é um cara para você ficar de olho. Qual a relação que você está gerando entre contexto e as dependências? Tem contextos que eles têm dependência, que eles não vão ser autossuficientes o tempo todo, mas qual é essa dependência? Ele consegue sobreviver sem, ele consegue trabalhar com algum tipo de mensageria no meio do caminho, ele consegue ser um pouco mais desacoplado para não gerar acoplamento ali no dia a dia? E as fronteiras que eu já falei bastante para vocês, acho que é isso, são as principais coisas que a gente tem que pensar no dia a dia sobre contexto de aplicação. Cara, depois que você fez isso, vamos falar um pouquinho do plano. A arquitetura-alvo tem que ser desenhada e bem embasada, gente, em cima do que a gente vai ter no futuro para resolver, tá? A gente precisa saber, conforme eu falei para vocês, qual é o desenho final que a gente quer chegar e por que a gente quer chegar nesse desenho. É bom ter. E por que é legal você ter um desenho da arquitetura? Pô, você tem um time, você não vai construir nada sozinho. Hoje em dia a gente não vai sentar aqui no canto escuro do quarto e sair codando tudo e terminar de fazer um sistema sozinho. Então, é legal você ter um desenho, um mapa do arquitetura onde você quer chegar. Fica muito mais fácil porque no dia a dia você diminui muito as discussões sobre arquitetura. Acho que quem nunca passou por uma coisa que é, você vai lá, desenha, pensa, não compartilha qual desenho você quer e nem quais são os benefícios que você quer trazer. Não deixa claro para todo mundo o que está sendo feito. E todo dia você tem que entrar em reuniões para explicar o que está sendo feito, porque você pensou naquilo, e daí você fala, putz, o outro time está indo na contramão, está fazendo diferente. A gente tinha pensado em ir para cá, o time está indo para lá. É muito importante você ter um desenho de arquitetura onde a gente quer chegar, quais são os pontos fracos disso e deixar amplamente divulgado para o time que está trabalhando com você, para ninguém ir na contramão para você não ter que ficar explicando toda a aula, senão você gasta muito tempo do seu dia explicando e possivelmente você vai se frustrar, porque você vai ficar ali correndo atrás com meia dúzia de time que vai estar ali conseguindo estar com você no dia a dia e vai ter um ou outro que vai estar indo no caminho contrário, porque não sabe, se não foi lá não explicou direito, vai entrar gente nova normalmente são projetos grandes, são projetos que demoram um ano, vai sair gente, você pode sair, então é legal deixar bem definidinho pra todo mundo arquitetura de transição também deixar muito clara pra todo mundo, a mesma coisa e usar os stacks, os stacks, como eu falei, sempre como seus aliados. Quanto que seu time conhece desse stack? Como aduro tá esse stack? Cara, eu quero começar a usar isso aqui porque é super revolucionário. Beleza. Brinca com isso lá num cantinho. Vai fazer... Vai usar a sua experiência, a sua experimentação numa funcionalidade menor, numa funcionalidade talvez pra dentro de casa, que você não vai impactar o cliente. Não vai fazer toda uma plataforma baseada em uma stack que está começando, que não tem nenhuma comunidade para te apoiar. Então é importante você pensar em quanto o seu time conhece, quanto uma pessoa nova que entrar no seu time vai conseguir usar o que vocês estão construindo. Deixar assim documentado o que vocês estão fazendo. Às vezes a gente cria stacks nossos ali, por mais que você tenha as stacks de mercado, às vezes você cria uma certa stack ali para te ajudar. Já deixa isso também bem documentado, porque quem chega não entende o que está acontecendo. É muito bom você ter sempre as stacks compartilhadas e a decisão não só embasada na tecnologia só. Ah, puta, essa stack ela consegue resolver um problema de processamento paralelo, bacana. A outra consegue ser mais rápida para subida de máquina, bacana também. Mas isso vai ser o seu diferencial? Ela consegue ser bem mais rápida, mas para contratar gente de mercado vai demorar seis anos. Às vezes vai te atrapalhar, então pensa direitinho se realmente você precisa daquilo.