E como os principais objetivos é identificação precoce de problemas. Então, vocês vão ver que antes de eu codificar alguma coisa e perceber que aquilo não vai dar certo, isso, eu falo de experiência que eu tenho, já aconteceu de invalidar um projeto, porque, eu não vou citar nomes aqui, mas já aconteceu de invalidar um projeto por conta de, no momento que a gente fez o levantamento do projeto, a gente descobriu que uma das peças principais que a gente precisava para aquela solução não era viável. Então, é a identificação precoce de problema quando ela ainda é barata. E quando que ela é barata? Quando eu ainda não coloquei aquilo em produção. Outra coisa é alcançar o consenso, por isso que eu tenho falado muito de comunicação de pessoas e de repassar, e é um consenso em torno de uma organização. Se eu estou propondo uma solução, eu vou passar ela para quem tem um entendimento daqueles domínios, e essas pessoas que têm um entendimento do domínio, que têm aquele envolvimento sobre um determinado problema, um entendimento de um determinado problema, elas podem gerar um consenso sobre aquilo. Então, vamos supor que meu time está decidindo entre um banco relacional e um não relacional. Então, a gente gera um consenso, uma decisão entre o time. E sempre documentando e mostrando, a gente decidiu por isso, por causa disso. E se uma pessoa lá pra frente voltar e ler o documento, e é até uma prática muito comum nas organizações, é porque eu citei, mais lá pra frente a gente uma pessoa entra nova no time, você passa o documento e fala, lê aí, você vai entender o que o sistema está lá, o sistema que você vai mexer está aqui. Outra coisa é assegurar a consideração de preocupações transversais. Quando eu digo preocupação transversal, eu até dei uma ênfase minha, é questão de segurança, testabilidade, manutenção, observabilidade, impactos de pessoas envolvidas. Se eu mudar o contrato de uma API, eu posso impactar um time que às vezes funciona no meu serviço. Então, isso é preocupação transversal. É preocupação com outras pessoas que dependem, às vezes, do meu serviço. E não só isso, mas aí a gente tem preocupação com a segurança, os dados que eu estou manipulando. Pode ser algo privado, eu tenho que... Enfim, escalar o conhecimento. Para mim, isso daqui é uma das chaves, é um dos objetivos mais legais que a gente tem quando documenta, que é eu tiro isso da minha cabeça e aquela coisa do deve daqui a uma semana, duas semanas ele sair do time, ou um mês, ou um ano, não sei, e ele levou com ele todo o conhecimento que tinha. Todo mundo que ficou no time tem que ficar pegando documentações desatualizadas ou às vezes nenhuma, ou ler um código para poder descobrir o que foi feito daquele jeito. Então a ideia é você escalar e a gente sabe que em organizações a gente tem diferentes minoridades e aí é uma maneira de você trazer todo mundo, subir a barra de todo mundo, porque a partir do momento que você inclui as pessoas, júnior ou pleno, na tomada de decisão, você está trazendo conhecimento para elas. Então é isso, escalar conhecimentos dos engenheiros sênior, mais sênior, não é de sênior, não é necessariamente só sênior, mas tem o staff plus e outras pessoas, mas é no sentido de pessoas que têm mais senioridade repassar isso para toda a organização. Formar uma base de uma memória organizacional, isso vai muito daquilo que eu falei, essa memória organizacional é por que as decisões foram tomadas daquele jeito? Então, para lá para frente a gente não parar e perder o nosso tempo de olhar novamente e entender por que a decisão foi daquele jeito. Porque aqui está documentado. E mais uma coisa é atuar como um artefato resumido no portfólio, e eu destaquei portfólio técnico dos designers de software. E aí, o que acontece? Na maior parte dessas empresas que eu vi, até essas empresas, outras empresas grandes que também utilizam o DesignDoc, conversando com outras pessoas, o pessoal da Zup também utiliza, tem N empresas que utilizam, o Shopify por exemplo também, esse eu me lembro de cabeça, mas eu tenho uma lista, eu vou mostrar depois. E assim, o que acontece, quando você quer pedir por uma promoção para subir o seu cargo, você normalmente tem que apresentar o porquê que você quer Tipo, a sua liderança tem que concordar com aquilo, mas você também tem que mostrar o seu portfólio. O que você já fez pela organização? E aí, os design docs servem como um portfólio para você. Você pode chegar e mostrar, ó, eu escrevi esse design doc e essa solução. Olha só, com coautoria de algumas pessoas, eu tive a revisão de certas pessoas que são mais sênios, mas aqui está. Então, serve como um portfólio para você pedir. E tem lugares que determinados cargos de senioridade um pouco mais altos, algumas empresas, inclusive, adotam isso como critério. Se você está aí num software developer 2, querendo subir para um software developer 3, ou do querendo virar o 3 seria o senior, né? Ou querendo virar principal ou coisa assim. Um dos critérios que eles analisam é exatamente o seu design doc. A qualidade do seu design doc. Então, assim, já falei o porquê daí ele motiva do que por que a gente vai querer escrever um documento Daqui a pouco eu falo os motivos ruins e quando a gente não vai escrever a gente vai querer escrever um documento? Daqui a pouco eu falo os motivos ruins e quando a gente não vai escrever, a gente ainda chega lá. Mas primeiro, beleza, pegamos as partes boas, vamos falar como estruturar isso. Como que eu escrevo esse documento? E aí eu até brinco, eu até já falei com o Wesley em algum momento, mas essa informalidade que tem o documento, a ideia é que você... Ah, beleza, eu peguei uma página em branco e comecei a escrever alguma coisa, ou eu tenho uma folha de caderno e comecei a escrever. Não tem um padrão, mas é uma informalidade que em alguns pontos você tem que ser formal. E aí é nesse ponto, essa pouca formalidade que tem, eu quero mostrar para vocês. Então, como eu preencho esse documento? O que é esse documento? Acho que muitas pessoas estão se perguntando o que é esse documento. Wesley, eu vou fazer esse como um ponto de pausa, se alguém tiver dúvidas, até esse ponto do porquê, seria interessante a gente já dar uma pausinha, porque agora a gente vem com o conteúdo da estrutura. Legal, show de bola. Eu tenho alguns pontos aqui que vale a pena a gente ressaltar, mesmo olhando em relações a perguntas, algumas coisas que eu trouxe aqui também. Uma das coisas que a gente sabe que é muito complicado numa empresa é a gente conseguir manter documentação. Então, às vezes, uma documentação sem ser mantida, ela acaba gerando um problema muito grande pelo fato de você ter uma falsa sensação de que você está no controle de tudo, que você sabe o que está acontecendo, mas, no final das contas, a documentação acaba não mais se refletindo no que o sistema faz. Então, a pergunta daí é, como que você vê de uma empresa conseguir, aos poucos, modificar essa cultura para, aos poucos, conseguir manter essas alterações consistentes? Legal. Eu acho que o primeiro ponto é definir qual é o tipo de documentação, porque a gente tem documentação de código e documentação mais estrutural, documento de arquitetura, decisão de arquitetura, como é mais o caso do design box. A questão da documentação de código é realmente complicada. A gente sabe que código, quando muda, é difícil manter. E aí tem algumas boas práticas a respeito disso, que é quando a gente for mexer, a gente ir lá e tentar tomar cuidado, mexer, dar uma olhada e evitar documentar coisas que possam se perder com o tempo. Um exemplo prático é você documentar algo, normalmente você colocar em cima do algoritmo alguma coisa que não necessariamente, você não traz uma explicação daquele algoritmo. Isso pode ser um problema porque no futuro, se aquilo que está para dentro muda, aquela documentação já não vale de mais nada. Mas isso é uma parte mais de código. De código realmente é um desafio, e aí a gente tem outras técnicas ou ferramentas para a gente ter essa coisa mais atualizada, ter uma coisa mais mantida. Só que eu acho que acaba que a resposta fica bem parecida com a resposta que você me perguntar sobre documentação de software, no sentido do design. A gente vai chegar num ponto aqui da apresentação onde eu vou falar sobre os ciclos que a gente tem que ter de ir revisitando a documentação. Só que a gente sabe que em dado momento, a gente para de revisitar aquela documentação. Porque ela já está pronta, às vezes a solução já foi implementada, já foi implantada, aquilo já está no ar. E aí realmente não precisa ser revisitada, a não ser que alguém entre novo no time que vai dar uma olhada e tal. E aí você me pergunta, mas como manter isso? E se não é cultura? A resposta é simples, é cultura. E aí a gente entra num ponto onde o State of the Office Report fala muito sobre a cultura, de a gente ter cultura generativa, uma cultura burocrática ou patológica. E aí, se você não gera uma cultura na empresa, das pessoas começarem a, quando pensarem em alguma coisa, escreveram em design doc, quando precisarem revisitar uma documentação, se você não gera essa cultura de documentação, não adianta. Você não vai conseguir acolher. Então, é muito mais uma questão de pessoas e cultura do que realmente qualquer outra coisa. É muito de você mostrar para as pessoas, e isso é um trabalho que eu já falo, em um dos lugares que eu passei, a gente encontra 100% de adesão a tudo isso, mas é você fazer esse trabalho de formiguinha ali, de começar entre você e seu time. Eu dou até um exemplo prático, em algum determinado momento, a gente estava desenhando um bot para trabalhar com Slack, a gente escre desenhando um bot para trabalhar com Slack, a gente escreveu um ZendDoc e aí a gente precisou revisitar um fluxo que a gente tinha. E aí o que a gente fez? Antes de qualquer coisa, a gente voltou no documento e falou o que o documento está dizendo sobre esse fluxo? E foi lá e atualizou. Decidiu, não, a gente quer que esse clipe seja feito assim. Então, assim, é mais da cultura. Enquanto você não gerar essa cultura generativa no sentido de espalhar esse conhecimento entre as pessoas, e eles entenderem o importante de voltar e revisitar em cada documento. Tem empresas, inclusive, que quando você vai para uma reunião, a pessoa já fala, não, beleza, me manda o documento, eu vou ler e quando eu entrar na reunião, a gente vai discutir sobre aquilo e eu já, inclusive, vou ter pontos para discutir com você sobre aquilo.