Treinamento sobre Innovation Games (/cc @adaptworks)

 

Na semana passada tive a oportunidade de participar do treinamento de Innovation Games, promovido pela Adaptworks, com Michael Gaines.

Os “jogos de inovação” são alguns jogos elaborados por uma consultoria do Vale do Silício, The Innovation Games Company ®, criada pelo canadense Luke Hohmann, que cria jogos que estimulam o engajamento de clientes, colegas e parceiros no desenvolvimento de produtos/projetos.

Por sua informalidade, a técnica de jogos permite que pessoas de diferentes níveis hierárquicos, com diferentes papéis na empresa no ou na equipe de desenvolvimento de produto/projeto, sintam-se a vontade para expor suas visões sobre o que está sendo feito.

No treinamento nos fizemos alguns dos jogos, que nos ajudaram a aplicar diferentes técnicas para priorizar atividades no desenvolvimento de um projeto/produto, a entender melhor aspectos que estimulam ou atrasam o ciclo de desenvolvimento e a relacionar recursos existens a fim de se chegar a novas idéias através da associação destes recursos.

Aqui vai uma breve descrição dos jogos que praticamos:

- Speed Boat – ajuda a entender o que seus clientes gostam ou não gostam em seu produto ou serviço, quais são os aspectos que estão ajudando a acelerar ou a desacelerar seu projeto ou ainda a entender quais são os fatores de motivação e desmotivação que sua equipe percebe no projeto. A técnica garante que reuniões de retrospectiva / avaliação fiquem sob controle e não se transformem numa avalanche de reclamações em que só aparecem os aspectos negativos do projeto, sem se pensar em como resolvê-los e avançar. A técnica é bem simples, você precisa apenas desenhar um barco num quadro branco ou folha de papel pendurada na parede, e as pessoas devem marcar, com post-its, as coisas que “ancoram” o barco, e as coisas que o fazem andar com maior velocidade. Os itens podem ter peso (marcado nos post-its), ou simplesmente estar em posições diferentes no quadro (as coisas que mais atrapalham ficam mais fundas, como se fossem as âncoras mais pesadas).

- Buy a Feature – ajuda a fazer com que seu cliente (ou CEO, ou Diretor, ou Gerente de Produtos, etc) consiga priorizar melhor o desenvolvimento de features que realmente irão agregar mais valor ao negócio. Geralmente o cliente quer o projeto todo pronto, para ontem. Mas nem todas as features serão usadas, nem todas são críticas para o lançamento e nem todas precisam de fato ser feitas (isso vai acabar sendo descoberto com o uso do produto). O jogo consiste em ter uma lista de features, e a dar um preço para cada uma delas (na vida real, o preço pode ser a estimativa e o custo de desenvolvimento, por exemplo). Cada cliente receberá um certo valor para poder comprar as features, mas, obviamente, não terá dinheiro suficiente para todas. Portanto, para algumas features, ele terá que negociar com outros clientes para que os dois juntos tenham recursos suficientes para comprá-las, e terá que abrir mão de outras. O resultado deste jogo é que o conjunto de clientes de seu produto terá priorizado o que realmente lhes traz valor.

- Remember the Future – o que você precisa fazer em seu produto para que daqui a 1 ano ele tenha trazido determinado benefício ao seu cliente? Partindo do benefício, a idéia deste jogo é pensar de traz para frente o que é necessário fazer com o produto para que ele traga tal benefício, e o que precisou ser feito imediatamente antes para que ele chegasse até este ponto. Dado o prazo para o produto atingir o objetivo, este jogo faz com que as pessoas pensem no que é realmente necessário para partir do ponto em que se está hoje, para se chegar ao ponto em que o produto trará o benefício esperado.

- Prune the Product Tree – todas as features são importantes e precisam ser entregues ao mesmo tempo? Isso não é verdade, e com este jogo você e sua equipe poderão montar o roadmap de seu produto pensando nos diversos aspectos do produto. A metodologia consiste em desenhar uma árvore, e ir colocando, com post-its, para dar o formato desejado à copa da árvore. Assim, os galhos da árvore representam os tipos de funcionalidade, as funcionalidades em si são as folhas, as features fundamentais são o tronco, e a base da aplicação são as raízes. Assim, as pessoas vão colando as folhas nos devidos galhos, sendo que as funcionalidades já prontas ou mais desejáveis ficam mais perto do tronco do que as menos importantes. A metologia deixa vísivel quando, por exemplo, algum aspecto de seu produto está ficando de lado (ex: muitas folhas no ramo que diz respeito ao front-end de sua plataforma de comércio eletrônico e poucas no raml que diz respeito ao back-end), para que você possa avaliar se está é mesmo a melhor opção.

- Product Box – Desenhando a caixa que venderia seu produto ou serviço num supermercado, os jogadores terão que identificar quais os aspectos mais importantes do produto, como comunicá-los melhor e quais problemas de fato seu produto resolve. As limitações de espaço exigirão que o grupo pense no que realmente são as principais características do produto, e tenha criatividade para comunicar da melhor forma.

- Spider Web – Este jogo, que funciona através do desenho de uma rede que relacione todos os produtos, serviços ou usos que podem ser feitos com seu produto na forma de uma teia de aranha. Com isso, percebe-se novos usos que podem ser feitos do produto através das conexões que aparecerão.

- Start Your Day – Descreva como seu cliente usa ou se relaciona com seu produto ao longo do tempo (pode ser um dia, uma semana, um mês ou qualque período, depende do seu produto). Pense em todas as situações em que seu produto é necessário para o cliente, e como seu produto pode ajudá-lo em cada caso. Com isso você entenderá melhor como seu produto é usado, para quais aspectos você tem que dar mais importância, e obviamente, ajudará a pensar na experiência do usuário, sob todos os aspectos.

Sempre que possível envolva também o cliente, afinal, é importante ele estar engajado com o projeto e totalmente alinhado com sua equipe.

Estes e outros jogos criados pela The Innovation Games Company (R) estão disponíveis no livro Innovation Games: Creating Breakthrough Products Through Collaborative Play, que todos os participantes do treinamento receberam como cortesia.

Pará vários dos jogos há versões onlines, para que times remotos possam participar, mas obviamente o ideal é a equipe estar toda reunida, uma vez que a colaboração e o debate são fundamentais para que os resultados esperados sejam alcançados.

Se você já aplicou alguma destas técnicas em alguma empresa ou cliente, aproveite o espaço de comentários do blog para contar sua experiência!

Se não aplicou, lembre-se, a técnica de jogos é simples, mas exige uma preparação prévia da sala e dos materiais a serem utilizados para que funcione bem e envolva a equipe de jogadores!

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Motivação baseada em Remuneração

Muitas empresas associam remuneração (promoção/aumento de salário/bônus) ao cumprimento de metas (melhorar determinado KPI/indicador, entregar determinado projeto no prazo, etc) e consideram que com isso estão estimulando seus funcionários a trabalhar melhor e mais motivados em prol dos resultados esperados. Empresas que têm esta visão consideram que seus funcionários se motivam exclusivamente pela remuneração, e não por outros fatores intrínsecos.

Obviamente existem outros fatores que geram motivação, e que dependem tanto do que sua empresa tem a oferecer (não só do ponto de vista financeiro), quanto das aspirações pessoais de cada um. Sua empresa oferece uma série de ‘benefícios’ aos funcionários, e cada um valoriza algun(s) deles de acordo com seus valores pessoais. Alguns, gostam do fato de sua empresa possibilitar o aprendizado, outros valorizam a estabilidade na carreira, já outros, valorizam o fato de trabalharem perto de casa, alguns, preferem o fato de serem reconhecidos como referência dentro de sua empresa e no mercado, etc.

Dificilmente as pessoas aceitam se sujeitar a condições com as quais não estão satisfeitas (ambiente de trabalho, relacionamento com pares e chefes, etc.), ainda que recebam a mais por isso. Obviamente existe uma remuneração mínima que cada um espera receber por seu trabalho (e satisfazer suas necessidades básicas, conforme a Pirâmide de Maslow), mas usar a remuneração como forma de inspirar motivação não é efetivo, principalmente quando as aspirações pessoais já estão nas camadas superiores da pirâmide.

Assim, reduzir as aspirações de cada um a KPIs e metas da empresa, e reduzir as formas de recompensar o cumprimentos destas metas à remuneração NÃO é garantia de que sua empresa irá motivar seus funcionários e reter os melhores talentos, que geralmente são os objetivos das empresas que adotam este sistema de recompensa.

Um aumento de salário ou promoção deve ser dado como reconhecimento pelo trabalho realizado e/ou pela expectativa de trabalho a ser realizado; um bônus deve ser dado como forma de a empresa (ou melhor, seus donos/acionistas) compartilhar seu sucesso com os colaboradores.

Obviamente todos gostam de promoções e bônus. Mas a forma de trabalho e o objetivo da empresa têm impacto maior sobre a motivação/desmotivação das pessoas do que o prêmio em si!

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Conversa Rápida – Metas Compartilhadas – Alexandre Magno

A discussão é bastante válida, e para prisioneiros, times de scrum, departamentos de empresa, enfim, dá pra extrapolar como quiser!

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Algum brasileiro vai na #BoS2011

Em 2009 participei da conferência Business of Software (http://gerentedeprodutos.com.br/category/bos2009/), e em 2010 participei novamente (http://gerentedeprodutos.com.br/category/bos2010/).

Irei de novo este ano, no final de Outubro – http://businessofsoftware.org/ – alguém mais pretende ir?

 

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Vagas para Gerente de Produtos

Caso sua empresa possua vagas para Gerentes de Produto, e queira divulgar neste blog, colocar aqui nos comentários deste blog que eu entrarei em contato por e-mail para pegar os dados e em seguida faço um post aqui divulgando a vaga.

Dependendo do volume, crio uma página específica para divulgação de oportunidades.

Aguardo os comentários ;)

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Resenha – “A Meta”, de Eliyahu M. Goldratt – http://amzn.to/nExP1u

The GoalO livro “A Meta“, de Eliyahu Goldratt, é um clássico romance sobre a Teoria das Restrições, em que o gerente de uma fábrica, Alex Rogo, se vê numa situação em que sua fábrica corre o risco de ser fechada pela administração da empresa por não estar conseguindo atender às demandas do mercado. Com pedidos atrasados em meses e ritmo de trabalho nada sustentável para ele e seus funcionários, Rogo, com ajuda de um consultor Jonah, identifica melhorias que poderia implementar na fábrica para que o lead time (tempo entre o pedido feito por um cliente e a entrega do produto) caísse de alguns meses para poucas semanas, salvando a fábrica da falência e recebendo uma promoção que lhe permitiria aplicar seu método em todas as fábricas da divisão.

Rogo percebe que, apesar de a fábrica não estar gerando dinheiro (devido a pedidos atrasados, clientes insatisfeitos, excesso de horas extras e diversos outros problemas), havia equipes na empresa que celebravam o sucesso por terem atingido suas metas locais (por exemplo, alta produtividade numa etapa do processo de fabricação do produto final). Rogo percebe que a alta produtividade de uma equipe (não gargalo) que gerava insumo para uma segunda equipe (gargalo) não era benéfica para a fábrica, pois gerava um inventário desnecessário (e caro), uma vez que o processo desta segunda equipe era mais lento e não dava conta de processar este insumo. Assim, a fábrica comprava matéria prima num ritmo alto para manter a produtividade da primeira equipe, e, no entanto, não conseguia entregar o produto final devido ao ritmo da segunda equipe. Assim, definem-se dois tipos de recursos: recurso-gargalo (aquele recurso cuja capacidade é igual ou menor do que a demanda colocada nele) e recurso-não-gargalo (qualquer outro recurso cuja capacidade é maior que a demanda colocada nele).

A primeira mudança na gestão de Alex se dá ao perceber que todos na empresa devem estar focados no objetivo da empresa, que é gerar dinheiro, e que a otimização local de uma etapa do processo era prejudicial para a meta global da empresa. Assim, sua primeira missão foi identificar a meta da empresa (geração de dinheiro) e fazer com que todos os times trabalhassem para o mesmo objetivo, e não para otimizações locais.

Através de três conceitos apresentados por Jonah, Alex e sua equipe conseguem identificar como gerenciar melhor seu processo de produção e identificar a meta de qualquer empresa: reduzir a despesa operacional e o inventário aumentando simultaneamente o ganho, onde Ganho é índice pelo qual o sistema gera dinheiro através das vendas -, Inventário é todo o dinheiro que o sistema investiu na compra de coisas que ele pretende vender -, Despesa Operacional é todo o dinheiro que o sistema gasta a fim de transformar o inventário em ganho”.

Rogo e sua equipe identificaram os gargalos da empresa (duas etapas do processo de produção), e fizeram com que toda a fábrica trabalhasse no ritmo do gargalo, assim, só haveria realização de trabalho caso fosse possível entregar o produto final para o cliente, caso contrário, todo trabalho realizado teria sido desperdício. Assim, através da otimização dos processos-gargalo da fábrica, Rogo percebeu que os únicos processos que precisavam ser otimizados eram os processos-gargalo, uma vez que estes eram os responsáveis pela baixa produtividade da fábrica.

Não adiantava hora-extra, pressão ou equipamentos melhores em processos que não eram gargalo, uma vez que isso geraria custos e inventário, e não teria impacto algum sobre a redução do lead time da empresa, que é o que geraria o resultado no final. Rogo percebeu que mesmo a compra de robôs para automatizar determinados processos da fábrica não havia sido benéfica, pois otimizava processos que não eram o gargalos, e portanto geravam inventário que não era processado pelas etapas seguintes.

Após todas as melhorias iniciais implementadas, o gargalo da produção passa a ser o mercado (vendas),  o que permitiu que a produção da fábrica fosse puxada pela demanda, e não empurrada para o mercado. A principal diferença é que quando a demanda é empurrada para o mercado, há geração de inventário (custo); quando a demanda é puxada pelo mercado, a fábrica produz (custa) somente o que precisa para gerar a receita (vendas), ou seja, o processo é muito mais otimizado e não há desperdício.

Através de um processo de melhoria contínua, Alex e sua equipe conseguem reduzir o lead time, reduzir custos e provar seu método para a alta direção da empresa, que reconhece o sucesso da fábrica com a produção dos principais envolvidos. O processo de melhoria contínua baseia-se em

1. IDENTIFICAR a restrição do sistema
2. EXPLORAR a restrição do sistema
3. SUBORDINAR tudo o mais a decisão acima
4. ELEVAR a restrição do sistema
5. SE num passo anterior a restrição for quebrada, volte ao passo 1. MAS não deixar que a INÉRCIA se torne  a restrição do sistema.

E o que isso tudo tem a ver com o desenvolvimento de produtos?

A analogia da fábrica descrita no livro pode ser feita com qualquer tipo de organização, inclusive com o desenvolvimento de software. Alguns exemplos:

- não adianta cobrar velocidade de entrega de features da equipe de desenvolvimento se a equipe de Marketing não consegue manter os clientes e prospects informados de que essas features existem no produto. As features são feitas para que mais clientes comprem o produto, e se não for publicado que a feature existe foi lançada, eles não comprarão, e assim ter feito a feature representa inventário

- não adianta a equipe de experiência do usuário (UX) ou design definir o layout de 20 telas do produto em uma semana, se a equipe de desenvolvimento consegue entregar apenas 1 tela por semana. Muito provavelmente boa parte das telas irá mudar por demandas do produto e dos desenvolvedores, então seria muito melhor a equipe de UX/Design estar no mesmo ritmo dos desenvolvedores do que tão adiantada.

- não adianta o Gerente de Produtos definir as histórias e funcionalidades num ritmo muito maior que a implementação, pois o inventário gerado certamente precisará de feedback, e quando o gerente de produtos receber este feedback, provavelmente terá que alterar boa parte do que havia planejado. Assim, terá trabalhado à toa se seu planejamento se distanciar muito do ritmo de entregas da equipe de desenvolvimento.

Em resumo, é importante que os lotes de trabalho sejam pequenos, para que os ciclos de entrega possam ser curtos e feitos conforme a demanda do mercado, para que não haja desperdício e possa haver feedback no processo. Lotes grandes implicam em ciclos de entrega grandes, que geram inventário e tornam as mudanças de prioridade mais difíceis e caras de serem gerenciadas.

A leitura deste livro é extremamente esclarecedora e importante para qualquer um que gerencia uma empresa, de qualquer tipo!

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Roadmap de Longo Prazo é apenas uma Referência

Muitos gerentes acreditam que, para dimensionar o trabalho de suas equipes e prever as mudanças com as quais terá que lidar ao longo do ano, é necessário saber qual o roadmap planejado para o produto. Como a função do Gerente de Produtos é definir e priorizar o roadmap do produto, logo, é função do Gerente de Produtos apresentar o roadmap de longo prazo para que os gerentes das equipes possam planejar suas equipes para isso ao longo do ano.

Considerando que o desenvolvimento de um produto é influenciado por uma série de variáveis, sendo a principal delas o feedback dos clientes, é praticamente impossível de se fazer um planejamento de longo prazo imutável. Isso porque o roadmap do Gerente de Produtos não é uma documentação detalhada de tudo que será feito no produto nos próximos meses. O objetivo do roadmap é, basicamente, servir de pauta para que ele possa fazer suas conversas com clientes, desenvolvedores e demais stakeholders do produto a fim de definir quais serão as próximas melhorias feitas no produto.

Durante o desenvolvimento de uma feature, é função do Gerente de Produtos pesquisar qual será a próxima feature a ser feita, com base no roadmap, no feedback dos clientes atuais, dos clientes em potencial e de todas as áreas envolvidas no desenvolvimento do produto. O roadmap é apenas uma referência da direção que o produto deve seguir no longo prazo, sujeito a mudanças constantes de acordo com o resultado de cada novo release.

O desenvolvimento de produto não é um projeto com começo, meio e fim, e, mais que isso, não deve ser um projeto de escopo fechado, em que o Gerente de Produtos define o que será feito e os outros simplesmente obedecem. Especialmente porque o grupo “os outros” inclui os clientes – que têm suas necessidades -, os desenvolvedores, que têm suas demandas – para implementar tal feature temos que melhorar a implementação de tal módulo -, a área de infra-estrutura tem suas demandas específicas – temos que migrar o servidor para outro data center para ter uma estrutura redundante de alta disponibilidade -, o mercado tem suas demandas específicas – o concorrente X vai entrar no mercado, temos que integrar nosso sistemas com o parceiro Y -, o Marketing tem suas demandas – a feature tal tem que estar pronta porque a campanha X precisa ir para o ar antes do Natal -, o Financeiro tem suas demandas – precisamos do relatório X para podermos pagar o imposto Y -, e assim para todos os envolvidos no produto.

Com tantas variáveis – todas elas fundamentais para a evolução do produto – não só é impossível ter um compromisso de longo prazo sobre o que irá acontecer com o produto, mas também é totalmente indesejável que exista este compromisso.

Se você precisa de parâmetros para fazer o planejamento de longo prazo, não utilize o roadmap como referência. O roadmap é que deve usar como referência os recursos e pessoas disponíveis para o desenvolvimento do produto, e, se isso não for satisfatório para a estratégia da empresa, a empresa deve definir se faz sentido ou não aumentar o investimento no desenvolvimento do produto.

O roadmap de longo prazo serve, principalmente, para que todos os stakeholders compartilhem da mesma visão do produto e saibam para onde o Gerente de Produto (que representa as demandas de todos e as prioriza conforme a estratégia da empresa) gostaria que o produto caminhasse no longo prazo.

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Lição de Vida do Sílvio Santos, um dos maiores empreendedores do Brasil

Esse cara merece um livro!

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Por que é necessário ter um Gerente de Produtos?

Desta vez vou definir a função do Gerente de Produtos por exclusão.

Se não fosse o Gerente de Produtos, quem deveria definir e priorizar o roadmap de um produto?

Equipe Comercial – Normalmente a equipe Comercial está preocupada com vendas (afinal, mais do que todos, seu rendimento fixo normalmente é baixo e o variável vinculado às vendas). Esta preocupação faz com que seja difícil recusar um cliente. Todo cliente é interessante e toda demanda vinda de cliente precisa entrar no produto. Todo cliente que não vai fechar porque falta uma determinada feature, COM CERTEZA fecharia se essa feature existia —- se fossem eles, o produto seria cheio de customizações, teria todas as features do mundo, teria pouca preocupação com usabilidade, e cada feature atenderia somente um único cliente. Não seria um produto, seria um Frankenstein :)

Equipe de Marketing – Normalmente a equipe de Marketing está preocupada com o que terá impacto na mídia. Mas não necessariamente o que aparece na mídia é a feature que o cliente precisa. A mídia divulga (pelo menos de forma espontânea) o que é diferente, o que chama atenção; mas não necessariamente o que é de fato útil. Dificilmente alguém bom de Marketing irá se entender com alguém de tecnologia, que precisa de definições mais detalhadas do que precisa fazer, e usa termos técnicos para explicar as possibilidades —- se fossem eles, o produto seria um show, talvez até vendesse muito, mas teria uma taxa de cancelamento bem alta.

Equipe de Desenvolvimento – A equipe de desenvolvimento normalmente gosta de algoritmos desafiadores, problemas complexos e projetos inovadores (ou se for uma equipe preguiçosa, gosta de poucos desafios e só das coisas bem simples!). Muito mais legal trabalhar a tecnologia mais nova, o banco de dados mais recente e investir um bom tempo no aprendizado disso. Mas precisa mesmo disso para entregar a solução que o cliente quer? —- se fossem eles, o produto seria uma obra de arte, que teria pouquissimos compradores, pois não necessariamente o problema do cliente precisa de muita complexidade técnica para ser resolvido.

Equipe de User Experience – normalmente quem trabalha com experiência do usuário é bastante perfeccionista. Não gosta de deixar nenhum detalhe de lado, e muitas vezes não sabe qual a complexidade de implementar algo que no protótipo fica lindo, mas que na prática é bem difícil de se implementar —- se fossem eles, o produto também seria uma obra de arte, mas para ficar tão perfeito, não ficaria pronto nunca ;)

Equipe de Suporte – normalmente está preocupada em reduzir seu custo operacional, e quer garantir a qualidade do atendimento. Quanto menos contatos de clientes na central, melhor. Vão colocar aquela feature? Melhor não, vai gerar chamados. Vão tirar aquela feature? Melhor não, vai gerar ligações. Vão fazer aquela campanha? Melhor não, vai gerar contatos —- se fossem eles, o ideal seria o produto ficar como está, e somente correções de bugs seriam implementadas.

O que está faltando? Alguém que faça o meio de campo entre todas estas áreas (e outros stakeholders envolvidos), e, com base em seu conhecimento dos clientes e do mercado, priorize e defina o que de fato precisa ser feito. Geralmente todos sabem o que precisa ser feito, mas poucos sabem priorizar. E poucos tem a coragem de dizer não:

- há clientes que não queremos atender porque implementar o que ele precisa exigirá uma customização que não faz sentido para os outros 9999 clientes.
- há funcionalidades que vão fazer os clientes se manterem clientes, mesmo que não gere buzz na imprensa.
- há funcionalidades que podem ser bem simples, mesmo que não seja necessário Phd em algoritmos para serem resolvidas
- há melhorias de navegação que podem ficar para depois, mesmo que seria bem mais fácil de usar o produto se fosse de outro jeito.
- há features que vão gerar receita maior que o custo operacional de atendimento, mesmo que seja necessário contratar uma pessoa a mais para o atendimento

Sim, estou sendo extremista, mas alguém precisa pesar todas estas variáveis. E se for alguém de qualquer uma dessas equipes, provavelmente ela não estará fazendo bem o seu trabalho direto e estará sendo o Gerente de Produtos.

Portanto, defina alguém que tenha esta função, e dê-lhe autonomia para assumir a responsabilidade pelo produto, e dizer NÃO com segurança, autonomia e responsabilidade.

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Atendimento e Redes Sociais

Na última semana tive duas experiências bem desagradáveis com Centrais de Atendimento. Nem sempre o Gerente de Produtos tem autonomia sobre como será feito o atendimento para seu produto, especialmente em empresas maiores em que há uma área de atendimento bem definida, ou separada do dia a dia do desenvolvimento de produtos. Mas é importante que ele levante as questões para que não passem batidas.

Vou citar os dois exemplos que passei:

- Migrei no começo do ano o plano individual da NET para o plano coletivo. Durante anos paguei o plano individual, e obviamente nunca foi interesse da NET me contar que meu prédio tinha a opção de plano coletivo, já que o plano coletivo é mais barato. Mas ainda assim, eu descobri! Conseguir a migração foi um processo que levou uns 2 meses, e várias horas no telefone. Cada um que me atendia falava coisas diferentes, preenchia o sistema errado e me dava informações conflitantes. Mesmo depois de ameaçar cancelar em vez de migrar, o atendimento deles se confundiu. Enfim, o saldo é que migrei de plano depois de uns 2 meses, só que logo no mês seguinte começaram a me cobrar por um ponto adicional, que não era cobrado antes, e nunca haviam dito que ao migrar para o plano coletivo o ponto adicional era cobrado por fora. De novo, liguei reclamando. A atendente disse que era para ser cobrado mesmo, que iria investigar, ouvir as conversas gravadas (acreditar em mim, pra que?), e que se alguém tivesse me prometido isso, veria se poderia cumprir a promessa e me dar a isenção. Fiquei bravo com a resposta. Twittei reclamando. Poucos minutos depois me ligaram, pediram desculpas e me deram a isenção que eu queria.

- Eu tinha um financiamento imobiliário no Unibanco, que agora virou Itaú. Mandei minha documentação para a Central para usar o FGTS para reduzir o valor da dívida, e, quando recebi o aviso de entrega dos Correios, liguei na Central para saber se estava tudo certo com a documentação. Quando ligo lá, disco meu número de conta e senha, e a pessoa que me atende diz que meu contrato não foi encontrado e que eu deveria ir na revenda (detalhe: nem sei o que é revenda!). Eu insisto que tenho um financiamento com eles, que já fiz esta mesma operação há 2 anos atrás, mas de nada adianta. A moça responde brava que eu deveria ir na agência ou na ‘revenda’ (detalhe: com a mudança para Itaú, minha agência já nem é mais a mesma). Não tive dúvidas: twittei. Logo entraram em contato comigo, acharam meu contrato na hora, me pediram 5 dias úteis para ter a resposta porque a documentação havia acabado de chegar e que iriam acompanhar o caso para conferir que a Central me avisaria quando tivesse uma resposta. Tudo perfeito.

O que eu aprendi destes dois casos? Que as Centrais de Atendimento destas duas empresas atendem mal e não estão nem aí para o cliente. Mas que as área de Marketing / Redes Sociais destas empresas não querem que os clientes falem mal delas em público, então, para compensar o mal atendimento, eles têm autonomia para fazer mais que a Central de Atendimento. Ou seja, para ser bem atendido, fale mal da empresa – em público. Provavelmente, quanto mais followers você tiver no Twitter e no Facebook, melhor será atendido. Aprendi. Da próxima vez nem ligo na Central, já saio falando mal que sei que terei um atendimento muito melhor e meu problema será resolvido na hora!

Será que as áreas responsáveis por Produtos, Atendimento, Marketing, Estratégia destas empresas se falam???? Fica a dica: as áreas tem que se falar!!!

Compartilhe!
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Add to favorites
  • LinkedIn
  • Live
  • Orkut
  • PDF
  • Posterous
  • RSS

Switch to our mobile site