Olhando as trilhas de análise de negócios e design thinking do TDC São Paulo que rolou semana passada, vi algumas palestras sobre negócios + design thinking e desenvolvimento ágil + design thinking… Falava disso em 2013, quando comecei meus estudos sobre design thinking (em especial, quando estava fazendo minha monografia da pós sobre desenho de processos de negócio usando práticas de design – outro tema que aparece bastante em palestras hoje em dia). Inclusive notei que um dos palestrantes gosta bastante dos meus slides no Slideshare (risos).
Em uma série de 3 posts vou falar um pouco sobre Design Thinking + desenvolvimento ágil. Este número é proposital pois acredito que para uma junção entre Design Thinking e desenvolvimento ágil têm três passos: entender o que é design Thinking, avaliar o que pode ser levado para para o seu time e o reforço cultural. Esta é a minha visão, já pude criar e colocar alguns times sob tais variáveis e tenho minhas conclusões um pouco diferentes das que tinha quando comecei a estudar o assunto em 2012 e aplicar em 2013. Vamos lá?
Começar falando do entendimento sobre design thinking é uma tarefa árdua hoje em dia, já que o termo simplesmente deu um salto (positivo, ao meu ver) de popularidade após diversos relatos de grandes players do mercado que aplicaram práticas e adotaram o mindset de design na concepção de novos produtos e serviços. Isso corrobora a frase do Tim Brown, da IDEO, sobre tecnologia.
"Sozinha, a tecnologia não necessariamente resulta em melhor experiência do cliente"
Hoje podemos dizer que o design thinking é uma abordagem com foco nos princípios do design, que ajudam profissionais de diversas áreas a entender as necessidades dos seus clientes, levando em consideração os desejos, experiências e a viabilidade das soluções encontradas, criando novos mercados ou modificando mercados existentes. Também existe a vertente que simplifica o que é design thinking como uma metodologia usada pelos designers para resolver problemas complexos e encontrar soluções para clientes. Particularmente não gosto tanto desta definição hoje, uma vez que o processo de design pode ser incorporado para diversas áreas além dos designers de profissão.
O design thinking busca resolver problemas complexos. O desenvolvimento de software é algo complexo por natureza. Dizem que bons programadores são aqueles que conseguem diminuir a complexidade em ambientes complexos. Quando ouvi falar sobre design thinking pensei "posso incorporar isso nas minhas práticas enquanto desenvolvo softwares" e daí passei a observar mais os pontos onde o processo ágil de desenvolvimento poderia se beneficiar dos pilares da empatia, experimentação e colaboração.
E começando pela empatia, a primeira coisa que pensei foi: "precisamos colocar a empatia como premissa de um time ágil". E isso é uma tarefa homérica, já que trabalhamos horas a fio em nossas telas, escrevendo estórias que foram compiladas em uma série de entrevistas e que serão traduzidas em linguagem de máquina por programadores que, muitas vezes, nunca deram um "oi, tudo bem?" para quem vai consumir a sua solução (que pode, no futuro, ser ele próprio o consumidor final)
Por isso, gosto de dizer para times ágeis o seguinte:
Em um time ágil, todos devem entender o lado do cliente e pensar em soluções que sejam tecnologicamente viáveis para gerar a melhor experiência do usuário, e não de quem está pagando ou coordenando a criação de um produto.
Sério, criar produtos é uma coisa que muita gente ainda insiste em enfiar trocentas features que nunca serão usadas ou são projetadas de acordo do mundo da pessoa que é um proxy do cliente final (gerente de projetos do cliente, analista…). Pior: insistimos em criar produtos, onde o foco da sociedade hoje é criar serviços (isso é assunto para o próximo post).
Claro que a visão do produto/serviço de um time ágil depende do trabalho do Product Owner (PO). E muito. Ele, na maioria das vezes, foca tanto em priorizar o valor que se esquece de mostrar o que é valor para o cliente: se produzir software para uma central automotiva, o valor é aquilo que vai gerar uma satisfação maior para a empresa A emitir a nota fiscal para a empresa B e a gerência da empresa A ficar contente com o progresso OU é fazer com o que o time tenha em mente que a segurança do motorista, bem como a praticidade de uso são valores indispensáveis para quem procura o serviço?
E aí surge a dúvida: "Como ajudar o time neste papel?", um PO me perguntou uma vez.
Existem algumas ferramentas do design thinking que ajudam o time a manter uma memória "viva" sobre o valor do produto como Product Vision Box, estudo de personas, Touch Points Mapping (Jornada de usuário), Storyboards e seções Service Usability. Deixar o conteúdo (pesquisas, resultados) a mostra vai criar uma espécie de memória auxiliar para todos envolvidos no processo de criação do produto/serviço. Hoje em dia, diversos conceitos do Design Thinking já se fazem presentes em sessões de levantamento de necessidades dos clientes, bem como a cultura de ir direto na fonte. Os analistas de negócio de hoje precisam entender que software é complexo demais para ser definido "de TI para TI" e ter uma aproximação mais humana e menos técnica dos clientes. Vai construir uma solução para uma operadora de supermercados, ao invés de ouvir o que a TI acha, que tal ouvir a menina do caixa? Vai fazer uma solução de pagamento de contas em bares? Que tal levantar requisitos na fila da balada ao invés de perguntar o que o rapaz da TI quer para não quebrar o servidor dele?
Entender o que é o pensamento do design pode ser demorado e cheio de armadilhas: pessoas que não acreditam nos pilares de empatia e experimentação, pessoas que acham que podem criar um processo de design thinking na sua organização e um sem número de "mas" que um time ágil já ouviu quando duvidavam do scrum (duvidavam? Acho que ainda duvidam). O pensamento do design deve ser entendido como um conjunto de conceitos que podem ajudar um time ágil a elevar o patamar dos produtos/serviços criados pelo time. Se o time comprar a ideia e trabalhar de maneira inteligente, fazendo entregas menores e com maior valor para o cliente final e alinhado aos desejos destes, o resultado final é um melhor produto/serviço… Podem haver falhas, mas elas serão úteis para todo o processo de criação. Falhar, divergir e mudar a mentalidade de produtos para serviços… É isso que vamos tratar no próximo post. Até lá.