Concrete Logo
Hamburger button

Você precisa conversar com usuários reais para construir bom software

  • Blog
  • 10 de Fevereiro de 2014
Share

*Post de Joca Torres, autor convidado

** Publicado originalmente em 12 de abril de 2012, no Joca on Stuff.

Acompanho de perto as publicações sobre a nossa indústria de software e TI, não só para ficar por dentro de novas tecnologias mas também para aprender sobre novos processos, novas formas de se fazer software. Foi assim que aprendi sobre metodologias ágeis, kanban, lean, TDD, BDD, integração contínua, deploy contínuo, entrega contínua, DevOps e tantas outras metodologias para poder aplicá-las no dia. Algumas publicações chegam até a fazer mapas classificando tecnologias, linguagens, plataformas, ferramentas e metodologias com recomendações do tipo “adote”, “teste”, “avalie”, “espere”. Esses mapas são a visão dos editores dessas publicações sobre o que é tendência em nossa indústria. Certa vez eu me toquei que todas essas publicações deixam de lado duas peças essenciais desse quebra-cabeças que é fazer software: Desenho de Experiência de Uso (XD, em inglês) e Gestão de Produtos.

No meu ponto de vista, Gestão de Produto e Desenho de Experiência de Uso são técnicas tão importantes para projetos de software de sucesso quanto DevOps, Entrega Contínua, Testes, Agile e Lean.

– O papel de Gestão de produto implica em dizer o que precisa ser feito e em que ordem.

– O papel do Desenho de Experiência de Uso é dizer como o que precisa ser feito deveria ser feito, da perspectiva da experiência do usuário.

É bem difícil desenvolver um bom software sem esses dois papéis e suas técnicas. Ambos deveriam não só constar de todo mapa de classificação de metodologias e ferramentas para desenvolvimento de software, como deveriam sempre aparecer com a recomendação de “adote”.

Gestão de Produto não é só para sistemas que se tornarão produtos, mas para qualquer sistema, desde que este sistema tenha usuários. O papel de Gestão de Produto é a ligação entre usuários do sistema e o time que construirá o sistema. É diferente do papel de analista de negócios, que é mais focado no negócio e nos donos do sistema. E é diferente do papel de Desenho de Experiência de Uso, que é mais focado em como o usuário interage com o sistema.

A Gestão de Produto é responsável por conversar com usuários reais do sistema, entendendo a dor que o sistema deve resolver para estes usuários, e ajudando a definir o que precisa ser desenvolvido. Note que um sistema sempre será propriedade de uma empresa, que irá te pagar para desenvolver esse sistema, por exemplo um sistema de ticket, um internet banking ou um sistema de e-commerce. Essa empresa vai te pedir um conjunto de funcionalidades para que o produto atinja certo objetivo de negócio. Mas a coleta de requerimentos estará incompleta se nós não ouvirmos os usuários reais, que normalmente serão os clientes da empresa que é dona do sistema.

Se você tem um ótimo grupo de desenvolvedores, QAs e analistas de negócio, todos veteranos no uso de Agile, Lean, Testes, DevOps e Entrega Contínua, tudo isso será inútil se você não for capaz de definir qual é o conjunto mínimo de características que podem criar valor para o cliente na primeira entrega. E subsequentemente definir as características mínimas a serem desenvolvidas e implantadas que traga o melhor valor para os usuários reais. O movimento Lean Startup chama isso de MVP – Minimal Viable Product, ou Produto Mínimo Viável. Mark Denne e Jane Cleland-Huag, autores de “Softwares by Numbers”, publicado em 2003, cunharam outro termo para este grupo mínimo de características. Eles chamaram de MMF – Minimal Marketable Feature.

O Manifesto Ágil diz que nós deveríamos valorizar “a colaboração do cliente antes da negociação do contrato” e define como seu primeiro princípio que “nossa maior prioridade é satisfazer o cliente por meio da entrega rápida e contínua de software de valor”. O problema com esses dois trechos é que ele assume que o cliente, que é o proprietário do sistema, sabe o que é “software de valor”. Entretanto, o cliente normalmente sabe o que é “software de valor” para ele, ou seja, ele sabe quais são os objetivos de negócio que ele quer atingir com o sistema. O problema é que o cliente não conhece seus próprios clientes/usuários o suficiente para definir os requisitos que deveriam ser desenvolvidos, ou seja, o cliente não sabe o que é software de valor para seus próprios clientes/usuários.

É papel da Gestão de Produto entender os usuários de um produto/sistema, o problema que os usuários têm, e trazer essa informação de volta para os desenvolvedores e os profissionais de experiência do usuário. Assim, esses três papéis podem vir em conjunto podem gerar um produto/sistema que resolve o problema dos usuários e, ao mesmo tempo, faz com que os objetivos de negócio do dono do sistema sejam atingidos.

O que você acha? Concorda? Discorda? Deixe seus comentários abaixo! =)