roadmap

Agile Brazil 2014

Postado em

Esse ano de 2014 está sendo um ano muito especial para mim. Foi o ano que comecei a palestrar em eventos, mostrando um pouco do meu trabalho e o que eu acredito que realmente agrega no desenvolvimento de software, utilizando a análise de negócios e os métodos ágeis como pilares fundamentais para a construção de um software eficaz.

47c70aad348dd9cf8f963eee6afa225f986c6630_original

Iniciei palestrando no The Developers Conference (TDC) em Florianópolis. Depois fui palestrante e coordenador da trilha Análise de Negócios no TDC em Porto Alegre, conforme já relatado nesse blog. E é com muito orgulho que palestro também esse ano no maior evento de métodos ágeis do Brasil, o Agile Brazil 2014, que ocorre em Florianópolis.

Estarei palestrando na próxima quinta (06/11) juntamente com meu amigo Rafael Helm, falando um pouco sobre os desafios da gestão de roadmap de produto em equipes ágeis.

Estou muito feliz e ansioso pela participação nesse grande evento, que já está com lotação máxima de inscrições. Com certeza teremos muita troca de experiências bacanas por lá. É uma forma de recarregar as baterias e seguir lutando pelas causas que acreditamos no desenvolvimento de software.

Para finalizar, fica a dica para quem acredita em seu trabalho e tem o objetivo de palestrar em algum evento. Não tenho medo. Lute pelos seus objetivos. Prepare-se na sua empresa, em casa, ou em algum evento menor. Mas não deixe seu sonho morrer. Com certeza, você irá verificar que aprende muito mesmo palestrando em eventos.

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.

Qual o momento certo para analisar uma nova funcionalidade?

Postado em Atualizado em

Fiz a análise completa de uma nova funcionalidade do sistema. Documentei os requisitos que serão criados e alterados. Montei o modelo do banco de dados. Quebrei a funcionalidade em pequenas tarefas e defini os critérios de aceitação para elas. Tudo que era previsto para iniciar o desenvolvimento da funcionalidade. E como foi a implementação? A funcionalidade ficou boa no produto? Não. Não foi desenvolvida. 😦

Você, analista de negócio, nunca passou por uma situação como essa? Situações onde a necessidade de um recurso novo no software era iminente, e no fim percebe-se que não era bem assim? O recurso precisava ser feito para “ontem“, mas após a análise completa, percebeu-se que não era tão prioritária assim, e existiam outras funcionalidades mais importantes para serem implementadas antes dessa.

Que desperdício! Seguindo teorias do Lean, esse estoque gerado é um grande desperdício. Isso porque, com certeza, quando chegar o momento certo de desenvolver a funcionalidade, a análise terá que ser toda reavaliada, pois o contexto do software já mudou. Pode ser até que nunca surja o momento certo, e a análise realizada nunca vire uma funcionalidade em produção.

Mas você deve estar pensando: “Se o roadmap do produto (aguarde novo post sobre o assunto) está bem priorizado, isso não ocorre!” Sim, é verdade. Mas o ponto é que nem sempre é simples priorizar quais são os recursos mais importantes e que agregam mais valor ao produto. Muitas vezes, pressões externas interferem nessa percepção de valor e urgência. E isso ocorre principalmente quando há um grande número de funcionalidades para serem desenvolvidas no produto.

Mas o que fazer para evitar esses desperdícios e focar realmente no que interessa? Eu sempre procuro manter todas as requisições registradas em cartões – conceito 3C (aguarde mais sobre isso em novo post) com o mínimo possível para não esquecê-las. A partir disso, vou aumentando sua prioridade conforme elas são lembradas novamente. Cada vez que o recurso faz falta ou é solicitado por alguém, vou aumentando sua prioridade.

Além disso, quando realmente analiso uma funcionalidade nova, procuro questionar: “por que essa funcionalidade é mais importante que as demais que ainda ficarão no backlog? Nesse caso, cada time possuirá diferentes critérios para avaliação e priorização, como: necessidade do cliente, valor investido pelo cliente e pela empresa, retorno que o recurso trará para o produto, disponibilidade do time para desenvolver o requisito, entre outros.

Qual o momento certo para analisar uma nova funcionalidade?

Não existe regra exata para saber quando analisar a nova funcionalidade. Existem muitas variáveis a serem avaliadas. Mas o importante sempre é questionar mesmo. O conceito dos 5 porquês (assunto que falaremos mais em outro post) é interessante e pode ser aplicado nesses casos. Quanto mais porquês forem realizados, maior será a certeza de ter realizado a priorização correta, e que o momento é o adequado para realizar a análise e desenvolver a funcionalidade.