Conhecimento

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.

 

Qual o nível de conhecimento técnico que um analista deve ter?

Postado em Atualizado em

A cada dia que passa nos deparamos com novas tecnologias no desenvolvimento de software. Surge uma nova versão do sistema operacional ou browser, um novo banco de dados, um novo smartphone ou tablet, um novo framework ou padrão de desenvolvimento, e assim por diante. Isso sem falar em novas regras de negócio, modelos administrativos, ferramentas de modelagem, indicadores de desempenho, etc. Ou seja, estamos sempre correndo atrás da máquina. Quanto mais estudamos, mais nos deparamos com coisas novas e percebemos que de fato sabemos pouco diante da imensidão do mundo de TI.

A partir disso, muitas vezes me questiono: “Quanto de conhecimento técnico eu preciso saber? Qual o nível mínimo de conhecimento que eu preciso?” Acredito que essa seja uma questão recorrente para muitos analistas de negócio, pois geralmente focamos nas regras de negócio, nas ferramentas de especificação de requisitos, gestão de demandas e outras atividades mais administrativas e menos técnicas. Com isso, em algumas especificações de requisitos a falta desse conhecimento técnico mais apurado sobre alguns assuntos, dificulta na especificação e passagem da necessidade para a equipe de desenvolvedores.

Torna-se muito mais simples a passagem da necessidade para um desenvolvedor quando realmente sabemos o que ele pode fazer. Não ficamos imaginando e pedindo o impossível e focamos realmente no que é viável. Além disso, a linguagem utilizada é muito mais direta e objetiva, facilitando muito a comunicação e compreensão das coisas tanto pelo desenvolvedor quanto pelo analista. Mas para isso acontecer, ambos devem estar com um nível semelhante de conhecimento.

O problema todo é que é muito difícil acompanhar a evolução técnica. Naturalmente, o analista acaba se distanciando da parte técnica e focando em questões mais de negócio mesmo. Para acompanhar tudo de forma efetiva, seria necessário trabalhar 24 horas por dia e 7 dias por semana. E não tenho certeza se conseguiríamos mesmo assim. Não podemos querer abraçar o mundo. Temos que entender que cada função possui suas atribuições principais. É do jogo mesmo. Um time de futebol não pode ser composto por 11 goleiros. Precisa ter também os zagueiros, laterais, meias e atacantes. Cada um com sua função e onde produz melhor. Mas o objetivo final é que o time vença. E no desenvolvimento de software é a mesma coisa.

Acredito que os analistas de negócio não devem abandonar totalmente a questão técnica. Devemos acompanhar vídeos, blogs e sites de referências para que estejamos cientes sobre o que há no mercado e as tendências que estão surgindo. Devemos utilizar redes sociais e ferramentas que nos mantenham “antenados” sobre as tecnologias existentes. Mas não precisamos saber fazer ou sermos especialistas nisso. Saber que existe e onde buscar se for necessário, já é um grande caminho. Ter experiência no passado como desenvolvedor também é algo saudável para entender as dificuldades e problemas enfrentados na geração de código-fonte.

Mas acima do conhecimento técnico que o analista deve ter, deve existir confiança e humildade no time. Se o analista não conhece detalhes técnicos, mas sabe que o time pode apoiar e ajudar na especificação, não deve exitar em pedir ajuda e especificar a necessidade em conjunto com a equipe técnica. O contrário também é verdadeiro. Ou seja, se a equipe técnica tem dúvida sobre regras de negócio ou como mapear um critério de aceitação ou modelagem no banco de dados, também deve sempre buscar apoio no analista. Ser humilde e reconhecer que há pessoas mais qualificadas para apoiá-lo é algo fundamental. E sempre pensar no coletivo e não no individualismo. Não queremos heróis e sim times coesos capazes de atingir os objetivos esperados.