LEDS UP: FRAMEWORK DE DESENVOLVIMENTO DE SOLUÇÕES E EDUCAÇÃO DO LEDS

"Fale, e eu esquecerei; Ensine-me, e eu poderei lembrar; Envolva-me, e eu aprenderei."
Benjamin Franklin

INTRODUÇÃO E NOSSAS INSPIRAÇÕES

O Leds Up! é um framework educacional para desenvolvimento de soluções. Ele foi construido tomando como base os conceitos e principios que regem as seguintes técnicas de desenvolvimento de soluções e educação: Educação Centrada no Estudante (Sala de aula invertida, do inglês Flipped Classroom e Aprendizado baseado em projeto, do inglês Project Based Learning) Manifesto Ágil, HCD (Human Centered Design) e eXtreme Programming . É importante comentar que sendo um framework, os usuários não precisam seguir todos os passos e ferramentas para executar um projeto. Cada projeto pode executar as etapas e ferramentas conforme a necesidade.

Antes de explicarmos os detalhes do LEDS UP! Vamos apresentar como cada uma das grandes técnicnas nos influênciaram no desenvolvimento deste framework.

EDUCAÇÃO CENTRADA NO ESTUDANTE

Como conversamos no LEDS RULES: DOMINAR O MUNDO COM EDUCAÇÃO acreditamos que a educação deve ser centrada no estudante. Assim, acreditamos que estamos formando Jedis que sabem a sua responnsábilidade no processo de aprendizado e sabem como aplicar seus conhecimentos para melhorar o mundo (Dominar o mundo).

Para alcançar tal objetivo utilizamos ao longo do projeto as seguintes técnicas: (i) Sala de aula invertida e (ii) Aprendizado baseado em projeto. Vocês devem estar se perguntando por qual motivos escolhemos essas duas técnicas? Bem, vamos a explicação:

  • Sala de aula invertida** ensina responsabilidade! (Simples assim): ** Como fazemos isso? Mais simples ainda, os tutores apresentam o caminho da pedras para o aprendiz seguir. O caminho das pedras pode ser um livro, uma tutorial, um bate-papo de corredor ... tudo que faça o aprendiz chegar aonde ele quer. Muitas vezes os tutores deram 30 minutos de "aula" para um aprendiz e falaram .. agora é com você .. tome o livro e estude. Me procure quando tiver dúvidas! Adivinha o que aconteceu? O aprendiz veio com dúvidas muito mais avançadas do que um simples aluno faria na sala de aula tradicional. Em alguns casos, já vi tutor falando: Ih rapaz nem eu sei isso! Bora estudar juntos?
  • Aprendizado baseado em projeto** é uma ótima forma de ensinar duas coisa: (a) habilidades sociais (b) e que vida é simplesmente: "TUDO JUNTO E MISTURADO": ao realizar um projeto o jedi aprende diversas habilidades que são importantes para qualquer um que queira conviver em socidade. Exemplos dessas habilidades são: (a) ouvir e aceitar que a sua opinião não tão boa quanto ao do outro membro da equipe, (b) confiar em cada membro da equipe, (c) saber que cada um tem um papel importante na equipe, (d) saber que cada membro possui uma habilidade que complementa a equipe, (e) comunicação é um dos fatores de sucesso de uma equipe e projeto e (f) trabalhar em equipe é uma arte que sempre precisa ser aprimorada. Em relação a questão que a vida é Tudo Junto e Misturado** isso é expresso de uma forma muito claro no Aprendizado baseado em projeto. Afinal, para fazer um bom e real projeto é necessário misturar diversas áreas em mesmo local. A figura abaixo apresenta o que é um projeto na vida real. É necessário misturar diversas competências e conhecimentos (representado pelas cores) para desenvolver um projeto real e de qualidade.

MANIFESTO ÁGIL

O Manifesto ágil é uma declaração que descreve que a computação, neste caso o desenvolvimento de projetos, deve ser mais humano do que técnico. Esse aspecto humano foi perdido há tempos, na busca de ser uma área extremamente exata. Sejamos humanos e focados em resolver o problema do cliente. Os 4 valores do Manifesto Ágil descrevem esse passo mais humano para desenvolver soluções:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Perceba que os valores do manifesto ágil são elementos chaves para desenvolvimento de soluções inovadoras. Essa soluções sempre pedem boas interações com os individuos do projeto e possíveis mudanças ao final do projeto. Quem nunca passou por isso? Esse manifesto representa o que realmente ocorre em um projeto real. Ao longo desse capítulo iremos explicar como trabalhamos com esses valores.

HCD - HUMAN CENTERED DESIGN

Design Centrado no Ser Humano (do inglês, Human Centered Design) é um processo e um kit de ferramentas que permite criar soluções inovadoras (e.g., produtos, serviços, ambientes, organizaçõese e modos de interação) para resolução de problemas. Essa foi criada pela IDEO.org (uma das maiores empresas de Design do mundo). O conteúdo desse texto foi retirado do Field Guide Human Centered Design.

"É um processo que começa com as pessoas para quem você está projetando e termina com novas soluções que são feitas com precisão para as necessidades dessas pessoas. Design centrado no ser humano tem tudo a ver com construir uma empatia profunda com as pessoas para quem se está projetando; gerar toneladas de ideias; construir muitos protótipos; compartilhar o que você fez com as pessoas para quem está projetando; e eventualmente colocar sua solução inovadora no mundo". (**https:\/\/www.ideo.org\/**)

"A razão pela qual esse processo é chamado de “Centrado no Ser Humano” é que ele começa pelas pessoas para as quais estejamos criando a solução. O processo do HCD começa por examinar as necessidades, desejos e comportamentos das pessoas cujas vidas queremos in uenciar com nossas soluções. Procuramos ouvir e entender o que querem, a chamada “lente do Desejo”. Enxergamos o mundo através desta lente durante as várias etapas do processo de design." (Field Guide to HCD)

O HCD guiado por 3 lentes: Desejo, Praticabilidade e Viabilidade. Essas lentes estão presentes em todo o processo de entendimento do problema e criação da solução.

Utilizamos o HCD por ser um processo\/kit de ferramentas que permite a equipe de desenvolvimento entender o cliente e ganhar a empatia pelo problema e desenvolver soluções viáveis no aspecto economico e técnico. O sentimento de empatia pelo problema faz com o que a equipe deseje fazer o projeto não somente porque foi solicitado e, sim, porque tomaram o problema como se fossem deles. Além disso, se preocupar com a viabilidade técnica e financeira do projeto faz a equipe criar soluções adequadas para as necessidades do cliente.

Essa diferença no modo de pensar e agir é muito importante para a execução e sucesso do projeto. Quando a equipe assume o problema como algo "pessoal", pois eles tem empatia e entendem o problema, a equipe irá resolver o problema da melhor forma possível. Pois agora, o problema também é deles. Repetindo, esse sentimento trás uma grande diferença no gerenciamento e na execução do projeto. Acredite! É verdade! Logo, segue a dica: FAÇA A SUA EQUIPE TER EMPATIA PELO PROBLEMA!

As próximas figuras abaixo apresentam as 3 etapas do HCD sob diferenetes perpectivas: Inspiração (ouvir), Ideiação (criar) e Implementação (entregar).


A Inspiração é dedicada a aprender diretamente com as pessoas para quem está projetando a solução. Para isso é necessário fazer uma imersão nas vidas delas e entender profundamente suas necessidades. A Ideação serve para organizar o que aprendeu na fase anterior, identicar as oportunidades de projeto e prototipar as possíveis soluções. Por fim, a Implementação é a etapa de construção da solução (protótipos e soluções finais) que será levada ao mercado.

Perceba que a imagem acima, apresenta etapas

O que achou do HCD? Gostou? Quer saber mais? Continue lendo o resto do capítulo que iremos explicar como aplicamos o HCD para dominar o mundo com LEDS UP!

Para maiores detalhes sobre o HCD, acesso o material em http:\/\/www.designkit.org\/human-centered-design

XP - EXTREME PROGRAMMING

"[...] o eXtreme programming (XP) é uma metodologia ágil de desenvolvimento de software voltada para times pequenos e de médio porte, no qual os requisitos são vagos e mudam frequentemente.[...]"

O XP tem como valores:

  • Comunicação: é a parte essencial em um projeto. Afinal, essa é o principal meio de transmissão e troca de informação e conhecimento. Faça isso por meio de uma conversa cara-a-cara ou por meio de um quadro branco. Quanto mais simples melhor!
  • Simplicidade: é a chave do projeto ágil. Seja o mais simples e focado no trabalho possível e, assim, entregando o que realmente agrega valor.
  • Feedback: é realizado em todo momento no projeto e com todo mundo. Quanto mais ele ocorrer melhor é para o projeto.
  • Coragem: tenha coragem em mudar o que não está certo em um projeto, seguindo boas práticas de projeto e conduta.
  • Respeito:respeite os seus colegas de time e o cliente. Simplesmente isso.

Esses valores são o nosso guia para o desenvolvimento de uma boa equipe. Afinal, sem uma boa comunicação não há um bom projeto. Um comunicação pobre é a terceira causa de falha de projeto. Veja outras causas de falhas em projetos nesse link. É necessário ter uma comunicação direta e simples. Acreditem, um bom bate-papo é melhor que um email de 1000 linhas.

Ser simples é a chave do sucesso de um projeto e o maior desafio nele. Afinal, pensar em coisas complexas e cheias de tecnologias é fácil. Mas, pensar em solução simples e barata que atenda o cliente é complexo.

O Feedback contínuo é uma poderosa ferramenta para a melhoria continua do projeto. Através dessa ferramente é possível identificar diversos problemas no projeto como, por exemplo, insastifação do cliente ou da equipe com algum elemento do projeto. É necessári encorajar o feedack contínuo de todos presentes no projeto. Sem isso, não há sucesso.

A Coragem e o Respeito são valores que devem ser inerentes em qualquer equipe de desenvolvimento de solução. Todos devem ter coragem em mudar o que está errado no projeto e devem respeitar os membros presentes no projeto.

Em complemento aos valores apresentados, exitem outros conceitos que também são importantes no XP e possuem impacto direto no sucesso de um projeo. A figura abaixo apresenta esses conceitos. Imagens de Freepik (http:\/\/www. aticon.com\/ authors\/freepik) em Flaticon (http:\/\/www. aticon.com) com a licença Cre- ative Commons BY 3.0 (CC BY 3.0) (http:\/\/creativecommons.org\/licenses\/ by\/3.0\/).

O XP propõem que um time de desenvolvimento deve ser coeso, multidisciplinar, auto-organizável, ter um Ritmo sustentável e aplicar Posse Coletiva. Veja a definição desses conceitos:

"Um time efetivamente coeso maximiza os valores do XP: possui maior comunicação por estar integrado, busca continuamente a simplicidade e constrói confiança para ter-se coragem e gerar feedback por meio do respeito mútuo. A multidisciplinaridade, a auto-organização, a proximidade física e a melhoria contínua são características essenciais para um time efetivamente coeso"

"Um equipe multidisciplinar é formada por individuos com competências distintas e complementares. Cada membro complementando um ou mais membros da equipe com as suas habilidades".

"Os times coesos são auto-organizáveis; ou seja, são responsáveis pelo seu próprio sucesso. Não há a necessidade de controle das atividades de cada indiví- duo do time por um gerente de projetos ou um coordenador. A gestão é tão importante que não ca nas mãos de apenas uma pessoa. O gerente empodera o time nas suas decisões e trabalha no macrogerenciamento. O microgerenci- amento está dentro do próprio time; não há ninguém melhor do que a própria equipe para tomar suas decisões de trabalho."

"Ter ritmo sustentável é uma regra criada pelo XP para balancear o desenvolvimento com as demandas do negócio. Todos têm seus ritmos equilibrados: o time XP, o cliente e pessoas envolvidas com o projeto. [...]\_ Produtividade em longo prazo é o ponto-chave aqui. Durante uma semana ou pouco mais, o time consegue produzir mais trabalhando com horas extras. Porém, a longo prazo é inviável, porque o rendimento vai decaindo semana a semana._"

Em resumo: planeja as tarefas de forma adequada para o time sempre volte disposto no outro dia para trabalhar.

"Posse coletiva é uma prática indispensável no XP, pois envolve colaboração, comunicação e feedback. Com a posse coletiva, qualquer membro ou par do time pode implementar uma funcionalidade, arrumar um bug ou refatorar em qualquer parte do código, a qualquer momento. No XP, todos têm a responsabilidade pelo sistema. Isso encoraja cada membro do time a sentir-se responsável pela qualidade do todo. É claro que nem todos saberão sobre todas as partes igualmente, mas todos saberão, ao menos, um pouco de cada parte do sistema."

Utilizamos os conceitos do XP para criar uma equipe de qualidade. Esse é o principal ponto para o LEDS em adotar o XP. Ao longo do texto, iremos explicar como aplicamos esses conceitos.

Todo os conceitos dessa seção foram retirados do livro **Extreme Programming: práticas para o dia a dia no desenvolvimento ágil de software**

LEDS UP! BORA COMEÇAR A DOMINAÇÃO MUNDIAL

O LEDS UP! é compostos pelas seguintes atividades:

A atividade de Warm up é a responsável pela início da construção do espírito de equipe nos integrantes do projeto e da identificação das habilidades individuais dos integrantes. Nessa atividade que a equipe começa a se conhecer.

Após a equipe está aquecida, ocorre a atividade chamada Inception. O objetivo dessa atividade é entender o problema contido no projeto junto ao cliente e, assim, determinar o Produto Minimo e Viável (MVP, do inglês, Minimum Viable Product) e "montar" o Planejamento de como construir o MVP. Ao fim dessa atividade, a equipe sabe as funcionalidades mínimas que devem ser produzidas para atender as necessidades do público alvo do produto. Um outro objetivo dessa atividade é ensinar a equipe a sentir empatia pelo problema do cliente e aprender a desenvolver soluções, utilizando HCD e TRIZ.

Build possue os seguintes objetivos: (i) ensinar a equipe as metodologias e tecnologias necessária para o desenvolvimento do MVP e (ii) desenvolver o MVP. Aqui a equipe aprende, vivência e implemeta os conceitos presentes no Manifesto Ágil e eXtreme Programming.

Em paralelo as atividades supracitadas, ocorre a atividade denominada Avaliação. Essa tem como objetivo medir o desempenho dos alunos ao longo do projeto. Através desta, será possível identificar problemas no aprendizado do aluno e, assim, o tutor poderá reforçar um ou mais conceitos ao longo do projeto. Ao final do projeto o aluno receberá uma nota referente ao seu desempenho.

Da mesma forma que a atividade de Avaliação, a atividade de Gerência de Projeto também ocorre em paralelo. Essa tem como finalidade gerenciar todos os aspectos (e.g., escopo, recursos e aquisições) que estão presentes no projeto.

O Post-Mortem é uma atividade realizada ao fim do projeto. Essa possui como objetivo apresentar as lições aprendidas no projeto e, assim, descrever os fatores de sucesso e não sucesso no projeto. Através do post-mortem será documentar as lições aprendidas e aplicar em futuros projetos.

Warm up: Aquecendo os motores

A atividade de Warm up tem como objetivo: (i) a construção do espírito de equipe, (ii) a identificação das habilidades dos membros presentes na equipe do projeto e (iii) a inserção de novas caracteristicas nos integrantes (caso elas não tenham): Pró-Atividade, Liderança, Empatia pela equipe e pelo problema a ser resolvido, Trabalho em equipe, "Sede" pelo conhecimento e Autruísmo. De acordo com Jeff Sutherland, as melhores equipes do mundo possuem as seguintes características:

  • Transcendência: possuem um senso de propósito além do comum. O objetivo percebido por todos permite que eles transformem o ordinário em extraordinário.
  • Autonomia: as equipe se auto-organizam e se autogerenciam. Essas têm o poder de tomar as próprias decisões sobre como fazer o próprio trabalho e de fazer que tais decisões sejam acatadas.
  • Interfuncionalidade: as equipes possuem todas as habilidades necessárias para concluir o projeto: planejamento, projeção, produção, vendas e distribução. Tais habilidades alimentam e reforçam umas as outras.

Para que os objetivos e as características sejam alcançados as seguintes atividades são executadas:

  • Quebrar o Gelo: dinâmica de grupo para todos se conheçam;
  • Conhecer as habilidades da equipe: dinâmica de grupo no qual todos apresentam as suas habilidades, desejo de novos conhecimentos e identificam no grupo quem pode lhe ajudar a alcançar os seus desejos de conhecimento.
  • Conhecer o mundo da construção de soluções: a equipe teve ter ciência das principais técnicas, filosofias e abordagens utilizadas para projetar e implementar soluções inovadoras. Vale ressaltar que para produzir soluções inovadoras também é necessário ter equipes inovadoras, logo a equipe deve saber como ser inovadora no contexto de trabalho de equipe.

Para "quebrar o gelo" sugerimos a atividade proposta no curso do IDEO.ORG chamada Telefone Visual. A figura abaixo apresenta as etapas da brincadeira. Para maiores informações veja o curso de HCD fornecido pela IDEO.ORG.

No intuito de conhecermos as habilidades dos atuais Jedis, os seus desejos de novos conhecimentos e saber quem dentro ou fora do Leds pode ajudá-lo a adquirir tais conhecimentos realizamos a seguinte dinâmica de grupo:

  • Coloquem todos em roda;
  • Dê um papel e um bloco de post-it para cada um do grupo;
  • Cada membro deve fazer a divisão apresentada na figura abaixo.

  • Solicite que cada um fale quais habilidades ele possui;
  • Solicite que cada um fale quais habilidades deseja aprender;
  • O membro do grupo que tiver a habilidade tonar-se responsavel por ensinar a habilidade para quem está requerendo;

Perceba que assim é possível realizar um mapeamento das habilidades entre os membros da equipe. Com essa informação os tutores e os novos jedis podem tomar decisões sobre o aprendizado da equipe ao longo o projeto. Essa técnica é a mesma utilizada no iniciativa Aceleradora Ágil (um primo distante do Leds).

Para conhecer o mundo da construção de soluções voltadas ao ser humano é necessário que haja uma quebra de paradigma no modo de pensar em cada membro da equipe. Essa quebra de paradigma visa adicionar novas filosofias e visões sobre a arte de construção de solução. Para que isso ocorra é necessário que cada membro entenda a importância dos seguintes conceitos: Liderança, Trabalho de Equipe, Design centrado no ser Humano, Equipe interdisciplinar, Equipe auto-gerenciada, Empatia pelo membro da equipe, Empatia pelo problem do cliente, Cliente faz parte da equipe, Inovação, Qualidade é indiscutível, Ritmo sustentável, MVP e outros termos que envolvem o desenvolvimento de produtos e negócios sustentáveis.

A última etapa do Warm up é dá uma base teorica e filosófica para os novos jedis com o intuito de entender os conceitos supracitados. Para isso o seguinte literatura é apresentada aos novos Jedis:

Perceba que as leituras solicitadas tem como objetivo apenas "abrir a mente" dos novos jedis. Essas leituras não apresentam nenhuma técnica de como gerenciar projetos ou como desenvolver produtos de qualidade. No fim das leituras os jedis devem discutir seus pontos de vista e apresentar isso aos tutores. Normalemente, pedimos uma apresentação em grupo.

Outras leituras sugeridas e descubra como elas podem mudar o seu mundo:

Inception: Esse problema também é meu!

A atividade Inception tem como objetivo entender o problema do cliente e definir as funcionalidades mínimas necessárias para resolver o problema do usuário, ou seja, definir o MVP. A definição do MVP é feita através do trabalho de equipe, no qual todos os membros da equipe tentam entender: (i) o motivo do projeto, (ii) as “dores” do cliente e (iii) a melhor e menor solução para o problema (MVP). o MVP é a menor e melhor solução que podemos oferecer para o cliente que atenda as suas principais necessidades.

A Inception é dedicada a aprender diretamente com as pessoas para quem está projetando a solução. Para isso é necessário fazer uma imersão nas vidas delas e entender profundamente suas necessidades. Essa imerção possibilita a equipe de desenvolvimento e o cliente responder as seguintes questões:

  1. Qual problema eu viso resolver com o produto?
  2. Quem é a pessoa que irá usar o produto?
  3. Quais os benefícios que o usuário terá ao usar o meu produto?
  4. Quais são os produtos que são iguais ao que estou produzindo? e
  5. Qual o meu diferencial do meu produto perante os produtos concorrentes?

Vale comentar que é muito comum que ao desenvolver um produto a equipe de desenvolvimento, e até mesmo o cliente, não consiga responder essas. O não conhecimento das respostas supracitadas torna a equipe menos interessada em desenvolver o projeto, afinal, essa não entende os conceitos básicos do projeto. Dessa forma, a equipe não cria empatia pelo problema em questão e, assim, não se dedicam por completo ao mesmo. O que fazemos?

Para sanar o problema supracitado, torna-se necessário que a equipe de desenvolvimento e o cliente formem um único e sólido time. Esse equipe deve ter um único pensamento sobre o problema e a solução. Para expressar esse pensamento a equipe pode escrever uma frase que respondas as perguntas acima. Um exemplo disso é o template apresentado na figura abaixo.

xxxx

Em muitos casos não é possível preencher o template acima no começo do projeto com 100% de certeza sobre cada lacuna (representada por []). Pelo menos no LEDS, nós nunca conseguimos fazer isso. Se você conseguiu. Parabéns! Essa é a nossa última tarefa do Inception.

É importate comentar que o cliente é peça chave desse processo e é um dos membros mais importantes da equipe e do projeto. Sem a participação dele, não há como ter sucesso no projeto. Logo, o cliente é um membro da equipe de desenvolvimento e ele precisa se comportar como tal. Um dos resultados da Inception é tornar os membros da equipe de desenvolvimento e o cliente um único SER.

A fase de Inception implementa as duas primeiras etapas do HCD: Inspiração (ouvir) e Ideiação (criar). Assim, temos o entendimento dos problemas do cliente e projetamos em alto nível uma possível solução que atende as necessidades do mesmo. Ao fim da etapa de Inception saberemos qual o problema do cliente e a solução adequada. Para alcançar esses objetivos, ao longo da Inception são criados os seguintes artefatos:

  1. Descrição do problema: ter informações sobre o problema o descreva qual o objetivo do projeto, qual a solução do projeto e qual o benefícios do projeto.
  2. Descrição do cliente: ter informações relevantes sobre o usuário da solução, que você vai pensar que é amigo dele de longa data.
  3. Propor uma solução viável (MVP): propor uma solução minima e viável para o problema do cliente.

Ao longo dessa seção, apresentamos como os artefatos serão criados. O item 1 e 2 serão criados na etapa de Inspiração e o item 3 na etapa de Ideiação.

Inspiração: Entendendo o problema do cliente (ouvindo mais e falando menos)

Para realizar a Inspiração é necessário imergir no mundo do cliente. Essa imersão tem como objetivo fazer a equipe de desenvolvimento sentir as dores, as necessidades e os objetivos do cliente e tomar para si essas características. Legal, mas como faremos isso? Por aonde começamos? Qual técnica utilizar? Calma .. vamos responder. :)

Para responder as perguntas acima, o Leds utiliza as etapas de Inspiração descritas no HCD (favor ler o detalhamento de como executar as etapas definidas abaixo no documento original):

  1. Identificação do Desafio Estratégico: é o problema que queremos resolver junto ao cliente. É a questão que norteia todo o projeto. Esse é definido em uma frase que traga um senso de possibilidade. Por exemplo: "Criar produtos de investimento e rendimento que são apropriados para as pessoas que vivem nas áreas rurais". Um bom Desafio Estratégico deve ser: (i) Moldado em termos humanos (ao invés de tecnologia, produto ou funcionalidade de serviço), (ii) Abrangente suficiente para permitir que você descubra áreas de valor inesperado e (iii) Específico o suficiente para tornar o tópico gerenciável;
  2. Avalie o conhecimento preexistente: é bem grande as chances de você e sua equipe saber "alguma coisa" sobre assuntos que norteiam o Desafio Estratégico. Logo, para saber o que sabemos fazemos uma sessão de "O que já sabemos?". De forma uma simples, essa sessão é executada da seguinte forma: (i) os participantes escrevem em post-it alguma coisa que sabe sobre o problema (uma informação por post-it), (ii) os participantes escrevem em post-it alguma coisa que NÃO sabe sobre o problema (uma informação por post-it), (iii) agrupe os post-it em temas. Isso irá ajudar a ter uma visão geral do conhecimento da equipe sobre o problema e também irá ajudar a planejar e executar o métodos de pesquisa, o plano de recrutamento e o guia de entrevistas.
  3. Identifique pessoas com quem conversar: recrutar participantes apropriados e inspiradores é critico. Assim, é importante encontrar pessoas que representem os "extremos". Participantes nos extremos ajudam a desvendar os comportamentos, desejos e necessidades do restante da população por serem mais fáceis de observar e identificar, já que sentem e expressam os efeitos mais intensamente que outros. Ao incluir ambos os extremos e também algumas pessoas entre os extremos, toda a escala de comportamentos, crenças e perspectivas serão ouvidas, mesmo quando a quantidade de participantes for pequena. Incluir a escala completa é importante nas últimas fases, especialmente para construir a estrutura da estratégia e servir de inspiração para brainstorms. O HCD fornece algumas dicas para escolher quem devemos conversar: (i) Um terço dos participantes deve ser composto por “membros ideais”: os bem sucedidos, os que adotam novas tecnologias rapidamente, e\/ou demonstram comportamentos desejáveis, (ii) Um terço dos participantes deve pertencer ao extremo oposto: os muito pobres, os que resistem à adoção de novas tecnologias, e\/ou exibem comportamentos problemáticos e (iii) Um terço dos participantes deve estar entre esses dois grupos: os que os pesquisadores acreditem pertencer “à média”.
  4. Escolhas os Métodos de Pesquisa: após identificarmos as pessoas que devemos conversar, agora temos que entender como esses e seus comportamentos influênciam o contexto que o Desafio Estratégico esta inseriado. Assim, é importante empregar diversos métodos de pesquisa como: (i) Entrevistas individuais, (ii) Entrevistas em grupo, (iii) imersão no contexto, (iv) Auto-documentação, (v) Entrevistas com experts e (vi) Buscar inspiração em novos lugares.

A execução dessas atividades gera um grande volume de informação sobre as pessaos envolvidas, contexto, regras de negócio, projetos simulares e outras informações que devem ser compartilhadas e visiveis para toda a equipe (lembrando que o cliente também é parte da equipe). Ao estar visível a equipe pode em qualquer momento refletir sobre essa. Para atender essa necessidade de compartilhar as informações e torna-la visível para todos o Leds utiliza duas técnicas nessa etapa: (i) Personas e (ii) a parte do Cliente (Customer Segment) do Valeu Proposition Canvas. (Gostamos muito de usar canvas, é um modo simples de resumir as informações, torná-las visíveis e compartilhadas). As próximas seções apresentam um pouco sobre essas técnicas. Então

Utilizando Personas para entender as pessoas

Todo projeto possui um ou mais funcionalidades que atendem a um ou mais objetivos de seus usuários [Pressman]. No entanto, conhecer apenas os objetivos do usuário não é bastante, é necessário conhecer o contexto no qual a funcionalidade será utilizada e também, em alguns casos, o perfil do usuário (e.g., grau de escolaridade, tempo para usar o sistema e etc), confome descrito por Mike Cohn em [**User Stores] e [Sucesss].**

A identificação do perfil do usuário é importante, pois através desse será possível projetar funcionalidades que realmente atenda necessidades dos usuários [**User Stores][Sucess Agile]. Afinal, não adianta criar uma aplicação com um formulário com 20 campos ou mais, que irá substituir o preenchimento de formulário feito em papel, se o usuário não tem tempo de sentar na frente do computador. Simplesmente, a funcionalidade ou o aplicativo não será utilizado corretamente ou não será utilizado [User Stores][Sucess Agile][**TW].

Dentre as diveras técnicas (Extreme Character, User Roles e outras [**User Stores][PRESMAN]), que descrevem o perfil do usuário, o Persona [**User Stores] tem ganhado destaque na comunidade. De acordo com Mike Cohn em [**User Stores]**, o Persona é uma representação imaginaria de um usuário do projeto. Essa representação deve ser descrita de tal forma que qualquer um da equipe do projeto deve ter a impressão ou sentimento que conhece essa pessoa e suas dores. [User Stores].

A descrição do Persona deve responder as seguintes questões:

  1. Qual o nome dele?
  2. Quais são suas dores e frustações?
  3. Qual a sua rotina?
  4. Aonde ela mora?
  5. Qual a sua profissão?
  6. Quais são seus hábitos?
  7. Quais são suas necessidades?
  8. Quais problemas o produto resolve?
  9. Quais objetivos do usuário serão alcançados com o produto?

Ao responder essas perguntas, a equipe saberá quem é o usuário e o que esse precisa e, assim, a equipe cria uma empatia pelo usuário e mantem o foco no que é mais prioritário para cada persona.

Para tornar a discussão sobre a descoberta e descrição das características do Persona mais visual e interativa, a equipe (time de desenvolvimento e cliente) deve realizar dinâmicas de grupo no qual as respostas as questões, apresentadas anteriormente, devem completar o modelo apresentado na figura abaixo. Esse modelo foi desenvolvido por Roman Pichler.

Conforme pode ser observador na figura acima, o modelo para persona é composto por três colunas: Picture & Name, Details e Goal. A primeira coluna a equipe deve adicionar uma foto e um nome para o persona. O nome e a foto podem ser fictícios. Na segunda coluna a equipe deve preencher com as respostas das questões (2), (3), (4) e (5) enquanto a terceira coluna deve ser preenchida com as respostas das questões (6), (7) e (8).

Value Proposition Canvas

O Value Proposition Canvas é uma técnica utilizada para entender as dores, as necessidades, a felicidade e as tarefas de um usuário (lado rosa ... também conhecido com Customer Segment do Model Business Canvas) e propor uma solução (lado verde) que satisfaça ou ameniza as dores e maximiza a felicidade de um cliente. Nesse momento da Inception, vamos apenas utilizar o lado rosa do Valeu User Proposition. Para maiores detalhes sobre como utilizar essa técnica leia [Osterwalder,2014] e acesso o site da metodologia. Na inspiração, somente focamos na lado do rosa. Queremos entender o problema no cliente. FOCO NO PROBLEMA E ENTENDER O CLIENTE.


Perceba que o lado rosa, Customer Segment, do Valeu proposition Canvas permite expressar conceitos essenciais que iremos obter ao exectar a Inspiração do HCD. Afinal, queremos saber quais são as tarefas que o cliente executa (customer Jobs), por qual motivo ele executa essas tarefas (Gains) e quais são as dores que ele sente ao executar essas tarefas (Pains). A Proposta de valor (lado verde) será preenchido na Ideiação.

Ideiação: construindo uma proposta de solução viável e sustentável

Como dito no HCD, a ideiação é a etapa de transformação dos dados e impressões em uma solução viável e sustentável para o cliente. Assim, o objetivo da ideiação é (i) entender os dados, (ii) identificar padrões, (iii) definir oportunidades e (iv) criar soluções viáveis e sustentáveis.

Para alcançar esses objetivo, o HCD define um conjunto de pequenas etapas que devem ser executadas. Essa etapas guiam a equipe de soluções e os interessados para encontrar um ou mais soluções. As etapas são:

1) Reuna os interessados em uma sala: reuna a equipe e todos os interessados em uma sala com bastante espaço nas paredes. Sim, vamos usar as paredes para projetar as soluções;

2) Compartilhar as histórias: distribua post-its e canetas para todos os presentes na sala e solicite que todos compartilhem, em forma de anotações, suas impressões, conhecimentos e sentimentos adquiridos na etapa de inspiração. As anotaçoes devem ser frases concisas que possam ser entendidas por todos. Citações dos entrevistados são bem-vindas. Uma nota em cada post-it. Cada post-it deve ser colado na parede.

3) Agrupar as histórias em temas: após os post-its na parede, o grupo deve agrupar as histórias em temas. Isso é feito da seguinte forma:

  • Econtrar os "preciosos": Cada pessoa escolhe 5 post-its e remove-os para uma área separada (podem ser 3 também). Esses são as jóias.
  • Em grupo, juntar os preciosos em temas (Clusters): em grupo, separe os post-its em "Clusters".
  • Encontre outras pistas (revise os clusters): revise os post-its que sobraram e adicione aos clusters, caso tenham relação com os já existentes.
  • Refine seus clusters: tente deixar o mínimo de cluster que representam o seu "Desafio Estratégico". Minimo de 3, máximo de 5 clusters.
  • Escreva tópicos (headlines) para cada cluster: Descreva uma palavra que descreva o significado do cluster. Exemplos: "Segurança", "Saúde", "Educação" e "Proximidade".

4)Crie frases reveladora (insights): Escreva seu desafio. Escreva as headlines. Pra cada headline, escreva três frases que descrevam porque isso é um problema para os entrevistados\/comunidade (insights).

O que é um insight?

  • Insights são revelações: – coisas inesperadas que nos fazem prestar atenção.
  • Insights extrapolam histórias indivíduais para verdades mais abrangentes.
  • Insights nos permitem ver o desafio estratégico sob outra luz Exemplo de como chegar em um Insight:
  • Observação (feita por um membro da equipe): Fazendeiros baseiam-se em informações de amigos e vizinhos, mesmo sabendo que seus conhecimentos são limitados.
  • Frase (escrita em um post-it): “Se o Agente vivesse fora da minha área, eu iria querer visitar a sua fazenda para ver a produção.”
  • Insight (da equipe): O processo de ganhar a confiança e o compartilhamento de conhecimento acontecem através do ‘ver para crer’

5) Criando áreas de oportunidades: Uma vez que tenha extraido os temas e padrões das coisas que ouviu, você pode começar a criar áreas de oportunidade. O processo de traduzir insights em oportunidades consiste em mover-se do estado atual para o de vislumbrar possibilidades futuras. Oportunidades começam com a frase “COMO PODERÍAMOS ...? (How might we ..?)” para criar um modelo mental que sugira possibilidades." Em grupo, escolham 3 insights, preferencialmente de clusters diferentes. Criem as perguntas não podem ser nem muito específicas, nem muito gerais.

  • Muito específica: Como projetar um cone de sorvete que permita comer sem pingar? Já diz qual é a solução (projetar um novo cone).
  • Muito geral: Como reprojetar sobremesas?
  • No ponto: Como reprojetar o sorvete para ser mais portátil? Fala sobre o desafio mas não subentende uma solução.

5) Brainstorm de novas soluções : agora é o momento de pensar nas soluções. Isso é feito por meio de brainstorm sobre as perguntas "Como Poderíamos ..?". O brainstorm nos dá permissão para pensar de forma abrangente e sem qualquer restrição organizacional, operacional ou tecnológica. Com essa linha e pensamento, que as soluções são criadas. Escrevemos uma seção sobre Brainstorm.
6) Criando protótipos para validar as ideias: tendo com base as ideias geradas no brainstorm é o momento de construir protótipos para que as ideias tornem-se tangíveis, testadas e avaliadas pelos interessados. Um protótipo deve ser barato e feito da maneira mais rápida possível. Não se apague a um protótipo, se precisar destruí-lo faça! Atualmente, devido a natureza de desenvolvimento de soluções do Leds, utilizamos uma técnica chamada Paper Prototyping. Essa técnica basicamente se resume a fazer a simulação da solução por meio de papel. Por qual motivo isso é bom? Simples, é facil, barato e se tiver algo errado .. rasgamos o papel e pegamos outro.
7) Colete os feedbacks: apresente os prótipos para os interessados e colete os feedbacks. Use os feedbacks para melhorar a solução.

Perceba que o finalizar a ideiação a equipe tem condições de preecher as seguintes questões da proposta de valor: (i) Quais serviços ou produtos serão ofertados ? (ii) Quais são os novos ganhos que os serviços ou produtos propostos oferecem ao cliente? e (iii) Quais são as dores que são amenizadas ou mitigadas pelos serviços ou produtos ao cliente?

Além disso, ao final do conclusão da ideiação a equipe consegue responder as perguntas que foram abertas no começo da Inception.

Gerencia de Projetos

  1. Histórias de usuário: um conjunto de "frases" que descrevem as necessidades ou algo que o "usuário" deve fazer para resolver a problema. De uma forma simples, essas descrevem as regras de negócio da solução.
  2. Mapa de histórias: a represetação visual sobre qual a relação de precedencias entre as histórias do usuário. Isso ajuda a planejar por qual história será feita primeira, por exemplo.
  3. Backlog do projeto: o conjunto de histórias de usuário (User Story) categorizadas por grau de importância.
  4. Roadmap de versões:

Identificando as Histórias de Usuário e suas relações

Após o entendimento da visão e do objetivo do projeto, é necessário que a equipe entenda melhor as dores do cliente e indentifique a quantidade mínima de funcionalidades que serão utilizadas para atingir o objetivo. O entendimento de um modo pleno do uso das funcionalidades, e o relacionamento entre essas, será feito através da criação do Mapa de Histórias de Usuário (do inglês, User Story Mapping) [XXX]. O Mapa de Estórias é formado por Histórias de Usuário (do inglês, User Stores) [xxxx]. Através das estórias será possível entender como os usuário irão utilizar o sistema. Tendo as Histórias de usuário podemos criar Backlog do projeto.

Uma História de Usuário, como o nome sugere, conta uma história sobre como um persona utiliza o executa um ação que deve estar presente na solução em desenvolvimento [**User Storie] [Agile Product Management]. Uma história de usuário é composta por um nome, uma breve narrativa, critérios de aceitação e condições que devem ser verdadeiras para que a estória seja completada com sucesso [User Storie] [Agile Product Management]. Além disso, uma História de Usuário deve: (a) descrever uma funcionalidade sob a perspectiva do usuário ou comprador do produto [User Storie] e (b) ser composta dos seguintes aspectos**:

  1. a descrição da estória deve ser utilizada para realizar o planejamento e como um lembrete;
  2. as discussões sobre as estórias devem servir para detalhar os detalhes dessa;
  3. os testes e a documentação detalhada podem ser utilizados para determinar se uma estória foi concluída com sucesso.

Para auxiliar a escrita das histórias, um modelo de escrita simples foi desenvolvido. Veja o modelo na figura abaixo.

O elemento do modelos type of user deve ser preenchido com o Persona, o elemento some goal descreve a funcionalidade (ou objetivo) que o usuário deseja e o some reason apresenta o motivo (ou valor) para que a funcionalidade existe. A figura abaixo apresenta exemplos de Histórias de usuário para um sistema de viagem.

Perceba, na figura acima, que as Histórias de Usuários são curtas e descrevem funcionalidades que são valiosas para o negócio e testáveis. De acordo com Bill Wake [USer Story], uma estória é considerada boa quando essa obdece o INVEST:

  • Independente: uma história de usuário deve ser independente, ou seja, uma história não pode depender de outra estória. Isso ajuda na implementação e na negociação.
  • Negociável: deve ser possível negociar com o cliente a entrega de uma história em um ritmo sustentável para entrega contínua de valor.
  • Valor para o usuário ou consumidor: cada história de usuário deve ter um valor agregado ao negócio do cliente.
  • Estimável: a equipe deve ter noção de qual velocidade é necessária para implementar a história de usuário
  • Small (pequena): deve ser pequena suficiente para ser implementada dentro de uma interação, sem se correr grandes riscos de não ser completada.
  • Testável: a história de usuário deve fornecer informações que seja possível realizar testes sobre essa.

Após identificar as Histórias de usuário é necessário criar o Mapa de Histórias. O Mapa de histórias descreve a relação precedência entre as histórias de usuário, ou seja, qual história deve ser executada antes da outra. Isso ajuda no planejamento da execução do projeto. Viso que deixa visível qual a ordem que histórias de usuários devem ser executadas. A figura abaixo apresenta um exemplo de Mapa de História que fazemos no Leds. As seta indicam a precedência e a dependência entre as histórias de usuário. Por exemplo, a história "RF002 - Atualizar Usuário" deve ser executada somente depois que a história "RF001 - Cadastro de Usuário" for concluída.


O nome das histórias de usuário não seguiram o formato indicado, por motivo de facilitar o desenvolvimento do Mapa de Histórias.

CRIANDO O PRODUCT BACKLOG INICIAL

Como dito em [Scrum nas trincheiras], o Product backlog é o coração do Scrum. O Product backlog é uma lista de histórias de usuário que o cliente deseja. Assim, esse é composto pelas histórias identificadas anteriormente. É importante comentar que esse nessa etapa do planejamento esse é chamado de Product Backlog Inicial, pois ao longo do projeto Histórias podem ser adicionados ou removidas. A figura abaixo apresenta um exemplo de Product backlog.

O Leds, utiliza um modelo de Product backlog que é composto pelos seguintes campos: Categoria, Código, História, Mockup, MoSCow, Precedências, Estimativa e Importância. A Categoria, o Código e as Histórias representam, respectivamente, uma forma de união de unir histórias, identificação da história que é utilizado para auxiliar no controle de execução das histórias na execução do projeto e funcionalidade que deve estar presente na solução. O campo Mockup é utilizado para registrar as interfaces que foram desenvovlidas no momento da prototipação para representar as histórias.

MosCow é uma técnica utilizada para auxiliar na priorização das histórias que são realmente necessárias para a solução. Por exemplo, as histórias marcadas com M (Must have) devem estar presentes na solução e histórias com W (Won't have) não estarão no planajemento da execução do projeto (perfurmaria). Para detalhes sobre a técnica favor acessar esse link.

O campo Importância é utilizado para indicar qual história tem mais valor para o cliente. O preenchimento desse campo é da responsabilidade do cliente. O cliente deve preencher com valores esse campo. Sendo o campo com maior número é o mais importante e o campo com menor valor é o menos importante. O Cliente não pode colocar o mesmo número para duas histórias. Isso deve-se ao fato que ao colocar duas histórias com o mesmo peso, a equipe de desenvolvimento não tem como decidir por qual começar.

Por fim, o campo Estimativa é preenchido pela equipe de desenvolvimento. Essa toma como base os conhecimentos adquiridos na etapa de Inception. A equipe usa o conceito de Pontos de Histórias para valorar e usa a técnica do Planning Poker [Scrum nas trincheiras] para ajudar na discussão sobre as histórias e valorar a história de usuário com os Pontos de Histórias.

DEFININDO VELOCIDADE RELATIVA DO PROJETO

PRODUCT BACKLOG DINÂMICO

Build: Bora Construir!

Os Spikes de planejamento é uma prática utilizada no XP para auxiliar na obtenção do conhecimento necessário para planejar as atividades de desenvolvimento da equipe. Basicamente, o spike é um período de tempo no qual a equipe de desenvolvimento estuda uma possível solução para resolver um ou mais problemas do projeto. (KNIBERG, 2007)

Durante esse tempo de estudo a equipe pode desenvolver um pequeno programa, que não será aproveitado, por exemplo, para entender a tecnologia que será utilizada no projeto é realmente adequada para solucionar os problemas presentes. O Leds utiliza os Spikes de planejamento como ferramenta de aprendizagem. Visto que o aprendiz ao deparar com um problema do projeto utiliza esse período de tempo, chamamos de Sprint de aprendizagem, para procurar uma solução para o problema e refletir se essa é adequada ou não para o solucionar o problema em questão. Os benefícios dessa boa prática são: o desenvolvimento da pró-atividade e senso critico dos aprendizes.

Gerencia de Projetos: Sim .. gerenciamos projetos!

  1. Cronograma macro do projeto: um cronograma macro sobre os sprints do projeto. Isso é últ para realizar o planejamento de entregas e reuniões com os clientes.

Após concluir as atividades anteriores, torna-se possível criar o Product Backlog [XXX] e o Project Model Canvas c [XXX]. O Product Backlog "basicamente" é uma lista contendo estórias de usuário, com suas prioridades (definida pelo cliente) e a estimativa de tempo (definida pela equipe do projeto). O Cronograma Macro do Projeto define as datas de inicio e fim dos sprints e, assim, definindo a datas das possíveis entregas de partes do software. É importante comentar que o Cronograma Macro do Projeto não define o que será entregue em cada sprint e sim, define as data das entregas de alguma funcionalidade.

Ao longo da execução das atividades supracitadas é comum que tanto a equipe quanto o cliente debatam sobre o custo, riscos e restrições e outros assuntos que afetam diretamente ou indiretamente o projeto. Para auxiliar nessa discussão, é utilizada a ferramenta Project Model Canvas [XXX]. A construção do Project Model Canvas ocorrem em paralelo as outras atividades da Inception. O Project Model Canvas é uma ferramenta que permite descrever as principais características de um projeto (e.g., stakeholders, riscos, custos, requisitos e restrições) de uma forma visual e simples. Dessa forma, toda a equipe pode ter acesso, de uma forma simples e visual, a informações do projeto. A figura abaixo apresenta um exemplo de Project Model Canvas. A seção "Gerencia de Projetos: Sim .. gerenciamos projetos!" apresenta os detalhes de como o Leds utiliza essa ferramenta.

Post-Mortem: That is all Folks!

Avaliação: Avaliação? Fui avaliado?

Referências

[Pigneur, 2010] Pigneur, Y.; Osterwalder, A. "Business Model Generation". Prentice Hall,2010

[Thoughtworks,2014] Bonat, A.; Klaser, A, et al."ThoughtWorks Antologia de Software Brasil: Histórias de aprendizagem e inovação".Casa do Código,2014.

[Osterwalder,2014] Osterwalder,A.; Pigner, Y; et al. "Value Proposition Design: How to create Products and Services Customer Want".Willey, 2014.

Técnica de Brainstorm

Brainstorming é um técnica comum, fácil de usar e efetiva. Mesmo assim, é importante seguir algumas orientações para ter um brainstorm melhor. Abaixo estão algumas dicas e também técnicas para quando parecer que há um "bloqueio" para novas ideias.

Regras para um bom brainstorm

  • Adie o julgamento: Não há ideias ruins em um brainstorm. Haverá tempo suficiente para filtrar as ideias depois;
  • Encoraje ideias malucas: Mesmo que pareça surreal, uma ideia maluca pode ajudar uma outra ideia em alguém, mais concreta;
  • Construa sobre as ideias dos outros: quando ouvir uma ideia de alguém, pense "e se..." ao invés de "mas..." para gerar mais ideias e ser o mais aberto possível;
  • Mantenha o foco: Para extrair mais da sua sessão, mantenha suas perguntas "How might we" à vista;
  • Uma conversa de cada vez: Todas as ideias tem que ser ouvidas, então ouça enquanto o outro fala. Espere sua vez e aguarde até que todos estejam ouvindo;
  • Seja visual: Desenhe suas ideias, ao invés de só escrevê-las. Bonecos de palitinho e desenhos simples podem dizer mais que muitas palavras;
  • Pense em quantidade: Tenha uma meta estratosférica - e a ultrapasse. A melhor maneira de encontrar uma ótima ideia é ter várias ideias.

Dicas para um bom brainstorm

  • Escolha um local apropriado
  • Tenha ferramentas para captura de ideias
  • Convide um grupo com diversidade
  • Planeje para aproximadamente 45 minutos
  • Selecione um facilitador
  • Reveja as regras com todos
  • Dê a todos as ferramentas para participar
  • Mova ideia a ideia (uma por uma)
  • Mantenha a motivação

Técnicas de desbloqueio

Muitas vezes ficamos "travados" após alguns minutos de geração de ideias. Para ajudar neste "desbloqueio" podemos usar algumas técnicas, que listo abaixo para futura referência.

  • Teletransporte :Imagine que você está em outro local ou outro tempo. Como seria o que você está pensando há 20 anos atrás? E em outro local, como a Antártica ou no meio da floresta
  • Outrostorm: Como seriam estas ideias se fossem pensadas por uma celebridade, seu chefe ou um familiar, como a sua avó? Realmente se coloque no lugar da pessoa e pense como acha que ela pensaria. Você pode falar como ela, imitando sua voz, para parecer mais real e "entrar mais no clima".
  • Mudança de atributos: Você não precisa se ver necessariamente como outra pessoa para ter novas ideias sobre um mesmo assunto. E se algumas características suas fossem diferentes? Se você fosse de outra raça, sexo ou tivesse outro peso corporal? Cada mudança pode ser uma chave para seu cérebro encontrar uma solução.
  • Superstorming: Se você tivesse superpoderes, quais ideias teria? Visão de raio X, regeneração, ser o Wolverine ou a Mulher Maravilha. Vale tudo. Até Ben 10. O melhor é que sejam superpoderes que você conhece.
  • Ao contrário:Pense no que deseja e, então, pense o que precisaria ter ou fazer para obter o contrário daquilo. Algo do tipo "Como seria uma maneira de não transportar bem sorvete em um pote?" ou "Como eu faria para pessoas não comprarem este produto?".
  • Parece, mas não é:Pense em soluções, artefatos ou técnicas que são parecidas com o que você quer, mas não exatamente. Por exemplo, em um brainstorm sobre uma nova embalagem de sorvete, você pode pensar em outras embalagens, outros produtos que tem embalagem, sorvetes em outros contextos e até mesmo em transporte de gelo no geral.
  • Escreva aleatoriamente:Parece bobagem, mas funciona muito bem para escritores e pode funcionar pra você. Comece a escrever tudo o que te vêm à mente. Tudo mesmo, tipo "não sei o que escrever agora então vou escrever qualquer coisa somente para escrever e poder pensar em algo etc etc etc". Experimente.
  • Mapa mental: essa é clássica, mas às vezes esquecemos dela. Coloque a ideia no centro, e vá fazendo quantas conexões possíveis com conceitos que emergem à medida que pensa nela.

results matching ""

    No results matching ""