Quando que eu não vou escrever esse documento? Porque eu acabei de falar, tem um custo. Não vem de graça. Todos esses benefícios não vêm de graça. Qual que é esse custo? Eu não devo escrever se a cultura da minha organização é patológica. Ou seja, se minha empresa chega e fala, vai ser implementado assim? Não tem motivo. O que eu vou discutir? Se a implementação é essa. Se tem muita decisão de cima para baixo, por que eu vou documentar isso aí? Não tem real benefício. Não é que não tem benefício, tem pouco benefício. Tem um benefício porque beleza, você tem uma documentação sobre aquilo, mas não vai ter exatamente as compensações. Porque naquela parte onde você vai falar por quê, ah, porque de cima falou que é assim. Então, se não tem alternativa, compensação, explicação, tudo bem. Uma outra coisa é a sobrecarga. Como eu disse, tem uma sobrecarga sim no processo. Nada vem de graça. Então, assim, escrever documentos gera uma sobrecarga. Só que é uma questão cultural. Então, escrever, se você está escrevendo um documento, mas você não tem entendimento dos benefícios que traz, você está escrevendo aquele documento, isso pode gerar ruído. Isso gera pessoas insatisfeitas porque estão tendo que escrever e considerar aquilo como uma burocracia. E não é esse o intuito dessa documentação. A informalidade está aí para que isso se torne uma burocracia. E aí tem um terceiro tópico que é quando não tem complexidade. Às vezes uma funcionalidade tão simples e não tem essas compensações, é uma coisa que só tem um jeito de fazer e ele é simples. Então, assim, não vale a pena você escrever isso que eu comento. Só para listar e vocês saberem que tem, a gente até já discutiu um pouco sobre isso, então acho que dá até para falar mais rápido. Que assim, tem a questão de, além de design doc, tem ADR. Eu coloquei aqui dois links. Esse primeiro é sobre ADR em si. E esse segundo é uma ferramenta do Nate Price. É um autor de alguns livros bem interessantes. Ele fez uma ferramenta para ADR. É bem legal, ela permite você criar uma decisão, depois fazer uma super feed, né? Eu esqueci a tradução, é quando você passa por cima daquela, fala, não, beleza, a gente mudou essa decisão. Ele tem muita recurso, bem interessante, e o modelo que ele usa é bem curto, rápido e simples. Eu gosto bastante de estar bem próximo ao código. Ele usa um modelo que é mais próximo ao código, um pouco diferente do design doc, que está um pouco preocupado com o design e etc. Ali é mais para documentar uma decisão que no final acabou sendo essa. Tem o RFC, que são pedidos de comentário, que nem o Wesley falou, ele tem um pouco de formalidade, e aí só que aí eu fiz questão de botar esse post do Mineta, que ele traz um pouco de como que isso foi feito na tribe, e é interessante porque as pessoas previnham deixar lá, tipo, sete dias, e aí depois, tipo, gerava comentários sobre aquilo e etc., e tira um pouco do peso de formalidade que tinha RFC, no sentido dessa Internet Engineering Task Force, que é aquilo que a gente está acostumado a ver de RFC. E por fim eu coloquei tutorial, e aí você pergunta, pô, mas tutorial o que tem a ver? Na real é porque vai ter momentos que isso for documentação no tutorial, de como que aquilo vai ser feito, como que a pessoa vai entrar e fazer. E aí também é importante a gente entender como fazer. Eu coloquei o tutorial que está aqui, um tutorial que eu tenho de criar aplicações, que às vezes são úteis para um on-board, para coisas assim. Então, cada tipo de documentação tem a sua funcionalidade e o seu público-alvo. Como eu falei, eu tenho N referências sobre o assunto, eu coloqueii alguns aqui tem esse link aqui que é o Google, explicando mais ou menos como que é isso lá no Google e eu disse lá no Google, até para ter promoção por exemplo, é avaliado esses Lend Docs, isso não é só Google, na verdade a maioria dessas empresas tem essa cultura tem uma introdução aos Lend Docs que esse aqui é do PicPay como escrever uma documentação efetiva, tem muitas... Eu dei umas dicas aqui, mas aqui pode complementar. Esse Botar o Cássio no YouTube é o meu canal, eu coloquei como referência, porque eu fiz toda uma explicação sobre Design Docs. E aí tem uma visão até legal, porque traz pessoas de outras empresas, que foram da Zupi e do Shopify, como que isso é feito nessas empresas. E esse último aqui, que eu deixei ele até aberto, que é o... Na verdade, esse último aqui, eu tinha deixado ele até aberto, mas eu acho que eu vou preferir responder as perguntas dele. Mas esse último link é interessante porque ele tem várias empresas que usam esse modelo de RFC Light e ele tem não só a empresa, mas o modelo que é usado na empresa. Então, assim como esses meus slides podem servir como alguma referência para alguma coisa, esse daqui também tem outros para você juntar tudo e fazer o que você julgar necessário para a sua empresa. Mas era isso que eu tinha para apresentar. Eu espero que vocês tenham... Eu tenha conseguido passar... Eu ter feito aquilo que eu falei sobre design doc, que é conseguir espalhar o conhecimento para todo mundo. E se alguém tiver alguma pergunta, a gente pode responder agora. Wesley, pode voltar aí. Vamos lá. Show de bola, Cássio. Cara, eu acho que deu para o pessoal, de forma geral, ter uma ideia geral da importância de conseguir trabalhar com documentos. Uma das pessoas que participaram aqui do MBA foi o Eduardo. O Eduardo trabalha na Amazon, ele trabalha como gestor, na área técnica, mas ele trabalha em uma área mais de gestão na Amazon. E da mesma forma que você sentiu um pouco, a Amazon é uma empresa totalmente centrada em documentos. E quando você começa a perceber, muitas vezes documentos fazem com que a gente evite um monte de reuniões desgastantes, reuniões que fazem com que a gente perca o foco, a objetividade e que faz também com que a gente perca o foco, a objetividade e faz também com que a gente não pense de forma mais detalhada sobre o assunto que você está colocando. Eu não tenho dúvidas. Se qualquer pessoa parar para fazer um documento, para colocar ali o porquê que eu devo implementar uma BFF na minha empresa, com certeza você vai pensar em muito mais coisa do que se você tivesse uma reunião, batendo um papo, um monte de coisa vai ficar voando e isso acaba não sendo consolidado e às vezes informações importantes saem. Então, uma vez que você consegue ter um documento, você consegue pensar, você consegue clarear as ideias. Nós que somos desenvolvedores, a gente sabe que, muitas vezes, a gente resolve o problema de código com o código. E, para que a gente resolve esse problema com o código, você tem que pensar. E, quando você para para fazer um documento, apesar de muitas pessoas acharem que isso pode ser um pouco difícil, trabalhar e criar um documento, uma vez que você tem um template pronto, uma vez que você acaba pegando o jeito, você vai perceber que você faz aquilo, manda para a galera, todo mundo olha, agora vamos bater um papo nessa reunião para conseguir ajustar o ponto A, B e C que foi falado para a gente melhorar. E acredite, a sua reunião não vai demorar mais que meia hora e você vai conseguindo fazer um monte de alinhamento e também ruídos de comunicação. Eu vejo aqui dentro mesmo da Full Cycle, a gente não é uma empresa grande, tem 40 e poucas pessoas e direto rola corrido em diversas situações. Situações essas que não tem documentos. Normalmente, quando é criado o mínimo de documento possível para determinada funcionalidade, uma pull request que seja decente, explicando cada detalhe, cada coisa que vai acontecer, você vai ver que o ruído demora muito mais. E para finalizar esse raciocínio, a gente tem que pensar o seguinte, galera. Muitas vezes, uma decisão que a gente está tomando pode estar muito clara na nossa cabeça. Pode ser algo óbvio, pode ser algo como um mais um igual a dois. Mas acredite que isso que você tem clareza nesse momento, existem pessoas que elas não conseguem enxergar dessa mesma forma se você não passar mastigadinho o que você está querendo dizer. Então, quando você não passar mastigadinho o que você está querendo dizer. Então, quando você remove o ruído, isso ajuda demais. A documentação ajuda nisso. E, novamente, eu acho que o Cássio deixou muito claro uma coisa que é importante. O design doc, ele não vem apenas para trazer burocracia. Ele tem que ser fácil, ele tem que ser light, mas ele tem que conseguir comunicar e deixar todo mundo na mesma página. Eu acho que eram esses aí os meus dois centavos. E, Cássio, se você quiser colocar mais alguma coisa, tem gente falando em Confluence, tem o SharePoint da Microsoft, para quem gosta também. Eu vi que perguntaram Sobre Colocar no Constant, etc O que eu mais vejo Normalmente é o Constant Acabei respondendo Acabei respondendo mais para frente Show de bola Bom Se tiver mais alguma dúvida Ou qualquer coisa, fica frente. Show de bola. Bom... Se tiver mais alguma dúvida ou qualquer coisa, fica muito a favor. Show de bola. Inclusive, quem quiser me procurar depois, tá? Eu até deixei na tela. Quem quiser me procurar, manda mensagem, qualquer coisa, estou à disposição. Perfeitaço, então. Pessoal, esse era o nosso papo com a participação aqui fantástica do Cássio. É muito interessante porque o Cássio é um cara que gosta dessa parada. E raramente você fala com pessoas que gostam de falar de documentação. É algo bem difícil de você encontrar. E eu acho que esse tipo de coisa é algo que nós, desenvolvedores, a gente tem que pensar. E talvez você seja aquela sementinha que vai começar a plantar isso dentro da empresa que você está trabalhando. Cássio, muito obrigado mesmo aí. Valeu aí por todo o seu capricho, por ter preparado tudo isso aí aqui para a galera. Muito obrigado mesmo e vamos que vamos.