Construir um SaaS não é apenas sobre funcionalidade; é sobre onde o seu código “mora” e como ele sobrevive ao crescimento. Quando desenhamos a arquitetura do Kyva — passando pelas nossas APIs, o ecossistema Web e o processamento de nossa caixa de cobranças escolha do provedor de nuvem foi estratégica. Optamos pelo Google Cloud (GCP).

Aqui não tem “papo de vendedor”. Vou direto aos pontos que realmente impactam o Kyva e o crescimento do negócio:

1. Performance de Infraestrutura (GKE e Cloud Run)

Nossas Solutions e o precisam de respostas em milissegundos. O GCP nos permite orquestrar containers com uma agilidade que outros provedores não entregam a mesma experiência . Seja via Kubernetes ou instâncias gerenciadas, o deploy é fluido e a latência é mínima. Se o Kyva demora para processar, o cliente perde tempo. No GCP, isso não tem acontecido.

2. Segurança e Gestão de Segredos

Trabalhamos com dados sensíveis. A camada Infra se integra nativamente ao Secret Manager do Google. Não existem chaves de API ou strings de conexão "soltas" no código. Tudo é criptografado e injetado em tempo de execução. Segurança para nosso time e para o cliente confiar seus dados.

3. Armazenamento Inteligente (Cloud Storage)

Documentos, notas fiscais e comprovantes. O volume de arquivos no Kyva cresce exponencialmente. A integração direta da nossa camada de Infra com os Buckets do GCP nos garante que o custo de armazenamento não vai engolir a margem de lucro, mantendo a alta disponibilidade, ao mesmo tempo garantindo segurança e disponibilidade ao cliente.

4. Otimização de Processos com Dados

A integração com o ecossistema de dados do Google foi a maior supresa, sinto estar pronto para o próximo passo: inteligência sobre os dados. O Kyva não é apenas um repositório; ele deve ser o cérebro financeiro da empresa. O GCP facilita o uso de ferramentas de análise que transformam dados brutos em insights reais dentro do nosso módulo de Relatórios.

5. Inteligência Artificial e Gemini: Otimização com Gems Especializados

Não usamos IA de forma genérica. Integramos o Gemini profundamente no ciclo de vida do Kyva. O diferencial aqui é o uso estratégico de Gems especializados para cada um dos nossos repositórios: Kyva API, Web e Cobranças.

• Desenvolvimento Assistido: Cada repositório tem seu próprio “contexto de IA”. Isso significa que nossos Gems entendem as particularidades da camadas do aplicativo independente de qual arquitetura escolhida para cada serviço, acelerando a escrita de código limpo e seguindo rigorosamente os nossos padrões arquiteturais. Ele também nos ajuda na escrita de testes e validação de Pull Requests diretamente nos repositórios.
• OCR e Extração de Dados: Em nossa caixa de cobranças (Um leitor que ajuda a receber os emails dos seus fornecedores), o Google ADK é o motor por trás da leitura de documentos. Substituímos o OCR tradicional por uma abordagem de IA generativa especializada , que não apenas lê o texto, mas interpreta o contexto de notas fiscais e faturas com uma precisão que métodos antigos não alcançam. Isso ajuda no dia a dia dos nossos clientes a não terem que ficar lendo nota por nota um redução de até 95% do tempo.
• Agentes de Decisão: O Google ADK nos ajuda a transformar dados brutos em decisões. Ele atua como uma fonte de leitura inteligente, saneando dados e garantindo que o que chega no banco de dados já passou por uma camada de validação cognitiva, hoje “gasto” tempo em criar agentes especializados em cada tema do Kyva, isso garante que no tempo nossos agentes aprendam com o uso de nossos clientes e aprimorem cada vez mais a leitura de dados.

O veredito

Fechar parceria com o Google Cloud foi uma decisão de escala. Queríamos uma infraestrutura que não fosse um gargalo, mas sim um acelerador. Hoje, o Kyva roda em uma base sólida, permitindo que o time de engenharia foque no que realmente importa: entregar valor para quem usa o Produto.

Se você está construindo um SaaS e ainda perde tempo configurando servidor, você está perdendo o jogo da escala.

Você precisa escolher a melhor ferramenta para cada cenário, e garantir o bom uso do tempo do seu time, eu sei, tenho experiência de longa data em criar times de alta performance, mas é diferente quando ao mesmo tempo você está criando um produto do 0 e não usando um crachá de uma grande corporação consolidada.

1- Não é sobre ser rápido, e sim consistente.
Um dia de cada vez, um tiljolo de cada vez. Sem romantizar, a jornada não é fácil. Depois de muitos anos tocando empresas desde a base até atuar junto a diretoria, tudo muda quando o capital é seu e não de terceiros. O grande desafio e a responsabilidade de criar algo que será de fato utilizado por seus clientes.
O jeito mais simples de pensar, não é uma corrida de 30 minutos, é um prova de resistência.

2. Pensar simples, sempre..
É o normal querer criar um produto com tudo oq os clientes pedem. Mas, ao aumentar a complexidade, gera-se problemas na execução. Inspirado por uma dor vivida em minhas passagens anteriores em empresas do ramo financeiro, percebi que o verdadeiro desafio é a simplificação. Como resolver a dor do cliente com o menor número de cliques possível? Simplificar, escondendo uma engenharia complexa nos bastidores. Se o usuário não percebe a complexidade do processo, então nosso trabalho foi bem feito.

3. Criar processos nem sempre é burocracia, é clareza de onde se quer ir.
No início, eu achava: “vamos burocratizar” criando processos e vamos matar a agilidade de nossa empresa. Na prática, aprendi aconteceu o oposto. Quando você lida com dinheiro, não existe margem para falhas. Estruturar seus processos de forma clara desde o dia 0 é o que lhe dá clareza para acelerar no desenvolvimento do produto. Os processos são os trilhos: se eles forem sólidos, o trem pode andar igual a um trem bala sem descarrilar.

4. Construa para a dor, não para o seu ego
No modelo do kyva, o foco é economizar o dinheiro e o tempo do cliente. Ao fundar a empresa, a tentação é construir o que achamos legal. Tivemos que exercitar a humildade de validar cada etapa. Estamos construindo um produto financeiro, o que significa que a confiança é a nossa moeda principal. Não adianta ter a interface mais bonita do mundo se não resolvemos a ineficiência real do dia a dia das empresas.

5. O “Skin in the Game” afia sua visão
Existe uma clareza assustadora que surge quando você financia o próprio sonho. Você não gasta tempo com métricas de vaidade, mas foca obsessivamente no que traz valor real e retorno. Essa “pressão” nos forçou a sermos eficientes de uma maneira que talvez não fôssemos se tivéssemos milhões sobrando no caixa.

Os próximos capítulos dessa história estão sendo escritos por um time totalmente capaz, exercitando a escuta ativa, focando no cliente e em resolver uma dor real, simplificar processos financeiros complexos. O foco é a redução de custo/tempo em algo que hoje o mercado gasta os tubos para tentar solucionar. A real é que o backoffice das empresas é muitas vezes subestimado (ou pior, esquecido completamente), e ficou claro para mim ao longo dos anos que é onde se deveria focar para crescer com inteligência.

Hoje irei falar sobre alguns padrões e tipos de documentos que podemos usar para organizar melhor nosso dia a dia na área de tecnologia, não vou focar em falar de ferramentas mas sim sobre modelos, porém fica a dica de que eu gosto bastante de utilizar o notion para armazenar minhas documentações pessoais, na empresa vai muito de acordo com a switch de ferramentas utilizadas, a Microsoft oferece bons recursos para isso por exemplo Microsoft Loop;

RFC

A Request for Comment (RFC) é um documento usado para solicitar comentários e feedback sobre uma ideia, proposta ou projeto antes de ser implementado. Ele é comumente usado em ambientes de desenvolvimento de software, mas também pode ser usado em outras áreas como engenharia, negócios e governo.

Os RFCs são criados para fornecer uma descrição detalhada do problema ou proposta e são destinados a ser lidos e comentados por um grupo de pessoas interessadas, como desenvolvedores, especialistas em segurança, usuários finais e outros stakeholders.

O processo de RFC geralmente inclui as seguintes etapas:

1. Criação: Um indivíduo ou equipe cria um documento RFC descrevendo a proposta ou ideia.
2. Revisão: O documento é revisado por especialistas relevantes para garantir que esteja completo e preciso.
3. Publicação: O documento é publicado em um local acessível para comentários, como um fórum ou lista de discussão.
4. Comentários: As pessoas são convidadas a ler e comentar o documento.
5. Revisão final: As sugestões e comentários são revisados e considerados para fazer mudanças no documento.
6. Aprovação: Se a proposta ou ideia é aprovada, ela é implementada.

Em resumo, um Request for Comment (RFC) é um documento usado para solicitar comentários e feedback sobre uma ideia, proposta ou projeto antes de ser implementado. Ele é criado para fornecer uma descrição detalhada do problema ou proposta e é destinado a ser lido e comentado por um grupo de pessoas interessadas, incluindo especialistas em áreas relevantes. O processo inclui etapas de criação, revisão, publicação, comentários, revisão final e aprovação.

DR

Um documento de Decision Record é um tipo de documento utilizado para registrar e rastrear as decisões tomadas em um projeto ou empresa. Ele é geralmente usado para garantir que as decisões são tomadas de forma consciente, baseada em fatos e que possam ser revisadas e rastreadas posteriormente.

O documento de Decision Record normalmente contém informações como:

• Data e hora da decisão
• Pessoas envolvidas na decisão
• Descrição da decisão tomada
• Motivo para a decisão
• Alternativas consideradas
• Impacto esperado da decisão
• Data para revisão da decisão

Ele é criado para garantir que as decisões sejam tomadas de forma consciente, baseadas em fatos e que possam ser revisadas e rastreadas posteriormente. Além disso, ele permite que as pessoas envolvidas na decisão possam entender e se lembrar do contexto e motivação da decisão, e que outras pessoas possam entender e seguir as decisões tomadas.

Os documentos de Decision Record podem ser usados em várias áreas, como gerenciamento de projetos, gerenciamento de negócios, desenvolvimento de software e outras áreas onde as decisões precisam ser documentadas e rastreadas. Eles são geralmente criados e mantidos por líderes de projetos, gerentes de negócios ou outros indivíduos responsáveis pela tomada de decisão.

One Page

Um documento de “one page” é um tipo de documento que se concentra em fornecer informações essenciais sobre um determinado assunto em uma única página. Eles são geralmente utilizados para comunicar de forma clara e concisa, resumindo informações importantes e fornecendo uma visão geral do assunto.

Os documentos de “one page” podem ser utilizados para várias finalidades, como:

• Resumos de projetos, planos de negócios e propostas
• Sumários executivos de relatórios e pesquisas
• Apresentações de vendas e de marketing
• Planos de ação e metas

Eles são projetados para serem fáceis de ler e compreender, com informações organizadas de forma clara e concisa e usando gráficos e imagens para ilustrar as informações. Além disso, eles são geralmente escritos com uma linguagem simples e direta, para que possam ser lidos e compreendidos rapidamente.

Os documentos de “one page” são geralmente criados e mantidos por líderes de projetos, gerentes de negócios, vendedores, profissionais de marketing e outros indivíduos responsáveis por comunicar informações importantes de forma clara e concisa. Eles podem ser facilmente compartilhados e distribuídos, seja por email, anexando-o em uma apresentação ou postando-o em uma rede interna ou site da empresa.

HLA

O High-level architecture (HLA) é um documento que descreve a estrutura geral de um sistema, incluindo sua organização, componentes e interfaces. Ele é geralmente utilizado para comunicar a estrutura geral do sistema a outros desenvolvedores, equipes de projeto, gerentes de projeto e outros interessados.

O HLA geralmente inclui uma descrição geral do sistema, incluindo seus objetivos, requisitos e principais características. Ele também descreve a organização lógica do sistema, incluindo seus componentes principais, como módulos, sub-sistemas e interfaces. Ele também pode incluir diagramas de arquitetura, que ilustram como os componentes se relacionam entre si.

O HLA é geralmente escrito em um nível abstrato, sem entrar em detalhes técnicos. Ele é utilizado para comunicar a visão geral da arquitetura do sistema e fornecer uma compreensão básica dos principais componentes e suas interações. Ele é um documento importante para a comunicação entre as equipes de desenvolvimento, garantindo que todos estejam alinhados e entendam a estrutura geral do sistema.

Além disso, o HLA também é útil como um documento de referência durante o desenvolvimento do sistema, pois fornece uma visão geral da estrutura do sistema, permitindo que os desenvolvedores entendam como seus componentes se relacionam com o sistema como um todo.

Modelo C4

O modelo C4 é uma metodologia para documentação de arquitetura de software que é baseada em diagramas de contexto, container, componente e code (ou seja, C4). Ele foi criado para tornar a documentação de arquitetura de software mais fácil de entender e mais útil para as equipes de desenvolvimento e outros interessados.

O modelo C4 se divide em quatro níveis, cada um representado por um tipo de diagrama:

1. Diagrama de contexto: Este diagrama mostra a visão geral do sistema e seu ambiente, incluindo os principais atores, processos e sistemas com os quais ele se relaciona.
2. Diagrama de container: Este diagrama mostra como os sistemas e aplicativos são organizados e distribuídos em uma rede de computadores. Ele mostra os principais sistemas e aplicativos, bem como suas dependências e como eles se comunicam.
3. Diagrama de componente: Este diagrama mostra como os sistemas e aplicativos são divididos em componentes e como esses componentes se relacionam. Ele mostra os principais componentes, bem como suas dependências e como eles se comunicam.
4. Diagrama de code: Este diagrama mostra como os componentes são implementados em código. Ele mostra os principais pacotes, classes e métodos, bem como suas dependências e como eles se comunicam.

A vantagem do modelo C4 é que ele fornece uma visão geral do sistema, desde uma visão geral do ambiente até a implementação de código, permitindo que os desenvolvedores entendam como os componentes do sistema se relacionam entre si e com o ambiente externo. Além disso, o modelo C4 é fácil de entender e usar para todos os interessados, desde gerentes de projeto até desenvolvedores de código.

Essas são apenas algumas ferramentas utilizadas por mim ao longo dos anos em que trabalhei com gerente de times de tecnologia, obviamente existem outras, mas foquei nas principais que eu utilizei.

Existe um grande desafio quando estamos focando em procurar pessoas focadas na tecnoligia salesforce, vou tentar descrever um processo simplificado para buscar profissionais, capacitar em engajar.

Especialidades Salesforce

A plataforma Salesforce oferece uma variedade de papéis e funções diferentes para seus usuários, cada um com suas próprias responsabilidades e níveis de acesso. Alguns exemplos incluem:

• Administrador de sistemas: este papel é responsável por configurar e gerenciar a plataforma Salesforce, incluindo a criação de usuários, configuração de segurança e definição de regras de negócios. Eles também são responsáveis por manter a integridade dos dados e garantir que a plataforma esteja funcionando corretamente.
• Desenvolvedor: este papel é responsável por desenvolver e personalizar aplicativos e funcionalidades na plataforma Salesforce. Eles usam linguagens de programação como Apex e Visualforce para criar novas funcionalidades e integrações com outras ferramentas.
• Gerente de Produto: Este papel é responsável por garantir que a plataforma Salesforce atenda às necessidades do negócio e dos usuários. Eles trabalham com equipes de desenvolvimento, design e operações para planejar, priorizar e entregar novos recursos e funcionalidades.
• Analista de negócios: Este papel é responsável por entender as necessidades dos usuários e do negócio e traduzi-las em requisitos para a plataforma Salesforce. Eles trabalham com os administradores de sistemas e desenvolvedores para garantir que a plataforma esteja configurada corretamente e atenda às necessidades do negócio.
• Consultor: Este papel é responsável por ajudar as organizações a implementar e usar a plataforma Salesforce. Eles fornecem orientação sobre a configuração e personalização da plataforma, bem como treinamento e suporte para os usuários.

Esses são apenas alguns exemplos, e a plataforma Salesforce oferece uma variedade de outros papéis e funções, dependendo das necessidades específicas de cada organização.

Capacitação de times

Existem várias maneiras de capacitar times Salesforce, incluindo:

1. Treinamento: A Salesforce oferece uma variedade de treinamentos, tanto on-line quanto presenciais, para ajudar os usuários a se familiarizar com a plataforma. Esses treinamentos incluem cursos básicos e avançados, bem como certificações específicas para diferentes papéis e funções.
2. Comunidade de desenvolvedores: A Salesforce tem uma comunidade ativa de desenvolvedores que compartilham conhecimentos, códigos e melhores práticas. Participar dessa comunidade pode ajudar os desenvolvedores a aprender novas técnicas e soluções para problemas comuns.
3. Mentoria: Designe um mentor dentro da equipe, que é um especialista em Salesforce e peça-lhes para orientar e ensinar novos membros da equipe.
4. Prática: A prática é fundamental para dominar qualquer habilidade, incluindo o uso da plataforma Salesforce. Encourage os usuários a experimentar com diferentes recursos e configurações, e forneça-lhes tempo e espaço para praticar e se familiarizar com a plataforma.
5. Customização de treinamento: Customize o treinamento de acordo com as necessidades específicas do seu time, considerando os objetivos, os desafios e as necessidades do negócio.
6. Atualização: Continuar a aprender sobre novos recursos e atualizações da plataforma Salesforce é essencial para garantir que o time esteja sempre atualizado e capaz de tirar o máximo proveito da plataforma.

Uma outra abordagem da qual eu falei anteriormente é construir um PDI, e ter metas claras para o time.

Postagem PDI: https://medium.com/@jonesroberto/pdi-plano-de-desenvolvimento-individual-b01bc04e37a6

TrailHead

Trailhead é uma plataforma de aprendizado online da Salesforce que ajuda os usuários a aprender sobre a plataforma Salesforce de maneira interativa e divertida. Ele oferece uma variedade de recursos de aprendizado, incluindo:

1. Trilhas: São conjuntos de módulos de aprendizado que cobrem tópicos específicos, como administração de vendas, administração de serviços, desenvolvimento de aplicativos e muito mais. Cada trilha é composta por módulos de aprendizado que incluem lições, exercícios e desafios para ajudar os usuários a praticar e testar suas habilidades.
2. Projetos: São desafios práticos que os usuários podem completar para aplicar o que eles aprenderam em trilhas. Os projetos incluem instruções passo a passo e verificações de progresso para garantir que os usuários estejam no caminho certo.
3. Certificações: Os usuários podem se preparar e fazer exames de certificação para provar suas habilidades e conhecimentos na plataforma Salesforce. Certificações incluem certificações de administrador, de desenvolvedor, de arquiteto de soluções e muito mais.
4. Comunidade: A comunidade Trailhead é composta por usuários de todo o mundo, incluindo desenvolvedores, administradores e especialistas em negócios. Os usuários podem se conectar, compartilhar conhecimentos e colaborar uns com os outros.
5. Gamification: Trailhead usa uma abordagem de jogo para tornar o aprendizado divertido e interativo. Os usuários ganham pontos, conquistas e badges ao completar trilhas, projetos e certificações, e podem competir com outros usuários para ver quem tem mais pontos e conquistas.

Pontuação na plataforma

A pontuação no Trailhead funciona da seguinte maneira:

1. Cada trilha, módulo, projeto e certificação tem um valor de pontos específico. Quando um usuário completa esses recursos, eles ganham esses pontos.
2. Os usuários podem ver a pontuação total atual em sua página de perfil.
3. Os usuários também podem ver como eles se comparam com outros usuários na comunidade Trailhead, verificando o leaderboard.
4. Os usuários também podem ganhar badges para mostrar suas conquistas.
5. Os usuários também podem ganhar reconhecimento e reconhecimento interno na sua organização.
6. Além disso, os usuários podem adquirir pontos extras completando atividades adicionais, como criando conteúdo, ajudando outros usuários e muito mais.
7. A pontuação do Trailhead pode ser usada como uma forma de medir o progresso dos usuários e sua capacidade de usar a plataforma Salesforce e também pode ser usada como critério para seleção de profissionais em empresas que utilizam a plataforma Salesforce.

Quais a badges na plataforma trailhead?

Os badges na plataforma Trailhead incluem:

1. Conquistas: são badges que reconhecem seus esforços ao completar módulos, projetos e desafios específicos.
2. Certificações: são badges que reconhecem suas habilidades e conhecimentos em áreas específicas, como administração de Salesforce, desenvolvimento de aplicativos, marketing digital, etc.
3. Superbadges: são badges avançados que testam suas habilidades em uma variedade de tarefas e cenários de negócios.
4. Projetos de Comunidade: são badges que reconhecem sua contribuição para a comunidade Trailhead, como ajudar outros usuários a completar módulos ou projetos.

Certificações

A Salesforce oferece vários tipos de certificações para reconhecer a habilidade e conhecimento dos profissionais em sua plataforma. Alguns tipos de certificação Salesforce incluem:

1. Administrador de Salesforce: certificação que reconhece sua capacidade de configurar, gerenciar e personalizar a plataforma Salesforce.
2. Desenvolvedor de Salesforce: certificação que reconhece sua capacidade de desenvolver soluções personalizadas usando Apex, Visualforce e outras ferramentas de desenvolvimento.
3. Consultor de Vendas: certificação que reconhece sua capacidade de configurar e personalizar a plataforma Salesforce para atender às necessidades de vendas de uma empresa.
4. Consultor de Service Cloud: certificação que reconhece sua capacidade de configurar e personalizar a plataforma Salesforce para gerenciar o atendimento ao cliente.
5. Consultor de Marketing: certificação que reconhece sua capacidade de configurar e personalizar a plataforma Salesforce para gerenciar campanhas de marketing e análise de dados.

Para obter uma certificação Salesforce, é necessário passar em um exame de certificação. Cada exame é projetado para testar seus conhecimentos e habilidades em uma área específica. Os exames podem ser feitos online e são cobrados taxas de inscrição.

Os próximos passos são focados em um bom trabalho de gestão de equipes, e acompanhamento próximo;

ESPECIAL > Modelo Spotify

O Spotify usa o modelo de “tribos” para organizar sua estrutura de equipe. O modelo de tribos é uma abordagem baseada em equipe que organiza as equipes em torno de áreas de negócios específicas, como música, podcasts, plataforma, etc. Cada tribo é composta por equipes autônomas e cross-funcionais que trabalham juntas para entregar valor aos usuários e ao negócio.

Cada tribo é liderada por um líder de tribo, que é responsável por garantir que a tribo esteja alinhada com a estratégia geral do negócio e que as equipes estejam trabalhando de forma colaborativa e eficaz. As equipes dentro de cada tribo são responsáveis por seus próprios produtos e funcionalidades, e trabalham de forma colaborativa com outras equipes dentro da tribo e com outras tribos.

Além disso, o Spotify também tem equipes de suporte técnico e operações que trabalham em conjunto com as tribos para garantir que as necessidades do negócio sejam atendidas e que os usuários tenham uma boa experiência.

Esse modelo permite que as equipes sejam mais flexíveis e ágeis, pois elas são organizadas em torno de áreas específicas do negócio e têm a autonomia para tomar decisões e entregar valor rapidamente. Além disso, isso também permite que as equipes sejam mais engajadas e motivadas, pois elas têm uma visão clara do impacto do seu trabalho no negócio e na experiência do usuário.

Design Thinking é um processo criativo e iterativo que busca entender e resolver problemas de uma forma humana-centrada. Ele é baseado na ideia de que, para desenvolver soluções inovadoras e eficazes, é necessário entender profundamente as necessidades e desejos dos usuários.

O Design Thinking segue geralmente cinco etapas:

1. Compreensão: Nesta etapa, o objetivo é entender o problema e as necessidades dos usuários. Isso pode incluir entrevistas, pesquisas e outros métodos de coleta de dados.
2. Definição: Com as informações coletadas na etapa anterior, é possível definir o problema de forma clara e objetiva.
3. Ideiação: Nesta etapa, o objetivo é gerar ideias para resolver o problema. Isso pode ser feito por meio de brainstorming, mind mapping e outros métodos criativos.
4. Prototipagem: Com as ideias geradas, é possível criar protótipos para testar e validar as soluções propostas.
5. Teste: Por fim, é importante testar as soluções com os usuários para coletar feedback e fazer ajustes antes de implementar a solução final.

O Design Thinking é uma metodologia amplamente utilizada em empresas e organizações para desenvolver produtos, serviços e soluções inovadoras. Ele é aplicado em diversos setores, como tecnologia, saúde, educação, entre outros.

Compreensão

A etapa de compreensão do Design Thinking é a primeira etapa do processo e tem como objetivo entender o problema e as necessidades dos usuários. É nessa etapa que se coleta informações e se compreende o contexto em que o problema está inserido. Algumas das atividades comuns nessa etapa incluem:

1. Entrevistas: Entrevistar pessoas que possam fornecer informações valiosas sobre o problema, como usuários, especialistas e stakeholders.
2. Pesquisas: Realizar pesquisas com usuários e outras partes interessadas para obter informações sobre necessidades, desejos e comportamentos.
3. Estudo de caso: Analisar casos existentes de problemas similares para obter insights e inspiração.
4. Observação: Observar usuários em seu ambiente natural para entender como eles interagem com o problema.
5. Análise de dados: Analisar dados quantitativos e qualitativos para entender o problema e as necessidades dos usuários.

Essas atividades são importantes para coletar informações valiosas e compreender a complexidade do problema. É importante lembrar que essa etapa é iterativa, ou seja, pode ser necessário realizar mais de uma vez para se obter todas as informações necessárias.

Definição

A etapa de Definição do Design Thinking vem logo após a etapa de Compreensão e tem como objetivo definir o problema de forma clara e objetiva. Esta etapa é importante para garantir que todos os envolvidos na solução do problema tenham uma compreensão comum do problema. Algumas das atividades comuns nessa etapa incluem:

1. Síntese: Sintetizar as informações coletadas na etapa anterior para identificar os problemas e necessidades dos usuários.
2. Identificação de oportunidades: Identificar oportunidades para resolver o problema de forma inovadora.
3. Definição de objetivos: Definir objetivos claros para a solução do problema.
4. Criação de um point of view (POV): Criar um point of view (POV) que resume a compreensão do problema e as necessidades dos usuários.
5. Elaboração de hipóteses: Elaborar hipóteses sobre como a solução do problema pode atender as necessidades dos usuários.

Essa etapa é importante para garantir que todos os envolvidos tenham uma compreensão clara do problema e do que precisa ser alcançado com a solução. A definição do problema também é uma base para as etapas seguintes do Design Thinking.

Ideiação

A etapa de ideiação do Design Thinking é a terceira etapa do processo e tem como objetivo gerar ideias para resolver o problema. Esta etapa é importante para criar soluções inovadoras e diferentes. Algumas das atividades comuns nessa etapa incluem:

1. Brainstorming: Reunir um grupo de pessoas para gerar ideias de forma colaborativa.
2. Mind mapping: Criar um mapa mental para organizar ideias e identificar conexões entre elas.
3. Sketching: Esboçar ideias de forma rápida e informal para explorar diferentes possibilidades.
4. Role-playing: Encenar cenários para visualizar como as ideias funcionariam na prática.
5. Prototipagem rápida: Criar protótipos rápidos para testar ideias e obter feedback.

Essa etapa é importante para gerar uma grande quantidade de ideias e explorar diferentes possibilidades. É importante lembrar que nessa etapa todas as ideias são bem-vindas, independentemente de sua viabilidade ou complexidade. As ideias geradas na etapa de ideiação servem como base para as etapas seguintes do Design Thinking.

Prototipagem

A etapa de prototipagem do Design Thinking vem logo após a etapa de ideiação e tem como objetivo transformar as ideias geradas em soluções tangíveis. Esta etapa é importante para testar as soluções e obter feedback dos usuários. Algumas das atividades comuns nessa etapa incluem:

1. Criação de protótipos: Criar protótipos de diferentes níveis de detalhes para testar as ideias geradas na etapa anterior.
2. Testes com usuários: Realizar testes com usuários para obter feedback sobre as soluções.
3. Análise de feedback: Analisar o feedback obtido para identificar pontos fortes e fracos das soluções.
4. Iteração: Realizar iterações para aprimorar as soluções baseadas no feedback obtido.

A prototipagem é importante para testar as soluções e obter feedback dos usuários. É importante lembrar que essa etapa é iterativa, ou seja, é necessário realizar mais de uma vez para se obter a solução final. A prototipagem permite verificar se a solução atende as necessidades dos usuários e se ela é viável antes de ser implementada.

Teste

A etapa de teste do Design Thinking é a quinta etapa do processo e tem como objetivo validar a solução prototipada com os usuários. Essa etapa é importante para garantir que a solução atende as necessidades dos usuários e é viável antes de ser implementada. Algumas das atividades comuns nessa etapa incluem:

1. Testes de usabilidade: Realizar testes com usuários para verificar se a solução é fácil de usar e atende às suas necessidades.
2. Testes de aceitação: Realizar testes com usuários para verificar se eles estão dispostos a usar a solução.
3. Análise de feedback: Analisar o feedback obtido para identificar pontos fortes e fracos da solução.
4. Iteração: Realizar iterações para aprimorar a solução baseada no feedback obtido.

Essa etapa é importante para garantir que a solução atende as necessidades dos usuários e é viável antes de ser implementada. É importante lembrar que essa etapa também é iterativa, ou seja, pode ser necessário realizar mais de uma vez para se obter a solução final e adequada.

Lean Inception é uma abordagem para o planejamento ágil de projetos que combina princípios de Lean Startup e Scrum. Ela foi desenvolvida pela ThoughtWorks e é usada para ajudar equipes a entender melhor o problema a ser resolvido e definir o escopo do projeto.

A Lean Inception começa com a formação de uma equipe multidisciplinar, composta por desenvolvedores, gerentes de projeto, gerentes de produto e stakeholders. Em seguida, é realizada uma série de atividades para entender melhor o problema e definir o escopo do projeto. Essas atividades incluem:

• Mapeamento do problema: a equipe identifica os problemas e desafios enfrentados pelos stakeholders e define o objetivo do projeto.
• Identificação de hipóteses: a equipe formula hipóteses sobre como resolver o problema e os desafios identificados.
• Validação de hipóteses: a equipe valida as hipóteses com os stakeholders e clientes para garantir que estão no caminho certo.
• Definição do escopo: a equipe define o escopo do projeto com base nas hipóteses validadas.
• Criação do backlog: a equipe cria um backlog com as tarefas necessárias para alcançar o objetivo do projeto.

Uma vez que o escopo e o backlog são definidos, o projeto pode ser gerenciado usando o framework Scrum. A equipe trabalha em sprints curtos e se comunica constantemente para garantir que o projeto está no caminho certo e para fazer ajustes se necessário.

A Lean Inception é uma abordagem útil para projetos complexos, onde é importante entender melhor o problema e definir o escopo antes de começar a desenvolver uma solução. Ajuda a equipe a se concentrar nas necessidades dos clientes e garantir que o projeto está alinhado com as expectativas.

Não iremos focar na execução completa da Lean Inception, pois temos uma referência excelente no livro Lean Inception: Como alinhar pessoas e construir o produto certo, escrito por Paulo Caroli.

Referências> https://caroli.org/livro/lean-inception-como-alinhar-pessoas-e-construir-o-produto-certo/

Livro:

https://www.amazon.com.br/Lean-Inception-Alinhar-Pessoas-Construir/dp/8594377061

5W2H é uma ferramenta de planejamento e gerenciamento de projetos que ajuda a identificar e definir os detalhes de uma tarefa ou projeto. A sigla representa as sete perguntas a serem respondidas:

1. O que (What) — Qual é a tarefa ou projeto?
2. Por quê (Why) — Qual é o objetivo ou motivo para realizar a tarefa?
3. Quem (Who) — Quem será responsável por realizar a tarefa ou quem será afetado?
4. Onde (Where) — Onde a tarefa será realizada?
5. Quando (When) — Quando a tarefa será realizada?
6. Como (How) — Como a tarefa será realizada?
7. Quanto (How Much) — Qual é o orçamento ou recursos necessários para realizar a tarefa?

Essas perguntas ajudam a garantir que todos os detalhes importantes sejam considerados antes de iniciar um projeto ou tarefa, o que aumenta as chances de sucesso.

A maneira certa de usar a ferramenta 5W2H depende do contexto específico de cada projeto ou tarefa, mas geralmente, o processo é o seguinte:

1. Identificar a tarefa ou projeto: Comece respondendo à pergunta “o que” (what). Defina claramente a tarefa ou projeto que precisa ser realizado.
2. Definir o objetivo: Responda à pergunta “por quê” (why). Por que a tarefa ou projeto é importante? Qual é o objetivo final?
3. Identificar as pessoas envolvidas: Responda à pergunta “quem” (who). Quem será responsável por realizar a tarefa? Quem será afetado pelo projeto?
4. Definir o local: Responda à pergunta “onde” (where). Onde a tarefa ou projeto será realizado?
5. Estabelecer um cronograma: Responda à pergunta “quando” (when). Quando a tarefa ou projeto será iniciado e concluído?
6. Identificar os recursos necessários: Responda à pergunta “como” (how). Como a tarefa ou projeto será realizado? Quais recursos serão necessários?
7. Estabelecer um orçamento: Responda à pergunta “quanto” (how much). Qual é o orçamento ou recursos necessários para realizar a tarefa ou projeto?

Após responder essas perguntas, é importante revisar e atualizar as respostas regularmente para garantir que o projeto ou tarefa esteja no caminho certo. A ferramenta 5W2H é uma ótima maneira de garantir que todos os aspectos importantes de um projeto ou tarefa sejam considerados antes de iniciar, e de acompanhar o progresso ao longo do tempo.

Olá, nesse post irei falar dos Design patterns mais usado atualmente,

Anteriomente eu fiz uma postagem falando de todos os padrões do GOF, que você pode acessar pelo link abaixo:

https://medium.com/@jonesroberto/design-patterns-34257406b136

Padrões Criacionais (Creational Patterns)

Singleton — https://medium.com/xp-inc/desing-patterns-parte-5-singleton-324c6effab6f

Factory Method- https://medium.com/xp-inc/desing-patterns-factory-method-a7496ae071aa

Padrões estruturais (Structural Design Patterns)

Adapter — https://medium.com/xp-inc/desing-patterns-parte-8-adapter-21ed67ceb9ed

Facade — https://medium.com/xp-inc/desing-patterns-parte-12-facade-ff66c68f5784

Decorator- https://medium.com/xp-inc/desing-patterns-parte-11-decorator-ba348f44142f

Proxy — https://medium.com/xp-inc/design-patterns-parte-14-proxy-9f72c15a2ee1

Padrões Comportamentais (Behavioral Design Patterns)

Command — https://medium.com/xp-inc/design-patterns-parte-16-command-9c73af726c9c

Template method — https://medium.com/xp-inc/design-patterns-parte-24-template-method-69e3a7927dcd

Strategy — https://medium.com/xp-inc/design-patterns-parte-23-strategy-50a18ccbd1de

Observer — https://medium.com/xp-inc/design-patterns-parte-21-observer-e2260412011a

Mediator — https://medium.com/xp-inc/design-patterns-parte-19-mediator-a35af116eef1

Hoje irei falar sobre os nove métodos HTTP normalmente associado ao desenvolvimento web Restful e ao protocolo de transferência de hipertexto e que são mais comuns ao desenvolver APIs RESTful

Métodos de solicitação HTTP

Os métodos de solicitação são diferenciados por meio de vários fatores, primeiro pelo verbo, mas também pelas seguintes características:

• Um método de solicitação será idempotente se puder ser processado com êxito várias vezes sem alterar o resultado. Para obter mais informações, confira RFC 9110: 9.2.2. Métodos idempotentes.
• Um método de solicitação pode ser armazenável em cache quando sua resposta correspondente pode ser armazenada para reutilização. Para obter mais informações, consulte RFC 9110: Seção 9.2.3. Métodos e cache.
• Um método de solicitação será considerado um método seguro se ele não modifica o estado de um recurso. Todos os métodos seguros também são idempotentes, mas nem todos os métodos idempotentes são considerados seguros. Para obter mais informações, confira RFC 9110: Seção 9.2.1. Métodos seguros.

**O método POST só pode ser armazenado em cache quando os cabeçalhos apropriados Cache-Control ou Expires de resposta estiverem presentes. Isso é muito incomum na prática.

Finalidade de cada método HTTP

A versão 1.0 do Hypertext Transfer Protocol, lançada em 1996, definia apenas três verbos HTTP: GET, POST e HEAD.

Método GET

O método HTTP mais comumente usado é GET.

O objetivo do método GET é simplesmente recuperar dados do servidor. O método GET é usado para solicitar qualquer um dos seguintes recursos:

• Uma página da web ou arquivo HTML.
• Uma imagem ou vídeo.
• Um documento JSON.
• Um arquivo CSS ou arquivo JavaScript.
• Um arquivo XML.

O método de solicitação GET é considerado uma operação segura, o que significa que não deve alterar o estado de nenhum recurso no servidor.

Método POST

O método de solicitação POST HTTP envia dados ao servidor para processamento.

Os dados enviados ao servidor normalmente estão no seguinte formato:

• Campos de entrada de formulários online.
• Dados XML ou JSON.
• Dados de texto de parâmetros de consulta.

A especificação HTTP permite ao desenvolvedor decidir o tipo de processamento dos dados enviados através de um método HTTP POST. Os usos prototípicos do método POST incluem o seguinte:

• Poste uma mensagem em um quadro de avisos.
• Salve dados de formulários HTML em um banco de dados.
• Calcule um resultado com base nos dados enviados.

Uma operação POST não é considerada uma operação segura, pois tem o poder de atualizar o estado do servidor e causar possíveis efeitos colaterais no estado do servidor quando executada.

O método HTTP POST também não precisa ser idempotente, o que significa que ele pode deixar dados e recursos no servidor em um estado diferente cada vez que é invocado.

Método PUT

O método HTTP PUT é usado para substituir completamente um recurso identificado por uma determinada URL.

O método de solicitação HTTP PUT inclui duas regras:

1. Uma operação PUT sempre inclui uma carga útil que descreve uma definição de recurso completamente nova a ser salva pelo servidor.
2. A operação PUT usa a URL exata do recurso de destino.

Se existir um recurso na URL fornecida por uma operação PUT, a representação do recurso será completamente substituída. Se não existir um recurso nesse URL, um novo recurso será criado.

A carga útil de uma operação PUT pode ser qualquer coisa que o servidor entenda, embora JSON e XML sejam os formatos de troca de dados mais comuns para webservices e microsserviços RESTful.

Método DELETE

O método HTTP DELETE é autoexplicativo. Após a execução, o recurso para o qual uma operação DELETE aponta é removido do servidor.Tal como acontece com as operações PUT, o método HTTP DELETE é idempotente e inseguro.

Método PATCH

Às vezes, as representações de objetos ficam muito grandes. A exigência de que uma operação PUT sempre envie uma representação completa de recursos ao servidor é um desperdício se apenas uma pequena alteração for necessária em um recurso grande.

O método PATH HTTP, adicionado ao Protocolo de Transferência de Hipertexto de forma independente como parte da RFC 5789 , permite atualizações de recursos existentes. É significativamente mais eficiente, por exemplo, enviar uma pequena carga útil em vez de uma representação completa de recursos para o servidor.

Método HEAD

O método HTTP HEAD simplesmente retorna metadados sobre um recurso no servidor. Este método de solicitação HTTP retorna todos os cabeçalhos associados a um recurso em uma determinada URL, mas na verdade não retorna o recurso.

O método HTTP HEAD é comumente usado para verificar as seguintes condições:

• O tamanho de um recurso no servidor.
• Se existe um recurso no servidor ou não.
• A data da última modificação de um recurso.
• Validade de um recurso armazenado em cache no servidor.

Método CONNECT

A operação connect é usada para criar uma conexão com um recurso do lado do servidor. O alvo mais comum do método HTTP CONNECT é um servidor proxy, que um cliente deve acessar para sair da rede local.

Os designers de API RESTful raramente interagem com o método de solicitação CONNECT HTTP.

Método OPTIONS

O servidor não precisa oferecer suporte a todos os métodos HTTP para todos os recursos que gerencia.

Alguns recursos suportam as operações PUT e POST. Outros recursos suportam apenas operações GET.

O método HTTP OPTIONS retorna uma lista de quais métodos HTTP são suportados e permitidos.

Método TRACE

O método TRACE HTTP é usado para diagnóstico, depuração e solução de problemas. Ele simplesmente retorna um rastreamento de diagnóstico que registra dados do ciclo de solicitação-resposta.

O conteúdo de um rastreamento geralmente é apenas um eco do servidor dos vários cabeçalhos de solicitação enviados pelo cliente.

Existem mais de 30 métodos HTTP, em breve irei abordar em um novo post, espero que tenha ficado bem claro.

Em um mundo cada vez mais orientado pela tecnologia, a implantação rápida e segura de software tornou-se uma prioridade para empresas que buscam se manter competitivas. Nesse cenário, estratégias de implantação eficientes ganham destaque, e hoje exploraremos cinco abordagens essenciais: Canary Releases, Blue-Green Deployment, Feature Toggles, A/B Testing e Dark Launches.

1. Canary Releases

As Canary Releases, ou “liberações canárias”, são uma estratégia ousada, mas eficaz, para implementar novas funcionalidades de software de maneira gradual. Funciona da seguinte forma: uma pequena parcela dos usuários (a “canária”) recebe a atualização mais recente. Se não houver problemas detectados, a liberação é expandida gradualmente para um público maior. Isso permite identificar e corrigir problemas antes que atinjam a totalidade dos usuários.

2. Blue-Green Deployment

A estratégia Blue-Green Deployment envolve a criação de dois ambientes idênticos: um “azul” (em produção) e outro “verde” (um clone). A transição entre os ambientes é suave: o tráfego é redirecionado do ambiente azul para o verde. Se surgirem problemas, a reversão para o ambiente azul é simples e rápida. Essa abordagem elimina praticamente qualquer tempo de inatividade durante as atualizações, garantindo uma experiência contínua para os usuários.

3. Feature Toggles

As Feature Toggles, ou “interruptores de funcionalidades”, permitem ativar ou desativar determinadas funcionalidades em tempo real. Isso oferece flexibilidade e controle, permitindo que equipes liberem código inacabado ou recursos experimentais sem impactar negativamente os usuários. Os desenvolvedores podem, assim, realizar testes de funcionalidades no ambiente de produção antes de uma implantação completa.

4. A/B Testing

O A/B Testing, também conhecido como teste de divisão, envolve a apresentação simultânea de duas versões de uma página, recurso ou fluxo de trabalho para diferentes grupos de usuários. Isso possibilita a análise de métricas de desempenho e a coleta de feedback em tempo real, permitindo que as equipes tomem decisões informadas sobre qual versão oferece a melhor experiência para os usuários.

5. Dark Launches

As Dark Launches, ou “liberações ocultas”, são uma estratégia que permite lançar novos recursos sem que os usuários os vejam inicialmente. Isso é alcançado ao direcionar tráfego para os novos recursos apenas internamente, permitindo testes extensivos antes da exposição ao público. Essa abordagem minimiza os riscos associados a novas implementações, garantindo uma transição suave para os usuários finais quando os recursos são totalmente revelados.

Em conclusão, as estratégias de implantação mencionadas oferecem diversas abordagens para otimizar o processo de entrega de software, maximizando a eficiência e minimizando os riscos. Ao incorporar essas práticas em seu fluxo de trabalho de desenvolvimento, as equipes podem alcançar uma implementação mais suave e uma experiência do usuário aprimorada.

Espero que tenham gostado, vejam todo meu conteúdo aqui no medium:

Https://medium.com/@jonesroberto