Todo projeto começa pela solução. Alguém tem uma ideia, acha boa, junta gente e começa a construir. O problema, que era para vir antes, fica para depois, e às vezes fica para nunca. Este artigo é sobre inverter essa ordem.Neste artigo eu mostro como separar uma dor real de uma dor que você só deduziu, como descobrir quem de fato vai usar, decidir e pagar pelo seu projeto, e um roteiro de cinco perguntas que funciona em vinte minutos de conversa. No caminho, uso dois casos: um aplicativo para condomínios que errou o alvo e o motivo pelo qual o próprio Lecursos.com existe.Sete meses do lado errado do problemaUma equipe de quatro pessoas passou sete meses construindo um aplicativo para condomínios. A tela de reserva do salão de festas ficou impecável: calendário colorido, confirmação por notificação. No lançamento, dois condomínios instalaram. Em três meses, o uso caiu a quase zero.Numa conversa tardia com um síndico apareceu a informação que teria mudado tudo. Reservar o salão nunca foi problema, porque acontece quatro vezes por ano e o zelador anota num caderno. O que consumia as noites daquele síndico era cobrar inadimplentes sem criar inimizade no elevador.Sete meses de trabalho competente resolveram um incômodo trimestral e deixaram intacta uma dor semanal. Esse é o erro mais caro que existe em projeto, e ele quase nunca aparece como erro: aparece como produtividade. A equipe estava ocupada, entregando, refinando.Por que isso acontece com tanta frequência, inclusive com gente experiente? Porque solução é divertida e problema é chato. E por um motivo menos confessável: enquanto o problema não está definido, qualquer coisa que você fizer parece progresso. Depois de definido, existe um critério, e o critério pode condenar a ideia que você já queria construir.Dor real e dor imaginadaDor imaginada é aquela que você deduziu. Ela aparece com verbo abstrato e sujeito indeterminado: "as pessoas têm dificuldade de organizar as finanças", "os alunos não se engajam", "os clientes querem mais praticidade". Frases assim são confortáveis justamente porque nenhum fato específico consegue contestá-las.Dor real tem quatro coisas que a imaginada não tem:- Uma pessoa concreta, com nome ou com papel bem definido.- Uma frequência: toda terça, ou toda vez que fecha o mês.- Um custo que dá para estimar em horas, em reais ou em desgaste.- Uma gambiarra: algo que a pessoa já faz hoje para contornar o problema, mesmo que mal feito.A gambiarra é o sinal mais confiável dos quatro. Ninguém constrói gambiarra para problema que não incomoda. Quando o síndico anota as reservas num caderno há anos, ele está dizendo que aquilo não dói. Quando manda mensagem individual para quatro inadimplentes toda semana, reescrevendo cada texto para não soar agressivo, ele está gritando onde dói. A informação estava disponível o tempo todo. Faltou perguntar.Um cuidado com a intensidade: dores grandes e raras não mudam o comportamento de ninguém, porque a pessoa resolve na hora e esquece. Dores pequenas e constantes constroem hábito, e hábito é o que faz alguém adotar uma solução nova. Projetos melhores costumam nascer das segundas.Quem sente, quem decide e quem pagaUm erro silencioso é tratar como uma só pessoa três papéis que quase sempre são diferentes. Um sistema de gestão escolar é usado pela secretaria, escolhido pela direção e pago pela mantenedora, e cada uma avalia por um critério próprio. Em evento, a mesma separação ganha outros nomes: quem participa é o público, quem autoriza é a coordenação, quem financia é o patrocinador.Um projeto que convence só o público não sai do papel. Um projeto que convence só o patrocinador acontece para plateia vazia. A pergunta prática é curta: quem sente, quem decide, quem paga? Se forem três pessoas, o projeto precisa de três argumentos.No seu projeto atual, quem sente, quem decide e quem paga são a mesma pessoa?As perguntas que não valem nada"Você usaria um aplicativo assim?" "Você viria a um evento sobre isso?" "Você pagaria por esse serviço?" Todas pedem que a pessoa preveja o próprio comportamento num cenário hipotético. Seres humanos são péssimos nisso e simpáticos por padrão. A resposta quase sempre é sim, e esse sim não vale nada.As perguntas que valem olham para o passado, que já aconteceu e não pode ser inventado no meio da conversa:- Como você faz isso hoje? Obriga a descrever o processo real, com os remendos.- Quando foi a última vez que isso te atrapalhou? Se a pessoa não lembra, a frequência é baixa e a dor é pequena.- O que você já tentou para resolver? Revela se houve esforço, tempo ou dinheiro investido antes de você aparecer.- Quanto isso te custa por mês? Em horas ou em reais; a estimativa pode ser grosseira.- Quem mais na sua situação sofre com isso? Abre a próxima entrevista e testa se o problema é de uma pessoa ou de um grupo.Repare que nenhuma menciona a sua ideia. Numa boa entrevista de descoberta, o entrevistado fala oitenta por cento do tempo e você só apresenta a solução no final. Apresentar cedo contamina tudo: a partir dali a pessoa comenta a sua proposta em vez de descrever a vida dela.A mesma conversa, feita de dois jeitosNa versão que não serve, a primeira fala já entrega o aplicativo: "A gente está desenvolvendo um app para síndicos. Você acha que seria útil?" O síndico acha ótimo, usaria a reserva do salão, pagaria trinta reais se for bom. Três respostas positivas, nenhuma informação. A equipe sai achando que validou a ideia.Na versão que serve, a primeira pergunta é "me conta como foi a sua última semana como síndico, o que tomou mais tempo?" E a resposta vem com tudo que interessa:“Mando mensagem no particular, uma por uma. Escrevo e apago umas três vezes para não soar grosseiro. Levo uma hora, fácil. Todo mês. E quando encontro a pessoa no elevador fica aquele clima. Tentei pedir para a administradora, mas eles só mandam boleto. O constrangimento continua sendo meu.”- Um síndico, quando ninguém mencionou o aplicativoFrequência mensal, custo de uma hora, gambiarra descrita e uma tentativa anterior que falhou por um motivo específico. Nada disso apareceria se a primeira pergunta tivesse mencionado o app.Erros que estragam a entrevista- Falar demais. Se você falou mais que o entrevistado, a conversa foi sua.- Apresentar a solução cedo. A pessoa vira crítica de proposta, e crítico educado elogia.- Perguntar duas coisas de uma vez. Ela responde a segunda e a primeira se perde.- Conduzir a resposta. "Não é verdade que isso atrapalha muito?" já entrega o que você quer ouvir.- Anotar só a conclusão. Registre a frase dita, entre aspas. A conclusão você reconstrói depois; a frase, não.- Entrevistar só quem gosta de você. Amigos protegem, e proteção vira ruído.Quantas conversas bastamCinco costuma ser suficiente para a primeira rodada, desde que sejam cinco pessoas que realmente têm o problema e não sejam suas amigas. O sinal de parada não é o número, é a repetição: quando a terceira, a quarta e a quinta descrevem o mesmo contorno de problema com palavras diferentes, você encontrou alguma coisa. Quando cada uma descreve um problema distinto, você ainda não tem um público, tem cinco casos isolados.Encontrar essas pessoas é a parte mais temida e a mais simples. Peça indicação ao fim de cada conversa, vá onde elas já se reúnem e use a rede de quem já está no projeto. Vinte minutos é um pedido pequeno.Depois de cada conversa, reserve cinco minutos para escrever o que foi dito em duas colunas: fatos relatados e interpretações suas. Parece pedante, e é a única coisa que impede que, três semanas depois, a sua interpretação apareça na apresentação como se fosse declaração do entrevistado.O que acontece quando a turma vai perguntarNa disciplina de Empreendedorismo e Prática, a sétima semana é dedicada a uma tarefa que gera resistência: entrevistar alunos de outros períodos antes de fechar o formato do projeto. A turma já escolheu o tema, já dividiu tarefas, já está animada. Parar parece perda de tempo.O resultado muda o projeto com mais frequência do que os alunos esperam. Uma turma que planejava um ciclo de palestras no horário do almoço descobriu que o almoço era exatamente a janela em que a maioria trabalhava ou estagiava. O tema estava certo, o formato estava errado, e a informação custou uma semana de conversas em vez de um auditório vazio.Há um segundo padrão. Estudantes raramente comparecem a um evento pelo tema anunciado. Comparecem porque um professor pediu, porque um amigo vai, porque conta como atividade complementar ou porque querem conhecer o convidado. Descobrir qual desses motores está disponível muda a divulgação inteira.E há um efeito sobre a própria turma. Quem entrevista passa a defender o projeto com outras frases. Sai o "acho que as pessoas vão gostar" e entra o "de doze pessoas que ouvimos, nove disseram que não conseguem vir de manhã". A segunda frase sobrevive a uma discussão. A primeira, não.O problema não era não ter um siteAté 2018 eu distribuía os resumos das minhas aulas em PDF, pelo Google Drive. Funcionava. Do lado de fora, não parecia haver problema nenhum, e é por isso que o caso é útil.O problema era invisível de dentro do meu computador. Quando eu corrigia um erro num resumo, a correção não chegava a quem já tinha baixado. As versões antigas continuavam circulando, reencaminhadas entre turmas, impressas e estudadas por alunos que nunca saberiam que estavam lendo uma frase errada que eu já tinha consertado meses antes.Repare no formato desse problema, porque ele é o de uma família inteira. A dor não era minha no momento em que acontecia, era do aluno, e ele não sabia que estava sentindo. Problemas assim não aparecem em reclamação nem em pesquisa de satisfação. Aparecem quando alguém compara o que deveria ter acontecido com o que aconteceu.Se eu tivesse começado pela solução, teria renomeado arquivos com número de versão, organizado melhor a pasta ou mandado e-mail a cada mudança. Tudo isso resolve o sintoma, que é a bagunça de arquivos. Nada resolve o problema, que é a correção não alcançar quem levou o material embora. Formulado assim, o requisito ficou estreito: o conteúdo precisa morar num lugar só, onde a última versão seja a única versão. Foi por isso que o Lecursos.com nasceu, e não porque eu quisesse ter um site.A ironia do desfecho: o serviço de hospedagem que contratei não funcionava bem no Brasil, e por um bom tempo o site simplesmente não abria para parte dos alunos. O requisito que eu tinha acertado no papel foi exatamente o que falhou na prática, e demorei a enxergar porque só recebia retorno de quem conseguia acessar. Definir bem o problema não garante que a execução vá honrá-lo. Garante apenas que, quando algo der errado, você vai saber o que estava tentando fazer.Um exercício para fecharMarque cinco conversas de vinte minutos com pessoas que têm o problema do seu projeto e que não são suas amigas. Use o roteiro de cinco perguntas deste artigo sem apresentar a sua solução até o final.Depois de cada uma, preencha quatro colunas: quem (nome ou papel), o que faz hoje (a gambiarra), frequência e custo, e uma frase textual entre aspas. Ao terminar as cinco, escreva só o que apareceu em pelo menos três delas.Se nenhuma das cinco pessoas disse nada que contrariou o seu plano, você provavelmente ainda não entrevistou ninguém de verdade. E se alguma disse, parabéns: essa frase vale mais do que os sete meses do aplicativo do condomínio.
Reactions
0
0 Comments
Be the first to comment