21maio2016

A falácia do cliente interno

(0) comentários

Tenho visto com alguma frequência pessoas usando o conceito de cliente interno ou de usuário interno, quando se referenciam a trabalhos feitos entre áreas. Algo na linha de “eu tenho aqui uma demanda para você(s) e, como sou seu cliente/usuário interno, preciso dessa demanda solucionada por você(s) o mais rápido possível, preferencialmente até o dia X”. Tenho inclusive visto algumas pessoas propondo que avaliemos uns aos outros como clientes-fornecedores internos, ou seja que avaliemos satisfação do cliente/usuário interno com seu fornecedor interno.

O problema de usar esse conceito de cliente interno para a relação entre áreas é que ele tende a colocar as pessoas dessas áreas em lados opostos, ou seja, uma pessoa de uma área pede algo ou, termo que também já vi sendo usado, tem uma demanda, para outra área. Uma área pede e a outra faz. Se a outra área não fizer bem feito, a área que pediu reclama. Se a outra área não entregar no prazo combinado, a área de pediu reclama. Aí a área que atendeu a demanda justifica que o pedido não estava claro e que o pedido tem que ser feito no formato Z, especificando A, B e C pois, sem isso, não dá para atender a demanda direito, nem no prazo. E assim por diante.

Além disso, as empresas normalmente têm mais do que duas áreas. Assim, um área pode ter mais de um cliente interno e, consequentemente, pode receber várias demandas que, na maioria das vezes, são todas “pra ontem” e todas são “a mais importante para a empresa”. Aí começa a disputa de prioridades.

Cliente interno vs trabalho em equipe

Em 2001 um grupo de pessoas que trabalhavam com desenvolvimento de software sob demanda se reuniu para conversar sobre maneiras melhores de se fazer software. Essas conversas deram origem ao Manifesto Ágil contendo a base dos conceitos de agilidade que melhoraram em muito a taxa de sucesso dos projetos de desenvolvimento de software em nossa indústria. Durante essas conversas eles chegaram à conclusão que, dentre outras coisas, era necessário haver mais colaboração com o cliente. Ou seja, para ter mais sucesso nos projetos de desenvolvimento de software é essencial que o cliente seja parte do time que está desenvolvendo software, e não mero demandante espectador.

É preciso parar com esse conceito de cliente-fornecedor interno e voltar a usar o bom e velho conceito de trabalho em equipe, inclusive entre áreas diferentes. Trabalho em equipe não serve apenas para pessoas da mesma área, mas também para pessoas de áreas diferentes. Qualquer empresa pode ser vista, em última instância, como uma equipe de equipes.

Para se trabalhar bem em equipe, é preciso ter empatia, ou seja, saber entender e respeitar o ponto de vista do outro, colocar-se em seu lugar, tentar entender como o outro pensa e porque ele pensa dessa forma. Áreas diferentes têm culturas e modos de pensar diferentes. E isso é bom! Equipes funcionam, principalmente, porque pessoas diferentes, colaborando entre si, são capazes de produzir um resultado de maior impacto do que se usassem somente suas habilidades individuais. Se todos pensassem igual, isso não seria possível. Por isso, para que haja um verdadeiro trabalho em equipe, é importante não só tolerar e conviver com as diferenças: é preciso explorá-las. É preciso colaborar, trocar conhecimento. Valorizar o conflito saudável, não ter medo de debater e discordar. Quando duas pessoas trocam ideias, cada uma sai com uma ideia a mais, todos ganham. Opiniões diferentes ajudam a construir, desde que motivadas não por ego ou desconfianças, mas sim pela crença num resultado melhor.

Para sair do teórico e citar um exemplo prático, vamos usar a necessidade de contratações de novas funcionários de uma determinada área que vai precisar do RH para efetuar essas contratações. Quando precisamos fazer novas contratações, devemos evitar simplesmente mandar para o RH um descritivo do cargo e aguardar passivamente o prazo que o RH tem para fazer essa tarefa e só aí chegar para o RH e perguntar se conseguiram preencher a vaga. O problema a ser resovido é preencher a vaga com a melhor pessoa possível dentro da faixa salarial orçada para a vaga e dentro do prazo. Esse não é um problema só do RH. É do RH e da área que pediu. Por isso quem pediu deve trabalhar junto com o RH para preencher esse vaga, não só fazendo as entrevistas, mas também ajudando a divulgar a vaga, conversando sobre cada currículo recebido, cada candidato entrevistado e assim por diante. Uma nova contratação deve ser um trabalho em equipe do RH e da área que precisa fazer essa nova contratação. As chances de fazer uma boa contratação no prazo adequado são muito maiores quando a área que precisa fazer essa contratação e o RH se juntam e trabalham em equipe.

Por isso sugiro pararmos de usar o conceito de cliente interno e voltarmos ao bom e velho trabalho em equipe, inclusive entre áreas. Isso vai aumentar em muito a taxa de sucesso das novas empreitadas, assim como a motivação das pessoas das áreas envolvidas.

18abr2016

OKRs, o futuro dos roadmaps

por em Sem categoria
(0) comentários

Já escrevi vários artigos sobre roadmap:

  • O que é um roadmap? Nesse artigo explico que o roadmap é uma ferramenta útil para gestores de produto pois com ele é possível planejar e comunicar a visão de futuro que vc tem para o seu produto.
  • Como fazer um roadmap? Nesse artigo conto que para fazer um roadmap é preciso saber bem os objetivos estratégicos da empresa, os problemas e necessidades dos clientes e o que dá para fazer. De posse dessas informações é possível criar um bom roadmap.
  • Como priorizar um roadmap? Parte 1 e parte 2. Esses dois artigos contém várias técnicas que ajudam o gestor de produtos a definir as prioridades de seu roadmap.
  • Roadmap = motivação + métrica. Nesse artigo da série sobre roadmaps, falo sobre o quão importante é ter em seu roadmap não só o que se quer fazer como também a razão pela qual se quer fazer e quais as métricas que mostram que o que se fez está de fato atendendo a razão pela qual se quer fazer esse item.

Desde 2012 temos na Locaweb uma mecânica de revisar o roadmap a cada trimestre. No início de cada trimestre fazemos uma retrospectiva sobre o que foi feito no trimestre anterior, quais itens foram sido entregues, quais não foram e quais as razões de sucesso ou insucesso.

Esse último artigo sobre motivação + métrica foi escrito em meados de 2014. Ele foi fruto de várias conversas que tivemos na Locaweb sobre ter o roadmap como uma lista de itens a fazer a cada trimestre mas não estar sempre claro a razão de estarmos fazendo cada um daqueles itens planejados. Desde aquela época começamos experimentar fazer nossos roadmaps onde cada item deveria ser composto de 3 sub-itens, o que fazer, por que aquilo tinha que ser feito e qual a métrica que esperávamos mexer ao fazermos aquele item. Contudo, apesar de tentarmos deixar claro a motivação e a métrica de cada item do roadmap, as discusões acabavam girando mais em torno do “o que fazer” do que sobre a motivação e a métrica.

No primeiro semestre de 2015 ouvimos falar de um framework chamado OKR, que significa Objectives and Key Results. Esse framework é usado no Google desde seu início e foi trazido para lá por John Doerr, um funcionário da Intel, empresa onde esse framework foi criado. John Doerr, após sair da Intel, se tornou investidor em negócios de tecnologia tais como Google, Amazon, Intuit e Zynga e acabou levando esse framework para essas empresas. Várias empresas de tecnologia hoje usam OKRs. Mais alguns exemplos são Linkedin, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify.

OKR é um framework derivado de uma ténica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954. A Administração por Objetivos consiste num processo que requer a identificação e descrição precisas de objetivos a atingir e prazos para conclusão e monitorização. Tal processo exige que as pessoas envolvidas concordem com o que se pretende atingir no futuro e que todos desempenharão as suas funções em função dos objetivos.

Como funcionam os OKRs?

Existem vários artigos e vídeos que explicam em detalhes como funcionam os OKRs, por isso farei um explicação sucinta. Os OKRs são compostos de duas partes, um objetivo e de 2 a 5 resultados chave (key results) que indicam que o objetivo foi atingido. Por exemplo:

Objetivo: Ter clientes satisfeitos ao ponto de recomendar nossos serviços aos seus amigos
Key Result 1: Manter 80% das notas de pesquisa de satisfação acima de 8 numa escala de 0 a 10.
Key Result 2: Pelo menos 50% das novas vendas devem vir de recomendações de clientes existentes.

O objetivo não precisa necessariamente ter números. Já os key results devem obrigatoriamente ter algum número, ou seja, devem ser alguma métrica e devem dizer onde se está e onde se quer chegar com a métrica, ou seja, qual é a meta que queremos atingir com aquela métrica.

Recomenda-se ter pelo menos 2 key results pois cada há apenas um key result pode haver o chamado “efeito perverso”. Por exemplo, suponha que o objetivo seja aumentar a produtividade do time de atendimento telefônico e que seja definido um único key result que seria o TMA (tempo médio de atendimento) que hoje está em 8 minutos deve cair para 2 minutos. Uma forma de se atingir esse resultado chave é simplesmente o atendente desligar o telefone quando estiver próximo de dar 2 minutos de ligação. Claro que isso seria péssimo para a qualidade do serviço, mas o key result e o objetivo seriam atingidos. Nesse caso, para balancear o “efeito perverso”, é recomendável ter mais um key result que garanta que a satisfação do cliente que estiver sendo atendido não caia.

Implementando OKRs na Locaweb

Após estudarmos OKR por algum tempo, chegamos à conclusão que ele era muito parecido com o que sempre quisemos fazer, nos focarmos mais nas motivações e métricas do que no “o que fazer” propriamente dito. A grande diferença é que nos OKRs o “o que fazer” simplesmente não entra. Ele pode ser discutido quando se define cada objetivo e seus respectivos resultados chave, mas o “o que fazer” não é documentado e, por isso, não vira um compromisso e pode ser mudado. O que importa é o objetivo e os resultados chave que indicam que o objetivo foi atingido.

Para nos ajudar nessa mudança, chamamos o Felipe Castro, consultor especializado em implementação de OKR. Chamamos ele em junho de 2015 e começamos a implementação no 3º trimestre de 2015, com uma série de treinamentos internos sobre OKR, definicão de objetivos, métricas e metas. Em agosto fizemos uma sessão de planejamento “café-com-leite” para definir OKRs para o mês de setembro. Foi apenas um teste para podermos entender um pouco melhor a mecânica do processo de definição de OKR. No final de setembro fizemos nossa primeira sessão de planejamento de um trimestre completo, onde definimos os OKRs do 4º trimestre de 2015 para os times de desenvolvimento e marketing de produtos da Locaweb. Em paralelo, continuamos com o planejamento trimestral de roadmap de produtos baseado em itens a fazer.

Cada time atualizava seus OKRs semanalmente. Além disso, acompanhávamos a evolução do roadmap mensalmente. Vimos ao longo desses acompanhamentos que os itens do roadmap eram as tarefas que habilitavam o atingimento dos objetivos e dos resultados chave, ou seja, havia um acompanhamento duplo para o mesmo trabalho. Ao longo desse acompanhamento surgiu a ideia: que tal abandonarmos o roadmap tradicional, da lista de tarefas a fazer, e focarmos apenas em definir e acompanhar OKRs?

De tarefeiros a gestores de ponteiros

Foi isso o que fizemos no planejamento de 1º trimestre de 2016. O planejamento foi feito totalmente baseado em objetivos e em métricas que queríamos mexer, ou seja, os ponteiros que queríamos gerir. Deixamos de ser meros tarefeiros, meros executores de tarefas, para nos tornarmos gestores de ponteiros. Dado um objetivo e uma métrica que indica que esse objetivo está sendo atingido, decidimos o que vamos fazer. Na reunião de revisão dos OKRs do 1º trimestre de 2016 e de planejamento dos OKRs do 2º trimestre, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Obviamente que durante a retrospectiva cada time comentou um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir esse “o que fazer” como quiserem.

Lições aprendidas

Temos aprendido algumas valiosas lições nesse quase um ano em que estamos lidando com OKRs. Essas lições aprendidas são relembradas frequentemente para que possamos constantemente melhorar nossas definiçãoes de OKRs:

  • Entregas e medições mais frequentes ajudam a atingir objetivos. Se houver entregas e medições apenas mensais, o time só terá duas chances no trimestre para testar sua ideia de como mexer a métrica. Se houver entregas e medições semanais, são 12 oportunidades de avaliar e mudar o rumo se necessário.
     
  • Objetivos técnicos podem e devem entrar se necessário. Alguns times de desenvolvimento de produto podem ter optado por colocar em seus roadmaps apenas tarefas que entregam valor para o cliente e preferem não colocar histórias técnicas como “atualizar versão da linguagem de programação” ou “rever arquitetura para torná-la mais escalável”. Esse era o caso da Locaweb. Ao fazermos a transição de roadmap para OKR, surgiu a dúvida se faria sentido definir objetivos técnicos, já que tarefas técnicas não entravam nos roadmaps. Após algumas conversas, todos concordaram que sim, podemos e devemos colocar objetivos mais técnicos em nossos OKRs. Por exemplo, ter infra mais robusta e escalável é um objetivo técnico que pode ter como métricas MTBF, MTTR, SLA, filas, etc.
     
  • Objetivos e KRs podem ser modificados ou mesmo cancelados, desde que isso seja combinado. Algumas vezes, ao começar a trabalhar em alguma métrica nova, que nunca se trabalhou antes, pode-se descobrir que mexer aquela métrica é mais difícil ou mais fácil do que inicialmente imaginado. É possível, nesse caso, mudar a meta daquela resultado chave, desde que todas as pessoas interessadas estejam de acordo. Também pode acontecer de um determinado resultado chave ou mesmo de um determinado objetivo ser menos importante do que algo que surge após o planejamento dos OKRs do trimestre. Também não é problema remover o OKR para colocar um novo, desde que todas as pessoas interessadas estejam de acordo.
     
  • Cuidado com interdependências. Tarefas que podem influenciar os KRs e que dependem de outros times que tenham outras prioridades ou mesmo de fornecedor externo têm grande risco de atrasar. O ideal é que sejam feitas no início do trimestre, ou mesmo no trimestre anterior. Em caso de interdependência onde um time precisa fazer A para que outro time possa começar a fazer B, pode-se colocar A nos OKRs do primeiro time em um trimestre e o outro time inclui B como OKR no trimestre seguinte.
     
  • Cuidado com métricas muito genéricas. Esse é um dos aprendizados mais recentes. Métricas como NPS e TMA (tempo médio de atendimento) são muito genéricas, ou seja, podem ser impactadas por uma quantidade enorme de fatores. Por exemplo, o TMA pode ser influenciado por razões tão distintas quanto o sistema de atendimento é lento, o produto está com uma usabilidade que deixa o cliente confuso, turn-over de funcionários de atendimento muito alto e assim por diante. Nesses casos é recomendável transformar a métrica em objetivo, por exemplo, “queremos baixar o TMA em 3 minutos” e definir KRs específicos como, por exemplo, “diminuir o tempo de carregamento do sistema de 30 segundos para 3 segundos”.
     
  • Cuidado com o excesso de otimismo! Quando se começa a trabalhar com OKRs e se começa a definir metas para as métricas, pode acontecer com muita frequência de as pessoas do time subestimarem o esforço necessário para mover o ponteiro. Existe uma tendência natural a setar metas muito otimistas e, na retrospectiva, perceber que mover o ponteiro é mais difícil do que o imaginado inicialmente. Nesses casos, na próxima sessão de planejamento de OKRs, pode acontecer o contrário, ou seja, após ter exagerado no otimismo, o time pode ficar receoso e acaba colocando metas muito tímidas.
     

Concluindo

Como eu disse acima, em nossas reuniões de retrospectiva e planejamento de OKRs na Locaweb, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Durante a retrospectiva cada time comenta um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir e mudar o “o que fazer” como quiserem, desde que atinjam seus objetivos.

Por esse motivo, está cada vez mais claro para mim que os OKRs são o futuro dos roadmaps. É uma ferramenta que coloca os objetivos e as métricas no centro da discussão, deixando a decisão do que fazer mais fluída e flexível, dando aos times mais autonomia na decisão sobre o que fazer.

12abr2016

Agile Trends 2016

(0) comentários

Sexta-feira, dia 29/04, estarei no Agile Trends falando às 10:15 na Sala ContaAzul sobre “Diversificação ou foco, qual a melhor estratégia para sua empresa?“. Espero você lá!

logo-agiletrends-350x218

Aqui está a descrição da trend talk: “Google, Microsoft e várias outras empresas adotaram a estratégia de diversificação do portfólio de produtos. Já Facebook, Twitter, airbnb, Uber e vários outras empresas optaram pelo foco em único produto. Qual a melhor estratégia? Quando aplicar uma ou outra? Nessa trend talk serão apresentados pontos positivos e negativos das duas estratégias e técnicas para gestão de portfólios de produtos.”

22mar2016

Gerindo gestores de produto

por em Sem categoria
(0) comentários

Da mesma forma que nem todo bom desenvolvedor pode virar um bom gestor de desenvolvedores, o mesmo acontece com gestores de produto. Assim como as habilidades que uma pessoa tem que ter para gerir desenvolvedores de software é diferente das habilidades que um desenvolvedor precisa ter para ser um bom desenvolvedor de software, as habilidades que um gestor de gestores de produto precisa ter para gerir gestores de produtos é diferente das habilidades que um gestor de produtos produto precisa ter para gerir seu produto.

Então o que faz um gestor de gestores de produtos?

Um gestor de gestores de produtos tem basicamente duas preocupações, uma tática e outra estratégica:

  • Ajudar os gestores de produto a performarem melhor. Essa é a preocupação tática do gestor de gestores de produto. Ele deve ser capaz de ajudar o gestor de produto a desenvolver as principais características de um bom gestor de produto, empatia, comunicação, gestão do tempo, conhecimento de novas tecnologias, business skills, curiosidade aguçada e conhecimento sobre o tema do produto. Todas essas características são fundamentais para o sucesso do gestor de produtos e nem sempre o gestor de produtos consegue perceber o que precisa ser melhorado ou, se percebe, não sabe bem como melhorar. Aí entra o gestor de gestores de produto, que deve ajudar o gestor de produtos a ver quais características tem espaço para melhoria e como melhorar cada uma delas. Muitas vezes há mais de uma característica que precisa ser melhorada e aqui o gestor de gestores de produto pode mais uma vez ajudar a perceber prioridades, ou seja, qual característica deve ser trabalhada primeiro.
     
  • Ajudar os gestores de produto a criar a visão e a estratégia dos produtos. Essa é a preocupação estratégica do gestor de gestores de produto. Ele deve ser capaz de ajudar os gestores de produto a criar a visão e a estratégia dos produtos da empresa. Aqui é importante fazer uma distinção entre as duas opções de estratégia de portfólio de produtos que uma empresa pode escolher, foco ou diversificação. Em uma empresa que optou pelo foco, cabe ao gestor de gestores de produto coordenar o processo de criação de visão e estratégia do produto da empresa. Ele deve, em conjunto com seus gestores de produto, designers de UX, pessoal de engenharia e gestores de mkt de produto, criar a visão do produto da empresa e desenhar a estratégia para chegar nessa visão. Já em uma empresa que optou pela estratégia de diversificação de portfólio de produto, a responsabilidade do gestor de gestores de produto é ajudar cada gestor de produto a coordenar o processo de criação da visão e do desenho da estratégia de seu produto específico. Além disso em uma empresa que optou pela diversificação, cabe ao gestor de gestores de produtos fazer a gestão do portfólio de produtos, ou seja, garantir que o portfólio de produtos está alinhado com os objetivos estratégicos da empresa e garantir que cada produto tenha o devido investimento de desenvolvimento e de mkt de produtos.

Para ser um bom gestor de gestores de produto é importante que a pessoa já tenha sido gestora de produtos, ou seja, que ela já tenha colocado a “mão na massa” e tenha cuidado diretamente das questões táticas e estratégicas de um produto. Isso irá ajudá-la quando estiver gerindo o trabalho de outros gestores de produto. Contudo, é preciso tomar muito cuidado para não fazer o trabalho no lugar do gestor de produtos ao invés de ajudá-lo a se desenvolver e a fazer seu trabalho. Note que em ambas as preocupações que descrevi acima eu usei “ajudar os gestores de produto”. Por já ter sido um gestor de produtos, é tentador para o gestor de gestores de produtos, no momento em que algum gestor de produto sob sua gestão estiver com dificuldades, fazer o seu trabalho. Mas a função do gestor de gestores de produto não é fazer o trabalho de gestor de produto, mas sim ensinar e ajudar os gestores de produto a fazerem seu trabalho.

Caso vc não tenha experiência como gestor de produtos, mas se veja na situação de coordenar o trabalho de gestores de produtos, como pode ser o caso de um CTO ou um gestor de time de engenharia, valem as recomendações acima, ou seja, ajudar os gestores de produtos a performarem melhor e a criar a visã e a estratégia de seus produtos.

16mar2016

O que é e como criar a visão e a estratégia do produto?

(0) comentários

Esse tema tem aparecido com alguma frequência não só na Locaweb mas também em outras empresas de software com quem eu tenho conversado. Por isso acredito que seja um bom momento para escrever um artigo sobre o tema.

O que é e pra que serve visão do produto?

Visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto. O que o que dá o contexto para o time de desenvolvimento do produto tomar decisões sobre o que priorizar em relação ao produto. Vale lembrar que quando falo “produto” estou me referindo a qualquer software que tenha usuários.

Lembrando da definição de gestão de produtos, um produto deve ao mesmo tempo atender aos objetivos estratégicos que o dono do produto tem para esse produto enquanto ele resolve problemas e necessidades de seus usuários. Pronto, esses dois elementos são o que você precisa para fazer a sua visão do produto.

Criando a visão do produto

A visão do produto será criada juntando esses dois elementos, o entendimento dos objetivos do dono do produto e os problemas e necessidades do usuário do produto.

Sendo assim, o primeiro passo para criar a sua visão do produto é ter bem claro quais os objetivos que o dono do produto tem para o produto. Por exemplo, um banco pode querer, com um sistema de Internet Banking, reduzir a necessidade de atendimento em agências. Um laboratório de análises clínicas e de imagem, com um sistema de consulta de resultados, pode querer diminuir os custos operacionais de manuseio e envio de resultados.

Em seguida é preciso entender dos usuários do produto quais são os problemas e necessidades que esse produto vai resolver, qual o contexto onde esses problemas e necessidades acontecem e qual a motivação que esses usuários têm para querer ter esse problema ou necessidade resolvido.

Uma ferramenta bacana para entender o usuário é o mapa de empatia.

empathy-map

Esse mapa ajuda a dar foco nas diferentes percepções que o usuário pode ter:

  • Vê? O que seu usuário vê? Como é o ambiente onde ele usa o produto? O que o mercado oferece?
  • Ouve? O que o seu usuário ouve? O que seus amigos dizem para ele sobre o seu produto? O que o chefe dele diz? O que os influenciadores dizem?
  • Diz e faz? O que o seu usuário diz e faz em relação ao seu produto? O que ele comenta com amigos e em redes sociais? O que ele consegue fazer graças ao seu produto?
  • Pensa e sente? O que seu usuário pensa e sente quando usa o seus produto?
  • Dores? Quais são as principais dores, medos, frustrações e obstáculos que o seu usuário encontra?
  • Ganhos? Quais os principais ganhos, desejos e necessidades resolvidas que seu usuário espera ter ao usar seu produto?

Outra ferramenta muito útil é a persona, que representa um grupo de usuários com padrões de comportamento, atitudes e motivações similares em termos de decisão de compra, de uso de tecnologias ou produtos, de estilo de vida etc.

As personas são usadas para:

  • Conhecer e entender clientes e usuários de produtos e serviços;
  • Trazer o usuário para o foco do projeto;
  • Tornar as decisões de design mais humanas e menos abstratas.

A figura a seguir mostra como construir uma persona:

persona-1

O primeiro passo é definir um nome e algumas características dessa persona. Isso ajuda nas conversas sobre o produto. No nome, é bacana já dar uma dica da característica principal. Por exemplo, Maria, a descolada ou Michelle, a ocupada.

Se você estiver fazendo um produto para Michelle, a ocupada e quiser inserir uma nova funcionalidade, vale a pergunta: “Será que Michelle, a ocupada vai conseguir usar essa funcionalidade? Ela a achará útil o suficiente para achar tempo para aprender a usá-la?”. Além do nome e características básicas, é importante também descrever seus comportamentos e seus problemas. Os exemplos a seguir deixarão mais claro o conceito de persona.

persona-2
Maria, a descolada

persona-3
Michelle, a ocupada

Maria, a descolada é uma das personas que usamos na Locaweb. Dados os diferentes produtos que temos em nosso portfólio, acabamos construindo oito personas. Contudo, para cada produto de nosso portfólio, temos uns 3 ou, no máximo, 4 personas, sendo que uma destas é a persona primária do produto, ou seja, para quem todas as suas decisões de seu produto de software são tomadas.

Como parte do entendimento do problema ou necessidade que seu usuário espera ver resolvido pelo seu produto é muito importante você mapear quais as alternativas que existem hoje para ele ter esse problema ou necessidade resolvido. No caso de produtos comerciais, são os concorrentes. No caso de produtos que são sistemas sem objetivos diretos de receita, como o internet banking ou o sistema de consulta de resultado de exames, são as alternativas existentes como ir ao banco ou ao laboratório, acesso ao banco por telefone, envio de resultados por correio, etc. Esse mapeamento de alternativas é muito importante para você entender como seu usuário se vira sem o seu produto e no que essas alternativas são melhores e no que elas são piores do que o produto que você cuida.

Tanto o mapa de empatia quanto a persona quanto o mapeamento de alternativas podem e devem ser criados em conjunto com pessoas de UX, de engenharia e de marketing de produtos.

Pronto, você já tem todos os elementos para criar a visão do seu produto:

  • Os objetivos do dono do produto.
  • Quem são os usuários e quais os problemas e necessidades esses usuários esperam resolver com seu produto. Ferramentas úteis para isso são o mapa de empatia, a persona e o mapa de alternativas.

Vale lembrar que para obter esses elementos o gestor de produtos terá que usar muita empatia para conversar com os donos do produto e entender seus objetivos e para conversar e entender o seu cliente.

Com esses elementos em mãos você está pronto para criar a sua visão que nada mais é do que deixar claro esses elementos. Simples, né? Seria algo mais ou menos assim:

O (nome do dono do software) decidiu ter esse software para (objetivos do dono do software em ter esse software). Esse software é usado por (descrição das pessoas que usarão o software) que, ao usar esse software, espera resolver (problema ou necessidade que o usuário espera resolver) de uma forma melhor do que (alternativas existentes). (Incluir mais informações sobre o problema ou necessidade, incluindo contexto e motivação para ver resolvido).

Por favor, não dê copiar + colar no texto acima! Crie sua própria visão do produto, que não precisa ser um texto. Pode ser uma apresentação ou um vídeo. Lembrando que a visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto.

Estratégia do produto

Uma vez que você tem em mãos a visão do produto, provavelmente vem um pensamento a mente, algo na linha de “hum, acho que meu produto ainda está distante da visão” e a pergunta subsequente é “como fazer com que meu produto chegue mais perto da visão?”. É aí que entra a estratégia do produto, ou seja, que passos serão dados para aproximar o produto da visão.

Uma boa ferramenta para ajudar a construir a estratégia do produto é a análise SWOT, sigla em inglês para Strengths, Weaknesses, Opportunities and Threats, ou pontos fortos, pontos fracos, oportunidades e ameaças.

swot

Os pontos fortes e os pontos fracos são itens internos, ou seja, do seu time de desenvolvimento de produto, ou da sua empresa, sobre as quais você, seu time ou sua empresa têm algum controle, que ajudam ou atrapalham o seu produto atingir a sua visão. As oportunidades e ameaças são os elementos externos a organização, ou seja, sobre os quais a organização não tem controle, e que podem influenciar positiva ou negativamente o atingimento da visão do produto.

Preencher o SWOT deve ser também um trabalho de equipe, ou seja, o gestor de produto deve ter uma ou mais sessões junto com pessoas de UX, engenharia e marketing para construir o SWOT do seu produto. É provável que sua organização também tenha feito uma análise SWOT para a organização como um todo. É um ótimo input para o SWOT do seu produto.

Tendo em mãos o SWOT preenchido, é hora de desenhar a estratégia do seu produto. A estratégia do produto nada mais é do que um roadmap de curto, médio e longo prazo. Longo prazo? Você certamente está pensando que, como vcs adotaram metodologias ágeis na time de desenvolvimento de produto, não faz mais sentido ter um roadmap de longo prazo, nem de médio prazo. Na verdade, faz sim, mas não no sentido clássico de roadmap como lista de funcionalidades, mas sim usando o roadmap como lista de prioridades, lista de pontos de foco que devem ser vistos para fazer com que o produto se aproxime da visão.

Com o SWOT preenchido você deve, junto com o time (UX, engenharia, mkt de produto) olhar para cada um dos itens em cada um dos quadrantes e avaliar qual o impacto dele na visão de produto que vocês criaram. Existem pontos fortes devem ser reforçados? Se sim, quais devem ser reforçados primeiro? Existem pontos fracos a serem combatidos? Se sim, quais devem ser combatidos primeiro? Existem oportunidades a serem aproveitadas? Se sim, quais devem ser aproveitadas primeiro? Existem ameaças a serem combatidas? Se sim, quais devem ser combatidas primeiro? Essa análise irá te ajudar a definir as motivações, os objetivos, ou seja, os macro-temas do seu roadmap, lembrando que roadmap = motivação + métrica, o que agora está sendo popularizado com a sigla OKR (Objectives and Key Results), tema de um futuro artigo. Essa análise te ajudará a definir no que se focar agora e o que deixar para depois, sempre tendo por objetivo final chegar mais próximo da sua visão de produto. E isso é a estratégia do produto, o caminho que você e o time de desenvolvimento de produto irá percorrer para chegar na visão do produto.

Seu produto evolui, sua visão e estratégia também!

Um ponto importante é que seu produto evolui à medida que o time trabalha nele. Muito se aprende sobre os usuários do produto, seus problemas e necessidades. Novas alternativas podem aparecer para ajudar seu usuário a resolver seus problemas e necessidades. O dono do software também pode revisitar seus objetivos estratégicos e, consequentemente, revisitar os objetivos definidos para o software. Além disso, pontos fortes e pontos fracos podem mudar com o tempo, e oportunidades e ameaças podem aparecer ou sumir. Por isso é importante entender que nem a visão nem a estratégia do produto estão escritas em pedra. Elas podem e devem ser revisitadas periodicamente. Minha sugestão é que elas sejam revisitadas anualmente, ou quando algum evento relevante acontecer como, por exemplo, quando houver uma mudança nos objetivos estratégicos da empresa ou quando aparecer uma alternativa que resolve o problema ou necessidade do usuário de uma forma diferente da do seu produto.

11mar2016

Ruby2.3 Net::Telnet was gemified

(0) comentários
According to ruby2.3 changelog, the class "Net::Telnet" was removed from the ruby-core and was "gemified"

Thu May 21 15:41:45 2015  SHIBATA Hiroshi  <hsbt@ruby-lang.org>

* lib/net/telnet.rb: gemify net-telnet.
[Feature #11083]
* gems/bundled_gems: added net-telnet to bundled gems.


To use it, just add the gem "net-telnet" to Gemfile!
11mar2016

Ruby2.3 Net::Telnet was gemified

(0) comentários
According to ruby2.3 changelog, the class "Net::Telnet" was removed from the ruby-core and was "gemified"

Thu May 21 15:41:45 2015  SHIBATA Hiroshi  <hsbt@ruby-lang.org>

* lib/net/telnet.rb: gemify net-telnet.
[Feature #11083]
* gems/bundled_gems: added net-telnet to bundled gems.


To use it, just add the gem "net-telnet" to Gemfile!
9mar2016

The book is on the table

(0) comentários

“The book is on the table” is a phrase that every Brazilian who learns English is faced with when learning about use of preposition in English language. Hence the title of this article. :-)

However, the book is not on the table. The is at LeanPub. Paulo Caroli is translating my book on Software Product Management that I wrote in Portuguese and launched in Brazil last year.

title_page

Our main objective with this translation is to increase the number of books on Software Product Management available for readers all over the world. The are not many books on the topic, even in English, and we believe the content of this book is useful for people in the software industry not only in Brazil but anywhere in the world.

We are working on the first chapters but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub.

And if you have friends who don’t read in Portuguese but are interested in Software Product Management topic, please feel free to point them to Product Management: Delight your customers with your software. Still in beta but already with valuable content. Feedback is always welcome!

9mar2016

The book is on the table

por em Sem categoria
(0) comentários

English version below…

A bem da verdade, não está em cima da mesa, mas está no LeanPub. O Paulo Caroli está trabalhando na tradução para o inglês do meu livro sobre gestão de produtos.

title_page

Nosso objetivo é aumentar a literatura sobre o tema Gestão de Produtos em todo o mundo. Há poucos livros sobre o tema, mesmo em inglês, e acreditamos que essa tradução pode ser útil para pessoas da indústria de software não só no Brasil, como em todo o mundo.

Ainda estamos nos primeiros capítulos, mas se vc quiser acompanhar a tradução e a publicação, basta visitar a página do livro lá no LeanPub.

Se vc tem amigos de outros países que não falam Português, mas que se interessam pelo tema Gestão de Produtos de Software, fique à vontade para indicar o livro Product Management: Delight your customers with your software. Ainda em Beta, mas já com conteúdo interessante. Feedbacks são muito bem vindos!

English version

“The book is on the table” is a phrase that every Brazilian who learns English is faced with when learning about use of preposition in English language. Hence the title of this article. :-)

However, the book is not on the table. The is at LeanPub. Paulo Caroli is translating my book on Software Product Management that I wrote in Portuguese and launched in Brazil last year.

Our main objective with this translation is to increase the number of books on Software Product Management available for readers all over the world. The are not many books on the topic, even in English, and we believe the content of this book is useful for people in the software industry not only in Brazil but anywhere in the world.

We are working on the first chapters but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub.

And if you have friends who don’t read in Portuguese but are interested in Software Product Management topic, please feel free to point them to Product Management: Delight your customers with your software. Still in beta but already with valuable content. Feedback is always welcome!

1mar2016

Sobre QA (e Front-end e BA)

por em Sem categoria
(0) comentários

No artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas, prometi que o próximo artigo seria sobre o papel de gestor de gestores de produto. Contudo, recebi alguns comentários sobre a falta do time e do papel de QA (Quality Assurance) na proposta de organização, por isso resolvi mudar um pouco a sequência de temas e vou falar nesse artigo sobre QA (e Font-end e BA).

Disclaimer

Antes de mais nada, gostaria de citar uma frase muito bacana que ouvi certa vez e que deve ser lembrada sempre que conversas sobre pontos de vista distintos acontecem:

O fato de discordamos não significa necessariamente que um dos dois está errado.

Qual é o objetivo?

Na minha visão, processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

QA (e Front-end e BA) na Locaweb

Até meados do segundo semestre de 2015 tínhamos na Locaweb os times de engenharia de produtos, um time para cada um ou dois produtos, e tínhamos dois times funcionais separados desses times de engenharia de produtos, os times de Front-end e de QA. O artigo anterior foi extraído do meu livro e no livro o texto ainda contempla Front-end e QA separados da engenharia. No final do ano decidimos por não ter mais time de Front-end nem de QA.

Sobre o time de Front-end:

  • O time tinha 5 desenvolvedores, enquanto a Locaweb tinha 12 times de desenvolvimento de produtos e sistemas. Como desenvolvedores de back-end não mexiam com front-end, o time de front-end acabava virando gargalo.
  • O time havia desenvolvido, junto com UX, o Locaweb Style um framework front-end de comportamento e estilo que usamos em nossos produtos e disponibilizamos para que qualquer pessoa tb possa utilizar em seus projetos. O objetivo do Locaweb Style é facilitar o programação front-end das interfaces de nossos produtos. Com o Locaweb Style ficou mais fácil desenvolvedores de back-end fazerem front-end e diminuir o gargalo.
  • Com isso decidimos não ter mais o time de Front-end e os desenvolvedores de front-end foram para os times de produtos onde front-end é mais relevante. Os desenvolvedores de front-end passaram a tb mexer em back-end, assim como os desenvolvedores back-end passaram a mexer em fron-end. Sempre respeitando o Locaweb Style.
  • Diego Eis, que era coordenador desse time de Front-end, contou em um artigo como foi a mudança. Ele passou de coordenador de time funcional a coordenador de time de engenharia de um produto. Isso deu a ele a aos membros do time de front-end, que agora são desenvolvedores alocados em um time de produto, um senso maior de propósito, pois entregam um produto completo e não só a programação da interface.

Sobre o time de QA:

  • Quando existe a função de QA separada da função de desenvolvimento de software, é comum ouvir frases do tipo “a funcionalidade está pronta, agora está em QA”, o que denota uma cultura waterfall, o que pode aumentar consideravelmente o tempo de desenvolvimento e impactar negativamente a qualidade do software.
  • Quando existe a função de QA separada da função de desenvolvimento de software, também é comum ouvir frases do tipo “por que o QA não pegou esse bug?”, o que denota uma cultura de busca de culpados, que pode ser bem prejudicial para o clima do time e, consequentemente, impactar negativamente a qualidade do software.
  • Qualidade não deve ser a preocupação de uma pessoa ou de um time, deve ser uma preocupação de todas as pessoas que estão trabalhando no software.
  • Qualidade é um requisito não-funcional, ou seja, um requisito que especifica um critério para julgar a operação de um software, o que é diferente do requisito funcional, que especifica um comportamento do software. Performance, escalabilidade, “operabilidade”, “monitorabilidade” são alguns exemplos de requisitos não-funcionais de software que são tão importantes quanto a qualidade. Mesmo assim, não existem o papéis de perfomance assurance, scalability assurance, operability assurance e monitorability assurance. Por que qualidade é o único requisito não-funcional que tem uma função específica para assegurá-lo?
  • QA tem por foco garantir a qualidade do processo de desenvolvimento de software. Se é necessário um papel separado para garantir essa qualidade, por que não existe a necessidade de um papel separado para garantir a qualidade do processo de gestão de produtos, do processo de design de UX, do processo de marketing de produtos, do processo de vendas, do processo financeiro?
  • Na Locaweb tínhamos em torno de 12 QAs, alguns com perfil mais de desenvolvedor e outros com perfil mais de SysAdmin. Ao propormos a extinção do papel de QA, alguns dos QAs viraram devs de um produto enquanto outros assumiram o papel de sysadmins.
  • Existia entre os devs a preocupação de que, se o próprio dev agora vai ter que testar, as entregas vão demorar mais para ficar prontas. Essa preocupação existia pois os devs consideravam que seu trabalho terminava quando passavam a história para o QA testar. Contudo, essa visão de pronto do dev é incorreta, pois ele só passou a história para a próxima fase, o teste. Do ponto de vista do usuário do software, a história só está pronta quando o usuário pode utilizar a nova funcionalidade. E o que acontece quando a história não passa por QA e tem que voltar pro desenvolvimento?

Sobre BA:

Outro questionamento que recebi quando publiquei o artigo anterior foi sobre a ausência de BA (Business Analyst). Não coloquei explicitamente o BA pois BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários. Em algumas organizações pode acontecer de o BA estar focado exclusivamente no business, ou seja, em entender apenas quais são os objetivos de negócio, deixando de lado os problemas e as necessidades dos usuários. Nesse caso, é importante o BA passar a levar tb em consideração os problemas e as necessidades dos usuários do software, balanceado-os com os objetivos de negócio.

Concluindo

Com esse artigo espero ter esclarecido as perguntas sobre a ausência de QA e BA que ficaram do artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas. Vale lembrar que processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

No próximo artigo meu plano é falar um pouco sobre o papel de gestor de gestores de produto. Stay tuned!