Como escrever uma declaração de desafio que as pessoas queiram resolver

Uma boa declaração de desafio nomeia um problema real, as pessoas que convivem com ele, por que ele importa agora, o que está fora de questão e o que o dono vai fazer com uma boa resposta, tudo numa página. Ela é específica o bastante para que as equipes comecem na primeira manhã e aberta o bastante para não ditar a solução. Os sete passos abaixo levam você até lá em cerca de duas semanas de preparação.

O que uma declaração de desafio precisa fazer

A declaração de desafio é o documento mais importante de qualquer hackathon, jam ou desafio de inovação aberta. Ela decide quem se inscreve, em que as pessoas trabalham, como os jurados pontuam e se algo sobrevive ao evento. A maioria das declarações erra numa de duas direções:

• Ampla demais. "Melhorar a experiência do cliente." As equipes passam o primeiro dia escolhendo um problema e terminam com dez ideias sem relação entre si, impossíveis de comparar.
• Estreita demais. "Construir um chatbot para a central de atendimento." A solução já foi escolhida. As equipes viram fornecedores sem remuneração e as melhores ideias nunca aparecem.

O alvo fica no meio: um problema claro, uma pessoa clara, restrições reais e liberdade no como. É a versão, no nível do desafio, do trabalho que descrevemos em como escrever uma declaração de problema; a diferença é que uma declaração de desafio precisa funcionar para desconhecidos que nunca estiveram dentro da sua organização.

Sete passos para uma declaração de desafio

1. Comece pelo dono, não pelo tema. Encontre a pessoa que convive com o problema e tem autoridade para agir a partir de uma resposta. Entreviste-a por uma hora. Pergunte o que continua dando errado, o que ela já tentou, o que não pode mudar e o que faria na segunda-feira com uma boa ideia. Se ninguém se encaixa nessa descrição, pare: um desafio sem dono produz trabalho que ninguém recebe, que é justamente o primeiro ponto de 9 erros em hackathon que os organizadores continuam repetindo.

2. Desça um nível abaixo do sintoma. O que o dono descreve primeiro costuma ser um sintoma: "as reclamações aumentaram", "os pedidos demoram demais". Use uma árvore de problemas ou uma rodada de cinco porquês para encontrar a causa que seja ao mesmo tempo real e trabalhável no tempo que as equipes têm. "Os pedidos demoram demais" pode virar "os solicitantes enviam processos incompletos e o caso fica parado numa fila esperando um documento que falta". Isso é algo para o qual uma equipe consegue projetar.

3. Nomeie as pessoas afetadas, em palavras simples. Um desafio sem pessoa é abstrato. Quem exatamente vive o problema, e em que momento? "Quem faz o pedido pela primeira vez, preenchendo o formulário no celular, geralmente à noite" é muito mais útil do que "clientes". Duas ou três entrevistas com stakeholders com essas pessoas, mesmo curtas, vão dar a você a linguagem e os detalhes que fazem a declaração parecer real. Uma declaração de ponto de vista (usuário, necessidade, insight) é uma boa forma de registrar isso.

4. Transforme em uma pergunta que convide muitas respostas. Reescreva o problema como uma pergunta Como poderíamos. Teste: dez equipes diferentes conseguiriam dar dez boas respostas realmente diferentes? Se só uma resposta cabe, está estreita demais. Se qualquer resposta cabe, está ampla demais. "Como poderíamos ajudar quem faz o pedido pela primeira vez a enviar o processo completo logo na primeira tentativa?" passa. "Como poderíamos construir um verificador de uploads?" não passa. "Como poderíamos transformar os serviços públicos?" também não.

5. Escreva as restrições com honestidade. Restrições não são inimigas da criatividade; a imprecisão é. Liste o que não pode mudar (legislação, sistemas centrais, teto de orçamento, prazos), o que está disponível (conjuntos de dados, APIs, tempo de pessoas da equipe, usuários reais de prontidão) e o que está explicitamente fora do escopo. As equipes respeitam um limite firme. O que as frustra é descobri-lo na hora do pitch, quando um jurado diz "isso a gente nunca conseguiria fazer".

6. Diga por que importa e o que acontece depois. Escreva uma ou duas frases sobre por que esse problema importa agora, de preferência na voz das pessoas afetadas, e não de documentos de estratégia. Depois diga claramente com o que o dono se compromete: um piloto num serviço nomeado, uma construção de 90 dias com uma equipe, um teste com verba. É isso que faz as pessoas quererem resolver o seu desafio e não o de outra organização. Se o compromisso for modesto, diga com honestidade. As equipes preferem um passo seguinte pequeno e real a uma promessa vaga de "possível implementação".

7. Teste com alguém de fora. Entregue o rascunho a duas ou três pessoas que não sabem nada sobre o problema, de preferência o tipo de gente que você espera ver participando. Peça que expliquem o desafio de volta com as próprias palavras e digam a primeira ideia que tentariam. Se entenderem errado, ou se todas as ideias forem iguais, reescreva. Um mapa de premissas do que a declaração dá como certo é uma boa última checagem.

Um modelo de uma página

Use estes títulos, nesta ordem, e mantenha tudo numa página:

1. O desafio — a pergunta Como poderíamos, em uma frase.
2. Quem é afetado — as pessoas, o momento, uma citação se você tiver.
3. O que sabemos — de três a cinco fatos ou observações, com a origem de cada um.
4. Por que agora — uma ou duas frases.
5. O que vocês podem usar — dados, sistemas, pessoas de prontidão.
6. O que está fora de questão — as restrições honestas.
7. Como é um bom resultado — os critérios de avaliação, publicados agora (veja critérios de avaliação que escolhem o vencedor certo).
8. O que acontece depois — o compromisso do dono, nomeado.

O que fazer e o que evitar

Faça

• Escreva na linguagem das pessoas afetadas, não na linguagem da sua estratégia.
• Inclua pelo menos um fato que as equipes não teriam como adivinhar.
• Publique os critérios e o compromisso pós-evento no mesmo documento.
• Peça ao dono que apresente o desafio pessoalmente na primeira manhã.

Evite

• Nomear a tecnologia. "Usando IA" ou "com blockchain" na pergunta estreita as respostas antes que alguém tenha pensado.
• Esconder restrições para o desafio parecer mais empolgante.
• Juntar dois problemas numa só declaração para agradar dois patrocinadores; escreva dois desafios ou escolha um.
• Usar siglas internas ou nomes de departamentos que quem é de fora não vai conhecer.

Exemplo ilustrativo

Ilustrativo. O serviço de bibliotecas de uma cidade num país do norte da Europa queria lançar um desafio aberto sobre "a biblioteca do futuro". O primeiro rascunho dizia: "Como poderíamos reimaginar a biblioteca para a era digital?" O teste com três estudantes produziu três versões do mesmo app.

A equipe voltou ao chefe dos serviços das unidades, que era o dono do orçamento para mudanças nas unidades. Em uma hora, descobriram o problema real: as visitas de adolescentes à noite tinham caído, enquanto as unidades ficavam abertas até as oito com funcionários que tinham pouco a fazer. Uma sessão de cinco porquês com a equipe das unidades apontou uma causa: os adolescentes viam a biblioteca como um lugar para estudar em silêncio na época de provas, e nada mais.

A declaração revisada dizia: "Como poderíamos dar a jovens de 14 a 18 anos um motivo para ir à unidade do bairro numa noite comum de dia de semana?" Restrições: nenhuma obra no prédio, apenas a equipe existente, um pequeno orçamento para materiais. Disponível: duas unidades dispostas a testar, cinco adolescentes de prontidão durante o evento, dados de visitas por hora dos últimos dois anos. Compromisso: o chefe dos serviços das unidades colocaria a ideia vencedora em prática em duas unidades durante um semestre letivo. Vinte e duas equipes se inscreveram; as ideias foram de uma troca de ajuda com a lição de casa a um repair café noturno. Todas as ideias podiam ser comparadas a partir da mesma pergunta.

Perguntas frequentes

Qual é a diferença entre uma declaração de problema e uma declaração de desafio? Uma declaração de problema descreve o que está errado, principalmente para a equipe que é dona dele. Uma declaração de desafio transforma esse problema num convite para pessoas de fora da equipe: acrescenta a pergunta, as restrições, os recursos e o que vai acontecer com uma boa resposta.

Qual deve ser o tamanho da declaração de desafio de um hackathon? Uma página. A pergunta em si deve ser uma frase. Se você precisa de mais de uma página, provavelmente tem dois desafios, ou está explicando a sua organização em vez do problema.

Devo dar exemplos de possíveis soluções no desafio? Geralmente não. Exemplos ancoram as equipes, e muitas vão simplesmente construir o exemplo. Se for indispensável, dê dois bem diferentes e diga claramente que são ilustrações, não expectativas.

Para onde ir agora

O desafio faz parte de um desenho mais amplo; veja como fazer um hackathon que produza algo real e o mapa dos formatos em hackathons, jams e desafios: todos os tipos explicados. Para fazer bem a preparação, use os guias de árvore de problemas, cinco porquês, declaração de ponto de vista e Como poderíamos.