O hackathon de ecossistema: um desafio, várias organizações

Um hackathon de ecossistema é um hackathon com vários donos, porque o problema não pertence a nenhuma organização sozinha: uma jornada do paciente que passa por um ministério, hospitais e operadoras de saúde, ou um processo de comércio exterior que envolve a alfândega, portos e empresas de logística. Ele dá certo quando os donos combinam quatro coisas antes de alguém escrever uma linha de código: o desafio comum, que dados cada um vai abrir, de quem é o que sair do evento e quem vai levar adiante as ideias vencedoras. A maior parte do trabalho acontece nas oito semanas anteriores ao evento, não durante ele.

Este texto trata só da versão com vários donos. Para a mecânica geral de conduzir o evento em si, veja Como fazer um hackathon que produza algo real. Para o panorama maior de organizações trabalhando em problemas comuns, veja Inovação em ecossistema.

Por que hackathons de ecossistema são diferentes

Um hackathon com um só dono tem um patrocinador, um conjunto de sistemas e um tomador de decisão. Um hackathon de ecossistema tem vários de cada, e o atrito aparece em lugares previsíveis:

• O desafio se dispersa. Cada parceiro empurra a própria prioridade, e o briefing vira uma lista de cinco problemas.
• Os dados chegam tarde, ou não chegam. As equipes jurídicas de cada organização revisam separadamente, cada uma no seu ritmo.
• A avaliação vira política. Cada parceiro torce em silêncio para que "a sua" equipe vença.
• Ninguém é dono da segunda-feira. Uma solução que exige que três organizações mudem geralmente não tem uma casa única.

O lado bom é real: os participantes enxergam a jornada inteira, não a fatia de uma organização, e os parceiros conhecem pela primeira vez as pessoas uns dos outros que trabalham no mesmo problema. Muitos hackathons de ecossistema valem menos pelos vencedores do que pelas relações de trabalho que criam.

Como fazer um, passo a passo

1. Mapeie o ecossistema antes de escolher os parceiros. Desenhe um mapa de ecossistema da jornada que importa para você: quem tem contato com o usuário, quem detém os dados, quem define as regras, quem paga. Depois decida quem precisa ser codono e quem pode ser colaborador. De três a cinco codonos é viável; mais do que isso, e as decisões andam a passo de tartaruga.

2. Combinem um único desafio, escrito do ponto de vista do usuário. Façam uma sessão de meio período com um tomador de decisão de cada codono. Usem uma árvore de problemas sobre a jornada compartilhada e depois escrevam uma única declaração de desafio que nomeie o usuário e o momento em que as coisas quebram entre as organizações. Se a prioridade de um parceiro não se encaixa, ela vai para um evento futuro, não para este briefing. Veja Como escrever uma declaração de desafio que as pessoas queiram resolver.

3. Assinem um memorando curto antes de anunciar qualquer coisa. Duas páginas bastam. O memorando deve cobrir: o desafio; a contribuição de cada parceiro (dinheiro, dados, mentores, local); propriedade intelectual (geralmente as equipes ficam com a sua PI e os parceiros ganham o direito de negociar primeiro, mas quem decide são os seus advogados); termos de uso dos dados; como os jurados são escolhidos; e quem lidera cada fase. Acertar isso depois do anúncio é o caminho para eventos atrasarem meses.

4. Preparem os dados cedo, e em conjunto. Decidam quais conjuntos de dados cada parceiro vai abrir, em que forma (reais, anonimizados, sintéticos ou de amostra) e em que termos. Coloquem tudo num só lugar, com um só formato de descrição. Deem às equipes jurídicas e de proteção de dados um prazo de pelo menos quatro semanas antes do evento. Se um parceiro não conseguir abrir os dados a tempo, um conjunto sintético realista com a mesma estrutura é melhor do que nada.

5. Nomeiem um líder e um quadro claro de papéis. Ser codono não significa liderar junto cada tarefa. Nomeiem uma organização líder para logística e comunicação e usem uma matriz RACI para o resto: quem aprova o briefing, quem recruta, quem fornece mentores, quem aprova os vencedores, quem financia a continuação.

6. Recrutem participantes de todo o ecossistema. Equipes mistas são o objetivo. Reservem vagas para pessoas de cada parceiro e busquem equipes que combinem pelo menos duas organizações, mais desenvolvedores, designers ou estudantes de fora. Peçam a cada parceiro que envie mentores que conheçam a sua parte da jornada e saibam responder "como isso funciona de verdade do lado de vocês?"

7. Montem uma banca conjunta com critérios publicados. Cada codono indica um jurado; acrescentem pelo menos um jurado independente. Publiquem os critérios antes do evento e atribuam pesos (uma matriz de decisão ponderada funciona bem). Incluam um critério que premie soluções que funcionem entre organizações, não dentro de uma só. Veja Critérios de avaliação que escolhem o vencedor certo.

8. Conduzam o evento com a jornada compartilhada na parede. Durante o hackathon, mantenham visível a jornada completa do usuário, com a parte de cada organização marcada. Quando a ideia de uma equipe exigir uma mudança de um parceiro, a equipe deve conseguir ver de quem e perguntar ao mentor daquele parceiro que está na sala.

9. Decidam a continuação antes do último dia. Combinem no memorando o que os vencedores recebem: um piloto com parceiros nomeados, um período fixo de apoio, acesso a sistemas reais. Nomeiem um dono por conceito vencedor e uma data para a primeira reunião de acompanhamento. Um plano de comunicação com stakeholders mantém todos os parceiros informados depois do evento, quando a atenção diminui.

Exemplo ilustrativo

Ilustrativo. Numa cidade portuária europeia, a autoridade portuária, a alfândega, uma associação de transportadoras e o departamento de transportes da cidade compartilhavam uma frustração: caminhões em fila por horas nas ruas da cidade, esperando liberação e horário de janela. Cada um já tinha tentado soluções por conta própria.

Passaram sete semanas se preparando. Uma sessão de mapeamento do ecossistema revelou que o atraso estava entre três sistemas que nunca trocavam estimativas de chegada. O desafio único dizia: "Como poderíamos dar ao motorista de caminhão que vai chegar ao porto um horário confiável para vir, antes de ele entrar na cidade?" O memorando deixava o código com as equipes, dava aos quatro parceiros o direito prioritário de pilotar e comprometia cada parceiro com um mentor durante todo o evento. A alfândega não conseguiu liberar dados em tempo real a tempo, então a equipe de dados da autoridade portuária montou um conjunto sintético com a mesma estrutura.

Quinze equipes participaram, cada uma com pelo menos um membro de uma organização parceira. A banca tinha quatro jurados dos parceiros e um presidente independente. O conceito vencedor foi uma janela de chegada compartilhada, alimentada pelos três sistemas. Como o memorando já nomeava a autoridade portuária como dona da continuação, um piloto de doze semanas começou no mês seguinte ao evento.

O que fazer e o que evitar

Faça

• Combinem um único desafio. Um problema claro vale mais do que cinco parciais.
• Assinem o memorando antes do anúncio, incluindo os termos de PI e de dados.
• Nomeiem uma organização líder para a logística e deem a todos os outros um papel claro.
• Premiem nos critérios as soluções entre organizações.
• Definam o dono e a data da continuação antes do anúncio dos vencedores.

Evite

• Convidar todos os parceiros possíveis como codonos. Colaboradores podem ajudar sem votar em tudo.
• Deixar o acesso aos dados como uma questão de última hora. É a causa mais comum de atraso.
• Deixar os parceiros avaliarem as equipes do próprio pessoal sem uma voz independente na banca.
• Associar a marca do evento a um único parceiro. Problemas compartilhados pedem visibilidade compartilhada.
• Terminar com uma foto em grupo e um release para a imprensa. Sem um caminho para o piloto, o evento confirma que a cooperação é só fachada.

Perguntas frequentes

De quem deve ser a propriedade intelectual num hackathon com várias organizações? Não existe uma única resposta certa, e quem deve decidir são as suas equipes jurídicas. Um arranjo comum é as equipes ficarem com a sua PI, enquanto os parceiros ganham o direito de negociar primeiro um piloto ou uma licença. O que mais importa é que isso esteja escrito e publicado antes das inscrições.

Quantas organizações podem coorganizar um hackathon? De três a cinco codonos é viável. Além disso, acrescente organizações como colaboradoras (mentores, dados, local), sem dar a cada uma um voto em todas as decisões.

E se um parceiro não puder compartilhar os dados? Use um conjunto de dados sintético ou de amostra com a mesma estrutura, descreva-o com honestidade aos participantes e planeje usar os dados reais na fase de piloto, com um acordo adequado.

Métodos para a preparação

Comece com um mapa de ecossistema e um mapa de expectativas dos stakeholders para ver o que cada parceiro quer. Combinem o desafio com uma árvore de problemas e depois dividam o trabalho com uma matriz RACI. Para toda a gama de formatos, veja o guia central de hackathons, jams e desafios e, para mobilizar um setor inteiro para além de um evento, Como ministérios e reguladores mobilizam um setor em torno de um desafio.