O que é Design Thinking

 

 

 

 

O que significa design thinking? Quais são suas etapas?

A primeira informação que deve ficar clara é que não é uma metodologia, e sim uma abordagem. Isso porque, quando pensamos em método, criamos a expectativa de ter às mãos uma fórmula matemática que se aplique indistintamente em qualquer situação. Não é o caso.

É uma abordagem que busca a solução de problemas de forma coletiva e colaborativa, em uma perspectiva de empatia máxima com seus stakeholders (interessados): as pessoas são colocadas no centro de desenvolvimento do produto – não somente o consumidor final, mas todos os envolvidos na ideia (trabalhos em equipes multidisciplinares são comuns nesse conceito).

O processo consiste em tentar mapear e mesclar a experiência cultural, a visão de mundo e os processos inseridos na vida dos indivíduos, no intuito de obter uma visão mais completa na solução de problemas e, dessa forma, melhor identificar as barreiras e gerar alternativas viáveis para transpô-las. Não parte de premissas matemáticas, parte do levantamento das reais necessidades de seu consumidor; trata-se de uma abordagem preponderantemente “humana” e que pode ser usada em qualquer área de negócio.

A razão de sua existência é a satisfação do cliente (interno ou externo), dádiva que só pode ser alcançada quando conhecemos em profundidade suas necessidades, desejos e percepções de mundo.

As etapas do design thinking podem, em geral, ser resumidas pelos seguintes passos:

1- Identificar onde encontrar oportunidades de inovação

“Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você se conhece, mas não conhece o inimigo, para cada vitória ganha sofrerá também uma derrota. Se você não conhece nem o inimigo nem a si mesmo, perderá todas as batalhas”. Este é um trecho de “A Arte da Guerra”, do filósofo chinês Sun Tzu, e que diz muito sobre o ponto que estamos abordando.

Descobrir onde encontrar caminhos para inovar envolve conhecer a si mesmo e ao ambiente externo. Conhecer seus pontos fortes, as fragilidades da concorrência, as condições macroeconômicas, etc. Análise SWOT, benchmarking, pesquisas de mercado e reuniões multidisciplinares te conduzirão às respostas para esse ponto.

2- Descobrir a Oportunidade de Inovação

Consequência direta do ponto anterior, aqui, pesquisas qualitativas e trabalho com soluções de Big Social Data podem indicar, muito além do setor, qual é, de fato, a oportunidade que o mercado desenha ao seu negócio.

3- Desenvolver a Oportunidade de Inovação (Produto ou Serviço)

O design thinking começa a tomar corpo nessa etapa. Aqui, iremos desenvolver o produto ou serviço partindo, não de pressuposições ou análises estatísticas frias (algo comum no mercado), mas a partir das necessidades e percepção de valor do cliente. Nesta etapa, poderemos lançar mão do Processo Heurístico para descobrir o diagnóstico e o Processo Criativo para gerar as possibilidades de produtos.

4- Testar as ideias — protótipos

Um MVP – Minimum Viable Product é uma bela dica do que se pode fazer nesse item. Para quem não sabe, MVP (muito usado em startups) é a versão mais simples de um produto, que pode ser lançada em período de testes, para verificar, sem grandes gastos, se sua ideia realmente atinge as necessidades do seu consumidor final.

5- Implementar a solução

Após testes com respostas positivas acerca de seu produto, ele já está pronto para ser lançado “aos leões”. É importante entender que o processo de desenvolvimento do produto é contínuo e incremental, ou seja, sua ideia irá ser melhorada permanente através um processo de copartipação entre todos os seus stakeholders (clientes, fornecedores, colaboradores internos, etc.).

Domain Driven Design

Domain Driven Design

Por Eric Evans

Todo software corporativo resolve problemas de negócio. E nada melhor do que o código fonte falar a mesma linguagem dos negócios em vez de tentar reinventar a roda com jargões e termos que não serão compreendidos pelas pessoas de negócios. Este livro ensina a criar uma linguagem comum entre desenvolvedores e usuários, e a pensar no design do código de uma maneira que favoreça o entendimento e a evolução do software através de padrões que colocam em primeiro lugar o domínio de negócio.

Versão em Inglês http://amzn.to/2DYqGe6 ou Português http://amzn.to/2Ds1EmJ

Domain-Driven Design – Resumo

Filosofia – filo (amor), sofia(sabedoria) – O software tem que ser importante para você.

Tracking complexity – O software não precisa ser complexo.

Heart of Software / Core Domain – O que faz as pessoas usarem o seu software e não usarem outro.

Domain – Tudo que compreende o software. Alinhamento com o negócio. Isolamento entre domínio. Reutilização. Mínimo acoplamento. Independente de tecnologia.

Modelo – é um gráfico

Domain model – A representação de uma domain.

Modelar um domínio – abstrair o que não é necessário, e focar no que é interessante.

Problemas de Comunicação – Fazemos presunções o tempo todo. Você acha que entendeu, mas não entendeu.

Ubiquitous Language – Existem um vocabulário em cada mercado. Por exemplo em um imobiliária.

Literate Programming –  When/Given/Then – BDD

Status quaestionis – Public request (PR), commit message etc.

Stop designing useless software architecture, Start coding useful software

Don’t Let Architecture Astronauts Scare You Article was written 2001, but It’s still up to date.

I disassemble two parts of that article that I’ve thought over:

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.

Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. Soap + WSDL may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA.

Alan Braz wrote in his Sametime message: Stop Talking, Start Doing. I found the ad video that explain the main idea, clicking on “Globalization” video.

In few words, we can brief both the article and the IBM Ad Video: Stop designing useless software architecture, Starting coding useful software.

Are you learning or using new technology because It is a hype or buzzword ?
Or are you learning or using new technology because It contributes to the bottom line ?
Any thoughts ?

Kleber Rodrigo de Carvalho

Paradigm based Polyglot Programming

Are you Polyglot Programmer ?
You can be Polyglot Programmer even so you have understanding just Java world.

How many languages are you using on the same project? If you go counting you will see that they are many. I mean XML, Java, XSLT, HTML, CSS… etc. But the reason why you are using almost all of them is that they happen to be mainstream and, oftentimes, they are the only language choice for a needed framework. You are actually almost obliged to use them. The choice is done for you. Style? CSS. Configuration? Often XML. Web interface description? Html. However, if you want to adopt true polyglot programming, you will have to face inevitable decision of language choice.

Read the full Article: Paradigm based Polyglot Programming