E agora a gente vai falar sobre custos tecnologia e pessoal. Um bom arquiteto de solução, ele vai ter que conseguir gerar uma previsão de custos do projeto. Lembra que a gente colocou inclusive total cost of ownership? Aquela parada, quanto que vai custar para implementar? Quanto que vai custar para eu manter esse negócio? Quais são as tecnologias e equipe pessoal que eu vou utilizar? Como que vai funcionar? Eu vou precisar apenas de pessoas técnicas? Eu vou precisar de gerentes de projetos? Eu vou precisar de pessoas que vão criar interface? Eu vou precisar de pessoas... Vai depender de cada projeto. O grande ponto é que o arquiteto de solução tem que pelo menos dar uma base. Isso aí vai ser acertado? Sempre? Não. Mas quanto mais experiência o cara vai tendo, e quanto mais tipos de projeto parecido ele vai pegando, ele consegue ter uma ideia de quanto vai custar, de quantas pessoas ele vai precisar e quais são os tipos de equipecido ele vai pegando ele consegue ter uma ideia de quanto vai custar enquanto quantas pessoas ele vai precisar e quais são os tipos de equipe que ele vai ter legal e agora galera a gente tem os próximos passos em relação a esses tipos de documento que é o seguinte qual que é a ordem de execução por onde que a coisa começa né porque imagina que você fez todo o negócio assim, bom, tá aqui. E daí alguém vai perguntar pra você. Então, Wesley, tudo ok por onde que a gente começa. Você já vai ter que ter esse plano por onde que as coisas vão começar. E algumas observações gerais que você acredite, acredita que vai fazer diferença. Legal? Pessoal, esse tipo de documento é uma baita burocracia. Dependendo de projetos, escrever um documento desse era a mesma coisa que perder tempo. Mas na maioria dos projetos, principalmente de grandes empresas, ou consultorias que trabalham com grandes empresas, eles são muito necessários. Eles são necessários, inclusive, para proteger a empresa que vai prestar o serviço. Então, a dica que eu dou aqui, se eu puder trazer algo importante aqui para você, é o seguinte. Comece por aquilo que importa. Foque naquilo que importa para o projeto não gaste tempo ou pensando em firulas tecnológicas num momento que você está fazendo um documento tão alto nível eu sei que tem projetos que eles acabam sendo tão experimentais que você tem que ter uma noção dessa firula tecnológica. Mas na maioria deles, não. Na maioria das vezes, arroz com feijão funciona muito bem. Então, tente se organizar. Existem diversos templates para esses tipos de documento. Provavelmente, se você for trabalhar como arquiteto de solução em alguma empresa provavelmente eles vão ter uma metodologia um documento alguma coisa parecida pra você preencher pra você conseguir gerais para o cliente final raramente você vai ter que criar isso do zero tá de uma forma ou de outra eu vou deixar aí pra você alguns links de templates desses tipos de documentos somente pra vocês terem uma ideia tá lembrando também que esse módulo aqui é apenas de fundamento sobre arquitetura de solução a gente vai ter um módulo específico onde a gente vai fazer sistema design e a gente vai falar também sobre design docs e eu acho que também vai abrir um pouco somente quando a gente chegar nesses aspectos. Legal? Pessoal, era isso que eu queria falar aqui nesse nosso capítulo. Espero que você tenha gostado. Apesar de ser uma parada densa, eu sei que é denso pra caramba, mas é importante pelo menos para você ter um insight. E mesmo que você não vá atuar como arquiteto de solução, eu acho que é importante você entender quanta coisa existe que importa e que às vezes a gente não pensa na hora do desenvolvimento. Legal? Espero também que esse tipo de capítulo consiga gerar um grau de amadurecimento para você desenvolvedor principalmente, que sempre está mais preocupado com a tecnologia e a implementação. E saber que muitas vezes você só está vendo o depois, o antes, esse tipo de projeto, documento e esse tipo de coisa que estão acontecendo. Beleza? Um grande abraço para você, tudo de bom e valeu por participar desse módulo.