Silicon Valey is Here

8/16/2019 Silicon Valey is Here

1/40


2/40

ÍNDICE

Introdução ...........................................................................................3

O dilema da agilidade digital .................................................................4

Os 10 maiores erros da abordagem de fábrica de software .........................6

Anti-patterns: por que pessoas inteligentes tomam decisões erradas .........9

Lean Startup e Lean Innovation ..............................................................11

Não fazemos projetos, desenvolvemos produtos! .....................................17

Práticas, Papéis e Plataforma ..............................

“Silicon Valley is coming” ....................................

OKR (Objectives and Key Results) *por Felipe Castr

Transformação digital ........................................

Presente e Futuro ...............................................


3/40

Silicon Valley is here - Como usar a agilidade corporativa para competir

Introdução

Há 15 anos, exatamente enquanto a Concrete Solutions nascia, um grupo de ve-

teranos em desenvolvimento de software se reunia para criar o Manifesto Ágil,

documento que tinha por objetivo melhorar o desempenho dos projetos de tec-

nologia. Sendo assim, não é por acaso que acompanhamos a evolução da agi-

lidade por todo esse tempo, seguindo seus princípios, iterando e aprendendo a

cada novo cliente e produto desenvolvido.

Neste livro, pretendemos contar parte dessa história. Como passamos do escuro

do waterfall para a luz do Scrum, como identicamos as melhores práticas, os

papéis ideais e uma plataforma que zesse sentido nesse contexto, como en -

tendemos que o que fazíamos era gerenciamento de produtos digitais

e como essa visão nos mostrou o tripé Lean Product Man

nharia Ágil, que consideramos o estado da arte no desen

atualmente. Entretanto, vale lembrar que o desenvolvim

ambiente complexo e caótico, em constante transformaç

mudam a todo momento, pois tudo o que fazemos é em

mental. Logo, pode ser que pouco depois de ler esse liv

uma nova epifania que faça sentido ou um aprendizado

novas, quem sabe baseados no seu feedback.

Esperamos que esse livro te ajude a entender melhor o a

no Brasil e te ajude a dar mais um passo no caminho do s

Boa leitura!


4/40


Nosso mundo mudou. Precisamos tomar decisões difíceis sobre sistemas complexos digitais que vão

afetar o futuro das nossas empresas. Estas decisões juntas, ao longo do tempo, deveriam ser uma buscapela evolução para uma cultura de agilidade digital.

Neste primeiro capítulo, pretendo sintetizar a mensagem central e atual que gostaria que casse destelivro. O que posso trazer aqui não é uma fórmula a ser aplicável sem mudança no seu contexto, masuma trajetória de aprendizado com experimentos aninhados ao longo de 15 anos para que talvez vocênão precise cometer o enorme número de erros que nós cometemos. Se servir para isso, o esforço decompilar essas ideias já serviu seu propósito. A partir do segundo capítulo eu busco manter uma ordemcronológica, e muitas vezes datada, do nosso processo de aprendizado.

Atualmente, o nexus competitivo brasileiro é uma combinação de um volátil ambiente de negóciosformado por uma crise sem precedentes do nosso capitalismo e a vinda de novos competidores digitaisdo Vale do Silício. Além deste novo ambiente, o nosso cliente mudou. Agora ele quer uma relação deautosserviço mobile com nossos produtos no mesmo patamar de qualidade dos aplicativos do Vale ecom a presença ubíqua da nuvem.

Juntando essas variáveis temos três dilemas competitivos: queremos mudar nossa cultura e implantaruma estratégia de execução digital nos moldes do Vale; queremos descobrir novos modelos de negócioque alavanquem as capacidades da empresa por meio de importantes ganhos operacionais; e queremosdisruptar nosso próprio negócio antes que alguém o faça.

Implantação de uma cultura de execução digital

Peter Drucker disse uma vez que “cultura come estratégia no café da manhã”. Nós acreditamos quea única estratégia que importa é a implantação de uma cultura de execução digital. Isso implica ementender que temos que ser iterativos, empíricos e incrementais quando lidamos com sistemas dinâmicoscomplexos, e isso tem que ser lentamente inoculado no DNA da empresa.

Essa agilidade digital global implica em aplicar e evoluir frameworks ágeis no “como fazer”, no “o quefazer” e, nalmente, no “como gerir a corporação”. Para nós, isso se traduz em ági l em escala, Lean ProductManagement e OKR, itens que serão melhor descritos ao longo desse livro. O principal termômetro deste

processo é o nível de maturidade de agilidade digital em que está

para seus clientes. Se ele está mal, você está mal.

O processo de implantação que parece funcionar também é empíricuma pequena estrutura de produtos operando o primeiro esquadrdependências departamentais e com o waterfall do resto da orgaexecutivo no nível adequado, ele vai entregar uma primeira vitória a cultura.

Neste ponto, o time deve escalar em uma estrutura de múltiplos ticom um Nexus da Scrum.org ou algo que obedeça aos mesmosvão “assimilando” as dependências e se tornando “feature teams” ctêm todas as capacidades necessárias para entregar o produto. Fi“core”.

Este processo cria uma estrutura supra departamental iterativamporque ao contrário do inferno anterior, ele entrega. A cultura afeta

e essa abordagem e framework de implantação de agilidade digalterando toda a corporação.

Descobrindo novos modelos de negócio digitais no seu negócio

Este problema é uma variação do anterior, mas o nível de comptemos que adicionar processos empíricos de ciclo rápido para reduse você tiver o desao de criar uma área de inovação, a abordagadicionais no “como fazer” e no “o que fazer” e de uma estratégia ddiferente, inspirada no modelo de venture capital.

Os times sempre devem começar com ciclos de Product Discocapacidade até que tenha pelo menos todos os papéis. Neste msprints, se temos validações claras e quantitativas das nossas hipfeatures de produto o nível de complexidade do sistema cai e po

O dilema da agilidade digitalCapitulo 1


5/40Silicon Valley is here - Como usar a agilidade corporativa para competir

anteriormente para escalar o produto.

Se, por outro lado, parte do produto continua muito complexa ou caótica, podemos utilizar estratégiasde “Dual Lane Scrum” (conceito de Je Patton) ou de Sprints de Discovery (de Marty Cagan) em paraleloao desenvolvimento dele.

Em relação à alocação de capital e orçamento, estes times devem ter portões de aprovações autogeridosno início seguidos de ciclos semestrais de “mantém”, “investe mais” ou “mata” o produto. Dentro de umambiente limitado, isso signica algumas vezes que para atender ao orçamento teremos que forçar“darwinianamente” a realocação do capital e dos times estáveis para os melhores produtos.

A implantação desta cultura de execução digital tem que sempre levar em conta as condições decontorno e o estado do sistema no qual o produto está inserido e ter agilidade digital para usar o modelomental e o ferramental correto.

Disruptando a si mesmo

Esse é um tema que tenho muito menos experiência, mas acredito que a decisão entre estratégias

de corporate venturing, investimentos, aquisições e aceleradoras corporativas, apesar de válidas epotencialmente de muito sucesso, muitas vezes esconde o problema de que a corporação patrocinadoranão começou o seu próprio processo de mudança.

Me parece que, no longo prazo, ser capaz de ter sua própria capacidade de execução digital comoalternativa a estes modelos equilibra o sistema e permite aos executivos tomar decisões de alocaçãocapital pelo motivo certo e de forma ótima, garantindo a sobrevivência de longo prazo da corporaçãonesse admirável mundo digital novo.



Lá em 2001, logo que a empresa foi fundada, zemos alguns projetos usando waterfall. Foi rápida,

porém, a mudança para ágil. Isso porque descobrimos diversos erros na abordagem em cascata. Vamosfalar um pouco sobre quais foram eles.

Se você procurar a denição do termo “fábrica de SW” no Wikipedia brasileiro temos a seguinte denição:

“Fábrica de software é um conjunto de recursos (humanos e materiais), processos e metodologiasestruturados de forma semelhante àqueles das indústrias tradicionais, utilizando as melhores práticascriadas para o processo de desenvolvimento, testes e manutenção dos softwares. Utiliza em suaoperação indicadores de qualidade e produtividade em cada etapa do ciclo de desenvolvimento de

software, bem como busca maximizar a reutilização de componentes anteriormente desenvolvidos.Tornou-se uma prática comum com o objetivo de massicar a produção de software pela redução de

custos”.

Apenas com base nessa denição livre da Wikipedia, podemos começar a listar os maiores errosrelacionados ao uso desta abordagem.

1. “Fábrica de Software é um conjunto de recursos humanos e materiais”Fazer software é um trabalho criativo, no qual as diferenças de produtividade podem chegar a 10 vezesde diferença entre trabalhadores do conhecimento, ou seja, pessoas que precisam ser motivadas eremuneradas para que produzam o seu melhor e tenham seus interesses alinhados com o cliente.Tratar o desenvolvedor como um recurso é não só infantilizar como desumanizar um tipo de prossionalextremamente sosticado e escasso. Inserir este prossional em uma forma arcaica e ineciente defazer software atrai o que há de menos produtivo para sua “linha de montagem”.

2. “Os recursos são estruturados de forma semelhante a uma indústria tradicional”

Novamente recorrendo à Wikipedia, temos como denição para o termo “linha de montagem”:

“As linhas de montagens são utilizadas no processo de produção em série, para que o produto em fabricação seja deslocado ao longo de postos de trabalho, mas a sua eciência depende da combinação

de quatro condições indispensáveis: componentes estandardizados, movimento mecânico, equipamento

de precisão e processos padronizados”

Fazer software tem mais semelhanças com o processo de criaçiterativamente de um conceito para um protótipo e chega a uma prde produzir a mesma coisa em série repetidas vezes. Os componeforma criativa para resolver um determinado problema, e o nível dee repetição foram eliminadas desta equação há muito tempo, são

3. “…utilizando as melhores práticas criadas para o procesmanutenções dos softwares”

A primeira fábrica de software foi criada em 1969, na Hitachi, e o pmalfadada leitura de um artigo de Winston Royce de 1970, no qual ethe implementation described above is risky and invites failure” . A criaçãleva a uma falta de feedback total, não só entre as áreas, mas priné tardiamente testado, tem pouca chance de sucesso e o investimsob estimativas sem nenhum embasamento.

Além disso, a criação de silos de requisitos, arquitetura, desemanutenção leva a um desalinhamento de interesses. Apesar de né testado em campo), um tratado extenso de requisitos é feito paexatamente qual é nem muito menos como resolvê-lo.

Quem testa tem conito de interesse com a i da de algo para produç(se ele eventualmente for para produção) não é quem dá manuten

Estes silos geram uma natural necessidade de burocratização dos mudança caótica e impraticável.

4. “…reutilização de componentes anteriormente desenvolvidos

A grande diculdade do reúso, que observei nos últimos 17 anos, é

Os 10 maiores erros da abordagemde fábrica de software

Capitulo 2



a necessidade de padronização de denição de uma forma clara de descrever aquele domínio e a

incapacidade da organização de prever o futuro e prescrever “a priori” o que de pop ular o seu catálogo.Onível de reuso dentro de uma mesma organização é baixíssimo, pois o catálogo é malformado. Em umambiente open source, ao contrário, toda uma comunidade elege o que é um ativo reusavel de formalivre (na prática regida pelas leis de mercado).

Em uma amostra pequena, cada projeto ou iniciativa tende a cobrir um pedaço do espaço do problemaque não será visitado desta forma novamente. As iniciativas de SOA, por exemplo, tentavam prescrevero futuro sobre quais seriam os serviços reusáveis de uma organização e, pior, gerava um ciclo waterfalldentro de outro ciclo waterfall, o que aumentava enormemente a complexidade e acabava tornandoum projeto com 13% de chance de sucesso (segundo o CHAOS Report) um projeto impossível.

5. “…tornou-se uma prática comum com oobjetivo de massicar a produção de softwarepela redução de custos”

Warren Buet uma vez disse que “não existe

desperdício maior do que produzir com perfeiçãoalguma coisa que ninguém quer” . Quandoanalisamos processos produtivos como ométodo Toyota de Taichi Ono ou leituras como aTeoria das Restrições de Eliyahu Goldratt, vemossimilaridades na busca da otimização global comframeworks de melhoria continuada. Se nãoanalisarmos e otimizarmos o sistema como umtodo, podemos (via otimização local) criar falsaseconomias de escala e gerar desperdício de duasformas: produzindo a quantidade errada da coisaerrada.

Se analisarmos o trabalho de Steve Blank e Eric

Ries, que reete o estado do conhecimento do Vale do Silício sob

digitais, entendemos que o maior desperdício não é fazer erraderrada. Esse erro é aumentado pela prescrição e pelo processo wBlank cita inclusive que o desenvolvimento de novos produtos é u

A produção de software é uma criação iterativa e incremental quede um cliente que você ainda não sabe qual é, se é um problema

menos como você vai resolvê-lo.

Pensar em uma linha de montagem para atacar um problema decavalaria e guerra de trincheiras no ambiente militar contemporântentar prescrever a invasão da Normandia. Esses cinco pontos pdeixa desconfortáveis para usar watefall. Mas ainda temos mais cdesconstruir.

6. “Você sabe qual é o problema que você tem que resolver e comprescrever o processo. O processo de trabalho é rígido”

No primeiro capítulo de The Toyota Way, Fujio Cho faz a seguinte a

“We place the highest value on actual implementation and takindoesn’t understand and therefore, we ask them why don’t you jus

something? You realize how little you know and you face your owthose failures and redo it again and at the second trial you realizedidn’t like so you can redo it once again. So by constant improvembased on action, one can rise to the higher level of practice and k

Tradução livre: “Nós colocamos o maior valor na implementaçãonão entendemos e, portanto, perguntamos ao cliente se devemações ou tentamos fazer algo. Você percebe o quão pouco você se pode simplesmente corrigir essas falhas e refazer tudo de novpercebe outro erro ou outra coisa que você não gosta e pode refaz

Identify theconstraint

Exploit the constraint

Subordinate and

synchronize tothe constraints

Elevateperformance of the constraint

Repeat theprocess

Goldratt, teoria das restrições

https://en.wikipedia.org/wiki/The_Goal_(novel)https://en.wikipedia.org/wiki/The_Goal_(novel)



melhoria contínua, pode-se subir ao mais alto nível da prática e do conhecimento”.

Colocando isso no domínio de software, processos que buscam melhoria continuada e desenvolvimentode produtos de sucesso têm que ser iterativos, pois se tratam de uma jornada de aprendizado focadano cliente.

Esta jornada deve ser feita com a ajuda de times multidisciplinares que se mantém juntos, trabalhandoem um mesmo domínio e mesmo cliente e, mais importante, próximos ao cliente. Essa estratégia leva aum aumento contínuo da uência ágil, ou seja, fazer de forma cada vez mais eciente. Criamos músculointelectual pelo aprendizado baseado na prática.

7. “Conseguimos estimar corretamente o esforço de um produto por meio de técnicas top down oubottom up ou de uma regressão e interpolação linear simples (pontos de função ou UC Points)”

Primeiro ponto a ser consider-ado aqui é a discussão sobrecomportamento passado ex-plicando comportamento fu-turo, o que neste caso espe-cialmente não se aplica. Emsegundo lugar, a amostra nãoé aplicável, ou seja, não ex-iste uma série histórica válidaa não ser que eu tenha o mes-mo time, no mesmo ambientede negócio e tecnologia, fazendo a mesma coisa. Em 18 a nos de experiência, nunca vi isso acontecer.

A criação de uma taxonomia que sirva para criar uma série (e um modelo de previsão)para descrever um fenômeno tão amplo como desenvolvimento de software, ignorando anecessidade de condições de contorno estritas, é simplesmente e completamente desprovidade rigor, seja pela visão da academia ou pela visão da comunidade que faz software (practitioners).

Pior do que a inacuracidade da abordagem é a falsa sensação

celebração de contratos na esfera privada e governamental.8. “Conseguimos prever o futuro, criando um gráco de Gant

ocorrerão nos próximos n meses”

Fazendo um paralelo, é como se um gestor de fundo de investimde todos os “trades” que ele vai fazer nos próximos seis meses, iggarantisse o nível de retorno desta estratégia. E VOCÊ ACREDITAS

9. Documentação e modelos ajudam a construir um produto dig

Fazendo um paralelo com projeto de construção civil, Glenn Vandand SW Engineering” a seguinte relação: o código é o projeto detrabalho de baixo valor agregado e repetitivo de executar o plano trabalho é virtualmente gratuito, não faz sentido fazer modelos e s

Modelos só precisam ser feitos em ambientes em que a constru

como na indústria aeronáutica e militar, para que a iteração em custosa no início. Em software, o código é o melhor modelo e o únreal para aquele problema naquele ambiente dinâmico e complexpróprio produto que deve ser usado nas iterações de aprendizado

10. Conseguimos denir corretamente o escopo, estimar o e

determinado com qualidade, passando a informação com suceda fábrica.

Se analisarmos o processo de criação do produto como uma caque ela tivesse integração perfeita entre os praticantes, estoqueinformação em um uxo perfeito de trabalho “Just in Time”, no qual cseu trabalho melhor que uma empresa só. A melhor representaçãmultidisciplinar trabalhando junto, dentro de um framework empíride produto. Ficou claro que waterfall não é o caminho? Então vam

@Scott Adams Inc./Dist by UFS, Inc. www.dilbert.com

http://pt.slideshare.net/kostasmavridis/glennvanderburgcraftandsoftwareengineeringhttp://pt.slideshare.net/kostasmavridis/glennvanderburgcraftandsoftwareengineering



A adoção de metodologias ágeis garante o aumento da chance do seu produto, mas não que essa

chance chegue a 100%. O desenvolvimento de software é uma área complexa, tratada por sereshumanos, e os erros são frequentes e devem continuar sendo. Apostamos em hipóteses, que devem ounão ser validadas, e seguimos em frente com o aprendizado que adquirimos em cada sprint. Entretanto,podemos enxergar os erros que cometemos (ou que outros cometeram) e entendê-los para que elesnão voltem a ocorrer.

Nos últimos quinze anos, criamos e trabalhamos em quase vinte startups. Nelas, alguns erros serepetem várias vezes. Por isso, resolvi organizá-los em um diretório de anti-patterns que permita queos próximos empreendedores digitais não precisem cair nos mesmos buracos que nós caímos. Estespadrões emergiram naturalmente, pois parecem ser uma predisposição natural do empreendedor. Semnenhuma ordem particular, seguem os erros mais comuns e graves que normalmente se repetem porfalta de reexão adequada:

1. Maximum Viable Product ou “La Sagrada Familia”

Essa ideia prega que o produto precisa de todas as funcionalidades de um

backlog mutável, feito dentro do escritório e sem nenhum embasamentoempírico (validação das hipóteses de negócio com clientes reais).Funcionalidades empurradas (não sugeridas pelos clientes potenciais) levama data de lançamento para as galáxias e, normalmente, quebram a empresa.O arquiteto Antoni Gaudí fez um projeto tão ambicioso e uido para a catedralde Barcelona (La Sagrada Família) que está em execução desde 1882 e devecar pronto em 2026.

A frase clássica desse erro é: “não podemos entrar em produção sem todasessas ‘features’ ou com menos do que a concorrência”

2. Yamato

O encouraçado Yamato era o maior navio da 2ª Guerra Mundial, com canhões de 500 mm. Ele foimandado para uma última missão sem combustível para voltar. Startups só têm uma métrica nanceira

que interessa: “qual é o meu burn rate” (perda de caixa mensal), ac

ainda levo para quebrar”. Uma gestão de produto que ignore essasda falta de combustível.

3. The Queen of Hearts

“Cortem-lhe a cabeça!” Se, por algum motivo, astravas emocionais relacionadas à demissão sãodiminuídas (em um contrato de terceirização demão-de-obra, por exemplo), ou a punição do erroé alta demais, todo o ciclo de “Build, Measure andLearn” é sabotado. Quando se encontra um even-tual insucesso, ao invés de se invalidar uma hipó-tese ruim, há uma busca de um bode expiatórioprontamente eliminado, o que elimina o aprendiza-do. Isso normalmente gera o aparecimento de “Yes

Mans” ou pessoas que reforçam o pensamento vi-gente e que têm esse comportamento bonicado.Em médio prazo, isso mata a startup, pois eliminaa convergência para um modelo de negócios quefuncione e gera um grupo homogeneamente apontado para a dire

4. The luv for Awesome

Um dos maiores (talvez poucos) desserviços que Zuckerberg prestele trabalha buscando o “awesome”. O Facebook entende profundpoucos, novas funcionalidades para atender seus problemas mais geek que ca no caminho do pronto e, portanto, do aprendizado, dOu seja, o “awesome” é inimigo do bom. Nada mata tão gloriosamuma inatingível beleza técnica ou uma visão de produto tão avass“home run or die”.

Barcelona - La Sagrada Familia

Rain

Anti-patterns: por que pessoas inteligentestomam decisões erradas

Capitulo 3



5. Claptrap

Transcrevendo um arquivo brilhante do Wall StreetJournal que cita Richard Feynman:

“Monitor yourself for vehemence. If you nd your - self tempted to ridicule anyone who tells you arewrong, you probably are wrong. The philosopherBertrand Russell wisely warned that the less evi-dence someone has that his ideas are right, ‘themore vehemently he asserts that there is no doubtwhatsoever that he is exactly right’”

Tradução livre: “Monitore você mesmo para aveemência. Se você está tentado a ridicularizarqualquer um que diz que você está errado, vocêprovavelmente está errado. O lósofo Bertrand

Russell sabiamente advertiu que quanto menosevidências alguém tem de que suas ideias estãocertas, ‘mais veementemente ele armará que nãohá dúvidas de quanto ele está certo’”.

Se o seu “ninja” técnico é muito assertivo, é o “goto guy” para quase tudo e vira noites o tempo todo,mate ele a pauladas (gurativamente).

6. Barrel rider meets mediocre

O processo waterfall, com compra via RFP, criou uma lógica de meritocracia reversa em TI muitosemelhante ao que ocorre em um estado comunista clássico. Sem entrar no mérito ideológico, o queinduz o comportamento do sistema comunista é a criação de controles, a inimputabilidade e a criaçãode uma nova ordem dirigente na qual quem tem mais poder não é quem produz, mas quem controla. Em

longo prazo, ninguém mais quer produzir, a não ser um grupo cada

vez mais caro de mercenários que inexoravelmente a empresa nãovai mais conseguir pagar.

7. Atlas Shrugged

Quando o anti-pattern anterior acontece, as pessoas que produzeme que levam o mundo nas costas desistem, dão de ombros e vãoembora. Quando as palavras dissonantes começam a car emsilêncio, no nal tudo converge para um pacto de mediocridadetácito.

8. Hulk

Nós resolvemos tudo na força bruta porque temos fundingnão importa se nosso “anel de Cassandra” não teve dois dias deplanejamento antes de entrar em produção. Débito técnico éinserido em uma taxa cada vez mais alta com horas e horas detrabalho extra em uma esperança bem-intencionada de que osistema vai se estabilizar quando de fato ele está morrendo. Outrafrase clássica é “Não consigo testar nosso cenário de produção”servidores e desenvolvedores são inseridos até que algo realmesaia do transe.

9. O bom, o mau e o feio

Uma startup precisa de três pers: o Hacker, o Hustler (vendedor) eestão em uma pessoa só. Tentar fazer bootstrap sem um hacker num tech co-founder brilhante como CEO na fase subsequente é do time. Além disso, as ações devem ser pensadas como um pagsalário, e devem ser “vestidas” ao longo deste período. Caso consócios zumbis até um deles aceitar uma proposta e ir para Nova Yo


11/40


Finalmente, todo contrato no Brasil precisa de cláusulas de saída e/ou resolução de conito. Se for

para o Tribunal, é uma competição de nado sincronizado em concreto: você se move vagarosamente e,quando ele secar…

A maior referência que temos sobre negócios digitais está no Vale do Silício, onde são criados os principaissucessos. Foi lá que surgiu a metodologia Lean Startup para desenvolver startups digitais, que agoraestá sendo aplicada também em grandes corporações.

No primeiro capítulo, falamos sobre como a utilização de waterfall é a principal causadora de insucessoem produtos e empresas de tecnologia. Depois do aprendizado da primeira bolha, Steve Blank enxergouum padrão nas startups de sucesso que resumiu no livro “The Four Steps to the Epiphany”. Segundo ele,tais startups eram capazes de enxergar que tanto o problema quanto a solução eram desconhecidosno início da jornada. Neste caso, não adiantava elaborar grandes ciclos de planejamento e encontrar ocliente tardiamente com uma solução não testada em campo.

Além disso, estes empreendedores visionários eram capazes de tratar estas etapas de validação deproblema e solução como ciclos de validação de hipóteses de negócio, que poderiam ser validadas ou

não.Ele formalizou assim uma heurística para validação de modelo de negócio:

Tempos depois, ele publicou esse cartoon:

Fonte:www.steveblank.comFonte: Banks

Lean Startup e Lean InnovationCapitulo 4

http://steveblank.com/http://steveblank.com/


12/40


Mas o que é Lean Startup?

O conceito foi criado por Eric Ries baseado no trabalho de Steve Blank, e parte do princípio de que oobjetivo de uma startup é validar um modelo de negócios e não executá-lo com eciência. Ou seja, onegócio deve ser tratado como um conjunto de hipóteses que precisam ser validadas ou abandonadasrapidamente.

No contexto digital, a prática une métodos ágeis, desenvolvimento de cliente (ou Customer Development)e alguns conceitos de Lean, como lotes pequenos.

Para desenvolvimento de produto, os métodos ágeis são os mais usados mundialmente, e sua adoçãoestá aumentando cada vez mais no Brasil. Com eles, os projetos não têm escopo rígido e cada etapaé construída de forma evolutiva, com cliente e fornecedor atuando conjuntamente. Porém, como diziaPeter Drucker, não existe desperdício maior do que executar com perfeição algo que ninguém quer.Métodos ágeis, apesar de endereçarem o espaço da solução, não ajudavam a entender o problema, queera validar o modelo de negócio. Por isso, a metodologia teve de adotar também o desenvolvimento docliente (Customer Development).

Tal abordagem não garante o sucesso da empreitada, mas aumenta muito sua chance de sucessoeliminando o desperdício e o crescimento precipitado (não sustentável). Com isso, hoje podemos criarstartups de tecnologia com investimentos iniciais de menos R$ 500 mil, o que na época da primeirabolha era de cerca de R$ 10 milhões.

Empreender continua precisando de paixão, mas os fundos precisam de dados reais obtidos de métricasvindas do que Ries chamou de contabilidade de inovação, isto é, de dados mais especícos paraacompanhar e principalmente aprender com a evolução da startup e o engajamento dos seus clientes.O dinheiro virá ao serem at ingidos os patamares de aprendizado.

O maior desastre da história das startups é uma prova por absurdo de que a abordagem de Lean Startupé a mais indicada. A Iridium destruiu US$ 5,2 bilhões porque durante os onze anos que comprou 15foguetes e colocou mais de 75 satélites em órbita o mercado de comunicação móvel mudou. Ao invésdos 42 milhões de clientes esperados, a empresa teve apenas 30 mil no seu pico. O plano de negócios

foi seguido com precisão até o precipício, enquanto que o proce

trazido alarmes antecipados disto.Podemos dizer mais que os modelos de open source e de cloud cde competição, eliminando a necessidade de investimentos na inuma adaptabilidade uida a esta estrutura, que se molda perfeitamsão visíveis em qualidade, velocidade e custo, o que faz da práticferramentas open source e cloud computing, a melhor forma de e

Lean Innovation (Lean Startup em corporação)

Mas e para as empresas já estabelecidas, que não são mais startupNovos projetos têm características similares a uma startup e, poiniciativas sejam desenvolvidas empiricamente, assim como prequatro macro processos precisam ser adaptados: a validação deprodutos, a criação de clientes e o ciclo de nanciamento.

Entretanto, há algumas diferenças entre a aplicação em startups eestá ligada à estrutura organizacional. Enquanto a startup é formempresas maiores têm uma hierarquia já preestabelecida. Por issdeve começar por determinadas áreas, normalmente ligadas à ino

Os times durante os primeiros sprints têm uma estrutura “Hackeestruturam como times ágeis com visão de customer developmenalguns papéis novos como o “PO Fundador” e a necessidade deuma determinada prática chamadas de “capítulos”. Esta estruturaaceleradora e os times são chamados de esquadrões pois têm ma

O orçamento destinado ao projeto também deve ter tratamento para gerar retorno nanceiro no início, mas maximizá-lo no futurodeveriam.

As métricas clássicas como Retorno sobre Investimento não se


13/40


algumas vezes também não se aplicam nos primeiros anos da startup. O Retorno sobre Capital Investido

(ROIC) deveria ser medido em um espaço de 6 a 7 anos (ciclo de abertura e fechamento de um fundo).Apesar disso, as métricas de sucesso serão rapidamente quantitativas como volume de clientes,conversão, likes, engajamento, retenção, recomendação e depois faturamento. Estranhamente nãobuscamos lucro a curto prazo.

A Lean Innovation diz que o investimento deve ser feito de acordo com patamares de aprendizado.Para isso, é necessário um comitê de investimento, formado por pessoas de diversas áreas que, juntas,geram apoio e alocam recursos de forma progressiva. Ou seja, se a iniciativa atingir os objetivos deaprendizado, recebe mais investimento.

O veículo sobre o qual a iniciativa está sendo feita pode ser “outbound” (começa dentro da empresae depois vira uma LTDA.) ou “inbound” (começa numa empresa externa de consultoria e depois éinternalizado (na entidade mãe ou como empresa do portfólio).

• Investir de forma Lean

• Burn rate mensal até atingir um objetivo de aprendizado ou uma hipótesede negócio previamente validada

• O único controle que é necessário é o gasto mensal de caixa e a quantidadede meses disponíveis

• O mercado tem que ser grande

• Manter como projeto interno ou montar uma LTDA ou S/A depois devalidar o problema (talvez depois de validar solução)

Por m, para adotar Lean Innovation a grande empresa não pode se restringir aos padrões de processose ferramentas. O que vale para a parte madura pode não ser adequado para iniciativas inovadoras.Novos meios surgem todos os dias e é preciso estar atualizado para se manter competitivo.

Normalmente estamos falando de inovação de borda (no limite da corporação) e gradualmente se

demanda a criação de APIs dos serviços de negócio da corporaç

inovação aberta. Alavancar estas capacidades é muitas vezes doloas corporações têm vantagens competitivas não copiáveis que a d

Ferramentas como open source e cloud computing, por exemplinvestimentos, tornando-os despesas variáveis. Uso extensivo de Scomo landing page, atendimento e métricas permite que a iniciativaforma ágil. O que deve ser desenvolvido sobre IaaS é o produto mí

A junção de tudo isso constitui a melhor forma de desenvolver um nque pode não garantir o pleno sucesso, mas aumenta considerave

Esta adaptação é um processo contínuo de mudança cultural que de trabalho:

1. Estabelecimento do ciclo de “build, measure, learn”;

2. Estabelecimento de métricas para gerir o portfólio e se comunic

3. Criar uma estrutura orçamentária que aloque despesas de formade iniciativas;

4. Permitir o uso de ferramentas open source, cloud computing oproduto, e não necessariamente uma padronizada;

5. Alterar a estrutura organizacional (times matriciais);

6. Criar uma estrutura de governança que permita avaliar o suaprendizado validado), sem comprometer a natureza do portfólio;

7. Gerenciar as relações com as áreas e stakeholders externos env

8. Dar segurança jurídica e política para todos os stakeholders e pac

Ou seja, os projetos começam quando a maioria dos stakeholders


14/40


Aprendizados

Alguns conceitos e ferramentas têm uma combinação perigosa de abrangência, poder e simplicidadeconceitual que levam a uma reexão imediata de praticantes das mais variadas áreas assim que osaprendem. São comuns frases como “Isso também pode ser aplicado em...” (preenchendo com o domínioconceitual em que eles estão mais confortáveis). Esta reexão acontece antes que o conceito tenhasido corretamente entendido e eventualmente fora das condições de contorno nas quais o modelo foicriado. Isto aconteceu na minha experiência com coisas bem variadas como Mapa de Forças de Porter,Matriz BCG, SCRUM, Opções Reais e, recentemente, Customer Development & Lean Startup.

O problema dessa abordagem não é óbvio, mas é muito sério. Antes de você generalizar um modelo,é necessário um conhecimento profundo dele. Na minha experiência, esse conhecimento não vemde uma reexão isolada sobre o tema, mas da aplicação repetitiva em um ciclo de aprendizado quealimente um mesmo grupo de praticantes. Esse grupo acumula a experiência e reexões passadasiterativamente até que se crie músculo intelectual (reexões validadas e ortogonais) e não gordura(“entendi a superfície”).

Nós passamos por Waterfall em 2000, RUP em 2003, SCRUM em 2007 (depois Kanban), CustomerDevelopment e BMG no nal de 2010, Lean Startup, Lean Analytics e AARRR + Inbound Marketing (Web)2011, Marketing Digital Mobile e Lean Innovation (Lean Startup em corporações) em 2012.

Quando começamos a generalizar o modelo de Lean Startup em 2012, tínhamos a nosso favor umgrupo que fazia software junto, como empresa, há 14 anos, e um “site SCRUM” com cinco anos dematuridade. O resto era muito recente para nós e para o mercado, então a trajetória de aprendizadofoi extremamente empírica. Depois desse grande aviso de cuidado, lá vão as maiores reexões quezemos neste período.

O primeiro ponto é que o inimigo é sempre interno. Os motivos de falha dos produtos digitais nunca sãoexternos, a competição é irrelevante. Utilizando a metáfora da “Idea Maze” do Chris Dixon, a busca davalidação do modelo de negócio de sucesso é como achar a saída de um labirinto: o bom fundador éaquele que consegue, apesar da desorientação natural, tomar boas decisões de caminho baseadas em

cada caminhada anterior. Competição é só sinal de que tem mais

estar próximo de alguma coisa. Estendendo a metáfora, o minotaantes de você encontrar a saída.

Existe uma enorme necessidade de facilitação interna com as áreaso modelo de negócio validado e as áreas com poder de veto. O foe ir para resultados de negócio, que devem ser comunicados à eempuxo até os tomadores de decisão.

No livro Lean UX, Je Gothelf fala “shift the conversation of the leaProduct managers and product owners must determine which busIn turn, have conversation around outcomes with managers, this whighest levels of the organization”.

Em tradução livre: “transforme a conversa entre os líderes em feate gerentes de produto devem determinar quais métricas de negóvez, conversar sobre resultados com os gerentes faz com que, inev

níveis mais altos da organização”.Outro ponto que observamos é que a principal causa de insucepenalização do erro. É preciso que haja uma mudança cultural dráe que os POs e fundadores sejam encorajados a tomar risco. Aaprendemos para chegarmos ao sucesso.

Temos que implementar uma nova visão do que é geração de“contabilidade de inovação” e “o que aprendemos até agora”. Geraimportante quanto desenvolver produtos, por exemplo. Uma manprocurar casos de fusão e aquisição, precicando esse processo desses investimentos.

Além disso, o fracasso é uma profecia autorrealizável. Os times de foram selecionados de forma natural pela sua capacidade de sob


15/40


de desenvolvimento de produto que tem 1 4% de chance de sucesso, é difícil não entender a posição

deles. Quando o projeto começa a se materializar, ca claro que o pior resultado vai acontecer. Se otime de negócios (business owners ou analistas) se colocar como cliente do fracasso de terceiros,viverá para fracassar uma nova vez (“live to fail another day”). Se o time de negócios e dono da visãose comportarem dessa forma, o fracasso é umaprofecia autorrealizável.

Então, peça desculpas, não peça permissão.Coloque em produção, gere conhecimentovalidado e divida isso com o time. Treine, nãoespere que o time do cliente se comporte comoPOs maduros se eles não viveram isso antes enem foram treinados formalmente como tais.

Aprendemos também que os produtos mínimosviáveis poucas vezes são realmente mínimos.O custo político de fazer a coisa realmente

iterativa e empírica no desenvolvimento de produtoé percebido como alto demais. O que acontece, namaioria das vezes, é um desenvolvimento ágil semCustomer Development no início, o que gera no timeuma busca paranoica de ir para produção o maisrápido possível. Aqui vale a máxima “o projeto começaquando os stakeholders acham que ele terminou”,ou seja, os primeiros releases em produção. A partirda primeira versão em produção o PO ou fundadorprecisa chavear mentalmente para CustDev e o timetrabalhar com sprints de uma semana ou Kanban.

Faça o projeto numa “empresa de propósito especíco”, diminua o

para implementar um MVP menor e validar proposições centrais nque o cliente entenda as bases dos processos lean e BMG de validaa virarem MVP venham com níveis melhores de validação de prob

O mundo com Lean Innovation continua guiado por orçamento, masconta o MVP político (gordo) que dicilmente levará menos do quepodemos usar métricas de validação de modelo de negócio de stPor outro lado, o orçamento via burn rate com três linhas (time, cm, acredito que o prazo mínimo de burn rate deve ser 12 meses e

Para ciclos de validação mais curtos, é necessário um mandato dia zero, implementar MVPs realmente pequenos e eventualmenclose”, ou seja, pivotar (mudar a direção), perseverar ou fechar. No úrecursos dessa iniciativa são realimentados no portfólio.

Outro aprendizado: é preciso estruturar o time para lidar com a est

emergiu a necessidade de uma mentoria adicional aos SMs (Scrupara lidar com os níveis hierárquicos mais altos, que estão longemísseis políticos, porque está naturalmente exposto a risco. Essa m

No m, os objetivos são duplos: fazer o produto e desenvolver timesfor externo, a corporação vai detectar um DNA de fora e rejeitar reinserido no ambiente corporativo para seus novos “pais”. Tão impnegócios é formar POs e fundadores, e esse processo de aprendiz

Importante lembrar também que você só deve inserir de volta nade negócio validados.

Além disso, valuation para ativos digitais não é uma ciência óbvia. Apara justicar investimento em corporações é o Fluxo de Caixa Desmaiores que o WACC (custo de capital médio ponderado) da emp

57%

14%

29%

9%

42% 49%

Waterfall Agile

S ucc es sf ul C ha ll eng ed Fa il ed

Fonte: The chaos manifesto, The Standish Group


16/40


paralelo, uso de séries históricas de classes de ativo semelhantes e, talvez, opções reais são maisindicadas. Tratar o processo de tomada de risco como se a classe de ativo fosse um negócio semincerteza irá levar a uma alocação errada de recursos. Se por outro lado a estratégia de investimento“Spray & Pray” de Venture Capital americano não é aplicável, existe, na minha opinião, a necessidade deespalhar risco em um portfólio de inovação.

Por m, aprendemos que o jogo é de estrutura e cultura. Deve existir uma estrutura fatorada comrepresentantes das áreas de negócio (futuras receptoras) em comitês. Continuo advogando o conceitode aceleradora corporativa, semelhante à estrutura de ágil em larga escala explicada pelo pessoal doSpotify que vamos falar mais para a frente. Tem que haver condições para aparecimento de uma culturade tomada de risco e de “ownership”, na qual curto e longo prazo possam conitar, mas que a busca deconceitos necessários como “tração” e “validação” de modelo e aprendizado não sejam mortos em umabusca prematura de monetização ou materialização de um produto.


17/40


Consideramos que existem poucas grandes escolas de

desenvolvimento de produtos digitais no Brasil, e estãoconcentradas em mídia e em empresas que evoluíramde um datacenter para um portfólio de produtos emnuvem. São companhias que tiveram um imperativode inovação claro: lançar produtos digitais de sucessoou trocar de negócio.

Se a Globo.com nos levou a ter uma Engenharia ágil deprimeira linha e a trazer UX como prática de primeiraimportância, a Locaweb nos trouxe o Marty Cagancomo referência. Eric Ries popularizou o conceitode Lean Startup, mas Marty Cagan e o Silicon ValleyProduct Group se tornaram referência de conhecimentovalidado “duro” sobre desenvolvimento de produtosdigitais. Lean Startup é como um livro de divulgação

cientíca, Inspired é “The Real Deal”.As nove práticas

As reexões do resultado de todos os estágios por quais passamos até aqui nos leva a uma reexãomuito importante: fazer produtos digitais de sucesso é uma tarefa hercúlea, composta de muitas práticasorganizadas sob uma cultura focada no modelo de pensar e de executar do Vale do Silício. Ao longo danossa trajetória, os anti-padrões se empilharam e pediram soluções que implicavam em novos papéise novas competências. Com o desenvolvimento de produtos internos e as subsequentes tentativas deaplicar Lean Startup em corporação, entendemos que a causa mortis principal dos projetos não eramais falta de agilidade e engenharia de software, mas a falta de gestão de produto.

A partir dessa conclusão, entendemos que desenvolver produtos digitais de sucesso signica implantarnove práticas que devem ser aplicadas por nós ou por nossos clientes, com times mistos e sem a culturado medo. É uma trajetória difícil, mas possível.

1. Engenharia ágil e Cloud

Você vai ter que aprender a fazersoftware direito e gastar pelo menos20% do seu orçamento para mantê-lo direito (refatorando o produto)sob pena de se encontrar comtanto débito técnico que o produtovai parar de evoluir. Isto implicaem inúmeras “subpráticas”, masdestaco as três mais relevantes, naminha opinião:

- Desenvolvimento ágil (com Scrum,XP ou Kanban)

- Integração e Entrega contínuas

- Cloud e Open Source

2. UX

É loucura tentar fazer um produtosem alguém de experiência deusuário e design. As pessoas têmque amar seu produto, e esse ponto é chave. Acreditamos que oalguns princípios inuenciados por três escolas: UX tradicional, dÉ preciso focar em resultados (não em entregas); entregar iteratiinformação e a experiência de uso de forma rápida; e analisar judestas entregas. Também é preciso pouca documentação intermetrabalho junto com o time multidisciplinar, saindo do escritório e fopequenos, menos análise prévia e muito conhecimento validado.

Não fazemos projetos, desenvolvemos produtos!Capitulo 5

9P

Desenvolvde sucess

co

En

6

Q.A

7

Growth

Hacking

8

Cultura eOrganização

9

Governança e“PortfólioGrooming”


18/40


3. Product and Customer Discovery

Antes de começar, você precisa validar o problema que seu cliente quer resolver, o tamanho domercado e que tipo de produto você precisa. Nesta fase, Alex Osterwalder, Steve Blank e Eric Riesajudam muito, mas novamente quem tangibiliza melhor o processo é o Marty Cagan. Você descobre edesenvolve seu cliente descobrindo o problema a ser resolvido e a visão inicial do produto que depoisevolui iterativamente.

Apesar de parecer um processo serial em primeira análise, Customer e Product Discovery são trabalhoscontínuos e devem ser paralelos à execução de produto feita pelo PO. As novas hipóteses que entramno backlog têm que ser geradas da forma mais cientíca possível e próxima do cliente, ou seja, juntandoa análise das evidências com a proximidade dos clientes (grupos de clientes-chave ou conselhos deproduto). Estas hipóteses são validadas com protótipos com dados reais (live data prototypes), quepodem ser “de jogar fora” ou o embrião do produto. A experiência de uso destes pré-produtos alimentao PO e evitam o processo, antes desordenado, de alimentação de novas features no backlog.

Algumas vezes, a descoberta de produto ou o processo de aprender como materializar a nossa proposta

de valor é fácil. Em outros casos, é extremamente difícil. Considerando nossa experiência, a questãomais difícil não é descobrir quem é seu cliente, qual é o problema que deve ser resolvido e validar umaoportunidade de mercado. Na maior parte das vezes é mais complicado descobrir a solução para esteproblema, o que independe de quão talentoso seja seu time. Alguns problemas são difíceis de resolver,mas muitos desses problemas difíceis são os que valem a pena serem resolvidos.

Esses processos valem para qualquer tipo de empresa, mas devemos destacar que, quando falamosde grandes corporações, temos dois postulados não negociáveis:

a) se estamos em um ambiente competitivo, precisamos continuar descobrindo novos produtos. Algunssetores e seus principais participantes têm barreiras competitivas e não competitivas não copiáveis, eneste caso o imperativo da inovação é menor pelo motivo errado. A resposta para barreiras de entradanão copiáveis é a disrupção do setor e, no Brasil, o trabalho de inuência no arcabouço regulatório podeimpedir a disrupção.

b) precisamos fazer esse processo de forma responsável, ou seja,

atuais, funcionários e marca. Apesar do nosso foco em deploymencom o chamado deployment gentil, ou seja, garantir que as no“mainstream”, que está acostumado com as antigas. As linhas de reas forças de vendas e operação têm que ser, além de protegidas, pinovadores testam hipóteses arriscadas. As estratégias de segmusuários) maior ou menor ou empresas de propósito especícodeslizes não afetem a marca principal.

Para criar um novo produto, precisamos descobrir problemas repotencial e de uma validação de oportunidade curta e em série. Ede contexto, pois estamos falando de um portfólio e não de um proportunidade deve ser feita, esta etapa deve ser seguida de um pproduto, buscando tangibilizar o produto mínimo viável por meio dvalidação de hipóteses. Muito rapidamente, esse processo deverácontínuo de desenvolvimento de produto.

A ideia do Customer Discovery é descobrir e desenvolver um grupcom descobrir e desenvolver o produto. A denição está bastantede Steve Blank, no qual você tem uma base de clientes/usuáriosaborda sistematicamente para saber se suas ideias são válidas de avalem a pena serem resolvidos ou novas “dores” relacionadas ao s

Nesta etapa, duas atividades principais devem ser executadas: destamos envolvidos em um mercado grande o suciente para aloé: estamos resolvendo um problema relevante que alguém pagrespostas para esta pergunta você só pode conseguir conversand

Em resumo, você deve criar uma proposição de valor clara e uma sModel Generation Canvas) que representem as validações e invalidpor meio de diferentes interações com nosso público-alvo. Tais in


19/40


barata e rápida, por exemplo, por meio de entrevistas, grupos no Facebook e pesquisas. Durante algumtempo este processo acontece ao mesmo tempo que a “Descoberta de Produto”, na qual protótiposcom dados vivos cada vez mais sosticados tentam descobrir como resolver o problema e se estasolução é viável.

Em empresas estabelecidas, a decisão “pivot” (mudar de estratégia sem mudar a visão) ou perseveraré feita por meio de práticas de governança de portfólio periódicas que decidem investir mais, manterou “matar” determinados produtos. Dentro dessas decisões, ainda temos uma divisão que é investirpreservando a visão e a estratégia (evolução natural dos uxos contínuos de descoberta de produto edesenvolvimento de produto) ou investir mantendo a visão, mas com outra estratégia, o que seria umparalelo do “pivot” do modelo de customer development clássico.

Da mesma forma que acreditamos que a escolha em startups é pivot, persevere ou “feche”, em corporaçãoé desligue, mantenha, invista seguindo a visão e a estratégia (uxo normal) ou invista na visão, maspivote.

O Product Discovery, por sua vez, vem em seguida: uma vez que já temos as informações sobre os

problemas e necessidades dos nossos clientes, buscamos o mínimo produto viável criando protótipose executando testes consecutivos para validar o conceito. É a partir daí que determinamos o conjunto decaracterísticas e interações e denimos qual produto vamos colocar no backlog para que o time construa.Time esse formado por três pessoas: o Product Owner (o dono/CEO do produto), um engenheiro sênior(Tech lead) e um designer de experiência de usuário sênior (UX designer).

Com o tempo (normalmente quatro semanas), o trabalho começa a alimentar o backlog do produto e otime multidisciplinar que está desenvolvendo. Os protótipos funcionais podem ou não ser dispensáveis,mas sempre têm dados reais (vivos) e são a principal ferramenta de comunicação com o time dedesenvolvimento de produto. Esses protótipos representam de forma clara e não contraditória, e devemresponder se a construção do produto é viável.

Deste processo também participam os grupos de usuários que melhor representem o público-alvo(subconjunto de clientes com características em comum) e depois o conselho de usuários (que melhorrepresente os “heavy users” do produto).

Com uma visão clara do que é o produto mínimo viável (MVP) descoberta de produto, temos que desenvolver o produto digital emque estamos evidenciando nesse capítulo. Algumas são mais espazul dizem respeito ao portfólio de produto e à organização.

4. Execução de produto

Alguém vai ter que entender como funcionao trabalho de “gerente/dono de produto”. OProduct Owner é o CEO, a pessoa que vaiconseguir traduzir a visão e a estratégia emhipóteses e depois em funcionalidades queserão colocadas no produto. Este trabalho vai serorganizado em um backlog e em um roadmapde produto de longo prazo. Os fundamentosestão na formação do PO dos times ágeis, masrapidamente precisa ser contaminado com a

visão de ciclagem rápida de hipóteses quegeram aprendizado. Os ciclos são chamadosde “construa, mensure e aprenda” pelo Eric Riesno livro The Lean Startup. A experiência mostraque o ciclo deveria ser construa, mensure,analise e aprenda.

Quando estamos fazendo um teste de DNA dofracasso no seu produto, ou seja, o que procurarno seu projeto para tentar preventivamente antecipar grandes dedescobrir quem e quão maturo é o seu Product Owner. Não imposeja bom, seu pessoal de UX brilhante, seu time de marketing de a eles algo relevante para fazer, não existe chance de sucesso.

Learn

Data

M


20/40


Saindo do escopo do projeto e pensando na empresa que mantém e patrocina um portfólio de produtos,a pergunta se generaliza rapidamente para “onde encontramos POs?”. Este, infelizmente, é o recursomais importante e mais escasso do ecossistema brasileiro de tecnologia. No livro Inspired, quandoconfrontado por esta pergunta, Marty Cagan responde categoricamente: eles já estão na sua empresa,pedindo para serem encontrados. Com o benefício do retrovisor, olhando de onde saíram os grandesPOs, Cagan parece ter razão. Eles já estavam lá, disfarçados e escondidos nas mais variadas formas.

Se isto é verdade, temos aqui que tentar chegar primeiro nos atributos deste prossional e depoisem como estes atributos se reetem em características individuais que podem ser procuradas nasua empresa. Depois de encontrados, temos a parte mais controlada: como medir, treinar, evoluir ouabandonar estas pessoas. Se o PO é o CEO do produto, não há espaço para concessões. A partir disso,seguem algumas dicas a partir de nossas experiências:

- Procure os Border Collies, ou os hypomaniacs apaixonados: depois de um trabalho cientíco extenso,mostrou no seu livro “The Hypomanic Edge: The Link Between (a Little) Craziness and (a Lot of)Success in America”, John Gartner uma correlação entre empreendedores de sucesso e os chamados“Hypomaniacs”. Este tipo de perl é obcecado, apaixonado e incansável quando se trata do objetivo

à sua frente. Ele faz o paralelo com a raça de cachorros Border Collies que, apesar de frágil quandocomparada com um Rottweiler, é reconhecidamente a mais inteligente e precisa estar fazendo algumacoisa o tempo todo, ou literalmente “come a mobília”. POs são hiperativos, apaixonados, estão semprerodando pela empresa, são obsessivos com seu trabalho, sempre “overworking”. Devem ser muitointeligentes, mas são frágeis contra a truculência.

- Pessoas com grande empatia com o mercado alvo: a distinção aqui, segundo Cagan (novamente), éfeita por meio de uma sequência de perguntas para saber se o seu PO potencial consegue se identicare solidarizar com o seu cliente. Tente procurar sinais de infantilização ou da projeção pretenciosa deque ele quer “iluminar” ou trazer luz para aquele nicho de clientes. Isto é especialmente importante emprojetos que são ou serão internacionalizáveis.

- Não traga especialistas de domínio: um PO inteligente consegue entender um domínio novo entre30 e 60 dias. Um especialista de domínio, apesar de tentador para este projeto porque talvez te faça

economizar algum tempo, pode rapidamente se deformar em umconsegue mais aprender porque ele acha que não precisa, ele é oque o cliente. Grandes erros podem advir destas boas intenções.

- Resista à tentação de transformar seus Lead devs e seus Senitrazer seus funcionários percebidos como os “mais competentesdois erros crassos: primeiro vai desguarnecer um anco igualmenHacker, Hustler e Designer e não “ou”) ou vai fazer com que eles, de se sintam miseráveis. Um ambiente sem POs de ofício às vezesprossionais estão salvando o dia, e pelo menos a casa não está chistória é diferente. Provavelmente, em uma simplicação, os POs qpara produtos digitais, mas não são os que eram os melhores eng

- The smartest kids: este perl precisa de neurônios. Sem rodeios,só esse, ele tem que passar na “NO JERK RULE”. Steve Jobs era umtodos os tempos no que tange a product management e era CEO ddo prossional inteligente mas desagregador é alto demais para o

rápido possível. Ser inteligente e se achar inteligente são coisas ache que ele é a cura para a malária e requeira uma carga de gespara o RH.

A boa notícia é que empresas digitais estão cheias de pessoas inteum taco de baseball (no sentido gurado) nos babacas assertivos não têm saco para seguir as discussões com eles. Procure aqueleno deserto”, não de derrota.

- Ética, integridade: qualquer que seja sua visão de ética e valorerepresente bem. No nal do dia, fora restrições de orçamento, eleenvelope da empresa e você vai esperar isso. Uma pessoa com estapontando para o lugar errado pode gerar prejuízos de marca e cu

- Entendimento da empresa e capacidade de comunicação e ar


21/40


falado, seu PO tem que ser um articulador, capaz de conseguir que a empresa colabore, ajude, informee ensine seu time para que seu produto tenha sucesso. Essa é uma qualidade rara, algo como um lídercolaborativo ou algo do gênero.

Onde eles se escondem? Pensei muito se escrevia ou não este parágrafo, mas vamos lá: hora de serfranco. Procure os paradoxos. Se sua empresa é elitista, procure o garoto brilhante que é reprimidopelo seu colarinho azul. Se ela é sexista, procure aquela mulher que tem brilho nos olhos mas escolheudeixar esta briga para outro dia porque é mãe solteira. Se sua empresa é uma ditadura de vendedoresou marqueteiros, ache o último engenheiro. Se sua empresa é de esquerda, procure um liberal. Emresumo, a “antimatéria” do PO é o assertivo truculento. Seu trabalho como líder é destravar potencial,se ele não estivesse travado este PO potencial já seria PO e eventualmente estaria em seu lugar. Lidecom isso. A boa notícia é que este tipo de gente é leal e vai entender o valor do julgamento cuidadosoque você fez.

E como treinar e desenvolver POs? Apesar de focado na prática de gestão/execução de produto, o POdeve também ser um generalista. Ele deve entender profundamente engenharia ágil e ter experiênciaprévia relevante em times ágeis. Sugiro fortemente treinamento formal em CSM e CSPO (ou equivalentes).

A leitura dos livros de Steve Blank, Eric Ries, Alex Osterwalder e Marty Cagan são a base, mas eleprecisa ainda buscar conhecimento em analytics, marketing e nanças. Analytics pode ser endereçadopor literatura (Lean Analytics) e pelo material de treinamento do Google para web analytics. AnalyticsMobile parece ser um mundo à parte e devemos nos aprofundar em ferramentas como Flurry e IDX.Finanças é um domínio por si só, mas ele deve saber o valor do dinheiro no tempo, contabilidade euxos de caixa descontados. Marketing digital também tem diferenças sérias entre web e mobile, maspelo menos o básico de PPC, PPI, PPM, Mail e redes sociais para se relacionar corretamente com o timede marketing, além do marketing de produto, é necessário. Recomendo fortemente o workshop doMarty Cagan (How to Develop Products People Love).

Não existe um desao de gestão de pessoas maior que esse, na minha opinião singela. O ecossistemabrasileiro de tecnologia é ainda cheio de waterfoleiros retardados e os POs potenciais (como aquela cena

do primeiro Matrix, na qual as crianças entortavam colheres) têm quMas se você é CEO, diretor/VP de produto de uma empresa que por ade inovação e desenvolvimento contínuo de produtos nesse node laços, não existe nada mais importante do que isso. Se você agestão silenciosa do seu processo sucessório.

5. Métricas

O mundo de métricas depende um pouco do modelo de negóciosbásico proposto pelo Dave McClure chamado AARRR e que represreferências muito boas são o livro Lean Analytics e, para negócios

Em relação a ferramental web temos, além do Google Analytics, o Kde calor o CrazyEgg funciona bem. Se seu produto é mobile, por odá para passar com o Google Analytics também. É importante prosegmentação de clientes (cohorts, em inglês) para evitar a síndrnúmeros te digam alguma coisa.

Profitability

MRR

ServicesRevenue

CAC

LTV

Revenue

Expenses

COGS

Revenue perEmployee

Expenses perEmployee

Micro- Economics(per customerprofitability)

OverallProfitability

(Accounting)

Profitability perEmployee


22/40


6. Quality Assurance

Garantir a qualidade de qualquer produto mobile é essencial, e por isso QA é uma prática imprescindívelpara o desenvolvimento de produtos digitais. A agilidade prega que os testes sejam realizados a todomomento, como forma de validar as hipóteses que estabelecemos. Em mobile, especicamente, o QA éainda mais crítico. Isso porque é importante fazer tudo o que for possível para que um erro não apareçadepois que o aplicativo já estiver disponível na App Store. Neste sentido, todos os testes, sejam unitários,funcionais ou de integração, devem ser feitos em números adequados para garantir a qualidade.

7. Growth Hacking e Product Marketing

Neste momento, você está buscando tração para seu produto. Então, terá que utilizar seu orçamentode marketing com sabedoria. A palavra-chave é que toda campanha tem que ser medida, tem que teruma hipótese de negócio relacionada e tem que ter orçamento limitado. Com o resultado medido decada campanha, você monta um portfólio iterativo e continuamente otimizado de apostas que devemaprender com as ações anteriores.

Para cada tipo de modelo de negócio você tem ferramentais mais adequados. Mas em uma visão geral

temos:a) PPC, pagar por click em redes sociais como LinkedIn ou buscadores como o Google. Vale estudarcomo funciona a questão de remarketing (marcação do cliente e uso de peças direcionadas);

b) PPM, banners e conteúdo;

c) Redes sociais, ações de engajamento orgânico via conteúdo e promoções de posts no Twitter,Facebook e outros;

d) Marketing de conteúdo: pode fazer muito sentido ter um blog, um canal no Youtube e uma presençaforte no Pinterest. O sucesso neste caso é proporcional a três fatores: a utilidade, a qualidade e o quãoinusitado é o conteúdo.

e) SEO e SEM: otimização de mecanismos de busca são importantes tanto para buscadores quantopara as app stores. Entender os algoritmos é chave;

f) Para mobile temos duas modalidades principais: ou você cominteligência da empresa para posicionar seus anúncios como JAMPou faz isso você mesmo;

g) Viralidade: gosto muito do Neil Patel e do material que ele prodblog Quicksprout;

h) E-mail marketing: ferramentas como Mailchimp podem te atend

i) Força de vendas: ferramentas como o Pipedrive ou Salesforceespecíca sobre o que funciona no seu setor.

8. Cultura e Organização

Além da questão direta de como implementar uma estrutura mato tema central aqui também é Cultura. Se não eliminarmos a culturprodutos. Denidos os papéis, existe uma problemática de desenvotreinamento e mentoria continuada é chave. Essas pessoas, além doutra estrutura ortogonal que organiza conhecimento e participan(capítulos ou áreas). Isto pode ser tão amplo como juntar toda aMétricas e Marketing de Produto em grupos ortogonais aos timesituação. Podemos simplicar em alguns temas:

- Papéis e responsabilidades;

- Capacidades e habilidades;

- Cultura de inovação (pessoas podem errar?)

- Estrutura organizacional (dedicada, multidisciplinar, “empowered

A maturidade dos times e das empresas pode ser medida pelas pepara de perguntar “o que fazer” e “como fazer” e vê que a perguntesteja começando a entender a extensão da t rajetória do que igno


23/40


Temos um ecossistema de engenharia de software de primeira linha (pequeno, mas de classe mundial),temos investidores maduros que entendem como ninguém como lidar com volatilidade e temos ummercado grande e quase virgem.

Nosso calcanhar de Aquiles é uma incrível incapacidade de entender como se faz produtos digitais,como ciclar rápido e produzir coisas como o Whatsapp, o Netix e o Google Glass ou como mantertimes realmente multidisciplinares trabalhando de forma ótima durante 24 ou 26 meses até produzirprodutos que as pessoas amem. O desao é enorme, mas o prêmio também é.

9. Governança, portfólio e grooming

Este tema é também bastante complexo. O trabalho de “portfolio grooming” tem que ser complementadocom ciclos de inspeção e comunicação na estrutura de produto da empresa e mais acima, nos níveis dediretoria e board. Esse processo de grooming tem algumas sub-práticas principais:

- Avaliação de ativos digitais e intangíveis;

- Innovation Accounting: foco em aprendizado validado e tração;

- Gestão e otimização de portfólio e alocação de recursos como uma startup (rounds);- Orçamento para novos produtos;

- Gestão do burn rate e portões periódicos de avaliação de decisão de investimento;

- Reuniões semanais e mensais com os POs e PMs e trimestrais com a diretoria e board;

Mas, enm, qual a diferença entre projeto e produto?

“Um produto começa quando um projeto termina”: essa frase resume muito bem a diferença entre osdois conceitos, mas vamos voltar um pouco no tempo para explicar com mais detalhes. Já falamos umpouco no início desse livro que projetos são abordados de maneira “waterfall”, ou seja, só se seguiapara a próxima fase quando terminava a anterior. Esses projetos demoravam muito tempo até ter algumcódigo disponível. Era necessário passar por fases de requisitos e design que muitas vezes demoravam

meses e geravam muito “papel”, material que tentava antecipar tque maneira. Depois do código implementado, ainda tínhamos asquando entrava em produção, muitas vezes o projeto não atendia

Esse problema tinha duas causas principais: ou demorou muito pou o projeto não previu determinado cenário. Resumindo, o nívesurgimento do movimento ágil, adotamos mais agilidade no desenão deveria car preso a vários processos que só faziam o deseburocrático.

O ágil trouxe uma nova abordagem aos projetos, passamos a entreaumentou consideravelmente. Entretanto, uma coisa ainda nentregando softwares que realmente agregavam valor ao cliente

É essa a pergunta que a abordagem de produto que defendemmuitas referências sobre o assunto, praticamos, aprendemos e chede produto o que interessa é entregar software em produção, rápid

seu stakeholder.Um produto digital só começa quando entra em produção, pois é apcolher dados e ver qual direção os clientes apontam para seu avaproduto em produção o quanto antes, e a fase de projeto deve ser a Google e todas as gigantes do mundo digital trabalham dessa manque elas apresentam. As entregas de projetos muitas vezes não sãpor essa falta de métricas e testes.

Os projetos costumam ter início, meio e m, ou seja, uma visão depode acontecer no meio do caminho. Os produtos, diferentemenCada avanço do produto é baseado em muita métrica colhida de spara dizer a direção que o produto deve tomar do que as pessoas


24/40


Enquanto o escopo de um projeto é xo, o escopo de um produto é variável. Enquanto no projetonormalmente você dene qual time trabalhará, quanto você vai gastar e em quanto tempo ele estarápronto, em um produto a visão é de longo prazo. O ideal é ter um time trabalhando e evoluindo aqueleproduto pelo tempo que o produto existir. Costumamos dizer que em software só conseguimos controlarduas dentre as variáveis tempo, custo e escopo. Se não quisermos abrir mão da qualidade, é precisovariar o custo ou o tempo de entrega.

Por m, vale lembrar que um projeto ca pronto em algum momento. Isso não acontece com um produto,que está sempre em evolução. Melhoramos, adicionamos features, vemos que determinada função nãoé adequada e assim vamos tornando um produto cada vez melhor. A evolução é constante.


25/40


Atualmente, os produtos digitais são bem representados por aplicativos mobile. Isso porque essa árease tornou imprescindível para qualquer negócio digital. Em 2016, faz 10 anos desde que zemos nossoprimeiro projeto mobile. Neste período, passamos pelo surgimento do smartphone, pela criação doiPhone, pela transformação do touchscreen em regra e agora estamos vivendo a internet das coisas, osurgimento dos wearables e nos dando conta de que o mobile está comendo o mundo. Essa trajetórianos proporcionou muitos aprendizados interessantes.

Começamos desenvolvendo para WAP (Wireless Application Protocol), em um longínquo 2005, epassamos pelo web mobile adaptativo antes de chegar nalmente aos aplicativos mobile e designresponsivo. Também aprendemos, considerando nossa expertise em e-commerce, que a experiênciamulticanal era uma demanda importante, e por isso criamos a CloudRetail, que tem o objetivo de oferecera melhor experiência mobile para o varejista.

1. As práticas

A partir dessa experiência, chegamos à conclusão de que nove práticas são essenciais emdesenvolvimento mobile. Nós já falamos sobre elas em um capítulo anterior: engenharia ágil, porque é omodelo que mais funciona para entregar o produto certo no tempo certo; UX, porque é preciso entendera experiência do usuário para ter sucesso com um aplicativo mobile; descoberta de cliente e produto,porque antes de começar você precisa validar o problema que seu cliente quer resolver, o tamanho domercado e que tipo de produto você precisa; execução de Produto (ou BML – Build, Measure e Learn),pois é preciso traduzir a visão e a estratégia em hipóteses e depois em funcionalidades que serãocolocadas no seu aplicativo, com uma visão mais geral e estratégica; growth hacking, porque vocêtem que buscar tração para seu produto e usar seu orçamento de marketing com sabedoria; métricasporque toda campanha tem que ser medida, tem que ter uma hipótese de negócio relacionada e temque ter orçamento limitado; cultura e a organização da empresa, que devem estar alinhadas com agovernança. Se não eliminarmos a cultura do medo e organizarmos a estrutura das equipes considerandoconhecimento e responsabilidades, não conseguiremos fazer produtos. E o trabalho de governança, ou“portfolio grooming”, tem que ser complementado com ciclos de inspeção e comunicação na estruturade produto da empresa e, mais acima, nos níveis de diretoria e board.

Por m, em mobile, especicamente, o QA (Quality Assurance) torna-sfazer tudo o que for possível para que um erro não apareça depois

na App Store. Neste sentido, todos os testes, sejam unitários, funfeitos em números adequados para garantir a qualidade.

2. Os papéis

Para garantir que essas práticas funcionem, precisamos de um Pestratégica e geral do produto organizando o backlog e o time eanterior; um Scrum Master, que garante que o framework scrum spráticas e as regras de um time ágil estejam ocorrendo, além deencontre e garantir a governança adequada para o cliente; um Devnuvem infraestrutura do projeto; e um ou mais Devs, que vão efeAlém destes, são importantes também o prossional de QA (Quanome diz vai garantir a qualidade do aplicativo por meio dos testdevices; o de UX (User Experience), responsável pelo design e por gseja excelente; e o Growth Hacker, que vai cuidar da aquisição, ativa

e fazer o marketing do seu aplicativo.

Esses sete papéis são complementares e devem trabalhar juntos diárias e frequentes inspeções e validações de hipóteses geram apreo aplicativo certo.

Práticas, Papéis e PlataformaCapitulo 6

PO QA DevsUX Gro

Hac


26/40


3. A Plataforma

Por m, a tecnologia! Para garantir a qualidade e a funcionalidade de um app mobile, é preciso contarcom um arsenal de ferramentas. Aqui na Concrete Solutions desenvolvemos uma plataforma aberta dedesenvolvimento de aplicativos móveis (OMADP), que junta o que consideramos de melhor em cadaárea com módulos desenvolvidos na Concrete. A plataforma está um pouco resumida nos quadrosabaixo. Lembrando que somos uma empresa agnóstica e não temos preconceito com nenhuma dastecnologias.

Entretanto, sempre é bom lembrar que fazer o produto mobile certo do jeito certo é uma trajetória deaprendizado dinâmica, aprendemos todos os dias. Além disso, o cenário mobile mundial muda a cadaperíodo, com novidades a qualquer momento. É por isso que consideramos que a forma adequada defazer mobile hoje pode mudar amanhã, e estamos atentos a qualquer fator que altere o que aprendemos.

Jenkins, Maven,Bots, cocoapods,

GITMobrelease,

EstaçãoMacOS de CI

Junit,Specta,

Cucumber,calabash,

TestCloud,estações de

QA IOS,Android

Newrelic Jmeter,

crashlitics, GA

Jmeter

Integraçãodeployment

contínuo,controle de

dependências,build

automatizado,versionamento

Dashboard, Relatórios, análise de “causas raiz”, indicadores

Testesunitários

Testesfuncionais

automatizadosem emuladores

e devices

Testes deperformance e

robustez

Testes deintegração

Jira,

greenhopper,TS, Google docs,confluence

Invision

Parse,(MBaaS),

GA, ADX,

Google tagmanager,Crashlitics,

Newrelic

Hu

AdxDiAp

Dashboard, Relatórios, análise de “causas raiz

Gestão deportfólio,

Gestãode produto,Governança

Productdiscovery

Monitor:Conversão,

Crash,Atribuição,

performance

AqAtRetAp

opti


27/40


Nos últimos anos, o movimento ágil foi abraçado com grande interesse no Brasil, e agora começa aencontrar desaos mais complexos relacionados à implantação de ágil em escala. Grandes escalas

trazem consigo a necessidade de organizar novas estruturas de produto, com mudanças radicais decultura e governança, o que vai ser um desao de grande complexidade para os próximos cinco ou dezanos no Brasil corporativo.

Dimensão econômica

Acredito que estamos passando por um momento de esgotamento de um modelo competitivo noBrasil. Recentemente, Luis Stuhlberger pontuou que a carga de tributos governamentais subiu 15%sobre o PIB desde a Constituição de 1988, tendo sido canalizada para distribuição de renda de um ladoe nanciamento subsidiado de longo prazo no outro. Este modelo gerou algum crescimento econômicorelacionado ao aumento de consumo, mas se esgotou e parece que teremos agora que sobreviver aum ajuste de contas públicas associado a uma tentativa de reativação do mercado de crédito de longoprazo privado.

Os efeitos deste modelo econômico geraram um cenário de estagação que poderá levar vários anospara se desfazer. Questões como a diculdade do reequilíbrio scal, a iminente quebra do mercadoimobiliário (como descrito pela pesquisa da Empriricus Research, devido ao esvaziamento da cadernetade poupança como lastro do nanciamento e o paradoxo da impossibilidade de aumento do valor dataxa referencial) nos levam a uma a nálise nada otimista dos próximos anos.

Dimensão competitiva

Este modelo competitivo com grande participação do Estado, seja na matriz de nanciamento ou noestabelecimento de políticas de proteção regulatórias e tarifárias, se esgota ao mesmo tempo em queenxergamos uma enxurrada de incumbentes e players estrangeiros estabelecidos em áreas comomídia (Google), economia do compartilhamento (UBER, EasyTaxi, AirBnb), nancial technology e nancialservices unbundling (Paypal, Nubank).

Usando a frase célebre de Marc Andreessen, “software is eating the world” e sua atualização feita por BenEvans, “mobile is eating Software”, como prefácio, o que acontece com nossa capacidade competitiva

no cenário de estresse descrito acima se não sabemos fazer softw

Se precisamos reagir com agilidade a alterações no cenário edigitalizando, uma hipótese é que para competir no ambientorganizações de aprendizagem, como disse Peter Senge. Se isto foa competitividade seria medir a distância que estamos da concorrque, sob essa ótica, estamos em algum lugar como:

a) 70 anos de distância, se medirmos o tempo entre a gênese do V

b) 48 anos, se levarmos em conta quando foi publicado o artigo “CEscala?”, de W Royce, que é a base para a metodologia waterfall q

c) 15 anos, se levarmos em conta o Manifesto Ágil.

Proposta

Uma das diculdades para analisar o DNA do Vale do Silício é seu na criação de unicórnios (empresas de USD 1 bilhão), e não em e

euforia inicial, livros como The Lean Startup são só “para ciência”, que sem muito esforço tenhamos a sensação de uma epifania.

Juntando as peças, a hipótese simplicadora que trabalhamos é qquatro fatores principais que podem inuenciar a competitividade baseado em Venture Capital e amplas possibilidades de “saíManagement e OKR (Objectives and Key Results).

A assertividade da proposta não é o objetivo. Ela é só uma soluçãoum processo de melhoria empírico no sistema que, a longo prazo

Como não podemos fazer muito sobre a estrutura de nanciadiminuição do Estado na economia e sua consequente obliteraçãonanciamento e saída no futuro próximo, devemos focar nos outroda Concrete Solutions é desenvolver produtos digitais de sucess

“Silicon Valley is coming”Capitulo 7


28/40


indireto de mudança cultural. O hacking cultural causado pela criação de casos de sucesso dentro dascorporações, quando associado a um apoio executivo claro, pode criar um gradiente de mudança a ser

perseguido internamente pela organização cliente.

Hoje, na Concrete Solutions, temos um framework amplo de abordagens iterativas e incrementais queendereça Como Fazemos (Scrum), O que fazemos (Lean Product Management) e, mais recentemente,em que escala fazemos (Spotify/Nexus/SPS) e com quais objetivos e métricas ágeis (OKR).

Lembrando que os ciclos de mudança tiveram velocidades muito diferentes e foram afetados pelo

contexto. Scrum tem quase dez anos, Lean Product Management cProduct Management tem cinco e OKR só um. Já falamos bastan

produtos e visão de produtos. Agora, vamos focar um pouco em Á

Ágil em escala

Como é natural, crescemos consideravelmente nestes últimos 15 analterações na estrutura organizacional e emergiram melhoras de upositivamente o sistema, criando um surto de crescimento no seguno crescimento de 165% no ano scal de 2015. Neste cenário, cheuma estrutura ágil de desenvolvimento de software que consiga aorganizada e tenha poucos níveis hierárquicos, sem interferir na qu

Com esse desao, fomos procurar as opções já estudadas peloiniciativas, como essas que foram comparadas por Richard Dolmainfoq.com/news/2014/07/compare-agile-scaling ). A tabela deleScrum of Scrums (SoS), Large Scale Scrum (LeSS), Scaled Agile FDelivery (DAD), Drive Strategy Deliver More (DSDM), Recipes for Scale e, por m, a que mais nos interessou, chamada de “Spotify Mooutros seis modelos propostos têm uma teoria bem fundada, masserviu de inspiração foi o modelo do Spotify, que vamos explicar e

Assim que começamos, nossa prática era baseada em times de enga um sócio. Neste experimento, o papel de Product Owner (dono dclientes. Oferecíamos o time multidisciplinar e o cliente coordedesenvolvido. Entretanto, a falta de uma estrutura de produto foacabou se tornando um desao, porque sobrecarregava o sócio quealém de desempenhar o papel de Scrum Master. Neste período pcom algumas referências de produto e chegamos à conclusão dede produtos, não apenas a organização de times multidisciplinarestrabalhar com ele dentro do time. Passamos, então, da prática de e


29/40


30/40


31/40


cada PO, são cerca de 80 pessoas abaixo de um PM. Na estrutura mencionada acima, a entrada de umHead de Produto permitiria que a prática tivesse em torno de 16 product owners e consequentemente

até 160 pessoas. Entretanto, destacamos que o número de dezesseis times abaixo de um Head deEngenharia pode ser um pouco alto, o que ainda não foi validado. Vai depender do nível de uênciade cada time, de quão bem funcionem os Chapter Leads e do nível de heterogeneidade técnica dosprodutos sendo feitos nessa prática. Entretanto, nosso cálculo nos leva a um limite teórico de 80 a 160pessoas por prática, o que na Concrete equivale a um total entre 300 e 500 pessoas nas quatro práticasatuais.

Quando chegarmos a esse número será a hora de criar novas práticas, novos sites e as guras de diretorde produto, que será o responsável por todos os PMs, e do diretor de engenharia, que cuidará dosheads de engenharia. Acreditamos que o último nível seria a criação de um VP de produto, anal nossapreferência é manter poucos níveis hierárquicos.

Fluência dos times

Com base na evolução e aprendizado dos nossos próprios times, chegamos a um modelo de maturidadeque se aplica na companhia como um todo, time a time, para tentar manter a garantia de qualidade.

Chamamos esse modelo de “4Ps”: Práticas, Papéis, Plataforma e Produto. Já falamos de cada um dessestópicos anteriormente, mas agora a intenção é mostrar como avaliar a uência em cada um deles.

Para medir o nível de uência dos times, aplicamos o modelo de maturidade de forma periódica. Primeiro,avaliamos os papéis. O time tem todos os papéis? Os papéis têm níveis de senioridade adequados? Éum questionário simples e fazemos quase que intuitivamente. Depois, é hora de avaliar se as práticasestão sendo cumpridas, e práticas e plataforma são acertadas ao mesmo tempo, em paralelo. Anal,não tenho como testar sem saber fazer integração contínua, deployment contínuo, etc. Todas essasvariáveis geram uma nota, ou um nível de uência, que vai de zero a quatro.

Mas é claro que cada membro do time é avaliado de forma individual, considerando também o modelode maturidade. Dois exemplos que valem a pena serem ressaltados são a avaliação do Product Owner,que passa por seis “áreas”, e do Scrum Master, avaliado em cinco instâncias. Enquanto o primeiro émedido pela uência na área de domínio, marketing & analytics, UX e engenharia, além de ágil e lean,

Práticas

EngenhariaÁgil

CulturaOrganiza

QA

Descoberta de produto/cliente

Métricas

GovernançaPortfólioGrooming

UserExperiênce

Papéis

Growth

Hacker

QualityAssuranceProfissional

ProductOwner

UserExperienceProfissional

DevOps Scrum

Master

Coder

Produto

Engenhar

Remoção dImpedimen

Lean

Engenharia UX

PO

Área deconhecimento

Marketing UX&

Analytics

POÁgil


32/40


o Scrum Master é avaliado considerando engenharia, capacidade de facilitação do framework Scrum,remoção de impedimentos e governança e política, além, é claro, de ágil.

Desaos

Ainda estamos conversando bastante sobre as atividades de sincronização e gestão da interdependênciade projetos. Anal, temos clientes com portfólios de produtos web e mobile, que misturam times, POse Heads de engenharia. No nível em que estamos, ainda conseguimos manter muitas conversas “oneto one”, tanto entre os mesmos papéis quanto entre os gestores. Mas ao chegar em um número maiselevado de pessoas pode ser que esse esquema não funcione mais.

Também temos uma questão importante de cultura. Quando os capítulos são menores é mais fácil passarconhecimento por meio de Hangouts, eventos, conversas informais e até em happy hours. Conformeo time vai crescendo essa facilidade vai diminuindo

Date post:	05-Jul-2018
Category:	Documents
Upload:	ju-weiss
View:	219 times
Download:	0 times

Silicon Valey is Here

Documents