Últimas notícias do evento

TDC 2015 Porto Alegre

Postado em Atualizado em

E mais uma vez chegamos a uma nova edição do The Developers Conferente (TDC) em Porto Alegre. O evento ocorre entre os dias 24 e 26 de setembro. Esse ano estou participando mais uma vez como palestrante na trilha Análise de Negócios. Sempre é um prazer compartilhar minhas experiências com a comunidade, gerando muito networking, troca de reflexões e conhecimentos dentro da comunidade de análise de negócios.

tdc2015poa-data-e-local

O tema escolhido esse ano sempre gera polêmica: estimativa de software. É uma questão que sempre é discutida entre diferentes times e projetos. Afinal de contas, qual é a melhor forma de estimar o esforço de trabalho do time? Story point, use case points, horas, ou algum outro método que você trabalhe? O método que você utiliza está gerando o resultado esperado? Está acertando em suas estimativas?

Essas são algumas proposições que pretendo levar a palestra para reflexão entre todos. E abordar questões como ritmo de trabalho, produção puxada, entrega contínua e comprometimento do time. Pretendo abordar como devemos encarar a estimativa evitando frustrações do time e principalmente do cliente.

Segue abaixo a apresentação. Participe da palestra, que irá ocorrer no dia 25/09/2015 por volta de 10:35 na Stadium, que é aberta para todas as trilhas. Leve suas dúvidas e compartilhe comigo suas experiências em estimativas de software.

Anúncios

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.

TDC 2014 Porto Alegre

Postado em Atualizado em

Há eventos que realmente valem a pena participar. São eventos sérios e bem organizados e que sempre possuem conteúdo de qualidade. Um desses eventos é o The Develepers Conference (TDC), organizado pela Globalcode em parceria com coordenadores interessados em diversas áreas da TI. Esse evento chega a sua segunda edição em Porto Alegre em 2014, entre os dias 16 e 18 de outubro.

banner-TDC2014-porto-alegre-250x120

O objetivo desse post é falar um pouco sobre a trilha que tenho a honra de coordenar esse ano, juntamente com a Diana Correia. Trata-se da trilha Análise de Negócios constituída por grandes palestrantes, que com certeza, irão agregar muito conhecimento a todos. Tenho certeza que teremos um dia intenso com muita troca de experiências, networking e uma profunda imersão em diversas áreas e temas ligados à Análise de Negócios.

Participei em 2013 do TDC de Florianópolis e Porto Alegre, acompanhando as palestras e agregando conhecimento. Esse ano já participei do TDC de Florianópolis como palestrante, conforme já relatado nesse blog. E em Porto Alegre estarei palestrando novamente e auxiliando na organização da trilha. É um grande prazer estar dividindo minhas experiências com todos. Com certeza, não existe melhor forma de aprender e fortalecer o conhecimento, que estar compartilhando vivências passadas, dividindo conquistas, problemas e frustrações enfrentadas.

Segue acima minha apresentação no TDC 2014 Porto Alegre. Durante a apresentação quis ressaltar alguns dilemas enfrentados por analistas ágeis. Isso ocorre porque seguimos os fundamentos ágeis, dentro do possível, mas muitas vezes trabalhamos em áreas de apoio, buscando facilitar o andamento do trabalho, removendo impedimentos, negociando contratos, prazos, custos, entre outras ações com menos importância segundo o manifesto ágil.

Caso tenham alguma dúvida, sugestão ou crítica, entrem em contato comigo. Vocês podem me encontrar em diversas redes sociais (http://about.me/eschenatto). Como agilista, considero o feedback fundamental para o crescimento.

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.

A importância do uso de CRM

Postado em Atualizado em

Depois de um longo tempo de inatividade do blog, estou retomando as atividades colocando meu ponto de vista diante de questões relacionadas a análise de negócio. Aproveitando minha participação no evento TTLabs Summit, realizado na empresa que trabalho, falarei um pouco sobre CRM aplicado em software-houses.

Normalmente, as empresas buscam sempre aumentar seu faturamento e lucro buscando novos clientes. O que não é errado, sem dúvida. O problema é que, muitas vezes, elas esquecem de seus clientes atuais. As organizações não percebem que o custo para a aquisição de novos clientes é muito maior. A venda de novos produtos e serviços para clientes atuais satisfeitos pode gerar um grande incremento no faturamento da empresa.

Para isso, o uso de uma boa ferramenta de CRM pode auxiliar muito as organizações. Além disso, é importante ampliar o conhecimento sobre os clientes a fim de categorizar os mesmos. Clientes com maior influência no mercado e com maior poder de investimento devem receber uma atenção especial. É um erro considerar que todos os clientes possuem o mesmo grau de importância e devem ser tratados na mesma forma. Clientes diferentes devem ser tratados de forma diferente. Cada um possui sua cultura, seu conhecimento sobre o produto, sua forma de comunicação.

O objetivo principal de uma ferramenta de CRM é conhecer melhor os seus clientes. Dar a atenção devida para cada um, de acordo com sua real necessidade. A partir disso, deve-se buscar o relacionamento com o cliente como um diferencial competitivo da organização. Entender de forma rápida e precisa o que cada cliente necessita, geralmente não é algo simples para as organizações. Principalmente em software-houses, onde os clientes normalmente possuem um conhecimento limitado sobre o processo de desenvolvimento de software. E isso se agrava ainda mais, se o cliente não possui uma área de TI bem estruturada.

É importante categorizar os clientes, para que em um atendimento todos possam saber de forma rápida qual seu grau de importância para a empresa, qual é o potencial de compra de novos produtos e serviços, e principalmente, seu poder de influência sobre o mercado, baseado em seu relacionamento e proximidade com outros clientes.

Não estou defendendo que clientes com uma classificação de menor relevância devem ser desconsiderados e distratados. Muito longe disso. Todos clientes são importantes. Só que clientes que agregam menos valor a empresa, não devem receber uma atenção maior que um grande cliente, considerado fundamental para a organização. É uma questão de alinhamento da operação com a estratégia, e uma forma de aumentar os esforços no mais relevante. Diante de uma situação onde deve ser dado retorno para mais de um cliente, sugiro que busque primeiro retornar para a mais relevante, e depois para o cliente com menor relevância. Claro que sempre respeitando o SLA de atendimento da organização.

Sendo assim, analisando o cotidiano de empresas desenvolvedoras de software, criei uma sugestão de metodologia para implantação de CRM, com algumas categorias de clientes e informações que devem ser coletadas em uma ferramenta de CRM. Esses dados podem ser conferidos no vídeo e/ou na apresentação que estão mais abaixo.

Buscar categorizar os clientes por:

  • Número de contatos (chamados) realizados
  • Geração de receita
  • Inadimplência
  • Maior conhecimento ou melhor utilização de seus sistemas
  • Maior visibilidade para seus softwares perante outras organizações

Informações que devem ser armazenadas no CRM:

  • Recursos, módulos ou programas que os clientes utilizam
  • Pessoas que utilizam o sistema e seus níveis de conhecimento sobre o sistema
  • Regras pré-estabelecidas pelo cliente, assim como particularidades no uso do sistema
  • Treinamentos realizados (com dados sobre quem fez e quando)
  • Reclamações dos clientes
  • Problemas solucionados
  • Ações pendentes com data e responsável pela próxima ação/retorn

Quer saber mais sobre o uMov.me Labs? Acesse o site http://umovme.cc e fique ligado nas novidades do blog.

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.