Browsing Category

Clientes

Clientes, Exemplos práticos

Um bom exemplo de customer experience em vendas para a área financeira

maio 7, 2018

Este artigo foi escrito por Eduardo Diederichsen, Felipe Lindenmeyer  e eu. Eduardo e eu somos líderes da área de desenvolvimento de software na ilegra, e Felipe é um account manager sênior. Todos estamos conectados diretamente às exigências de clientes.

 

Diariamente negociamos com muitos clientes. A parte mais difícil não é dá-los um preço ou conduzir uma apresentação com slides bonitos e muitas buzz words. A parte mais difícil é identificar se o cliente potencial possui um desafio real e como este desafio pode ser abordado pelo potencial, linguagem e visão de mercado de nossa companhia. Quando descobrimos, o cliente merecerá nosso mais profundo foco para termos um bom entendimento e oferecer algo que se encaixe perfeitamente a suas necessidades, mesmo que ele ainda não entenda isto, e então tentar ajudá-lo a entender.

 

A experiência

Mas o que faz a experiência ser tão perfeita quanto deve ser para que o cliente assine o novo contrato? Impossível dizer pois que compra qualquer coisa são pessoas. Pessoas se baseiam em coisas diferentes para avaliar suas experiências em todos os lugares, dando mais peso a diferentes pontos baseado na sua personalidade e nas influências que receberam durante toda sua vida.

 

O cenário 

Este recente novo cliente executou uma jornada completa, desde o contato mais inicial até a assinatura de contrato toda dirigia por eles junto de vários candidatos. No final do processo eles decidiram comprar de nós. Vou relatar o que foi feito e como as coisas poderiam ter acontecido de forma diferente.

O cenário do cliente

É um cliente da área financeira, então ele sabe que os clientes financeiros no Brasil são muito exigentes com relação a toda a UX e a flexibilidade dos produtos. Na área financeira, o Brasil é o país com a User eXperience mais desenvolvida em todo o mundo, então a competição e os investimentos por aqui são grandes.

Primeiros contatos

O que aconteceu: o primeiro contato aconteceu em uma celebração casual não relacionada a trabalho. O assunto no grupo se dirigiu a trabalho. Exploramos rapidamente alguns exemplos de como temos ajudado alguns importantes parceiros a estarem a frente de seus competidores. O que realmente aconteceu: a atenção foi pega e cartões foram trocados. Poucos dias após uma reunião foi solicitada a nós para falar sobre nosso portfolio e conhecer seus requerimentos e preocupações.

A reunião

O que aconteceu: aconteceu na sede do cliente. O objetivo era, como solicitado, falar um pouco sobre cenários em que temos trabalhado e as oportunidades que temos identificado e previsto como experts no mercado. O que realmente aconteceu: eles entenderam que tínhamos conhecimento para ser um bom parceiro, e que se contassem conosco teriam opiniões de especialistas no mercado. Então o próximo passo é enviar uma proposta e todos comemoram? Sim, mas não tão rápido.

Os desafios
  • Primeiro! O que aconteceu: este cliente é uma empresa brasileira muito conservadora que ainda não tomou iniciativas relacionadas a transformação digital e nem mesmo quer isto. Já nós estamos muito acostumados a trabalhar baseado em metodologias ágeis, abordagens Lean, testar e descartar perdas rapidamente, etc. Eles queriam que tudo fosse previsível com objetivos e passos definidos. O que realmente aconteceu: eles entenderam que seus concorrentes já não trabalham mais neste modelo e que se mantivessem aquela forma, se manteriam atrás no cenário de competição. Então formulamos um misto de práticas que dariam parte dos controles que eles estavam solicitando mas ao mesmo tempo deram partes da liberdade que este tipo de trabalho necessita.
  • Segundo! O que aconteceu: eles nos disseram que gostariam de estar a frente de seus concorrentes sabendo quanto isto custaria e quanto tempo tomaria. Bem… se nós tivéssemos estas respostas, nós seríamos um dos competidores. E é neste ponto em que o mindset Lean e de experimentação recebem atenção. As startups que estão incomodando gigantes da indústria não têm este tipo de respostas. O que realmente aconteceu: decidimos atacar um primeiro entregável (podemos chamar de MVP) e depois disso realizar uma nova avaliação para desenhar próximos passos.
Quando as coisas esfriaram

O que aconteceu: tivemos os passos acima, mas estava tomando muito tempo para uma decisão ser feita e as coisas esfriaram (más notícias). Nossa decisão foi de convidá-los para vir à nossa empresa para que pudessem ver com seus próprios olhos tudo que discutimos. Eles realmente se impressionaram com nosso escritório pois viram que é desenhado da forma que precisa ser para dar liberdade às pessoas pensarem e inovarem. Este foi um passo chave porque puderam falar com pessoas que realmente trabalhariam em seu projeto. O que realmente acontece: a negociação esquentou novamente.

 

O que será encarado de forma diferente por cada pessoa

Há muitas questões subjetivas na explicação das frases acima. Nelas não exploro linguagem corporal. Não estou explorando frases que dissemos uns aos outros e como nos portávamos durante as reuniões. Logo, não estou dizendo como a empatia foi criada aqui. Vamos dar uma olhada mais próxima.

O cenário do cliente

Algumas empresas podem ter receio de inovar. É um cenário completamente novo. Pessoas temem o que não conhecem. Elas não sabem o que está vindo, então ficam com medo e param. Para outras companhias, o desconhecido é entusiasmante e elas sabem que é do desconhecido que a inovação virá. Elas procurarão por isso rotineiramente.

Primeiros contatos

Uma vez que aconteceu em um evento social, o foco não era uma avaliação. A empatia veio facilmente pois falamos de nossos cases brevemente (sem mover o foco de toda a noite para trabalho somente) e humildemente. Se fossemos muito sedentos pelas suas necessidades, poderíamos ter transformado o momento em momento chato e perder a atenção conquistada.

A reunião

O objetivo da reunião foi mostrar nossas capacidades e também flexibilidade para entender as preocupações sobre modelos e o que estávamos propondo. Naquela hora nós investimos tempo explicando e desmistificando práticas de desenvolvimento de software como Dojos, Meetups, modelos de gerenciamento de times, nossas preocupações com relação a qualidade (Testes A/B, testes de caos, etc). E naquela hora um fato muito importante aconteceu: a empatia com um dos participantes foi tão grande, ele viu tanto valor na proposição, que começou a defender algumas das abordagens sugeridas aos sponsors do projeto de forma muito entusiasmada.

Os problemas

Tivemos de usar muito conhecimento para mostrá-los as diferenças entre a forma que estavam tentando abordar o problema e a direção que vemos que o mercado está tomando. Foi um trabalho duro entender como ele estão acostumados a tratar projetos e misturar a uma realidade que pudéssemos trabalhar de forma a ter certeza de que alcançaríamos os resultados que ambos estávamos buscando naquela parceria. Mas o maior passo alcançado foi o uso do mindset de experimentação para abordarmos a primeira fase. Eles optaram por dar um tiro inicial no modelo que foi sugerido. Esta é a chance de manter as coisas andando bem para construirmos ainda mais confiança.

Quando as coisas esfriaram

Esta foi a parte perigosa. Ligar e incomodar a paciência do cliente não teria sido uma abordagem eficiente. Trazê-los a um ambiente conhecido onde poderíamos falar novamente sobre alguns assuntos e remover as dúvidas e objeções restantes foi uma boa iniciativa. As pessoas não entenderão tudo na primeira vez que você falar ou apresentar algo. Você precisará repetir no momento perfeito em que sua explicação fará sentido a eles para ter sua atenção e interesse afetados.

 

Apenas mais alguns exemplos genéricos

Um cliente pode gostar de escutar mais buzz words todas pronunciadas em inglês. Outro cliente, vindo do interior, pode não gostar pois considera que isto só funciona em grandes companhias. Sobre a proposta: um cliente pode preferir um documento repleto de belas imagens explicando de forma mais abstrata o que será alcançado. Outro pode preferir receber um documento de somente uma página indo direto ao assunto com relação aos entregáveis, usando somente texto. É imprevisível.

 

Legal! Como posso aprender com este cenário? 

A boa CX (Customer eXperience) se torna mais desafiadora de atingir quando falamos de ofertas B2B ou B2B2C. Quando você tem um cenário B2C você provavelmente terá pessoas no fim do processo que você deve agradar com sua oferta e vantagens. É mais fácil perguntar: “hey, você gostou desta nova feature?”. Voltando ao B2B ou B2B2C as variáveis são incontáveis, uma vez que você precisará lidar com muitas pessoas desde o início da negociação até alcançar o fim do contrato.

 

Como atacar de forma eficiente?

Resposta rápida: esteja interessado. Resposta longa: Mantenha o conhecimento entre as pessoas envolvidas, use esta experiência, e esteja interessado sobre evoluir o processo e realmente aprender com as lições aprendidas. Tente entender linguagem corporal e psicologia, conheça mesmo quem está comprando de você. Esta pessoa escreve publicamente? Dá discursos? O que ele está falando/escrevendo/lendo/escutando/estudando que você pode levar em consideração para criar um momento para um contato rápido?

Clientes, Exemplos práticos, TI é o negócio, Transformação digital

Processo de compra de software na evolução da TI

fevereiro 14, 2018

Quanto mais diferentes visões você possui sobre o mesmo assunto, mais informações você terá para tirar suas conclusões e tomar decisões se necessário. Este primeiro artigo sobre a evolução da TI teve uma visão de desenvolvedor e muito superficial de negócios. Este novo artigo procura olhar pela perspectiva de clientes comprando software e como estas visões são diferentes dentro de uma mesma indústria.

 

Como software costumava ser comprado

Nos últimos anos, empresas costumavam comprar software como qualquer outro produto: quero 5 carros com 4 rodas cada, transmissão manual e de cor branca. Elas não se importavam em como o software é produzido, ou qualquer tipo de boa prática para aplicar ao processo. Sim, dentro de documentos de requerimento de software havia sessões sobre segurança, protocolos e coisas como estas, mas no final de tudo, o menor preço venceria.

 

Velha (não tão velha) matriz de decisão

A matriz de decisão (exemplo abaixo usando o processo de compra de um carro) era muito simples de se ter critérios levantados. Eles também eram superficiais. O critérios em alto nível eram facilmente elencados como: níveis de segurança, performance, cronograma proposto, preço, cobertura do escopo, cases de sucesso, conhecimento na tecnologia selecionada, etc. Com esta matriz de decisão, os pesos eram dados de acordo com cada projeto. Mas o preço e o cronograma, depois de todas as avaliações de critérios ainda determinariam quem ganha.

No exemplo acima: o que exatamente é conforto e estilo para este comprador? Segurança pode ser avaliada usando dados públicos do governo. Este é o paralelo para mostrar como nenhum dos critérios está detalhado.

Qualquer um dizendo que poderia cobrir todo o escopo, dentro do cronograma solicitado, tendo uma quantia de dinheiro fixa, poderia vencer a batalha pelos projetos. Se eles não possuíam o conhecimento suficiente, não faria grande diferença. Depois de tudo, software era tratado como qualquer outro produto. Não importava como era feito. Só importava que funcionasse.

 

Matrizes de decisão recentes

Deixando de lado a indústria governamental, e poucas outras não afetadas nem um pouco pela transformação digital, a realidade tem mudado.

O que tenho visto ultimamente é um investimento maior de tempo no detalhamento dos critérios. Para cada um dos critérios, os compradores querem saber o que os fornecedores já fizeram, como eles planejam conduzir a solução e também avaliar alternativas para tudo.

  • Segurança: garantir que a troca de informações acontecerá dentro de um ambiente controlado? Táticas para obfuscação de código. Preocupações com segurança natural das plataformas. Certificações dos cloud providers, etc;
  • Cronograma: de “um cronograma detalhado” (que nunca era atingido) para “uma visão macro de tempo e um mix de metodologias ágeis para serem seguidas”;
  • Casos de sucesso: mostrar onde/quando soluções similares foram criadas;
  • UX: de “o sistema precisa ter boa usabilidade” (completamente subjetivo) para “precisa seguir guidelines de UX da Google e ser conduzida por um profissional adequado, e não pelos desenvolvedores”;
  • Performance: de “o sistema precisa carregar dentro de 10 segundos” para “cada endpoint precisa responder dentro de 2 segundos”;
  • Escopo: de “tudo deve ser contemplado” para “vamos fazer o máximo que pudermos dentro do cronograma”;

As companhias querem saber como seus projetos serão conduzidos em detalhes, e elas também querem colocar suas opiniões sobre tal. Uma vez que a transformação digital está fazendo as companhias entenderem que a TI é o core, a TI deixa de ser suporte. Então agora elas são capazes de fazer sugestões e falar no mesmo nível das consultorias.

Com esta comparação e cenário de evolução, o mindset de MVP fica muito claro. Também os objetivos de atingir time-to-market e receitas mais velozes.

 

Requisições diferentes dentro da mesma indústria

O relato acima é correto para 100% das companhias nas indústrias mais maduras do Brasil. Porém para o resto delas, usando varejo como exemplo, ainda não:

Há lojas que já estão evoluingo seus ecommerces para segurança, performance, escalabilidade, estabilidade e o mais importante: experiência do usuário. Mas também há aquelas que tratam suas lojas online como algo necessário somente. É comum a cópia de práticas de layout dos concorrentes. Também, segurança é algo caro. Algumas empresas possuem budget para perder devido a invasões de hackers, em vez de investir em segurança naquele momento.

A boa notícia é que o mercado está evoluindo cada vez mais rápido. Em breve nenhuma indústria estará para trás.

Clientes, Escritório, Evitando problemas, Exemplos práticos

Como evitar aplicações suicidas

janeiro 29, 2018

Tendo experiência em gerenciamento de muitos projetos em muitas metodologias diferentes e diferentes misturas delas, recentemente pude identificar algumas características que acontecem em todos estes cenários e tornam um projeto suicida na forma de se gerenciar. Por suicídio me refiro a um projeto que encontrará problemas e decairá até que alcance um ponto inaceitável, levando a perda de um cliente ou algo extremo como isto.

Os itens abaixo foram identificados como algo comum a todas as formas de gerenciamento, e se qualquer um deles for comum a você ou parte da sua rotina, é hora de mudar algo. Alguns deles se referem ao relacionamento entre as pessoas e alguns deles a práticas técnicas.

 

Sem ambiente de QA

Um projeto que tem somente um ambiente formal de produção. O desenvolvimento é feito pelo time nas suas próprias máquinas. Não há ambiente de QA (Quality Assurance).

Parece loucura, certo? Mas ainda acontece. Geralmente acontece quando quem está pagando a conta não entende quanto catastrófico pode ser não ter um ambiente de QA / Testes / Homologação. Quando isto acontece, você está lidando com sua sorte diariamente, como a imagem acima.

O ambiente de QA deve ser, idealmente, uma cópia exata do ambiente de produção. Rotinas de cópias de PRD (produção) para QA precisam ser mantidas de tempos em tempos. Quando isto funciona, sempre que um problema em PRD aparecer, será mais rápido para identificar e simular em QA. Se é mais rápido de simular, é mais rápido encontrar uma solução e consertar PRD. Quando um problema em PRD é solucionado rapidamente, o cliente perde menos dinheiro relacionado àquela falha, ou no mínimo sua marca é menos afetada devido àquela parada.

Podem haver diferentes formas ou requerimentos mínimos para ter pelo menos um teste confiável antes de enviar código novo a PRD. Os dados de QA podem ser diferentes dos atuais de PRD. Os ambientes podem ter diferentes configurações de hardware e etc. Mas quando mais diferenças houver entre QA e PRD, mais tempo será gasto rastreando problemas.

Falando sobre um serviço diferente, quando você não possui um ambiente de QA, é o mesmo cenário de um médico tentando um novo método cirúrgico que não foi testado em ratos ou macacos antes. Pode até funcionar. Mas há uma grande chance de dar errado. E quando funciona, é sorte.

 

Zero automação

Quanto mais automação você tiver, menos erros humanos acontecerão. Pessoas vão falhar. Isto é normal! Vamos deixar que as pessoas pensem no que realmente importa e não em atividades de rotina. De alguma forma isto irá acontecer algum dia:

  • Vão commitar o último código na branch errada. A produção vai parar;
  • Vão esquecer de executar um script antes de deployar um pacote. A produção vai parar;
  • Vão esquecer de rodar um teste mínimo programado antes de executar um novo processo ou serviço. A produção vai parar;

Uma boa forma de prevenir estes erros é automatizar a maior quantidade de coisas que puder.

Um bom ponto de partida pode ser automatizar a atividade de deploy. Muitas companhias com que me relacionei ainda possuem problemas com processos de deploy. Elas planejam com 4 semanas de antecedência. O deploy é feito. Dá errado. Requer mais uma ou duas semanas para consertar o código e colocar a produção para rodar novamente. Então planejam o próximo com dois meses de antecedência. Dá errado novamente. Se o deploy é um problema, porque não torná-lo algo trivial? Tente fazer todos os dias. Muitas coisas serão aprendidas.

Automatizar testes também é uma ótima iniciativa. Testes automatizados são uma das melhores armas para estabilidade de software. Quanto maior for a cobertura de testes, mais estável a aplicação será. Estas duas sugestões vão requerer tempo para serem implementadas, mas seus benefícios serão sentidos na credibilidade do software por toda a companhia.

Falando de um serviço diferente, não ter automação é como carregar um armazém caixa por caixa, sem uma empilhadeira. Muito tempo será desperdiçado, é claro. Mas também muitas caixas serão derrubadas. Muitas serão chacoalhadas demais. Vai funcionar, mas muitos riscos são adicionados ao processo desnecessariamente.

 

Displicência dos usuários chave

O responsável por testar seu projeto é o ator principal da sua rotina. A opinião dele será questionada sobre quaisquer óticas e práticas. Esta pessoa precisa estar comprometida e viciada no seu projeto, ajudando e apontando dedos a qualquer coisa que dê errado.Os melhores projetos com os quais já me envolvi tinham pessoas muito minuciosas testando e dando seu OK às features entregues.

Se o seu projeto carece desta preocupação, alguns problemas podem surgir:

  • Falta de percepção de valor. O que você vêm praticando/dizendo não é o que o cliente gosta de ver/escutar;
  • Falta de alinhamento entre o que é desenvolvido em comparação ao que adiciona valor ao negócio;
  • O pior deles: falta de conhecimento sobre o sistema. Esta pessoa deveria ser quem conhece todo o sistema. Se ela não o faz, muitos problemas podem aparecer em função de diferentes concepções sobre porque algo foi desenvolvido de certa forma, e não de outra.

Este exemplo é como uma mãe que não se importa com a edução de seu bebê. Ele vai crescer, é claro. Mas pode se tornar uma bomba relógio.

Fraco julgamento para escolhas tecnológicas

Tecnologia é algo sério e não pode ser tratado como tendências de moda. Tendências de moda vêm e vão e se renovam de tempos em tempos. Uma linguagem de programação, framework, feature, provedor de cloud, e todo o restante relacionado ao desenvolvimento, não podem ser eleitos porque são legais ou por serem a coisa de que todos falam, a moda. Todas estas decisões precisam ser questionadas pelo time de desenvolvimento e, se possível, contar com ajuda de alguém de fora do projeto para pensar junto com o time e alcançar a melhor escolha.

Quando alguma má escolha tecnológica é feita, alguns problemas podem surgir:

  • Dificuldades de encontrar profissionais que conheçam aquela tecnologia para trabalhar com seu projeto;
  • Problemas no futuro devido a incompatibilidades daquela tecnologia com os requisitos do projeto;

Usando o paralelo com outros serviços, usando uma tecnologia que não está provada ainda é como comprar um hamburguer com bacon vegano dentro dele. Pode ser bom, mas ainda não temos certeza. É uma aposta.

 

Comunicação/status deficiente

Como está estruturada a rotina de comunicação com o seu cliente? Você tem um momento formal para compartilhar informação? Ou você faz isso baseado em um gatilho? Neste ponto não há resposta certa, como sugerido no artigo “A resposta mágica para gerenciamento de projetos de software“.

Mas você terá um processo para compartilhar informação e dizer o que você tem feito a quem quer que esteja pagando a você. Pode parecer estranho, mas compartilhar informação pode ser um problema sério em muitos projetos. Você precisa ter certeza de que as atividades que você está conduzindo fazem sentido ao cliente, e ele entende que o que você está fazendo é bom para o negócio. Você tem reuniões semanais? Diárias? Um status report?

Quando você não tem um processo para dar feedback sobre o que você está fazendo, é como investir dinheiro com uma empresa de investimentos que não te informa sobre seus ganhos.

 

Porque atacar tudo isso?

Todas as constatações acima se referem a práticas que precisam ser consideradas em seu projeto. Caso contrário, os problemas em seu relacionamento ou nos dados da aplicação serão evidentes. Quando qualquer um dos pontos abordados acontecem, significa perda de dinheiro ou pelo menos enfraquecimento da marca envolvida. Pode ser natural que o aplicativo principal de um banco não tenha grandes problemas. Mas o usuário não gostará quando o registro para aquele programa de cashback quebra. Significa que o banco não é sério frente a seu usuário e sobre suas campanhas de marketing.

Clientes, Exemplos práticos

Status report – Um exemplo e modelo real

janeiro 1, 2018

Status report é uma ferramenta poderosa para vários assuntos e intenções. Este exemplo prático traz um cenário real criado por mim algumas semanas atrás e mostra uma abordagem para passar a mensagem às pessoas que importam.

O modelo está apresentado, e todas as seções também estão descritas abaixo, mostrando qual é a intenção e porque faz sentido a este cenário. O documento está DISPONÍVEL AQUI (inglês e português) e você pode utilizar em seus projetos livremente.

O modelo

 

 

Identificação, gerente de projeto, objetivo e data

Estas quatro seções são muito importantes para garantir que todos que abram seu arquivo saibam exatamente sobre que projeto você está falando.

  • Cliente X – Qual é a empresa pagando e interessada pelo seu projeto? É importante para você e para qualquer pessoa dentro da sua empresa entender;
  • Projeto Y – Qual é o nome do projeto? Esta é a identificação para qualquer um que receba este arquivo entender seu propósito;
  • Gerente de projetos – Quem é o responsável por este projeto? Em todas as pontas que importam a você. Neste caso apenas minha companhia e o cliente foram importantes. Você pode adicionar outros fornecedores por exemplo;
  • Objetivo – Seu objetivo principal. É importante para manter o foco. Uma vez que este arquivo é acessível a todos do projeto, todos precisam entender a que eles estão contribuindo e se sentir parte daquilo;
  • Data – mostra o período a que o arquivo se refere. Mantenha histórico dos seus status reports! Isto permitirá que você acompanhe seu progresso, as coisas que você já tentou ou está tentando, e como elas estão indo;

 

Status, logos and datas planejadas
  • O status geral é uma informação executiva e para onde todos olharão. É uma mensagem simples mostrando como seu projeto está indo. Não se trata de como você acha que está indo. Você precisa ter números para definir. Neste documento foram usados 3 KPIs (mostrados abaixo) e as regras foram: se todos estiverem verdes, o geral é verde. Se pelo menos um estiver amarelo, amarelo é o geral. Se qualquer um estiver vermelho, todo o projeto está vermelho;
  • Os logos (seu e do seu cliente) possuem uma mensagem importante sobre a parceria responsável por conduzir este projeto. Isto passa uma mensagem subjetiva mostrando a todo o time como as duas companhias estão engajadas para alcançar o mesmo objetivo;
  • A data fim original é a primeira data planejada para finalizar o projeto de acordo com o cronograma;
  • A data fim replanejada é preenchida somente se você precisou replanejar sua data de finalização por alguma razão. As razões precisam ser mostradas nas atualizações (exemplos abaixo) quando um replanejamento acontecer;

 

Riscos, mudanças e dependências

Qualquer acontecimento aos riscos e mudanças precisam ser verificados por você, como gerente de projetos responsável, para entender se requererão qualquer tipo de replanejamento. Pode afetar seu cronograma, seus custos, pessoas envolvidas, recursos externos, fornecedores, etc;

  • Riscos é onde você lista tudo que pode afetar seu projeto e mudar algo planejado. É comum que seja algo fora de seu controle, então tenha um plano para cada um dos riscos para lidar com problemas quando algo der errado;
  • Mudanças precisam ser preenchidas quando algo relevante acordado foi alterado por alguma razão. Uma decisão foi repensada? Faça com que todos saibam;
  • Dependências é uma seção usada quando você tem tarefas dependendo do esforço de outras pessoas ou times. É muito importante pois se eles se atrasam, você precisará tratar o impacto;

O exemplo possui uma dependência com um deadline tachado. O objetivo é mostrar que uma entrega planejada não foi finalizada e precisou ser replanejada.

Também há uma dependência com um deadline pintado em vermelho. Isto se refere a uma tarefa que precisa ser desenvolvida por alguém fora do time original do projeto. Precisa haver uma pessoa responsável e também uma data quando o entregável será de fato entregue. Se a tarefa está atrasada, todo o projeto poderá ser atrasado.

 

Atualizações

Esta seção é a que terá maior quantidade de informações sendo mudadas de semana para semana. Todo seu conteúdo pode ser mudado de uma semana para outra. Aqui é onde você listará tudo o que aconteceu, pessoas adicionadas, resultados de testes, entregas de outros fornecedores e etc. Também gosto de manter dois sub-tópicos: o que foi finalizado durante a última semana, e o que será feito na próxima.

 

Cronograma

O cronograma faz sentido quando você está lidando com um projeto com escopo fechado ou não. Você pode usar para dar visibilidade sobre a próxima entrega importante quando estiver gerenciando projetos ágeis, por exemplo. Você pode mostrar atividades macro ou ainda mostrar 100% de todo seu planejamento (como o exemplo mostra).

O exemplo lista as tarefas e as dá cores:

  • Quando verde, está pronto para ser desenvolvido;
  • Se está laranja, depende de algo externo e não pode ser iniciado no momento;
  • Para vermelho, significa que está atrasado por alguma razão;

Também mostra as tarefas planejadas para serem entregues durante a semana (destacada em laranja na primeira linha da tabela). Estão representadas pelo X na célula respectiva. E por último mostra o percentual de cada uma das tarefas;

 

KPIs

As métricas que você decide medir durante o projeto. Para este, pessoas, escopo e datas eram os aspectos principais. A tabela mostra a métrica e o status de cada uma. Quando você tiver algo diferente de verde, você deve escrever o motivo que justifica aquela métrica não estar indo bem. Não esqueça de adicionar os custos à seção de KPIs;

Carreira, Clientes, Evitando problemas, Exemplos práticos

Problema de comunicação? Talvez seja problema de engajamento

dezembro 24, 2017

Comecei a pensar neste artigo como minha retrospectiva de fim de ano. E percebi que a maior coisa que aprendi durante o ano é sobre engajamento.

Tenho escutado, durante anos, que “80% dos projetos que falham, falham por causa de falta de comunicação”. Esta é uma verdade triste, mas neste ano percebi que esta é uma fácil e confusa abstração. Quando você fala que comunicação é o problema, você está escondendo vários problemas sérios,  não apenas no seu projeto, mas também em sua organização. E após este momento eureka, um novo momento veio: “pessoas se comunicam da forma correta” se estão engajadas e têm suporte para se desenvolver.

 

Alguns exemplos
  1. Temos um contrato para monitorar uma aplicação online. Não é muito crítica, mas ainda temos SLAs para cumprir quando há algum problema. Então um problem vem e a pessoa de OPS esquece de avisar ao cliente, durante os primeiros 15 minutos, que ele está procurando uma solução. Além disto, ele toma uma hora além das 4h planejadas, para resolver o problema. Isto causa uma discussão durante uma reunião entre os gerentes e todos finalizam o assunto dizendo que tiveram um problema de comunicação.
  2. Evoluímos uma solução bastante crítica, que trabalha com o dinheiro de um cliente. Então um desenvolvedor não cria o test automatizado e o aplicativo quebra quando vai para produção. Isto causa uma discussão durante uma reunião entre s gerentes, e todos concordam que o profissional de QA não se comunicou corretamente com o desenvolvedor sobre o teste faltante.
  3. O gerente de projeto avisa que o projeto está atrasado, mas não diz o quanto. Quando alguma coisa vai mal e alguém pergunta sobre, ele defende a si mesmo dizendo que contou sobre o atraso, e houve um problema de interpretação porque aqueles que leram não entenderam a mensagem da mesma foram que ele quis dizer. Então após mais uma reunião, todos concordam que ele não se comunicou da maneira correta.

 

Porque acontecem

O que aprendi durante este ano, sobre engajamento, foi a identificar porque estes exemplos acontecem:

  1. A pessoa do time de OPS não contou ao cliente que estava trabalhando já nos primeiros 15 minutos, e esqueceu de avisar que tomaria mais uma hora para resolver o ticket, porque ele não estava de fato empoderado de sua posição. Ele não entende a vitalidade de sua posição. Se ele esquece de avisar ao cliente sobre o down time, o cliente não poderá avisar aos usuários. Os usuários começarão a acionar o call center. Então pelo menos 10 pessoas terão mais trabalho para fazer, forçando a empresa a pagar por horas extras, por causa de uma informação faltante. A pessoa de OPS não teria esquecido de contar a ninguém necessário caso ele entendesse todo o cenário.
  2. O segundo exemplo não tem nada relacionado ao QA. A responsabilidade afeta o desenvolvedor. Ele não criou o teste porque não sabe que a cada hora do sistema parado, o cliente perde US$ 10.000,00. Ninguém, quando velho, irá querer contar histórias aos seus filhos dizendo “hey, uma vez eu parei o sistema de produção, e estraguei a vida de várias pessoas”. Então o desenvolvedor foi negligente sobre o teste porque não estava de fato empoderado de suas responsabilidades e atribuições.
  3. A intenção do gerente de projeto não é esconder informação. Ele é pago, essencialmente, para manter as pessoas informadas. Quando ele espera um ou dois meses para dizer que o projeto está 2 meses atrasado, ele não pensa que as pessoas necessárias ao projeto serão demandadas no próximo, e que isto causará prejuízo à companhia. Uma vez que as pessoas não estarão disponíveis, o projeto original não terá orçamento suficiente, e toda a companhia precisará gastar mais dinheiro para contratar novas pessoas para o próximo.

Então se você está dentro de qualquer um destes exemplos, pense no outro lado como se fosse um amigo seu. Você deixaria qualquer um destes exemplos acontecerem se soubesse o quão profundo eles afetarão?

 

Resolvendo da forma errada

É fácil pegar estes problemas e rotulá-los como problemas de comunicação. Então nossas cabeças técnicas pensarão em processos para garantir que:

  1. O sistema de tickets envie emails automaticamente avisando o cliente de que estamos trabalhando sobre o problema;
  2. Nós criaremos uma integração entre a ferramenta de aceitação de tarefas e o repositório de código para verificar se todas as tarefas têm pelo menos um teste desenhado;
  3. O gerente de projeto sempre apresentará o status report tendo o cliente ao seu lado, então nenhuma informação será perdida novamente;

As sugestões acima não estão erradas e não devem ser encaradas como algo para ser evitado. Mas elas precisam ser a última alternativa. Elas são remendos para a falta de engajamento das pessoas.

 

Resolvendo da forma correta: construa

As pessoas são boas. Quando você compartilha, da forma correta, as responsabilidades delas e como as atividades delas afetam as outras, elas se sentirão como parte do grupo e tentarão sempre ajudar a todos. Então porque não perguntar a cada um dos atores destes exemplos como eles resolveriam o problema? Apresente o problema, diga tudo o que aconteceu ou pode acontecer em função do comportamento deles. Como resolver? Esta é a parte mais difícil. Provavelmente a primeira coisa a vir não será a solução perfeita ou a solução em que você pensou. Então é hora para mostrar uma solução melhor e verificar se ela faz sentido àqueles que a colocarão em prática. Um mix das ideias pode ser um bom início.

E começamos a falar sobre a maturidade das pessoas para resolver problemas:

  • Se eles são junior com um bom potencial, apenas envolvendo-os e contextualizando-os sobre suas responsabilidades pode resolver o problema. Eles possuem boas intenções! Eles não esquecerão de contar a ninguém o que estiver acontecendo da próxima vez;
  • Se eles estão sobrecarregados, você aconselhará sobre procurar ferramentas para auto gerenciamento. E também ajudará a focar no que é importante e a não ficar sobrecarregado novamente;
  • Se você identificar que é necessário, porque não usar uma das soluções processuais descritas acima como o caminho errado? Tome cuidado porque elas precisam fazer sentido para todos os afetados. Depende da maturidade das pessoas para que não se sintam forçadas;

 

O objetivo é olhar para o mindset de empowering e de colaboração (networks), como descrito na imagem abaixo:

 

Sempre tenha próximos passos

Certa vez fui convidado para participar de uma retrospectiva. O objetivo era ajudar um time com uma visão externa para que eles pudessem melhorar seus processos. A primeira coisa que perguntei foi onde estavam os “próximos passos” da retrospectiva anterior. Para minha surpresa, não havia próximos passos.

Sempre mantenha histórico dos objetivos e resultados. Isto lhe dará senso de melhoria, e se não der, será fácil encontrar onde os novos erros foram cometidos. Tenha um checkpoint periódico sobre cada um dos cenários acima, até que eles se encaixem em uma estrada em que os problemas não aconteçam novamente.

Depois disso, quando você tiver a solução completa, você poderá ainda compartilhar sua boa prática com outros times próximos de você:

  • O que aconteceu; Porque aconteceu; Quando aconteceu;
  • O que você fez para resolver, quais foram as primeiras tentativas, o que realmente resolveu?
  • O que você aprendeu disso? Próximos passos;
Clientes, Escritório, Evitando problemas

A resposta mágica para gerenciamento de projetos de software

dezembro 3, 2017

Recentemente tenho negociado com diferentes clientes sobre muitos diferentes projetos. Em uma olhada rápida pelos projetos, é incrível como as pessoas perseguem de forma errada uma única metodologia de gerenciamento de projetos para aplicar a todos eles. Além disso, quando clientes procuram por “metodologias ágeis”, o que a maioria deles quer dizer é “use Scrum para tudo”. Então após minha opinião ser questionada por um amigo que recebeu a missão de estabelecer um PMO, a ideia deste artigo surgiu.

 

Diferentes clientes têm diferentes necessidades

No meu cenário, como uma empresa de consultoria, é muito fácil notar que diferentes clientes possuem necessidades diferentes. É comum ser questionado sobre metodologias de desenvolvimento de software. A questão principal é que, mesmo dentro da mesma companhia, haverá diferentes formas de gerenciar projetos. Não há um único padrão. Depende das pessoas. Depende diretamente da maturidade do time para agir, e vou mostrar alguns exemplos baseados no infográfico “Breve história da evolução da maturidade do desenvolvimento de software“.

A abordagem tradicional / cascata / CMMI:

Ainda o mais comum dentro de grandes organizações. Dá informação executiva e muita informação concreta sobre o projeto aos gerentes. Foca em muitos processos e arquivos para manter rastreio de tudo que está acontecendo no projeto. Mapeamento de dependências, mapeamento de comunicações, controle de escopo, e muitos outros serão feitos pelo gerente. E isto irá custar muito dinheiro.

A abordagem Scrum:

Mais flexibilidade, menos processo, mas ainda alguns problemas. Scrum permitirá que o projeto seja mais dinâmico devido ao foco menor em processos e arquivos. O que o Scrum diz é “continue mandando trabalho e nós continuaremos entregando”. Possui muitos benefícios: menos tempo perdido em burocracia, “customer first” mindset, etc. Mas possui alguns problemas: é difícil de se trabalhar com datas e dependências, e as dailies perdem o valor facilmente.

As práticas XP:

Flexível, foco em encontrar valor rapidamente, feedback em toda esquina. XP foca em encontrar valor o mais rápido possível com o mindset MVP (Mínimo Produto Viável, em tradução livre). Também ajuda a melhorar as práticas do time constantemente devido a ciclos de feedback constantes. XP precisa de um time muito disciplinado para ser executado, caso contrário o time pode perder o foco devido à falta de práticas de controle.

A abordagem DevOps:

Auto-atendimento, zero gargalos e automação. DevOps tem sido a palavra mais dita em TI durante o último ano pelo menos, mas pouquíssimas pessoas de fato o praticam. Ele foca em fazer com que todos que realmente importam ao projeto trabalhem juntos, e isto inclui o time de negócios, experiência de usuário, DEV e OPS, e todos os outros que possam importar. Eles precisam ter autonomia para tomar decisões. Ninguém pode ser gargalo. Os desenvolvedores precisam ter o mindset de auto-atendimento, caso contrário dependerão de outras pessoas para finalizar seu trabalho. DevOps também trará alguns desafios, como os DEVs que não gostarão da operação, e o time de OPS que não gostará de criar código.

 

Diferentes mindsets para gerenciamento de projetos

Todos os modelos acima foram apresentados com benefícios e problemas que trazem. Cada um deles pode ser útil se aplicado ao contexto correto. Então, nenhum deles é a resposta mágica para quaisquer que sejam os problemas que você está encarando em seus projetos. O cenário perfeito é agregar práticas, EXPERIMENTAR, até que você encontre o melhor modelo para você e seu time. Mas como fazer isso? Se o seu momento não está permitindo que você encontre o como, é muito provável que você esteja sobrecarregado pela operação e esteja esquecendo de pensar nos seus objetivos reais. Tente olhar de cima. Seus principais objetivos, em desenvolvimento de software, estão explorados abaixo, e é onde os seus esforços devem ser focados:

  • Entregue valor constantemente – mudar o fundo da aplicação de azul para vermelho pode ser legal. Mas isto realmente agrega valor ao negócio? Qual é a diferença ao projeto ou ao usuário final? Foque no que realmente importa e não apenas em criar mais código.
  • Customer first – a razão para todo projeto de desenvolvimento de software existir é o usuário final. Sempre foque em agradar a este usuário. Se a opinião dele(s) não for positiva sobre o que você estiver entregando, eles não usarão sua ferramenta. E seu projeto será inútil. Seu cliente final está feliz? Eles sentem que o software tem boa experiência de uso? Eles encontram valor usando sua ferramenta?
  • Experimentação – a forma mais rápida de se melhorar as coisas, mesmo quando você não sabe que coisas deve melhorar. Experimentar depois de uma boa retrospectiva é algo para ser feito frequentemente.
  • Foco nas pessoas – a chave para alcançar todos os pontos acima. Se as pessoas estiverem felizes e encontrarem valor na sua organização, confiarem em você e gostarem do ambiente e das rotinas, elas farão e testarão tudo que o time idealizar.

 

Então gerencie do seu próprio jeito

Então a resposta para você aplicar as melhores práticas de desenvolvimento aos seus projetos é o seu mindset. Uma vez que seu mindset estiver alinhado aos objetivos que você precisa alcançar, esquecendo quaisquer vícios em processos anteriores, então o seu processo correto será naturalmente criado pelo time.

Clientes, Escritório, Evitando problemas

Comunicação – como

novembro 16, 2017

Ultimamente tenho visto muitas pessoas tendo problemas para passar mensagens adiante. Isto sempre foi uma verdade. Mas uma vez que tenho visto muitos exemplos ultimamente, decidi dar prioridade à esta ideia de artigo.

O maior problema da maior parte das pessoas é a falta de contexto e como elas estruturam uma ideia. Não importa se elas estão dando um discurso, falando com alguém, ou escrevendo um email, o problema é o mesmo. Todos sabemos que a comunicação tem sido a maior causa de falha de projetos. Isto é TÃO REAL que é fácil encontrar artigos de qualidade sendo publicados recentemente. Um bom exemplo é este artigo da CIO, que publicou um texto dando conselhos sobre problemas comuns. Os números 1 e 5 são sobre comunicação.

 

A riqueza de cada interação

Do melhor para o pior:

  • Conversa cara-a-cara: você pode falar seus assuntos, checar na hora se a outra pessoa entendeu, e receber um feedback em tempo real.
  • Vídeo conferência: o mesmo acima, porém com menos clareza sobre as percepções e reações do outro lado.
  • Telefone: o mesmo acima, mas você não pode ver as reações do corpo e do rosto da outra pessoa.
  • Email: você pode escrever, mas você não terá um feedback (pelo menos não em tempo real).
  • Comunicação broadcast (vídeos, folders, etc): será muito difícil receber um feedback/

 

Quando você está falando com alguém

Primeiro de tudo, o que é feito é importante, mas foque no como é feito.

Sempre que você quer falar com alguém, o que a sua boca diz é menos de 10% da sua mensagem. 38% é dito pela seu rosto e 55% pelo seu corpo.

Então se você está falando com alguém e aquilo é importante, é claro que você precisa preparar seu discurso. Você precisa convencer um cliente de que sua decisão é melhor do que a dele? Vamos tentar organizar isto dentro dos três passos abaixo:

Seu discurso

Se prepare MUITO. Quanto mais você se preparar, mais fácil será alcançar os próximos dois passos. Vamos dizer que você está tendo uma discussão técnica: tente olhar pela ótica de todos os outros envolvidos para ter certeza de que todas as opiniões foram consideradas. Tente fazer o papel do diabo e imagine os questionamentos que poderiam aparecer da pessoa mais crítica que você conhece. Você tem um colega ou um líder que sempre questiona tudo e todos? Talvez este cara seja útil. Então a parte mais importante é preparar você mesmo o máximo que puder, porque se você souber tudo sobre aquele cenário, você estará muito confortável para argumentar sobre o assunto.

Seu rosto

Agora que você sabe tudo que precisa ser dito, é hora de ser confiante. Pessoas são mais propensas a acreditar nas mensagens de pessoas que elas julgam confiáveis. Você não gosta de ser abordado por um mendigo, certo? Sua aparência conta muitos pontos aqui. Também, se você está mostrando felicidade no seu rosto, você captará a empatia das pessoas mais facilmente. Mas tome cuidado para não rir de tudo, caso contrário as pessoas pensarão que você está fazendo piada nesta parte tão importante do trabalho.

Seu corpo

Como acima, o ponto principal é que as pessoas acreditam no que elas vêem. Então você é sua imagem, não seus pensamentos. Seu corpo precisa estar confiante ao mesmo tempo que sua mensagem é clara e seu rosto está calmo. Péssima hora para chacoalhar as pernas, roer as unhas, ou ficar olhando para o rosto de todas as pessoas na reunião procurando por aprovação. Como ter toda esta confiança? Se preparando MUITO. Uma vez que você já está muito bem contextualizado com o assunto, e seu rosto está calmo, foque em ser claro e estar confiante.

 

Escrevendo comunicados

Ok, você não pôde encontrar a pessoa com quem precisava conversar e precisará usar um meio assíncrono de comunicação. Vamos deixar isto MUITO claro. Você NÃO PODE simplesmente enviar uma mensagem importante por email e assumir que o outro lado recebeu e leu exatamente da mesma forma que você escreveu. Isto nunca vai acontecer.

Mas vamos dizer que você quer enviar um relatório que é muito ruim para seu cliente. Precisa ser formal (usando email), mas também precisa ser dito de forma muito clara. O jeito perfeito de fazer é: escreva o email, confira muitas vezes, então encontre uma forma de ligar para a pessoa do outro lado. Então diga tudo o que está no email, peça pelo seu feedback, mude algo que ele possa discordar (de acordo com a realidade é claro), e só então envie.

Mas como escrever este email?
  • Qual é o objetivo? O que você quer que aconteça após o outro lado ler seu conteúdo?
  • Quem receberá? Coloque-se no lugar da oura pessoa, lendo seu email. O que ela pensará de cada frase?
  • Use frases curtas: pessoas são impacientes. Não escreva grandes parágrafos. Elas pararão de pensar no meio do primeiro parágrafo extenso, e não vão entender o resto.
  • Palavras difíceis: evite. As pessoas sabem que você é inteligente. Pessoas são impacientes.
  • Não assuma que as pessoas sabem de tudo: é você quem tem todo o contexto para escrever aquele email, não o outro lado. Todos precisam estar na mesma página. Se você está em dúvida, explique.
  • Seja claro: divida seus pensamentos como abaixo:
    • Introdução: estou aqui para falar sobre o desafio X.
    • Justificativa: nós devemos falar sobre o desafio X porque Y.
    • Argumentação: mostre seu ponto!
    • Conclusão: o que faremos agora?

Lembre: você não está escrevendo um livro. Cada um dos pontos acima pode ser feito em uma frase, por exemplo, exceto pela argumentação.

Clientes, Empreendedorismo, Transformação digital

A onda de inovação que não estamos surfando bem

outubro 20, 2017

Durante os últimos anos, temos visto muitas novos e disruptivos negócios e empresas surgindo a nossa volta. São as conhecidas Startups. Elas têm entendido as tendências e novas possibilidades de mercado que a tecnologia está permitindo, encontrando espaços para se estabelecer, e permanecendo intocadas por algum tempo, o que os permite continuar inovando, crescendo e colocando as antigas companhias de lado.

 

A onda

Esta inovação e disrupção de mercado muito rápida é um movimento sem volta, e as companhias e pessoas inovarão ainda mais rapidamente nos próximos anos. Porém as companhias bem sucedidas que temos visto, como Contabilizei, Guia Bolso, Love Mondays, Movile and Nubank, que tiveram capacidade de crescer, são apenas um pequeno grupo de uma grande massa de empresas que são criadas. No início de 2016, o Brasil possuía 4151 startups (o que era um número bastante expressivo para nossos padrões). Mas naquela mesma época, apenas a região do Vale do Silício, nos Estados Unidos, tinha mais de 23000 startups.

Então porque o Brasil, um dos países mais criativos no mundo, contando com a sexta maior população em números absolutos, tem um número tão pequeno de startups sendo criadas e, principalmente, alcançando o sucesso? Nós temos boas ideias? Elas estão sendo bem exploradas?

 

Onde estamos parando

É de conhecimento geral que o Brasil possui a burocracia enraizada em sua cultura, e estes dados do World Bank Group mostram que, comparado aos Estados Unidos, é 15 vezes mais difícil de se fazer negócios por aqui.

 

Fonte: World Bank Group

 

Mas é realmente somente a burocracia que nos proíbe de criar novos negócios, mercados e inovar em larga escala? Talvez nossa abordagem aos problemas não esteja tão madura quanto está em outros países.

Como um exemplo conhecido, temos as fábricas de redes para cabelos: na década de 1910, o negócio principal era produzir mais e mais redes para cabelos para que as mulheres daquela época pudessem “segurar”seu cabelo para manter o penteado. Os donos das fábricas mantiveram este conceito muito forte e não puderam ver a real questão. A demanda não era sobre redes para cabelos. A demanda era sobre “segurar cabelo”. Então os fixadores de cabelo vieram e a indústria de redes de cabelo faliu. Mas porque os donos da indústria de redes de cabelo não viram a mudança no mercado? O mindset deles estava ajustado ao produto, e não à demanda. Não ao cliente.

O mindset precisa ser “customer first”

Agora abordando o mesmo problema com uma visão orientada a serviços. Um negócio comum de salão de beleza geralmente possui uma hierarquia parecida com isto:

Uma vez que sabemos que é o cliente quem traz o dinheiro, e que é ele quem precisa ficar satisfeito para que volte a fazer negócios com esta empresa: neste diagrama, quem é o ator mais importante PARA O CLIENTE? É fácil pensar no gerente ou mesmo que o dono é o mais importante. Eles possuem autonomia para resolver quaisquer problemas, e conhecem a melhor forma de interagir com os clientes e como fazê-los felizes, porque já possuem muita experiência. Mas a realidade é que, como os clientes têm ficado cada vez mais exigentes, o dono E o gerente são inúteis. Os atendentes, que estão interagindo diretamente com o cliente, são a parte mais importante aqui! Eles tem um comportamento chave para todo o sistema. Vamos pensar no cliente indo até o salão de beleza e tendo problemas com o atendente. O gerente será chamado e o problema será resolvido. Legal! Foi resolvido mas este foi um movimento reativo. Dependendo do nível de stress causado no cliente, é muito provável que ele não retorne ao salão de beleza. Ele encontrará um serviço melhor.

 

Estratégia de negócios

Então uma abordagem melhor é pensar sobre os atendentes como a parte mais importante do sistema.

Mas o dono e gerentes continuam sendo chefes… o que muda? O pensamento (mindset) precisa mudar. O atendente que está interagindo com todos os clientes precisa entender toda a companhia, seus objetivos e as responsabilidades dele neste cenário. Ele precisa ter poder e autonomia para resolver problemas, para que nenhum cliente sequer queira falar com qualquer outra pessoa. Todos os pedidos do cliente seriam resolvidos o mais rápido possível. O papel do gerente é simplificado para alguém que conhece toda a companhia, consequentemente dedicando mais tempo a pensar na estratégia, e em fazer mudanças e alterações quando forem necessários.

Como estratégia de negócios precisamos pensar no que de fato é a demanda real do cliente. Ele realmente quer um corte de cabelo? Ou ele quer ficar mais bonito? Talvez quando a maior parte dos empreendedores brasileiros mudar seu mindset para isto, finalmente começaremos a ter um número grande de empresas sendo criadas.

Clientes, Evitando problemas

Como posso “agregar valor ao cliente”?

outubro 16, 2017

Se você trabalha em uma empresa de serviços, como eu, provavelmente já escutou alguém dizendo “precisamos aumentar o valor que o cliente está recebendo”. Isto certamente é uma missão que todos que interagem com clientes deveriam atingir e perseguir de forma constante e natural. Mas antes de tudo, o que é “valor” para o cliente?

 

Percepção de valor é relativo

Cada cliente (estamos falando de pessoas, não empresas! São elas quem nos contratam e pagam pelos nossos serviços) vai ter sua própria concepção de valor. Se você entender perfeitamente o que o seu cliente mais quer para agregar valor às suas iniciativas, será muito fácil responder ao pedido de “aumentar o valor que o cliente está recebendo”.

Uma boa forma de começar seria entendendo profundamente qual é o objetivo do seu projeto. Como o cliente está investindo dinheiro para permitir nosso trabalho, podemos pensar na mesma frase como “o que o cliente quer de volta deste dinheiro?”. A resposta SEMPRE será uma das duas alternativas: a) gastar menos dinheiro OU b) fazer mais dinheiro. Alguns exemplos:

  1. Fazer com que uma linha de uma fábrica produza mais rápido, ajudará o cliente a vender mais -> faz dinheiro;
  2. Trocar pessoas desta mesma linha fabril por robôs irá ajudar o cliente a gastar menos dinheiro com funcionários -> gasta menos dinheiro;
  3. Melhorar um processo interno de RH para que o cliente consiga contratar pessoas mais rapidamente -> guardar dinheiro por requerer menos tempo das pessoas envolvidas;

 

Então o que eu estou realmente fazendo todos os dias? Qual é o objetivo do meu projeto? Como todas estas pequenas tasks serão reunidas no futuro e então formar um grande e vantajoso produto?
  1. Se eu produzo software, vou ter muitas tarefas para resolver todos os dias. Mas o que este grupo de tarefas resolverá para o cliente?
  2. Se o meu trabalho é fazer pesquisas no mercado e entregar conteúdo altamente qualificado para meu cliente, quais seriam as ações que ele tomaria após receber este resultado?

Quando sabemos as respostas para estas perguntas, a postura do time mudará naturalmente. Deixaremos de ser apenas produtores de código e começaremos a ser críticos, começaremos a ser consultores: “Porque eu estou executando um número enorme de tarefas para criar uma calculadora dentro deste sistema? O usuário pode usar seu próprio telefone! Vamos seguir em frente para algo que realmente adicionará valor ao produto!”.

Provavelmente a postura acima será a resposta verdadeira para “o que é valor para seu cliente”. Mas lembre-se de checar se o seu entendimento sobre as necessidades do cliente estão de fato corretas e se o cliente aprovará suas opiniões sobre alterar a direção do projeto mesmo naquelas pequenas tarefas.

 

Percepção de valor também é dinâmica

Quando conhecemos a percepção de valor de nosso cliente, temos a operação estabilizada e estamos andando para o caminho correto, precisamos sempre manter em mente que, mais cedo ou mais tarde, a percepção de valor irá mudar. Pode ser devido a uma mudança de mercado (Ex.: somos uma companhia de seguros e ninguém está comprando seguros agora. Certamente precisaremos rever nosso produto) ou mesmo porque o projeto não foi bem sucedido (Ex.: nós disponibilizamos o novo produto no mercado mas ele não atingiu nossas expectativas quanto ao ROI (Return of Investment), talvez porque o projeto está chegando ao seu fim, etc.

Manter uma relação aberta e próxima aos sponsors e às pessoas corretas em cada cliente ajudará a prever mudanças. Sabendo os planos do seu cliente e para onde ele está caminhando sempre ajudará a entender e planejar com antecedência.

 

Como o cliente paga

Encontraremos novos contratos e aumentaremos nossas receitas se nossos clientes enxergarem mais valor em nós. Mas o cliente sempre irá pagar pelo que ele recebe e também pelo que acontece com ele após receber o produto. Ele é quem define o preço do produto ou serviço. Caso ele veja muito valor, pagará muito dinheiro. Caso ele não veja muito valor no produto, ele não pagará muito dinheiro.

Considero os Critérios de Aceite como raízes da percepção de valor do cliente. Se as suas tarefas entregues são exatamente o que o cliente estava esperando, dentro do tempo que acordaram, dentro da qualidade que ele esperava, se ele está satisfeito e aceita suas entregas, você tem um bom ponto de partida. Qualquer ponto que vier depois disso será muito honrável de se discutir.