finito

Tag: JTBD

  • A Caixa de Ferramentas do PO

    A Caixa de Ferramentas do PO

    Não são poucos nem triviais os trabalhos do PO. Para inspirar e orientar o desenvolvimento de produtos ele precisa de boas ferramentas. Estamos cheios delas. E isso não é necessariamente bom. Sobram sobreposições e redundâncias. Faltam interfaces para que as ferramentas se comuniquem e possibilitem a construção de uma narrativa lógica e coesa. A organização da caixa de ferramentas do PO dá trabalho¹.Uma caixa de ferramentas bagunçada é uma contradição. Ferramentas devem nos tornar mais produtivos – ágeis de fato. O problema é que vivemos numa era de grandes ideias isoladas e quase herméticas. JTBD, OKR, canvases mil, jornadas de clientes e usuários, User Stories, Job Stories, Value Stories e por aí vai. Existem diversos livros, artigos ou cursos sobre cada uma delas. Mas não são comuns os trabalhos que proponham um conjunto ou, melhor dizendo, um sistema.

    Sistema: para entendermos que o TODO deve ser maior que a soma das partes; Para fazer com que as ferramentas conversem entre si. Como o JTBD troca ideias com um OKR? De que forma eles se relacionam com épicos e histórias? Como eles apoiam a organização e priorização do backlog? Precisamos de um mapa.

    Mapa Rico

    São duas as principais inspirações para a sugestão que segue. A primeira é o Pensamento Sistêmico. Mais especificamente, a Rich Picture proposta por Peter Checkland somada ao DSRP. A segunda fonte de inspiração é o livro User Story Mapping de Jeff Patton (O’Reilly, 2014). Vejamos.O diagrama é formado por três camadas: Bússola, Mapa e Roteiro.

    Bússola: seja dia ou noite, faça chuva ou faça sol, ela sempre nos dá o norte. Em nosso caso, ela sempre lembra as motivações do produto. Motivações, no plural, porque buscamos criar valor para o cliente (expresso no JTBD) e para o negócio (VS – Value Stories). Um GPS sempre ajuda. Aqui ele atende pela sigla OKR (Objectives and Key-Results). Você informa para onde quer ir (JTBD + VS) e ele te guia, mostrando a sua distância em relação aos Resultados-Chave. O ‘O’ de objetivo é o elo entre as três ferramentas.  

    Mapa: se estamos falando de um produto ou serviço que será comercializado, faz sentido que o mapa capture toda a jornada do cliente. Por isso temos um cabeçalho identificando o que ocorre Antes, no Início, Durante e Depois da compra ou contratação. A inspiração aqui é o Service Blueprint. Na primeira linha desenhamos as ações do cliente na forma de um fluxograma. Na linha inferior colocamos o trabalho interno – tudo o que precisa ser feito para que o cliente tenha aquela experiência. Se você registrou Atividades-Chave em um Business Model Canvas, por exemplo, é nessas duas linhas que elas serão desenhadas. Se você identificou Recursos-Chave no Canvas, faz sentido explicar quando e onde eles serão necessários. Daí a terceira linha do mapa. Jeff Patton é econômico nesta camada, mas não desmerece o seu valor. Tanto que a trata como o Backbone (espinha dorsal).

    Roteiro: ou, para ser menos direto, Roadmap + Product Backlog. Porque um backlog orientado pelo negócio, pela experiência do cliente, faz muito mais sentido do que uma fila indiana. Quando alguém vê um item², entende não apenas o que ele é e deve fazer mas também o seu propósito. O contexto está dado: onde e quando aquela função ou atributo é necessário. A posição vertical dos itens indica prioridades. Quanto mais alto, maior a contribuição do épico/história para a realização dos resultados descritos no OKR. Mas não ficamos só nisso. Em cada item devemos registrar o seu valor³. E, oportunamente, também o seu custo. As linhas divisórias do roteiro são traçadas em outro momento, quando já temos razoável noção do que precisa ser feito. Podemos dizer que a primeira linha representa o MVP/MVS (Minimum Viable Product / Solution). O importante é que cada linha (cada versão do produto) se comprometa com resultados. Daí o lembrete ou detalhamento de OKRs no canto direito do diagrama.

    O mapa é uma ferramenta que pode acomodar, como no exemplo acima, outras ferramentas. Não é uma colcha de retalhos. É um sistema. Ou, caso queira, é uma história que deve ser contada de forma colaborativa. E iterativa. O mapa evolui na medida em que navegamos entre os trabalhos de descoberta, exploração, desenvolvimento e entrega.No exemplo acima tivemos que colocar o roteiro no lado direito. A bússola (post-its no topo e anotações no canto) foi junto.

    As informações (quem, o que, quanto, onde, quando) descobertas, o conhecimento (como) desenvolvido e a compreensão (por que) alcançada com o apoio das ferramentas citadas são essenciais para o desenvolvimento de um produto. O Mapa Rico pode ser a principal ferramenta de um PO. Mas, claro, não pode ser a única.

    Notas

    1. E isso justifica, em partes, o intervalo de dois meses desde o último artigo. As sugestões aqui apresentadas foram testadas em uma turma da oficina FDP e com três times do Ateliê de Software, uma empresa que é 100% Ágil há dez anos. Agradeço ao pessoal do Ateliê pela oportunidade e acolhida. E ao Will pela foto.
    2. O diagrama indica quatro formatos possíveis para itens: Épicos, US – User Stories, JS – Job Stories e UC – Use Cases. Poderia ter citado protótipos também. Não são variações do mesmo tema. Cada formato captura informações e perspectivas diferentes. Vale sempre lembrar: só a variedade absorve variedade. E existe coisa mais variada do que desejos, necessidades, restrições e caprichos de clientes e usuários?
    3. Se você pretende utilizar um conjunto da sequência de Fibonacci ou escalas mais simples não importa. Importante é que isso seja pensado e negociado. E que a régua definida para o Valor seja a mesma utilizada na aferição dos custos. 
    4. Rectilinear, de Stuart Caie, ilustra este artigo.
  • O Problema do Cliente

    O Problema do Cliente

    Hoje o problema não é nosso. Mas a gente quer que seja. Pretendemos desenhar um produto ou serviço que melhore a vida de um cliente. Por onde devemos começar? Quais ferramentas podem nos ajudar? Quais hábitos e mal entendidos colocam em risco a nossa empreitada?Ideias não faltam. Estamos cheios de hipóteses. Mas elas não são um bom ponto de partida para o desenho de um novo produto ou serviço. Por estranho que pareça, é preciso dizer: antes da solução deve haver um problema. A formulação de boas hipóteses requer o entendimento e a definição do problema. Necessidades, tendências e ofertas concorrentes são estopins tradicionais. O mundo está cheio de exemplos de como essas fontes de inspiração podem ser frágeis e traiçoeiras. Microsoft Zune, os óculos do Google, Segway e a Antarctica Sub Zero não me deixam mentir sozinho. Lá se vão vinte e cinco anos desde que a Teoria JTBD (Jobs to be Done – Trabalhos a Executar) foi apresentada¹. Parece que agora ela pegou. Em que ela é diferente dos estopins tradicionais? No olhar de fora para dentro. Na preocupação com o entendimento de um contexto, causas e motivações. Entender o porquê, num primeiro momento, é mais importante do que elucidar quem e o quê. JTBD não são inventados. Nós os descobrimos. Nesta sequência de artigos mal acoplados eu tenho insistido na palavra descoberta. Na conversa anterior eu mostrei como a ferramenta enxuta 5 Porquês, devidamente amparada em modelos sistêmicos, nos ajuda a descobrir a verdadeira raiz de um problema. JTBD é uma teoria e ferramenta mais específica. Mas parte do mesmo princípio: precisamos descobrir – esclarecer, revelar uma situação.

    Lavar roupa em casa.
    Tornar menos desagradável a espera no consultório médico.
    Ir do endereço A para o endereço B com conforto, rapidez e sem gastar muito.
    Comunicar o estado de um projeto respeitando o tempo e a inteligência de todos os envolvidos.
    Afastar a filha do smartphone por duas horas consecutivas.

    Ao apreciar um JTBD devemos considerar três dimensões:

    • Funcional: qual é, de fato, o trabalho a ser feito. Aqui sempre temos um verbo – uma ação devidamente contextualizada.
    • Emocional: como a pessoa espera se sentir ao executar aquele trabalho. Ou ao se ver livre dele.
    • Social: como a pessoa quer aparecer. Não leve em conta apenas as questões narcisísticas. Mas não as ignore.

    Completamos o quadro ao listar as principais coisas que o cliente quer e aquilo que ele não quer (receber, sentir, arcar) ao executar aquele trabalho. Essas informações podem ser capturadas na forma de um Mapa de Expectativas. Uma ferramenta que permite que o negócio também descubra o que ele quer e não quer quando fornece determinada solução.Essas fotografias nos ajudam a entender por que um cliente contrata determinada solução e demite outra(s). Repare nesse jeito de pensar: o cliente não compra produtos ou serviços, ele contrata soluções para se livrar de problemas. Nem sempre essas decisões estão relacionadas com aspectos funcionais. Aliás, dependendo do JTBD, a dimensão funcional pode ser a menos importante.

    Isso basta? JTBD é uma varinha mágica que nos leva para o mundo da solução perfeita? Longe disso. Agora é que o trabalho de análise começa a ficar divertido.

    O Mapa de Transformações

    JTBD bem capturados nos mostram o que precisa ser feito. No mapa ao lado eles aparecem no eixo vertical. A dimensão horizontal nos permite brincar com o como: COMO o trabalho será realizado, contratado, precificado, distribuído e suportado. Enfim, neste eixo nós começamos a cogitar alternativas de solução. Vamos conhecer melhor o mapa. Sua origem é um diagrama apresentado no livro Dual Transformation, de Scott Anthony, Clark Gilbert e Mark Johnson (HBR, 2017). Na falta de um nome, o batizei Mapa de Transformações. Ele é composto por quatro áreas.

    A primeira, no canto inferior esquerdo, representa o Core Business – no caso de uma empresa já existente, está aqui o JTBD que ela atende. A segunda área é representada pela seta ADJACÊNCIAS. Ela acomoda outros JTBD. Repare: todos eles compartilham o modus operandi, ou seja, o COMO. Pense na Amazon vendendo livros, brinquedos ou roupas. O JTBD muda. O COMO é praticamente o mesmo.

    A terceira área do mapa é chamada de Transformação A (seta horizontal). Aqui brincamos de reinventar o hoje. Formulamos hipóteses sobre como criar, entregar, precificar, cobrar e suportar determinada solução para um JTBD. A Netflix mudou dos átomos (DVDs) para os bits (streaming). O JTBD é o mesmo: curtir filmes e séries no conforto de nossas casas. A forma de realizá-lo ficou radicalmente diferente.

    Na quarta e última área do mapa somos convidados a criar o amanhã. É a seta diagonal, a Transformação B. Nela contemplamos novos JTBD e novos modelos de operação, comercialização e suporte. Sua intenção é nítida: resolver o que Clayton Christensen chamou de O Dilema da Inovação (MBooks, 2011). Quem fica bitolado, se iludindo com melhorias incrementais numa zona confortável (Transformação A), pode ser surpreendido por um sanguinário e impiedoso cisne negro. A Transformação B, combinada ao jeito Ágil de pensar, come cisnes negros no café da manhã². A Amazon Web Services é um bom exemplo desse tipo de transformação.

    Conclusão

    Essa combinação de três ferramentas (JTBD, Mapa de Expectativas e Mapa de Transformações) nos ajuda a dar os primeiros passos no sentido de descobrir um problema. O Mapa de Transformações facilita a descoberta e classificação de hipóteses. E nos joga na cara a importância de tratar simultaneamente o hoje e o amanhã. Pense em como essa classificação pode ser útil na elaboração de um portfólio e de roadmaps de produtos, por exemplo.

    Quando comecei esta série falei que deveríamos compreender e diferenciar o VALOR PARA O CLIENTE, o VALOR PARA O TIME e o VALOR PARA O NEGÓCIO. Scott Anthony, em outro trabalho (The First Mile – HBR, 2014), fala da tríade da primeira milha. São três perguntas que precisamos responder:

    1. Há um Trabalho a Executar? A quem ele interessa?
    2. A gente dá conta de criar uma solução viável? Esse trabalho nos motiva?
    3. Essa solução cria valor para o nosso negócio? Quanto?

    O próximo artigo, a terceira parte de nosso Checkup Ágil, vai tratar do segundo ponto acima e explicar o que chamo de VALOR PARA O TIME. Na sequência, eu acho que devo sintetizar as ideias apresentadas nesses nove artigos em um modelo.

    Notas

    1. Anthony  Ulwick é o pai e explorador da criança. Clayton Christensen a popularizou através de seus artigos e livros. Do primeiro há este livro gratuito e um Canvas JTBD. Pois é, mais um canvas…
      Do Christensen eu sugiro a leitura de Muito Além da Sorte (Bookman, 2017), que trata só da Teoria JTBD e suas aplicações.
    2. É muito legal ver como o Movimento Ágil é percebido em situações muito distantes do desenvolvimento de software. Em The Social Labs Revolution (Berrett-Koehler, 2014) Zaid Hassan escreve que “O Ágil come cisnes negros no café da manhã”. Ele mostra como o Scrum ajuda ONGs e similares a resolver problemas realmente complexos, como desnutrição, doenças e analfabetismo em regiões paupérrimas ao redor do mundo. São exemplos que ajudam a rebater alguns mal entendidos que pipocam aqui e ali no mundo Ágil. Mais que isso: mostram como o Movimento ficou grande e maduro por causa e apesar da gente de TI.
    3. Apple of StickyNotes é o título da imagem acima. Compartilhada por StephenMitchell no flickr
  • O Mapa de Transformações

    O Mapa de Transformações

    “Mude antes que seja forçado” é um dos mantras mais famosos de Jack Welch. O que está vivo muda – tenta se adaptar – na marra, na sorte ou por querer. Se para melhor ou pior, o tempo dirá; No caso dos negócios, os clientes julgarão.

    A mudança é uma certeza muita incômoda em tempos de tantas incertezas. Existem estratégias e ferramentas mil para a redução dos desconfortos e riscos. Este artigo apresenta uma, o Mapa de Transformações.Com certeza você já viu negócios que se fingem de mortos. Seus sinais vitais – balanços e balancetes – estão normais. Há um vermelhinho ali e outro acolá, mas não é nada que um bom plano de contenção de despesas não corrija. O predador (Amazon, Netflix, Uber, AirBnb, Marfrig, <coloque seu favorito aqui>) circula, cada vez mais próximo. Mas é preferível acreditar no mágico escudo invisível das barreiras de entrada (legislação, cultura) e permanecer quietinho – quase morto.

    Um pouco mais raros, mas não menos folclóricos, são os empreendimentos do tipo “metralhadora giratória sem controle”. Porque esse papo de “controle”, dizem, é coisa vintage. TUDO vira hipótese factível; TODOS merecem ser ouvidos; TODAS as balas devem ser disparadas. Geralmente, um único recurso é escasso: a paciência. E dá-lhe barulhentas saraivadas de experimentos seguidos de meia-volta-volver (pivotagens). No final das contas, na imensa maioria das vezes, registram-se um incalculável aprendizado e prejuízos muito bem mensurados. E só.

    Entre esses extremos circula a grande maioria de nossas firmas. Assustadas, mas cientes ou temerosas daquela bipolaridade.

    E Por Falar em Bipolar

    Nosso mundo, em quase todas as searas e assuntos, anda perigosamente viciado em dilemas. É a vitória do OU em detrimento do E. É a onipresença do cobertor curto, a bandeira dos novos tempos.

    Ao que tudo indica, foi-se a era d’O Dilema da Inovação (Clayton Christensen – M. Books, 2011). Porque o presente – o mercado e clientes atuais – não é mais uma zona de conforto onde podemos pendurar nossas redes. Aliás, será que em algum momento na história das organizações essa zona realmente existiu? Muito antes de Christensen, muita gente falou e escreveu¹ sobre a necessidade de escutar o amanhã – particularmente aquele que vinha soprado por novas tecnologias – sem descuidar do aqui e agora.

    Essa conversa se renova e foge da retórica rasa em Dual Transformation, de Scott D. Anthony, Clark G. Gilbert e Mark W. Johnson (HBR, 2017). Resumindo: ? = A + B + C

    Duas Transformações e um Bebê

    O diagrama ao lado, o Mapa de Transformações, guiará esta breve apresentação. Ele foi surrupiado do livro citado acima, onde é apresentado como “Opções estratégicas para líderes”.

    O eixo vertical representa o QUE a  empresa faz. São os Trabalhos a Executar (ou JTBD – Jobs to be Done, como apresentados no artigo anterior). No eixo horizontal temos COMO a empresa realiza aqueles trabalhos. O COMO são os produtos e serviços, o know-how aplicado e os componentes financeiros (modelos de precificação e cobrança, por exemplo). O quarto de círculo menor representa o núcleo do negócio, o core business atual. As três grandes setas nos ajudam a pensar as transformações viáveis.

    Você espera um exemplo e eu vou te apresentar o Agostinho Carrara, famigerado motorista de táxi. Sua empresa é de um homem e um JTBD só: levar alguém de algum lugar para outro. Agostinho anda p da vida com a concorrência do Uber e afins. E mais p da vida com ele mesmo, por ter ignorado o conselho do Jack. Agora, precisa mudar na marra.

    Agostinho cogita o primeiro caminho (Adjacências) porque adora atalhos. Em outras palavras: ele considera agregar outro JTBD sem mudar nadinha seu modus operandi. “Além de transportar alguém, por que não levar coisas de um lado para outro?” Passado o entusiasmo de dois segundos, repara que entraria em concorrência com seu ex-inimigo favorito, o motoboy. E desiste da ideia, resmungando: “O mar não tá azul e nem pra peixe nas adjacências”.

    Mudar COMO o trabalho é executado é o que fazemos com a Transformação A. Significa reinventar o hoje. E Agostinho viaja nas possibilidades: melhorar o condicionador de ar; nada de funk no rádio, só os 3 B’s da música clássica (Bach, Beethoven e Bezerra da Silva); balinhas sortidas e água gelada; uma cervejinha, talvez (dá pra colocar um frigobar no porta malas?); serviço de agendamento via app ou 0800 (neste caso, a menina tem que ter a voz da Camila Pitanga!). Agostinho viaja e faz contas – com uma única certeza: “como tá não pode ficar”.

    Dezesseis segundos de ânimo renovado e nova ducha d’água fria: com exceção da Camila Pitanga, todo o resto pode ser copiado facilmente pela concorrência. “Preciso mudar o hoje, mas isso não garante o amanhã”.

    Criar o amanhã é a motivação da Transformação B. Além de agregar novas responsabilidades (novos JTBD), Agostinho também precisa mudar o COMO (trabalha, precifica, cobra etc). Ele admira o case da Amazon: “caraca, os caras foram do varejo para serviços na nuvem! E hoje abocanham 30% desse mercado!!”

    “Trocar essa carroça por um SUV bem chique e oferecer passeios por pontos turísticos sem a chatice dos guias tagarelas; Montar um roteiro exclusivo para paparazzis iniciantes e fãs enxeridos- casas, bares e praias dos famosos; o bilhete único do agostinho: táxi, parapente, prancha de surf e 500ml de água de coco”…

    Enquanto o Agostinho sonha, é preciso fechar a equação proposta acima: ? = A + B + C.

    C é de Capacidades. Quais ativos existem hoje e precisam ser aproveitados e replicados em todas as transformações. Não se trata de qualquer ativo, mas aqueles difíceis de copiar. O Agostinho conhece bem os seus: simpatia, criatividade e domínio ímpar dos roteiros exóticos da cidade. Numa empresa menos modesta, ATIVO deve ser interpretado da forma mais ampla possível: posses, patentes, informações, conhecimento, processos e por aí vai.

    Léxico

    Há pistas indicando que “Gestão de Mudanças” está caindo em desuso. O termo “Transição” já aparece aqui e acolá. Não é apenas uma troca de palavras. A Gestão de Transições é mais ampla, entende a Complexidade e abraça o Pensamento Sistêmico². Falaremos em Gestão de Transformações? Não creio. Mas é bom ficar de olho.

    Na seara Enxuta (Lean), o glossário original nos dá três tipos de mudanças: Kaizen (melhoria contínua), Kaikaku (mudança radical) e Kakushin (mudança total). A primeira é condição inegociável de qualquer ser ou sistema que se pretenda viável. As demais, com alguma boa vontade, podem ser relacionadas com as Transformações A (Kaikaku) e B (Kakushin).

    O Mapa de Transformações é uma ferramenta para pensar, uma ferramenta conceitual³. Ele nos ajuda a apreciar nosso portfólio de produtos e serviços de uma maneira diferente – nos ajuda a avaliar melhorias e oportunidades. Ele parte da ferramenta JTBD e a enriquece. Este mapa é uma das 22 ferramentas apresentadas na oficina Design de Negócios Viáveis. (Pegue aqui sua versão em PDF).

    Por fim, 1100+ palavras passadas, me diga uma coisa: você sentiu falta dos termos inovação e disrupção? Sério?

    Notas

    1. E dois caras, diferentes em quase tudo, merecem destaque: Peter Drucker e Stafford Beer. O mundo merecia um debate entre os dois, que tinham “inimigos” comuns: a ignorância e o Milton Friedman.
    2. Não se trata de uma contradição – não estou propondo outro duelo: Gestão de Mudanças X Gestão de Transições. São coisas distintas e, no meu modo de entender, complementares.  
    3. Por favor, me ajude a definir qual é o melhor nome para esse tipo de ferramenta: Para Pensar ou Conceitual? Qual funciona melhor?
    4. Crossroads é o nome da foto no topo, de autoria de Eric Fischer. A imagem do Agostinho foi surrupiada do Sensasionalista.
  • JTBD: Uma Ferramenta para Pensar e Agir

    JTBD: Uma Ferramenta para Pensar e Agir

    Qual é o seu ponto de partida para desenhar um produto, serviço, sistema ou negócio? Dentre várias alternativas, vem se destacando a teoria e ferramenta JTBD (Jobs To Be Done – Trabalhos a Executar). Premissa: a gente não compra produtos ou serviços – os contratamos para realizar um trabalho. A JTBD nos ajuda a estudar e definir esse trabalho. Simples e versátil, a ferramenta é um acréscimo valioso ao seu cinto de utilidades.JTBD foi apresentada por Clayton Christensen em The Innovator’s Solution¹. O conceito já estava por aí, com nomes e formatos variados. Citada em diversos trabalhos², a ferramenta vem ganhando popularidade e novos usos. O último livro de Christensen, Muito Além da Sorte (Bookman, 2017), trata apenas da teoria e ferramenta JTBD. Vamos a elas.

    O desenvolvimento de produtos e serviços, em sua forma tradicional, parte de atributos dos clientes ou das soluções. Tendências, concorrentes, desejos e necessidades entregam os requisitos e parâmetros comuns. A teoria JTBD propõe outro caminho através de uma simples questão: qual trabalho o cliente precisa executar?

    Um trabalho pode ser algo simples como “lavar roupas em casa” ou “tornar mais agradável a espera pelo avião”. Também pode ser complexo como “encontrar uma carreira mais promissora”. Um trabalho pode ser parte de um projeto: “desenvolver requisitos”³. Ou a razão de um projeto: “aprender a tocar violão para animar as festinhas das família” (opa! qual é o verdadeiro trabalho aqui?).

    Dos exemplos acima derivamos duas características fundamentais:

    • Um JTBD sempre expressa o que precisa ser feito, nunca o como; e
    • Um JTBD pode ser apresentado assim: verbo + substantivo .

    Trabalho (O Quê) x Solução (Como)

    Um trabalho não pode ser inventado – ele é descoberto. E é perene e recorrente. O que muda, cada vez mais, são as alternativas para executá-lo – as soluções. Pense, por exemplo, em seu trabalho de “ir ao cinema”. Caminhando, no transporte público, de táxi, bicicleta ou carro próprio são opções. Uber e equivalentes são novos “comos”.

    Repare o jogo de soma zero: no instante em que um produto ou serviço é contratado para executar um trabalho, outro é demitido.

    A correta definição do que precisa ser feito é briga antiga. E cria confusões mil, até onde menos se espera. Gente de marketing (e de análise de negócios) vive replicando um dito um tanto bugado: “clientes não querem brocas de ¼ de polegada, querem furos com ¼ de polegada”. Oras, quem deseja um furo pelo furo? O verdadeiro trabalho (JTBD) talvez seja “colocar um quadro na parede”. Ou, indo mais fundo, “deixar a sala de visitas mais bonita”. O tal furo, em linguagem jornalística, é uma bela barrigada. No desenho de soluções, uma perigosa miopia. Que pode ser curada através de outra ferramenta, a 5 Porquês (5 Whys).

    Há Controvérsias

    Apesar da relativa simplicidade da teoria e ferramenta JTBD, existem interpretações conflitantes. Christensen e Ulwick concordam que, além da parte funcional, um trabalho pode envolver os lados:

    • Emocional: como o cliente/usuário quer se sentir;
    • Social: como o cliente/usuário espera aparecer perante sua patota.

    Quem contrata um iPhone, por exemplo, talvez dê mais valor aos trabalhos emocionais e sociais do que aos funcionais.

    Alan Klement, autor de When Coffee and Kale Compete (PDF gratuito aqui), acha isso tudo uma baboseira. Para ele o trabalho é um só e deve ser definido assim. Klement detona o trabalho de Christensen, citando um caso de fracasso. Neste artigo, muito bom, ele mostra como escrever Job Stories. Este outro, igualmente bom, de Fabrício Teixeira, traça um comparativo entre Job Stories e User Stories.

    Apesar de certo cinismo e dos golpes abaixo da linha da cintura, o debate é bom porque enriquece a ferramenta.

    Ferramenta Multiuso

    JTBD, em sua intenção original, nos ajuda a iniciar o processo de desenho de produtos e serviços. Clayton Christensen, em Muito Além da Sorte (Competing Against Luck), reposiciona a proposta: organizações podem ser desenhadas a partir dos Trabalhos a Executar. Seria uma maneira de derrubar silos e entregar valor de forma mais eficaz e eficiente.

    Scott Anthony, em Dual Transformation, coloca o JTBD como peça chave dos processos de transformação de uma empresa. E mostra modelo e casos de enfrentamento bem sucedido do que Christensen chamou de O Dilema da Inovação.
    (Mais sobre isso no próximo artigo)No FAN eu mostro como a ferramenta JTBD ajuda analistas de negócios em dois momentos: iniciando projetos e desenvolvendo requisitos.

    Na OPA! a JTBD é o ponto de partida para o desenvolvimento de projetos de aprendizagem. “Tocar violão”, “Fazer pão de queijo”, “Administrar Riscos” e “Promover Comunicação Não Violenta” são alguns exemplos.

    Na oficina/lab Design de Negócios Viáveis, JTBD é a segunda ferramenta utilizada. Ela nos ajuda a desenhar um negócio e sua proposta de valor. A partir dela desenvolvemos: Mapa de Expectativas, Mapa de Alternativas, Mapa de Transformações, Matriz Benefício/Custo, Pitch etc.
    (Clique aqui ou na imagem ao lado para baixar modelo em PDF)

    JTBD é uma ferramenta versátil, simples e poderosa. Daquelas que merecem posição privilegiada no cinto de utilidades, sempre ao alcance das mãos.

    Notas

    1. Na edição original de 2003, pela HBR Press. Neste livro Christensen atribui o termo original a Richard Pedi, então CEO da Gage Foods. E reconhece as contribuições de Tony Ulwick, que então chamava a ideia de “outcomes that customers are seeking” (resultados esperados pelos clientes). Ulwick se apresenta como o pai da ferramenta em Jobs to be Done: Theory to Practice (Idea Bite Press, 2016).
    2. Dentre eles:
      • The Innovator’s Toolkit – David Silverstein et al. (Wiley, 2009).
      • Value Proposition Design – Alex Osterwalder et al. (HSM, 2014).
      • Dual Transformation – Scott D. Anthony et al. (HBR, 2017).
    3. Puristas e puritanos deram pulos neste momento. “Um JTBD não pode ser uma tarefa ou atividade”, eles dirão. Meus caros, se a ferramenta funciona nesses contextos, por que não utilizá-la? Vale apenas o alerta: em seu propósito original e quando bem utilizada a ferramenta tem mais valor,  menos concorrentes e poucos cupins, por enquanto.
    4. Beautiful Tools, de THOR, foi surrupiada no flickr para ilustrar este artigo.
  • Uma Aula

    Uma Aula

    Quanta informação cabe em sessenta minutos? De quantas peças é feito o mosaico de uma aula? Quantas pessoas garantem a diversidade necessária? E quantos ciclos de maturação demanda um bom produto? Este artigo compila um punhado de achados e perdidos de um experimento. [videoembed url=”https://youtu.be/bie_FQV-5BM”]Na última quarta-feira (15/mar) apresentei a aula aberta “Design Instrucional e Scrum para Projetos de Aprendizagem”. Foram 205 inscrições e uma audiência média de setenta e poucas pessoas. Sou novato e muito desastrado em transmissões via web. Defasado, sinto uma falta danada de olhar o público. Esse fidbeque que chega aos olhos é imbatível em termos de riqueza – de volume de informações. Se pelo menos eu pudesse prestar atenção no bate papo que ocorre em paralelo. Mas é impossível. Até para o mais mentiroso multitarefa da face da terra. Quando em público, elegemos pontos de referência. Às cegas, nos resta imaginá-los.

    A aula foi projetada para dar uma visão geral da OPA! Oficina de Projetos de Aprendizagem. Ou seja, todas as peças principais de minha proposta deveriam aparecer. A restrição de tempo – sessenta minutos – me obrigou a eliminar uma: as contribuições das neurociências. Menos mal, elas já haviam aparecido em um pequeno artigo. Restaram quatro. E pouco mais de dez minutos para cada uma.

    Fluxo

    A teoria do genial e impronunciável Mihaly Csikszentmihalyi dá cola e sentido para todos os componentes sugeridos. Devemos fazer com que cada aula, independente do formato ou extensão¹, seja uma Experiência Ótima – que ela “siga o Fluxo”.

    Trazendo isso para o contexto da aprendizagem, sugiro um metamodelo citando Charlie “Bird” Parker (“Domine a música; Domine o seu instrumento; Agora, esqueça essa baboseira toda e apenas toque!”) e uma ideia do outro lado do mundo, o ShuHaRi (Abrace, Solte, Deixe Voar).Creio não ter sido muito leviano ao sugerir uma relação destes três níveis com aqueles apontados por Alexandre Magno em “How Creative Workers Learn | Learning 3.0”. Nem ao afirmar, gaguejando, que a aprendizagem 1.0 é puro push enquanto a 3.0 é puro pull.
    (Explorarei melhor essa deixa em futuros artigos).

    Patrícia Segatto: ?Os educandos de minha sala parecem estar no 3.0, pois indicam o que querem descobrir e saber mais… eu procuro seguir esses interesses e altero as aulas pensando na motivação deles. Têm 5 anos de idade.

    Raul Roigsim: @Patricia Segatto, nessa idade não existem bloqueios para atingir o fluxo.

    Saca só o nível da conversa que eu perdi…

    Trabalhos a Executar

    Ou JTBD (Jobs to be Done), teoria que chega aos 25 anos de idade muito bem, obrigado². Eu sei, ela foi concebida para guiar inovações. Mas cai como uma luva em projetos de aprendizagem. Um trabalho (ou tarefa) é bem delimitado: fazer pães de queijo; mapear stakeholders; chutar de trivela. Você entendeu. Cada trabalho pode ser capturado na forma de uma estória: Quem, o Quê, Por Quê. Eu não cito isso na aula, mas o Rodrigo Vasconcelos, do Rio, pegou na hora.

    Design Reverso

    Ou Understanding by Design®. Este modelo nasceu fora do mundo do Design Instrucional. Nos EUA, é mais conhecido por quem trabalha com ensino médio ou fundamental. Tem esse nome – Backwards Design, no original – porque propõe que as avaliações e testes sejam elaborados antes do plano de aula. Pois é, TDD (Test-Driven Development) em outro contexto. O modelo é rico e flexível. Ou seja, serve para projetos de qualquer porte ou natureza. Em minha sugestão, para cada trabalho (JTBD) deveríamos desenvolver três aulas (ShuHaRi). Claro, se a intenção for atender iniciantes, iniciados e experts.

    Scrum

    A entrada é um trabalho; A saída, uma aula. Em Design Instrucional, os processos mais populares são variações do ADDIE (Análise, Design, Desenvolvimento, Implementação e Avaliação). No artigo anterior apresentei minhas justificativas para a adoção do Scrum. Agora tento mostrar que o Scrum não serve apenas para o desenvolvimento, mas também para a condução de uma aula. E que seu cerimonial de encerramento de iterações, as reuniões de Revisão e Retrospectiva, casam bem com o mais conhecido modelo para avaliações de treinamentos, o modelo em quatro níveis de Donald Kirkpatrick. A retrospectiva atende o nível 1 (Reação). A revisão mira os níveis 2 e 3 (Aprendizagem e Aplicação, respectivamente). Sobra o nível 4 (Resultados – ROI). Quem mede isso?

    A pergunta é retórica. A resposta: quase ninguém! Quem vive de vender projetos de aprendizagem, como eu, adoraria conhecer esses números. Mas eles são nebulosos até em projetos de larga escala e alto risco. O que dizer dos projetos de aprendizagem, geralmente mal tratados porque mal aparecem nos balancetes? Nosso desafio: facilitar a medição.

    E por que gastaríamos tempo com isso? Por causa de uma certeza: se o treinamento é bom e aquele conhecimento é de fato aplicado, o retorno tende a ser altíssimo. E não estou falando apenas em cursos para empresas. Se contribuímos para que uma pessoa aumente sua renda, apareça melhor na fita ou “simplesmente” ache seu Fluxo – caramba, qual o valor disso? Aliás, é para isso que estamos aqui, não?

    Notas

    1. Há quem ache que o Design Instrucional só atende demandas de EaD. Confusão gerada por uma coincidência: o DI se tornou um pouco mais conhecido por causa da EaD. Na OPA! não há restrições de formatos ou temas, é DI puro. Atacando o essencial: o desenvolvimento e condução de experiências ótimas.
    2. O JTBD se tornou mais conhecido por causa do trabalho de Clayton Christensen. Seu último livro, Competing Against Luck (HarperBusiness, 2016), é só sobre isso. Anthony W. Ulwick é o pai da criança. E recicla suas sugestões em Jobs To Be Done: Theory to Practice (Idea Bite Press, 2016). Repito: em todos os trabalhos sobre o tema, o foco é inovação. A aplicação da ferramenta para o desenho de aulas, até provem o contrário, é mea culpa.
    3. spiralling é o nome da imagem de hoje. Por dugg simpson, no flickr.