A importância do uso de CRM

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/retorno

A Importância da Utilização de CRM em Software-Houses from Emerson Schenatto

Quer saber mais sobre o TTLabs? Acesse o site http://ttlabs.cc e fique ligado nas novidades do blog.

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

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.

A importância de ver o todo

Em qualquer organização há muitas pessoas e muitos meios para efetuar a comunicação. A comunicação eficaz entre todos, sempre é um desafio constante na análise de negócio. Conseguir buscar as informações e repassar de uma pessoa para outra, e entre os setores da empresa de forma clara e objetiva, é praticamente uma arte. Precisamos conhecer bem as pessoas e saber como abordá-las para que elas recebam as informações da melhor forma. Por isso que a Programação Neurolinguística (PNL) está sendo tão procurada por analistas de negócio. Muitas vezes, precisamos ser mais "psicólogos" que analistas mesmo.

Isso deve-se ao fato de cada pessoa possuir a sua própria percepção sobre seu trabalho. O setor de vendas, por exemplo, valoriza mais seu trabalho e considera fundamental, pois é através dele que entram os clientes e o dinheiro das vendas. Já o setor de compras considera seu trabalho essencial para adquirir bons preços, produtos e condições de pagamento para melhorar o fluxo de caixa. E o setor financeiro que cuida do caixa da empresa? A produção, por sua vez, considera que leva a empresa nas costas, já que é responsável por desenvolvedor o produto ou serviço com qualidade. Mas afinal, existe algum setor mais importante que outro? É claro que NÃO.

É muito natural que cada pessoa e setor considere o seu trabalho bem importante, pois sempre buscamos a valorização de nosso trabalho. Mas não podemos considerar que o que fazemos é mais importante que o trabalho de outra pessoa ou setor. Em uma organização as coisas somente acontecem quando o todo funciona bem. Não adianta a produção fazer tudo de forma rápida e perfeita e não ter vendas. Também não adianta ter vendas e não conseguir produzir, ou vender com prejuízo devido a uma negociação mal feita com o fornecedor. Sempre o todo tem que estar bem alinhado.

Dessa forma, considero fundamental que na análise de negócio sempre seja buscada uma visão mais ampla. Muitas vezes, por estarmos mais próximos de uma área, como desenvolvimento por exemplo, acabamos deixando nossa visão mais míope, mais limitada e não enxergando a empresa como um organismo mais complexo e cheio de conexões internas que levam para um resultado maior. A visão mais restrita nos tira a percepção de valor sobre algumas tarefas que devem ser implementadas.

Temos somente que ter cuidado para não nos envolvermos com tudo na empresa, buscando ser especialista em todas as áreas, e nos tornarmos assim super heróis. Sempre temos que ver o todo, mas sabendo que não seremos especialistas em tudo. Cada área possui sua experiência e conhecimento natural, e somente devemos apoiar esses setores entendendo a sua importância e suas necessidades na organização.

Mas também deve ser salientada a importância de sempre recebermos o contexto mais amplo para execução de algumas atividades. Recebermos uma tarefa para execução sem entendermos o real valor dela não é nada saudável. Temos que entender e acreditar no que está sendo feito. Fazer somente porque a direção da empresa quer, ou porque a equipe de desenvolvimento acha importante, não é a melhor saída. Sempre temos que parar, nos afastar um pouco do problema e buscar visualizar o todo. A partir desse ponto, estaremos aptos para tomarmos a decisão mais acertada.

Você confia nas pessoas do seu time?

Lendo o post "Não quero gerentes, mas pessoas capazes de gerenciar" do Daniel Wildt que é muito bom e está em linha com o que acredito também, veio a inspiração para esse novo post. ;-) Falarei um pouco sobre confiança. Sim, confiança. Assunto não técnico, mas que tem muito a ver com análise de negócio, relações entre pessoas de um time, liderança e trabalho em equipe.

Delegar responsabilidades não é algo simples. É importante saber delegar. Passar uma tarefa a alguém e esperar que ela faça exatamente o que você faria não é a forma adequada. Muito pelo contrário. É um sinal claro de desconfiança. As pessoas sempre farão diferente do que você faria. Isso é natural, pois cada pessoa é diferente com seu conhecimento, habilidade e atitude (CHA). Se você quer que as coisas sejam exatamente como você espera, o melhor é que você mesmo faça. Caso contrário, a chance de frustração é bem grande.

Além disso, encontrar as pessoas que possuem a aptidão e perfil adequado para desenvolver algumas funções também é delicado. Devemos conhecer as pessoas e saber o que cada pessoa do time é capaz de executar. Cobrar algo de alguém que não tem o perfil adequado, com certeza é um tiro do pé. A relação de confiança da pessoa com o restante do time ficará abalada, pois a execução da tarefa não se dará de forma adequada, já que o perfil da pessoa não é o adequado para tal execução.

O mais importante de tudo é confiar nas pessoas do time. O que quero dizer com isso? Quero dizer que devemos passar uma tarefa para a pessoa e ter certeza que ela dará um jeito de resolver. Se ela não conseguir resolver, ela deverá avisar. Mas não devemos ficar cobrando se está indo ou não, ou como fez. Se delegou a tarefa, e deixou claro o que deve ser feito, não deve se preocupar como ela será feita. Importante é que o objetivo seja alcançado. E a pessoa deve ser responsável o suficiente para executar a tarefa e dar feedback a fim de continuar tendo a confiança do líder e de todo o time. Isso faz com que o time seja auto gerenciável, sem necessidade de cobranças e controles excessivos.

Quem não passou por situações onde o gerente ou diretor ficou cobrando as coisas diariamente, semanalmente ou mensalmente? Isso na minha visão, é total falta de confiança no time ou nas pessoas. Claro que o time deve dar retorno sobre o andamento da tarefa. Mas muitas vezes, nem consegue iniciar a execução, que já vem outra cobrança. Um time somente cresce quando há confiança. Se o líder não confia no time, não serão criadas novas lideranças e não irá ocorrer crescimento individual. O mesmo serve para a confiança entre as próprias pessoas do time. Com a desconfiança entre as pessoas, irão surgir "heróis" que sempre ficarão com as tarefas mais difíceis e irão se tornar gargalos, não propiciando o crescimento das demais pessoas através do repasse de conhecimento.

A confiança é a base de qualquer relação. E é sobre esse pilar que devemos construir o relacionamento entre as pessoas do time. Lendo o livro Transformando Suor em Ouro do Bernardinho, que sem dúvida nenhuma é um grande líder, podemos tirar algumas lições importantes que devem ser aplicadas nos times:
- Deve-se sempre fomentar as lideranças no time
- Nunca esquecer que a vaidade é inimiga do espírito de equipe
- Buscar o "brilho da vitória" no olhar das pessoas do time
- Combater o desperdício do talento. É fundamental conhecer as pessoas para motivá-las
- Quanto mais o gestor mostrar que acredita no potencial das pessoas do time e se dedicar a elas, maior será a produtividade

Para finalizar, reforço a necessidade de aumentar cada vez mais a confiança entre as pessoas do time. Cada pessoa deverá ser responsável por suas atividades de acordo com sua aptidão. Mas para conquistar a confiança de todos, é necessária muita responsabilidade sobre as tarefas executadas.

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

"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.

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.

Qual o momento certo para analisar uma nova funcionalidade?

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.

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.

A Importância do Uso dos Indicadores (BSC)

Todas as organizações possuem sua missão, visão, objetivos estratégicos e tudo mais que um bom planejamento estratégico define como regra para identificar onde a empresa quer chegar. Mas a pergunta é: "quem faz com que a empresa atinja tais objetivos?"

Com certeza são os colaboradores que farão com que as metas da empresa sejam ou não atingidas. São as pessoas que movem a empresa. Mas a questão principal é: "Será que todos sabem claramente o que precisam fazer para que a empresa atinja suas metas? O caminho está claro para todos?"

 

Para exemplificar a importância dessa comunicação, lembro de uma pequena história sobre caranguejos que ouvi há um tempo atrás em um curso que realizei. Essa metáfora com a vida organizacional relata que os caranguejos capturados no mangue ficam presos em um barbante solto no próprio mangue. Eles poderiam fugir se todos puxassem o barbante para o mesmo lado. Mas como não se falam, cada um puxa para um lado diferente e eles acabam ficando no mesmo lugar, sem conseguir escapar.

Para melhorar esse cenário confuso sobre a comunicação da empresa com seus colaboradores, há uma ferramenta importante que visa simplificar esse diálogo, orientando todas as pessoas a seguirem um caminho único. Essa ferramenta é o Balanced Scorecard (BSC), formado por indicadores em todas as áreas da empresa, interligados e balanceados, evitando comportamentos inadequados.

O processo mais complicado na construção do BSC é a escolha correta dos indicadores. Sempre deve ser avaliado se o comportamento gerado a partir do indicador é o adequado. Os indicadores não podem ser controladores de performance. Eles devem auxiliar no comportamento dos colaboradores para que todos busquem atingir os objetivos organizacionais. Não devem ser criadas medidas a fim de punir as pessoas e sim indicadores para auxiliar as pessoas nas tomadas de decisões.

Para finalizar, lembro da famosa e verdadeira frase do Goldratt: "Diga como me medes e te direi como me comportarei. Se me medires de forma ilógica, não reclame de comportamento ilógico."

A importância do uso dos indicadores (BSC)

View more PowerPoint from Emerson Schenatto
 

TTLabs Summit (Q2/2011) - Balanced Scorecard from TTLabs on Vimeo.