Eduardo Batista

Meu produto digital vai dar certo?

Com certa frequência sou chamado para conversar sobre novas ideias especialmente quando o assunto é software.

"Estou com a ideia X, o que você acha?". Depois de tantas experiências tenho aprendido que a relevância do problema e a criatividade empregada na solução têm muita importância, mas que por uma relação de precedência, devemos investir bastante no entendimento do problema. A boa compreensão do problema vai direcionar a solução e a experiência relacionada.

Existem 4 ferramentas que eu gosto muito de usar em tempos diferentes:

5W2H e OKR: Antes mesmo de iniciar qualquer exploração;
Design Thinking: Pra explorar problema e solução;
TAM, SAM, SOM: Quando o problema a ser atacado está definido, estudamos o tamanho do mercado.

O primeiro passo, portanto, é resolver um problema real de alguém. E é importante entender esse alguém, a persona: a pessoa para a qual a sua solução resolve aquele problema. Ainda que você tenha percebido essa oportunidade observando uma dor que você tenha, é importante delinear um traço comum da sua persona para você buscar semelhantes para validação do problema e da solução.

Você pode observar relatos das pessoas, dificuldades no seu próprio dia a dia, estudar temas relevantes e identificar oportunidades. Enfim, as fontes de problemas a serem resolvidos são muitas.

Design Thinking é um processo que recomendo fortemente para essas etapas que comumente chamamos de Discovery. As etapas te guiam não só para descobrir legitimamente os problemas, mas a idear soluções que poderiam resolvê-los e como testá-los.

E pra testar tem ferramentas diversas que proporcionam baixo custo e rápido tempo de desenvolvimento: NoCode, LowCode, prototipação de alta, de baixa, Sem Codar, etc.

Só de posse dos resultados da exploração do problema e experimentação da solução, validação do conceito é que eu acho válido investir em desenvolvimento de software.

Como você, seu time e sua empresa exploram as reais necessidades de seus clientes e desenham soluções?

Meu produto digital vai dar certo?

Com certa frequência sou chamado para conversar sobre novas ideias especialmente quando o assunto é software.

"Estou com a ideia X, o que você acha?". Depois de tantas experiências tenho aprendido que a relevância do problema e a criatividade empregada na solução têm muita importância, mas que por uma relação de precedência, devemos investir bastante no entendimento do problema. A boa compreensão do problema vai direcionar a solução e a experiência relacionada.

Existem 4 ferramentas que eu gosto muito de usar em tempos diferentes:

5W2H e OKR: Antes mesmo de iniciar qualquer exploração;

Design Thinking: Pra explorar problema e solução;

TAM, SAM, SOM: Quando o problema a ser atacado está definido, estudamos o tamanho do mercado.

O primeiro passo, portanto, é resolver um problema real de alguém. E é importante entender esse alguém, a persona: a pessoa para a qual a sua solução resolve aquele problema. Ainda que você tenha percebido essa oportunidade observando uma dor que você tenha, é importante delinear um traço comum da sua persona para você buscar semelhantes para validação do problema e da solução.

Você pode observar relatos das pessoas, dificuldades no seu próprio dia a dia, estudar temas relevantes e identificar oportunidades. Enfim, as fontes de problemas a serem resolvidos são muitas.

Design Thinking é um processo que recomendo fortemente para essas etapas que comumente chamamos de Discovery. As etapas te guiam não só para descobrir legitimamente os problemas, mas a idear soluções que poderiam resolvê-los e como testá-los.

E pra testar tem ferramentas diversas que proporcionam baixo custo e rápido tempo de desenvolvimento: NoCode, LowCode, prototipação de alta, de baixa, Sem Codar, etc.

Só de posse dos resultados da exploração do problema e experimentação da solução, validação do conceito é que eu acho válido investir em desenvolvimento de software.

Como você, seu time e sua empresa exploram as reais necessidades de seus clientes e desenham soluções?

Um erro em um software pode vir de muitas formas e tamanhos diferentes, e o custo nem sempre é financeiro. O software está em quase tudo o que fazemos atualmente, e as consequências quando as coisas dão errado podem ser desde o custo de vários bilhões de reais até a perda de vidas humanas.

Ariane 5, vôo 501: O foguete de lançamento de satélite não tripulado da Europa reutilizou o software de seu antecessor, o Ariane 4. Os motores mais rápidos do Ariane 5 exploraram um bug que não foi encontrado nos modelos anteriores. Trinta e seis segundos depois de seu lançamento inaugural, os engenheiros do foguete apertaram o botão de autodestruição após várias falhas do computador. Custo de quase US $ 8 bilhões.

Abertura do Terminal 5 de Heathrow: Pouco antes da abertura do Terminal no Reino Unido, a equipe testou o novo sistema de manuseio de bagagem construído para transportar a grande quantidade de bagagem despachada todos os dias. Os engenheiros testaram o sistema exaustivamente com mais de 12.000 peças de teste de bagagem. Funcionou perfeitamente em todas as execuções de teste, menos no seu primeiro dia de funcionamento real. Acredita-se que cenários da “vida real”, como remover uma mala do sistema manualmente quando um passageiro deixou um item importante em sua bagagem, fizeram com que todo o sistema se confundisse e desligasse. Nos 10 dias seguintes, cerca de 42.000 malas deixaram de viajar com seus proprietários e mais de 500 voos foram cancelados.

Outras falhas famosas:

–1985 – Devido a uma falha no software de um equipamento médico, pacientes morreram devido a overdose de radiação
–1991 – Na Guerra do Golfo, a bateria anti-míssel Patriot ficou operando por mais de 100 horas, causando uma falha em um acumulador. Um míssel Scud atingiu um acampamento millitar
–2003 – Uma falha no sistema de pagamento de aponsentadoria nos EUA causou o envio de milhares de cheques inválidos

Você sabe, um bom desenho de solução e uma arquitetura bem projetada podem mitigar o risco de uma catástrofe.

Ficar pouco tempo na empresa é um problema? O que é pouco tempo? Quanto é muito tempo?

Parece que permanecer mais de 2 anos na mesma empresa é coisa do passado se considerarmos que as big techs são as grandes geradoras de tendências.

E se ao invés de olhar para a métrica de tempo total, olhássemos para métricas de engajamento, contribuição e felicidade?

Você é ouvido? Tem sido Feliz? Contribui? Aprende? Evolui?

Não? Há algo que vc possa fazer? Sim? Se proponha legitimamente a isso por um tempo.

Não? Não sei quanto tempo se passou, mas você tem fortes sinais que você pode contribuir em outro lugar.

Certa vez um especialista de uma renomada consultoria de software de BH me perguntou: Estou fazendo DDD e estou com uma dúvida: onde eu coloco as chamadas às classes de infraestrutura para comunicação com o banco de dados? Nas classes de domínio?

Na maioria dos casos essas pessoas não entendem a essência do DDD nem seus princípios mais centrais. DDD trata de discussão, escuta, compreensão, descoberta e valor percebido de negócio, tudo em um esforço para centralizar o conhecimento.

Em muitos desses casos não houve uma preocupação legítima em aprender profundamente o contexto/domínio do negócio e os fundamentos centrais da Orientação a objetos.

Passo a passo para aprender DDD: Aprenda muito sobre o negócio no qual trabalha. Converse com os especialistas, seja curioso, tire todas as suas dúvidas. Independentemente de como abordar tecnicamente, você deve entender profundamente o problema. Aprofunde seus conhecimentos em orientação a objetos. Junte os conhecimentos prévios e leia sobre DDD, tenho certeza que muita coisa coisa não será novidade por lá.

“Uma arquitetura técnica incrível para o problema errado será um fracasso no curto prazo. Uma arquitetura ruim para o problema certo, será um fracasso no médio prazo. Uma boa arquitetura que comporte mudanças ao longo do tempo para o problema certo será sucesso sempre.”.

O método Desenho de Solução não é sobre DDD, mas ensina em detalhes a técnica, como, quando e onde utilizá-la, além de combinar com outras técnicas.

Me mande uma mensagem, vamos falar mais sobre Desenho de Solução.

Propriedade coletiva, arquitetura de software, utopia e maturidade de times de desenvolvimento de produtos digitais.

O que você pensa a respeito?

As principais responsabilidades do arquiteto de software

1. Gerenciar os direcionadores arquiteturais
2. Criar a estratégia técnica
3. Gerenciar riscos técnicos
4. Exercer liderança técnica
5. Garantia da Qualidade

1. Entender as metas e restrições; ser protagonista do time de desenho de solução para definição do problema, idear, prototipar e testar as hipóteses de solução; capturar os principais atributos de qualidade;
2. Criar e documentar a visão e o roadmap técnico da solução;
3. Identificar, mitigar e gerenciar os riscos técnicos para assegurar que a arquitetura funcione;
4. Protagonizar definições técnicas; Facilitar práticas para a equipe de desenvolvimento; Dar coach aos membros do time; Incentivar os mais altos padrões de qualidade;
5. Garantir aderência a padrões, guias, princípios e práticas adequadas de desenvolvimento de software.

Stanford, 2017. Extensão do MBA.

E um pouco do Museu da História do Computador.

Ê saudade!

Qual o futuro do desenvolvimento e arquitetura de software?
 
Eu acredito em:

- Arquiteturas de software serão hiperplexadas;
- Programação com o poder do pensamento. Compilação em nuvem, feedback em smart glasses;
- Os vários apps vão sumir do mapa. A UX será voltada a superapps, assistentes virtuais, smart speakers, hologramas, smartwatches e smart glasses;
- LowCode e NoCode perderão espaço. A programação se torna disciplina obrigatória desde a educação primária;
- Blockchain governamental fecha cartórios. Advogados precisarão ser programadores.
 
Queria destacar a arquitetura hiperplexada. Nas últimas décadas as arquiteturas de software evoluíram de arquiteturas mainframe para monolíticas, em camadas e, recentementemente,  cloud-native.
 
Com o uso crescente de novas tecnologias, como: inteligência artificial, robótica, realidade aumentada, realidade virtual, IOT e redes 5G, surge a necessidade de uma nova geração de arquiteturas de software. A BCG cunhou o termo “arquiteturas hiperplexadas”.
 
Muitas empresas perceberam que para se manterem competitivas precisam digitalizar seus processos e reinventar seus negócios, promovendo na maioria dos casos, a tal da transformação digital. Naturalmente isso pede uma nova forma de se desenvolver software. O desafio é que muitos softwares nascem distribuídos hoje em dia, tendo que trabalhar em múltiplas clouds, em dispositivos específicos e em edge.
 
Hiperplexada porque as arquiteturas do futuro precisarão suportar a criação e a escala de aplicativos rapidamente, além de suportar novos tipos e paradigmas de programação, deployment e operação. Terão que suportar softwares largamente distribuídos, muitos tipos de dispositivos e novas experiências de usuários.
 
Nesse ponto, eu acho que o futuro tá logo ali.

Entendeu ou quer que desenhe?

Essa clássica pergunta, apesar de um tanto quanto arrogante, credita ao desenho o caminho para que os interlocutores tenham o mesmo entendimento do tema em debate.

O desenho ou um esboço é uma linguagem visual, composta por símbolos, notações, linhas e representações figurais.

Ao desenhar usamos nosso cérebro, não porque apenas libera endorfina, mas porque ajuda a criar novas conexões e caminhos. Quando desenhamos, usamos os dois lados do cérebro, o direito para a criatividade e o esquerdo para o pensamento lógico. Isso tanto fortalece e ajuda na habilidade de focar quanto na de pensar estrategicamente. Naturalmente, tomamos melhores decisões.

À minha maneira, tenho por prática desenhar tudo: Viagens, finanças, móveis, formato de times, metodologias, ideias de negócios. No mundo do software, aliás, acredito que problemas, dores, personas, processos e, principalmente, as complexas arquiteturas de software, PRECISAM ser desenhadas nas diferentes perspectivas a fim de garantir compreensão e o buy-in de todos os impactados. Não importa a forma nem a ferramenta, um desenho precisa ser feito e contemplar todas as principais perspectivas. Nesse contexto, existem ferramentas e notações que facilitam muito o esforço de modelagem. Tive a oportunidade de trabalhar com diversas, como: UML, BPMN, C4, SysML, Archimate, Powerpoint, Excalidraw, etc.

E eu queria me dirigir aos colegas arquitetos e desenvolvedores e perguntar: Vocês desenham as suas soluções? Qual a opinião de vocês a respeito do desenho/modelagem de arquiteturas? Qual ferramenta/notação vocês utilizam?