12jul2016

Mais lições aprendidas sobre OKRs

(0) comentários

Já contei sobre como substituímos os roadmaps por OKRs na Locaweb. Nesse artigo também falei sobre algumas lições aprendidas. Acabamos de fazer a retrospectiva do último trimestre e adivinha só o que aconteceu? Aprendemos mais algumas coisas interessantes, que vou compartilhar aqui! :-)

Réguas claras para os KRs

Um dos pontos que chamou a atenção na última retrospectiva foram a falta de clareza da definição sucesso ou insucesso de cada KR. Na tentativa de criar um padrão de análise igual para todos os KRs, nós os definíamos sempre com um valor alvo e o critério de sucesso era definido como sendo o atingimento de 80% ou mais do valor alvo e o de insucesso era o atingimento de 40% ou menos do valor alvo.

okr_1

O problema é cada KR tem seu próprio contexto e sua própria mecânica. Enquanto para um determinado KR o atingimento de 80% de seu valor alvo pudesse ser considerado bom, para outro, esse mesmo atingimento de 80% poderia ser considerado ruim e, para ser considerado bom, seria necessário o atingimento de 98% do valor alvo.

Em função disso, cada KR terá agora 3 valores, o valor alvo, o valor acima (ou abaixo) do qual o KR será considerado OK e o valor abaixo (ou acima) do qual o KR será considerado como não OK.

okr_2

KRs semanais

Ao definir KRs, é comum nos depararmos com métricas de mensuração mensal como, por exemplo, churn, novas vendas, receita, margem, contatos de suporte e assim por diante. Como essas métricas são mensais, durante um trimestre teremos apenas duas oportunidades de avaliar se o que estamos fazendo está surtindo efeito em mover o ponteiro. Duas oportunidades é muito pouco, se você erra a primeira, só tem mais uma.

Por esse motivo nós decidimos nos esforçar em dividir métricas mensais em semanais. A ideia é fazer isso de forma bem simples, dividindo o valor mensal por 4. Por exemplo, se o objetivo for 2000 novas vendas por mês, deveremos ter pelo menos 500 novas vendas por semana. Assim, se numa determinada semana tivermos 380 vendas, saberemos que estamos atrás que teremos que compensar de alguma forma na semana seguinte. Um outro exemplo pode ser um KR de atingir um churn de 2% ao mês ou menor. Esse churn de 2% ao mês equivale aproximadamente a 0,5% de churn por semana. Assim, se numa determinada semana tivermos 0,3% de churn estaremos bem, mas se tivermos 0,6% de churn estaremos mal.

Com KRs semanais é possível acompanhar de forma fácil e frequente se estamos bem em relação a um determinado KR e fazer ações apropriadas para manter ou melhorar o KR sem ter que esperar o fechamento do mês para ver como estamos.

Lag measure vs lead measure

A maioria das métricas que olhamos podem ser chamadas de lag measures ou métricas históricas. Elas contam o resultado de algo que aconteceu, mas não contam o que foi feito para esse algo acontecer. Para que algo aconteça é importante que a gente saiba quais são as lead measures, ou seja, o que precisa ser feito. Exemplificando, quando uma pessoa emagrece 5 quilos em 3 meses, a lag measure é emagrecer 5 quilos em 3 meses, mas quais foram as lead measures feitas para atingir esse resultado? Provavelmente ela deve ter restringido sua alimentação a um determinado número de calorias por dia, evitado determinado tipo de alimentos e se exercitado por uma certa quantidade de minutos uma certa quantidade de vezes por semana. Essas são as lead measures que levaram à lag measure de emagrecimento descrita. Outro bom exemplo, agora que estamos próximos das Olimpíadas, são os resultados esportivos. Por exemplo, determinado país foi líder no quadro de medalhas dos últimos jogos Olímpicos. Essa é a lag measure. E quais foram as lead measures para obter esse resultado? Investiu em formação de atletas e em patrocínio para o esporte.

KRs normalmente são lag measures. NPS, TMA, novas vendas, receita, custo, churn, quantidade de contatos, etc. Todas essas métricas são lag measures. Mas quais são suas lead measures? O que as faz mudar de valor? O que as influencia? É muito importante conhecer esses influenciadores para saber onde trabalhar para mexer na métrica. Na Locaweb fizemos um trabalho de mapeamento de influenciadores de NPS e de TMA. Esse trabalho consistiu de algumas sessões de brainstorming onde procuramos identificar tudo o que influencia o NPS ou o TMA. Em seguida, para cada item, avaliamos se já o medimos, se o valor medido parece estar OK e qual o seu impacto, usando uma escala simples do tipo P, M eG, na lag measure. Com isso conseguimos um bom guia do que deve ser nosso foco para podermos melhorar o NPS e o TMA.

Dashboard visíveis

Outro ponto importante que pode ajudar bastante é o conceito de controles à vista. Esse conceito é bastante difundido nas metodologias ágeis, com os times tendo um quadro que os permite constante ver como andam as principais métricas e, em alguns casos, sua evolução histórica. O uso de controles à vista tem origem no sistema de produção usado em fábricas japonesas conhecido como kanban. Aliás, a palavra japonesa kanban significa, literalmente, cartaz ou placar.

A ideia aqui é criar um placa à vista que mostre o que são os OKRs e como eles estão progredindo. Com isso fica mais fácil para todo o time acompanhar a evolução de cada uma de suas métricas.

okr_dashboard

Contudo, só ter o dashboard visível não é suficiente. Ele precisa ser constantemente atualizado para ser útil. Daí a quinta lição aprendida.

OKRs weekly standup

Mais uma ideia que também está sendo “emprestada” das metodologias ágeis. Como explicado acima, não basta só o time criar o seu dashboard visível, ele precisa ser atualizado. A sugestão é atualizá-lo semanalmente, afinal definimos KRs para serem acompanhados semanalmente.

okr_weekly_standup_1

okr_weekly_standup_2

Uma reunião em pé de 15 minutos para atualizar os KRs, e cada um contar o que fez na semana passada e o que pretende fazer na semana atual. Algo bem simples, mas que ajuda na comunicação e no comprometimento do time.

Aprendizado contínuo

Temos aprendido muito com o uso dos OKRs. O fato de começarmos a medir mais nos ajuda a visualizar melhor como estão as coisas e a identificar pontos de melhoria. Temos certeza de que iremos continuar aprendendo bastante e vou continuar compartilhando à medida que formos aprendendo.

E vc, já implementou OKRs na sua empresa? Compartilhe vc também suas lições aprendidas!

6jul2016

5 anos depois, como está o ContaCal?

por em Sem categoria
(0) comentários

ContaCal foi o experimento de startup que iniciei em julho de 2011 e que venho tocando até hoje nas minhas horas vagas. Está completando agora em julho 5 anos! O ContaCal foi um experimento para ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno.

Esse experimento acabou virando um livro, o “Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis“, meu primeiro livro, lançado em 2012, que acabou sendo também o primeiro livro da editora Casa do Código, startup criada pelo pessoal da Caelum para edição de livros de tecnologia que hoje conta com mais de 380 títulos.

Quanto tempo demora até ter retorno?

Uma pergunta que todo mundo que começa um novo empreendimento se pergunta é quanto tempo leva para começar a ter resultados desse empreendimento. Como dá para ver acima, por mais rápido que se seja, o caminho é longo. As entrevistas que fiz (veja no índice) mostram sempre uma história de anos até ter os primeiros resultados. Mesmo nos produtos da Locaweb, após lançarmos o produto leva meses, e às vezes até mais de um ano, para atingir a rentabilidade no mês. Isso sem contar o tempo de desenvolvimento do produto. Por isso é importante estar preparado financeira e emocionalmente para a jornada.

Em 2012 foi disponibilizado um relatório chamado “Startup Genome Report“. Esse relatório é uma análise feita com dados de mais de 650 startups de produto web, feito por alunos e professores de Berkley e Stanford, com o apoio do Steve Blank, da Sandbox Network e de 10 aceleradoras de startup de todo o mundo. Vale a pena dar uma olhada. Tem muita informação interessante nesse relatório.

Esse relatório divide o ciclo de vida de uma startup em 4 fases:

  • Discovery: o foco é descobrir se o produto web resolve um problema e se há alguém interessado nessa solução. Média de 5 a 7 meses.
     
  • Validation: aqui o foco é validar se existem pessoas interessadas no produto em troca de dinheiro ou de atenção. Costuma demorar entre 3 a 5 meses.
     
  • Efficiency: esse é o momento de refinar o modelo de negócio e melhorar a eficiência da aquisição de clientes. Mais 5 a 6 meses.
     
  • Scale: Se tudo correu bem nas fases anteriores, aqui é o momento de pisar no acelerador para fazer a startup crescer. São mais 7 a 9 meses.
     

Ou seja, até chegar na fase de escalar são de 13 a 18 meses. No final do relatório é apresentado um gráfico que mostra o tempo que leva para chegar na fase de escalar em função do número de sócios-fundadores:

Tempo para chegar a fase de escalar

Esse gráfico mostra que leva pelo menos de 20 a 30 meses até chegar na fase de escalar. Isso se vc não estiver sozinho. Caso você esteja sozinho na sua startup, o que é o caso do ContaCal, pode levar mais de 5 anos.

A evolução do ContaCal

Desde o começo, em julho de 2011, até maio de 2012 foram os meses em que tentei entender se o ContaCal resolvia o problema de alguém e se havia alguém disposto a pagar por essa solução. Essa foi a fase de descoberta, e durou 9 meses.

Em seguida veio a fase de validação. Em agosto de 2012 o ContaCal havia atingido a rentadilidade no mês, ou seja, as receitas do mês foram maiores do que os custos do mês. Nesse momento comecei a investir um pouco mais em marketing para continuar fazendo a validação até maio de 2013.

A partir daí veio a busca pela eficiência.

Abaixo o gráfico de receita mensal do ContaCal que mostra essa evolução.

Evolução do ContaCal até jan/15

Retorno do investimento

Até hoje (julho/2016) investi R$ 136.201,82 no ContaCal e recebi R$ 137.668,52. O retorno do investimento acumulado só aconteceu há 3 meses atrás, 4 anos e 10 meses depois do primeiro mês. Esse prazo bate com o previsto pelo Startup Genome Report. Veja abaixo a curva de resultado acumulado do ContaCal.

contacal-resultado-acumulado

Então o ContaCal deu certo?

A resposta curta é depende!… :-P

Depende do ponto de vista. Como explicado acima, o ContaCal foi um experimento para ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno. Desse ponto de vista, ele deu certo, pois mostrou ser possível.

Do ponto de vista de retorno financeiro, não deu certo. A partir de julho de 2013 começou fase da eficiência, ou seja, de refinar o modelo de negócio e melhorar a eficiência da aquisição de clientes. O correto seria passar alguns poucos meses nessa fase para então entrar na fase de escalar, mas isso não aconteceu, como fica bem claro na imagem abaixo.

evolucao-contacal-2

Por que o ContaCal não escalou?

No artigo entitulado Quanto tempo dedicar? Quem devo chamar? eu falei sobre dois temas que poderiam ter influenciado o resultado e ajudado o ContaCal a escalar:

  • quanto tempo dedicar: no artigo minha recomendação era que “vc continue com seu trabalho atual e use-o para financiar sua startup. Depois que sua startup crescer, veja se ela demanda sua atenção tempo integral. Pode ser até que ela não demande a sua atenção em tempo integral, mas sim a de alguém com um perfil diferente do seu, que vc venha a contratar para tocar o dia-a-dia da sua startup que, a essa altura já não será mais uma startup.” A recomendação continua válida. Contudo, é importante ter clareza sobre qual o momento em que vc vai investir mais tempo na sua startup. Olhando em retrospecto, provavelmente no início de 2014 eu deveria começar a colocar mais energia no ContaCal. Ele estava começando a ficar cada vez mais eficiente e eu já precisaria ter estratégias para escalar. Muito provavelmente para escalar seria necessário mais dinheiro. É nesse momento que se busca investidores, que poderia ser eu mesmo, caso eu decidisse investir minhas economias, ou poderia ser parentes e amigos, outra possível fonte de dinheiro para investir em um novo negócio. Outra opção ainda seria buscar um investidor anjo, o que certamente dá um pouco mais de trabalho. Ou seja, em um determinado momento eu, ou alguém que eu contratasse, teria que se dedicar bastante ao ContaCal, com a missão de fazê-lo passar da fase de eficiência para a fase de escala.
     
  • quem devo chamar: no artigo comento que “essa é uma pergunta e uma decisão muito pessoal. Depende muito de sua personalidade. Ter sócio numa startup significa ter uma pessoa que vai trabalhar com vc nesses primeiros passos de desenvolvimento de seu produto web. Tem pessoas que não conseguem trabalhar sozinhas. Já outras só conseguem trabalhar sozinhas. E ainda há as que às vezes preferem trabalhar sozinhas e às vezes preferem trabalhar em conjunto com outras pessoas.” Sem dúvida é uma decisão bastante pessoal, mas até mesmo o Startup Genome Report deixa claro que a startup anda bem mais rápido de forem duas ou mais pessoas. Isso provavelmente acontece pelo comprometimento que cada pessoas tem com as outras para que a startup dê certo. Olhando em retrospecto, o ContaCal poderia ter se beneficiado se eu não o tocasse sozinho.

E por que eu decidi não dedicar mais tempo, nem procurei dividir com alguém? Porque o ContaCal era um experimento de startup. Meu objetivo não era fazer uma startup nem que gerasse meu sustento, nem que crescesse rapidamente, dois possíveis objetivos que expliquei no artigo sobre porque ter uma startup. Meu objetivo era ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno. E esse objetivo foi atingido! o/

Exemplo de startup que escalou

No final de 2012 a Locaweb decidiu investir em uma startup chamada Eventials, uma plataforma para transmissão de palestras online. Nessa época a Eventials vinha crescendo em termos de visitantes e número de palestras online. A equipe da Eventials, na época 3 pessoas, decidiu reescrever toda a aplicação para atender a demanda por novas funcionalidades e evitar gargalos na infra-estrutura. No início do segundo trimestre de 2013 a nova aplicação foi lançada. Também nessa época a equipe da Eventials, que era de Blumenau, decidiu se mudar para São Paulo, para dentro do escritório da Locaweb. Sou membro do Conselho da Eventials e passei a ter reuniões quinzenais com o Thiago Lima, fundador e CEO, para que pudéssemos trocar experiências sobre startups e gestão de produtos. No início de 2014 decidimos mudar o modelo de negócios, de Freemium com “Pay-As-You-Go”, onde o palestrante podia criar palestras gratuitas mas, para poder ter funcionalidades mais avançadas tais como estatísticas, palestras pagas e palestras privadas, o palestrante precisava comprar créditos que eram consumidos quando os visitantes assistiam as palestras, para venda de planos com mensalidade, o que aumentou consideravelmente a previsibilidade da receita mensal da empresa.

A Eventials é um ótimo exemplo de startup que escalou. Ela foi fundada em 2010. Em 2012 o Thiago já tinha um time de pessoas com ele e procurou alguém para investir, além dele mesmo. A Locaweb decidiu fazer essa aposta. Até hoje a Eventials ainda não retornou tudo o que foi investido, isso porque toda a receita é reinvesitda na empresa. Contudo, ela já está num patamar de receita bem interessante, com mais de R$ 100K por mês. Veja abaixo a evolução de receita da Eventials e as fases do ciclo de vida claramente definidos.

evolucao-eventials

Concluindo

Como sua startup irá evoluir depende muito de vc e de seus objetivos. Isso tem a ver com o que escrevi no artigo sobre porque ter uma startup. É importante que vc tenha isso bem claro.

Se vc está construindo sua startup junto com alguém, vcs precisam estar alinhados sobre seus objetivos. Se vocês tiverem objetivos diferentes, isso certamente trará conflitos durante a jornada, conflitos esses que poderão chegar ao ponto de serem irreconciliáveis.

Vale lembrar que seus objetivos em relação à sua startup podem mudar ao longo do tempo, à medida que vc tem novos aprendizados pelo caminho.

No meu caso específico, meus objetivos em relação ao ContaCal se mantiveram os mesmos ao longo de todo o caminho, conduzir um experimento para ver se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno. Comprovei que é possível e aprendi bastante no caminho, não só com o ContaCal, como também com muitas pessoas das várias startups e empresas estabelecidas com quem conversei ao longo desses anos.

Como você sabe, esse aprendizado todo acabou virando um livro, o Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis, lançado em 2012. Agora no segundo semestre de 2016 vou lançar a segunda edição desse livro, revista e ampliada com todas as lições aprendidas desde então.

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!