User Stories: Use a inteligência coletiva para contar histórias melhores!

Este texto não abordará técnicas de escrita de User Stories, uma vez que já existe um “caminhão” de conteúdos que cumprem muito bem esse propósito. A ideia central aqui é trazer uma abordagem de uso das User Stories que preconiza a colaboração, o desenvolvimento das pessoas envolvidas e a construção de produtos e serviços com maior potencial de sucesso.

Vou começar com uma simples pergunta para facilitar o entendimento desta proposta de como as User Stories podem ter um papel fundamental na construção colaborativa de produtos digitais: Qual é o objetivo de uma User Story?

De forma pragmática, elas têm o objetivo de servir como lembretes estruturados de uma característica que um produto deve ter a partir da visão do usuário que a utilizará.

Simples, não é mesmo?

Acredito que, apesar da simplicidade, temos muitos benefícios ao utilizarmos as User Stories como um dos principais artefatos para nos guiar pelo desafiador caminho do desenvolvimento de produtos digitais. Contudo, ainda vejo alguns times deixando de aproveitar o poder de engajamento e colaboração que o processo de concepção baseado nesta ferramenta pode proporcionar.

Frequentemente as US são adotadas como um “documentos de requisitos ágeis”, são escritas por um PO ou Analista de Requisitos em uma ferramenta de gerenciamento de atividades utilizando a estrutura básica de 3 partes (Quem?, O que? e Para quê?) e com minuciosos detalhes de implementação e validação, que em alguns casos chegam até a descrever detalhes técnicos do que será construído. Com a documentação “completa” é feito o “hand-over” para os desenvolvedores do time ou, em um cenário pior, para um time responsável pelo desenvolvimento.

Alguns problemas desta abordagem:

Na maioria dos contextos, esta abordagem implica em alguns problemas que afetam diretamente a todos os envolvidos no processo de desenvolvimento do produto:

• Fluxo de trabalho em cascata, com “hand-over” de negócio para time técnico;
• Comando e Controle, pois há um time responsável por criar e outro por executar, e ao final o criador valida o que foi construído;
• Detalhes de implementação definidos em um momento em que ainda não se tem visão de todos os desafios técnicos que serão enfrentados no desenvolvimento da nova característica;
• Sobrecarga de trabalho de POs e Analistas de Requisitos, além da sobrecarga cognitiva pela necessidade de conhecer detalhes técnicos para avaliar a viabilidade da solução proposta;
• Deixamos de promover a comunicação e colaboração entre os diferentes atores do processo de desenvolvimento;
• Time de desenvolvimento sem “ownership” por não participar efetivamente do processo de criação/evolução do produto. (Como se sentir dono de algo quando não somos protagonistas no processo de construção?);
• Abdicamos do poder da experiência e inteligência coletiva em favor da visão mais restrita de uma pessoa.

Essa não é uma lista exaustiva, porém acredito que os problemas descritos já nos convidam a uma reflexão de como evitar muitos deles e como podemos criar ambientes de desenvolvimento de produtos muito mais eficazes e engajadores.

Contando histórias de usuários de forma colaborativa.

Apesar do efeito negativo e da complexidade para resolver alguns dos problemas gerados pela prática descrita acima, a solução pode ser iniciada com uma mudança de procedimento baseada em uma visão mais ampla do objetivo das User Stories:

As User Stories têm o objetivo de servirem como lembretes estruturados de uma característica que um produto deve ter a partir da visão do usuário que a utilizará e servem como ponto de partida para a discussão de um grupo multidisciplinar envolvendo os “stakeholders” de negócio e o time de desenvolvimento em busca do melhor caminho para se atingir o objetivo proposto.

A parte em destaque, adicionada ao objetivo citado anteriormente, sugere que ao invés de utilizarmos as User Stories como um documento contendo o que deve ser desenvolvido (já com suas regras de negócio e critérios de aceitação) passemos a usá-las como um catalisador de colaboração onde as diferentes vivências e skills dos especialistas de produto se juntam aos skills do time técnico. A sugestão aqui é realizar cerimônias onde a validação e elaboração dos requisitos das User Stories sejam construídos por um grupo envolvendo especialistas de produto e desenvolvedores.

Está cada vez mais claro que o trabalho do conhecimento se beneficia muito da colaboração e da inteligência coletiva. Então, por qual razão não tirarmos proveito dessa característica humana ancestral, que acelerou nossa evolução como espécie, para criar produtos melhores e ambientes de trabalho com pessoas mais satisfeitas e felizes?

Evidente que existirão desafios após promover a mudança, nem todos estarão prontos para colaborar de forma efetiva, ou mesmo, se sentirão à vontade com a nova responsabilidade, mas com o passar do tempo a maioria se engajará e passará a não abrir mão de ser protagonista desta construção.

Recentemente, o time de Arquitetura da Neogrid, ao qual faço parte, fez a transição para usar as User Stories com mais efetividade e os benefícios já começaram a aparecer. Aumento na colaboração, maior preocupação com os resultados, e não apenas com entregas de tarefas, maior autonomia e sentimento de dono. Outro grande valor que essa mudança trouxe também é saber que todos têm a possibilidade de ter um papel relevante para proporcionar, cada vez mais, a melhor experiência possível para os nossos clientes.

Que tal também colocar a inteligência coletiva a favor do seu produto e da sua organização?

Obrigado e até a próxima!