Feedback

Seja o cliente de seu produto

Postado em

A proximidade com seu cliente, buscando feedbacks frequentes são fundamentais para o bom andamento de um client-feedbackprojeto e evolução de um produto. Bom, isso deve estar muito claro para todos e não ser novidade para ninguém. Porém, o objetivo desse post é indicar que devemos ir um pouco mais além do que só receber feedback do cliente. Precisamos, de fato, sentir a dor que ele está sentindo.

Mas como assim sentir a dor do cliente? O que isso significa? Bem, acredito ser fundamental para uma evolução eficiente de um produto o uso interno dele, pela equipe que o vende e principalmente o desenvolve. Muitas empresas acabam desenvolvendo o produto e não o usam efetivamente no dia a dia. Apenas fazem testes, montam ambientes de demonstração e se baseiam na percepção dos clientes. Mas nem sempre isso é suficiente.Satisfação-do-cliente

Já vivenciei situações que os colaboradores da empresa não conheciam as funcionalidades do produto. Isso porque não o usavam efetivamente. Se você desenvolve software, também já deve ter vivenciado isso. Principalmente quando no desenvolvimento há diferentes tecnologias e módulos, e pessoas que não trabalham em todas as áreas. Acabam surgindo ilhas de conhecimento, não tendo uma visão sistêmica de todo o produto. Isso é um perigo e pode gerar um produto com ótimas funcionalidades isoladas e que não se comunicam adequadamente entre si.

Em experiências passadas, percebo que algumas vezes o feedback negativo do cliente parece exagerado pela equipe interna. Parecemos pais que não gostam quando outras pessoas falam mal de seus filhos. Porém, ao visualizar exatamente o cenário do cliente, utilizando o sistema, percebe-se que não houve exagero algum. Nesse momento, temos que guardar um pouco do nosso orgulho e perceber que realmente há lacunas no produto, e que ele, de fato, precisa ser melhorado.practice_makes_perfect_254524251

Utilizar o produto que você desenvolve parece um pouco óbvio, não é? Mas nem sempre é. Por exemplo, se você desenvolve uma solução de mobilidade para Windows Phone e ninguém da equipe possui um smartphone com esse sistema operacional? E se você utiliza o produto, mas não realiza a integração via arquivos ou API com outro sistema? E se você desenvolve uma solução específica para farmácias? Perceba que nem sempre é simples utilizar realmente todos os recursos do seu sistema.

Mas eu insisto. Dentro do possível, crie situações onde sua equipe utilize o produto no cotidiano. Uma utilização real, onde necessita de dados reais e regras de negócio bem mapeadas no sistema. Você, mais do que ninguém, conhece o produto que você desenvolve e sua empresa. Pense numa forma de adaptar um ao outro. Isso irá gerar uma maior visão sistêmica do produto, entendendo as intersecções entre módulos e tecnologias. Irá também antecipar possíveis problemas ou lacunas no produto que precisem ser ajustadas. Seja você o primeiro cliente de seu produto.

 

TDC 2014 Florianópolis

Postado em Atualizado em

Estive por um longo período afastado do blog, sem postar nada. O que aconteceu nesse período? Muitas coisas, com certeza. Vários novos assuntos surgiram e mudanças ocorreram na minha vida, e na própria análise de negócios. Durante esse período, infelizmente acabei perdendo o hábito de postar aqui no blog Análise Ágil de Negócio.

O que me20140522_210149 levou a retomar o blog? Bem, já tinha esse projeto pessoal e estava postergando, por N motivos. Porém, a participação no TDC 2014 Florianópolis me fez refletir que já tinha passado a hora de fazer isso. O tempo estava passando e eu perdendo a oportunidade de realizar essa troca de aprendizado entre todos.

Conforme citado acima, participei no TDC 2014 Florianópolis pela primeira vez como palestrante. Foi uma experiência incrível, onde aprendi muito. Eu e meu colega Rafael Helm palestramos na trilha Análise de Negócios. Nossa palestra “Os desafios na gestão de roadmap de produto em equipes ágeis”, contou de forma breve como realizamos a gestão de roadmap de produto na uMov.me. Buscamos explicar como buscamos gerar maior alinhamento entre a equipe de desenvolvimento e a estratégia da organização. Falamos sobre priorização, estimativa, planejamento e entrega das funcionalidades, entre outros pontos fundamentais para atingirmos os objetivos definidos para o produto.

TDC Vale destacar a qualidade do evento, que como sempre é excelente. Boas trilhas, ótimas palestras e uma organização impecável. Com certeza vale o investimento de ir até Florianópolis e obter um grande volume de conhecimento em poucos dias. Estive lá entre os dias 16 e 18 de maio, e tive o privilégio de ter acesso a ótimos materiais nas trilhas Análise de Negócios, Agile e Management 3.0. Buscarei falar mais sobre os assuntos abordados no evento nos próximos posts do blog.

O fato de ter estado no evento, e ter acompanhado inúmeros temas relevantes para compartilhamento e estudo, me fizeram sair da inércia. 🙂 Há muito conteúdo para estudar e compartilhar com todos, buscando uma troca maior de conhecimento e experiências vividas. Inclusive já estou preparando submissões para novos eventos ainda esse ano, como Agile Brazil 2014 (submissões já abertas) e TDC 2014 Porto Alegre. Acredito que devemos buscar um aprendizado constante, uma atitude e um desafio novo a cada dia. E palestrar para os profissionais qualificados que se encontram nesses eventos, compartilhando um pouco das minhas experiências vividas, é uma aprendizado enorme e uma grande m0tivação para seguir desempenhando o meu papel da melhor forma possível.

Fique ligado nos posts e novidades do blog. Estarei postando no mínimo 2 vezes por mês, buscando incluir um conteúdo variado sobre análise de negócio, passando um pouco de experiências enfrentadas na análise e temas ligados diretamente a área. Conto com a colaboração de vocês para comentarem e levantarem novos assuntos para discussão.

Afinal, está pronto ou não para entregar?

Postado em Atualizado em

“Se criarmos um preview da tela para auxiliar na configuração, não seria melhor? E se a gente criasse um novo passo indicando a situação atual do cadastro? E se tivéssemos uma lista múltipla ao invés de um combo na configuração? Mas essa relação 1 x N não precisa ser N x N?” Esses são alguns exemplos básicos de perguntas que muitos times enfrentam. Saber se a nova funcionalidade está realmente pronta para entrega ao cliente é uma dúvida enfrentada muitas vezes por muitas equipes de desenvolvimento.

A questão que precisamos entender é que as respostas não estão com a gente. Somente há uma resposta que deve ser avaliada e levada em consideração: a posição do cliente. É ele que deve dizer se o que foi feito agrega ou não ao seu negócio, se precisa de melhorias e ajustes, e se está contemplando sua necessidade ou não. É ele que tem o poder

O fato é que muitas vezes nossa visão sobre determinada funcionalidade não está de acordo com o seu uso efetivo. Na prática é que realmente vamos validar se o que foi feito ajuda ou não o cliente. Muitas vezes, o cliente não está preocupado com preview, wizards, telas de seleções múltiplas, entre outras coisas. O que o cliente realmente espera é que a funcionalidade atenda a sua necessidade e resolva o seu problema. É por isso que uma quantidade enorme de software desenvolvido nunca é utilizado, conforme pode ser visto no report do Standish Group abaixo.

Não estou dizendo com isso, que devemos esquecer as melhores práticas de desenvolvimento e os cuidados com a usabilidade do produto. Com certeza são questões muito importantes e que agregam ao produto, tornando seu uso melhor. Mas já vi softwares com uma usabilidade fantástica e com vários recursos avançados que foram um fracasso. E também vi softwares com interface bem simples e poucos recursos serem um sucesso absoluto.

O segredo muitas vezes está na simplicidade. Quanto mais simples e objetivo for para o usuário, melhor será sua experiência no uso do sistema. E se você está com dúvida em relação a qual padrão utilizar, e fica pensando se a tela ficará melhor do jeito X ou Y, sugiro que priorize a forma mais simples e fácil. Afinal de contas, você não tem a resposta certa mesmo. A resposta está sempre com o cliente.

Por isso é importante sempre ter a participação do cliente na construção do software. Ele ajudará a nortear o desenvolvimento, indicando o que agrega mais valor e como. Os feedbacks dos clientes são fundamentais para garantir o sucesso no desenvolvimento do produto. E quanto mais cedo o feedback, melhor. Essa é a grande vantagem de um desenvolvimento iterativo e incremental, sempre buscando o feedback do cliente e a melhoria do produto durante a sua elaboração, sem aguardar um retorno somente ao final de todo o desenvolvimento.

Afinal, está pronto ou não para entregar?

Além disso, não devemos ter medo de entregar uma parte do software, pensando que ainda falta muito a desenvolver. Temos que entregar sempre o mínimo possível que temos para ir agregando valor ao produto e buscando com isso feedback do cliente. Se com o mínimo já atende o cliente, então porque vamos realizar o resto? E se com o mínimo já percebemos que não estamos no caminho certo, porque vamos continuar nesse caminho? Pensar no MVP – Minimum Viable Product (falaremos mais sobre isso em outro post) e ir já realizando a prova prática dele, entregando ao cliente, é um ponto importante para descobrirmos realmente se está ou não está pronto.