O Software que você produz é utilizado?

O Software que você produz é utilizado?

O software que você produz todo dia é utilizado? Qual parte dele é utilizado frequentemente? Qual parte dele é raramente utilizado ou nunca utilizado?

Em 23 de junho de 2016, eu participei o Scrum Gathering Rio e uma das melhores palestras que assisti foi a “Lean Products and the Validation Board” do Rodrigo Toledo. E eu repasso aqui a pergunta do Toledo:

Você sabe dizer quantas pessoas estão clicando em cada funcionalidade, em cada botão do seu software?

Se você não mede quais funcionalidades são mais acessadas no seu software, você não sabe como ele é utilizado e não tem feedback. Será que aquela nova funcionalidade que você colocou no ar, que você imaginou que seria matadora está sendo utilizada? Ou será que ninguém sabe que ela existe?

Uma das piores coisas que pode acontecer no desenvolvimento de software é produzir software que não é utilizado. É puro desperdício de dinheiro…

Mas, de onde vem essa preocupação?

Background

Utilização de funcionalidades Standish Group XP2002
Utilização de funcionalidades Standish Group XP2002

Muitos artigos e apresentações citam o estudo do Standish Group, apresentado Jim Jonhson na conferência XP de 2002, que cita que 64% das features de um produto são raramente utilizadas ou nunca utilizadas.

Muitos usam estes dados de forma generalizada, como se o estudo tivesse sido feito de forma extensiva. Na verdade, o estudo foi feito com 4 produtos de uso interno (veja o que o Mike Cohn fala sobre isso).

Apesar do estudo ser restrito, eu tenho certeza que vários softwares seguem uma tendência próxima da mostrada no gráfico. Na minha própria experiência eu já vi até sistemas inteiros que foram utilizados só uma vez e foram descartados em seguida.

De onde vem o desperdício?

Processos de desenvolvimento que se aproximam mais do modelo cascata tem mais chances de levar a funcionalidades que serão pouco utilizadas. Neste modelo, o Time e o Cliente são forçados a pensar em todos os requisitos muito antes de terem algum feedback dos usuários.

Outro fator é a desvinculação do requisito com o valor que ele gera para o usuário. Muitas vezes não nos preocupamos em pensar qual o perfil de usuários vai utilizar aquela funcionalidade? E por que ele vai utilizá-la? Por que aquela funcionalidade é importante para ele? E como isto está ligado ao objetivo do sistema ou do projeto?

Então, para onde vamos?

Quais os princípios devemos seguir para produzir software que seja utilizado? E parar de  jogar dinheiro fora?

Alguns princípios que eu sigo são:

  • Iterações curtas levam a mais feedback do usuário.
  • Software em produção em intervalos menores levam a mais feedback do usuário.
  • Identificar o valor de cada funcionalidade, de cada requisito para o software ou projeto.

Uma das técnicas que nos ajudam a identificar o valor das funcionalidade e fazer somente as que geram mais valor são as Histórias de Usuário.

Eu montei um mini curso de histórias de usuário. O mini curso é GRATUITO. São 3 vídeo aulas de cerca de 10 minutos cada. E um PDF de bônus.

Para ter acesso à esse mini curso, clique aqui e tenha acesso imediato.

Um abraço!

Seu comentário aqui

%d blogueiros gostam disto: