아이디어에서 첫 번째 파트너까지: OnStage
2024년 11월. 아이디어는 있었지만 검증이 없는 아이디어는 그냥 의견. 나는 유용한 것을 만들려면 다음을 수행해야 한다는 것을 알고 있었습니다. 실제로 행사를 주최하는 사람들과 이야기를 나눠보세요.
운 좋게도 나는 이미 누군가를 알고 있었습니다: 협회 문화적 온스테이지, 열광적인 그룹 수년 동안 Salento에서 이벤트를 조직해 온 연극과 음악. 저녁, 쇼, 리뷰. 연간 수십 건의 행사.
이 기사에서 찾을 수 있는 내용
- 아이디어를 검증할 첫 번째 파트너를 찾은 방법
- 사이드 프로젝트에 적용된 애자일 방법론
- 협업을 통해 나타난 실제 요구사항
- 첫 번째 스프린트와 첫 번째 기능
OnStage가 완벽한 파트너였던 이유
온스테이지(OnStage)는 단순한 협회가 아니었습니다. 그들은 사용 사례 이상적인 이벤트를 플레이하세요.
그들의 프로필
- 연간 15-20개 이벤트
- 30명에서 200명까지 참가자
- 8명의 주최자로 구성된 팀
- 예산은 제한되어 있지만 실제로 필요한 사항
- 전용 도구 없음
그들의 문제점
- WhatsApp을 통한 회신 관리
- Excel 시트의 참가자 목록
- 단편화된 커뮤니케이션
- 이벤트 내역이 없습니다.
- 결제 추적이 어려움
나는 그들에게 간단한 거래를 제안했습니다. 당신은 나를 위한 베타 테스터 역할을 하고 있어요. 무료로 악기를 만들어 드릴게요. 그들은 그랬을 것이다 맞춤형 플랫폼. 실제 사용자로부터 실제 피드백을 받았을 것입니다.
"드디어 우리가 회사가 아니라 회사라는 것을 이해하는 사람
생일파티도 아니고. 우리는 중간에 있고 아무도 없습니다
우리를 생각해봐."
— Marco, OnStage 사장
사이드 프로젝트를 위한 애자일 방법론
저는 이벤트 플레이에 일주일에 40시간을 투자할 수 없었습니다. 그것은 저녁과 주말에 개발된 사이드 프로젝트. 하지만 이건 아니야 이는 구조화된 접근 방식을 포기하는 것을 의미했습니다.
나는 적응했다 스크럼 내 필요에 따라: 스프린트 2주, 백로그를 OnStage와 공유하고 스프린트가 끝날 때마다 데모를 진행합니다.
STRUTTURA SPRINT (2 settimane)
LUNEDÌ SERA (1h)
├── Sprint Planning
├── Review backlog con OnStage (via call)
└── Selezione user stories per lo sprint
MARTEDÌ-DOMENICA
├── Sviluppo (2-3h/giorno quando possibile)
├── Commit frequenti
└── Deploy su ambiente di staging
LUNEDÌ SUCCESSIVO (1h)
├── Sprint Review con OnStage
├── Demo delle nuove funzionalità
├── Raccolta feedback
└── Sprint Retrospective (cosa migliorare)
ARTEFATTI
├── Product Backlog (Notion)
├── Sprint Board (Notion Kanban)
├── User Stories con acceptance criteria
└── Definition of Done chiara첫 번째 회의: 요구사항 수집
온스테이지와의 첫 만남은 깨달음이었습니다. 자기 소개를 했어요 "이벤트 플랫폼"이라는 막연한 생각으로. 나는 한 명과 함께 나갔다. 목록 구체적인 문제 해결하다.
내가 회의를 진행한 방법
나는 기술에 대해 이야기하지 않았습니다. 나는 모형을 보여주지 않았습니다. 내가 그랬어 딱 한 가지: 나는 들었다.
내가 했던 질문들
- "지난번에 주최한 행사에 대해 말해주세요." 첫 번째 아이디어부터 끝까지 단계별로 진행됩니다.
- “가장 답답했던 부분은 무엇이었나요?” 무엇이 당신을 가장 많은 시간을 낭비하게 만들었나요?
- "프로세스에서 한 가지만 변경할 수 있다면 무엇을 바꾸시겠습니까?"
- "오늘은 어떤 도구를 사용하시나요?" 정확히 왜 그런가요?
나타난 문제
문제 #1: 확인 혼돈
각 이벤트에 대해 WhatsApp, 이메일, 메시지를 통해 확인을 받았습니다. 인스타그램, 구두로. 중앙 집중식 지점 없음. 매번 참가자 목록을 수동으로 재구성해야 했습니다.
문제 #2: 팬텀 결제
유료 이벤트는 악몽이었습니다. "누가 지불했는가? 누가 빚을 졌는가?" 아직도 지불해? 우리가 비용을 충당할 때까지 얼마나 걸리나요?" 모두 하나로 실시간으로 누구도 업데이트하지 않는 엑셀 시트.
문제 #3: 단편화된 통신
모든 참가자에게 업데이트를 보냈어야 합니까? 그것은 의미했다 3개의 다른 WhatsApp 그룹에 동일한 메시지를 보낼 수 있습니다. 그룹에 속하지 않은 사람들에게 이메일을 보내세요.
문제 #4: 제로 히스토리
“지난해 행사에는 몇 명이 왔나요?” 아무도 몰랐습니다. 각 이벤트는 처음부터 시작되었습니다. 믿을 수 있는 과거 데이터.
문제에서 사용자 스토리까지
회의가 끝난 후 나는 문제를 다음 언어로 번역했습니다. 사용자 스토리 표준 형식을 따릅니다.
US-001: CREAZIONE EVENTO
Come organizzatore
Voglio creare un evento con data, luogo e descrizione
Per avere un punto centrale di riferimento
Acceptance Criteria:
- Form con campi: nome, data, ora, luogo, descrizione
- Generazione automatica di un link condivisibile
- Salvataggio in database
US-002: RSVP SEMPLIFICATO
Come partecipante
Voglio confermare la mia presenza con un click
Per non dover scrivere messaggi o email
Acceptance Criteria:
- Pagina pubblica accessibile senza login
- Bottoni: Parteciperò / Non parteciperò / Forse
- Campo note opzionale (es. allergie, +1)
US-003: LISTA PARTECIPANTI REAL-TIME
Come organizzatore
Voglio vedere chi ha confermato in tempo reale
Per sapere sempre quante persone aspettarmi
Acceptance Criteria:
- Lista aggiornata automaticamente
- Filtri: confermati, rifiutati, in attesa
- Export in CSV/Excel
US-004: NOTIFICHE CENTRALIZZATE
Come organizzatore
Voglio inviare un messaggio a tutti i partecipanti
Per non dover usare 5 canali diversi
Acceptance Criteria:
- Invio email a tutti i confermati
- Template personalizzabile
- Storico messaggi inviati
US-005: GESTIONE PAGAMENTI (v2)
Come organizzatore
Voglio tracciare chi ha pagato e chi no
Per avere sempre il quadro finanziario chiaro
Acceptance Criteria:
- Campo "pagato sì/no" per ogni partecipante
- Totale incassato vs totale atteso
- Promemoria automatico a chi non ha pagato스프린트 1: MVP
백로그가 준비되면 첫 번째 스프린트를 계획했습니다. 목표 그것은 분명했습니다. 현재 MVP 그 온스테이지 다음 이벤트에 사용할 수 있습니다.
SPRINT 1 (2 settimane)
Goal: "Un organizzatore può creare un evento e ricevere conferme"
USER STORIES SELEZIONATE:
├── US-001: Creazione evento (5 punti)
├── US-002: RSVP semplificato (8 punti)
└── US-003: Lista partecipanti (5 punti)
CAPACITY: 18 punti (realistici per un side project)
COMMITMENT: 18 punti
TECHNICAL TASKS:
├── Setup progetto (Next.js + Supabase)
├── Modello dati eventi e partecipanti
├── API REST per CRUD eventi
├── Pagina creazione evento
├── Pagina pubblica RSVP
├── Dashboard lista partecipanti
└── Deploy su Vercel첫 번째 데모
2주 후에 보여드릴 것이 생겼습니다. 완벽하지는 않았습니다. UI는 최소화되었습니다. 하지만 효과가 있었어.
OnStage에서 영상 통화를 통해 데모를 진행했습니다. 그들의 반응은 나에게 내가 알아야 할 모든 것을 말했습니다.
“잠깐만요. 이 링크를 보내면 사람들에게
확인하려면 클릭하시겠습니까? 아무것도 다운로드하지 않고도요?"
— 엘레나, OnStage 주최자
"그리고 목록은 자동으로 업데이트되나요? 더 이상 물어볼 필요가 없습니다.
'그가 온다고 누가 말했어?' 매번?"
— Marco, OnStage 사장
스프린트 리뷰의 피드백
효과가 있었던 것
- 로그인 없이 공유 가능한 링크
- 단 한 번의 클릭으로 답장하기
- 실시간 참가자 목록
- 간단한 인터페이스
무엇이 빠졌나요?
- +1 캠프(동반자)
- 주최자에게 표시되는 메모
- 응답하지 않으신 분들을 위한 알림
- 향상된 모바일 버전
실행 중인 반복적 접근 방식
이것이 애자일 접근 방식의 장점입니다. 추측할 필요가 없었습니다. 무엇이 필요했는지. 나는 만들고, 보여주고, 피드백을 수집하고, 개선했습니다. 모든 스프린트는 실질적인 가치를 가져왔습니다..
SPRINT 1: Creazione evento + RSVP base + Lista partecipanti
→ OnStage lo usa per "Serata Jazz" (45 partecipanti)
SPRINT 2: Campo +1 + Note partecipanti + Reminder email
→ OnStage lo usa per "Teatro sotto le Stelle" (120 partecipanti)
SPRINT 3: Gestione pagamenti base + Export CSV + Mobile responsive
→ OnStage lo usa per "Concerto di Natale" (200 partecipanti)
METRICHE DOPO 6 SETTIMANE:
├── 3 eventi gestiti
├── 365 partecipanti totali
├── 0 email "chi viene?" inviate
├── 100% delle conferme tracciate
└── Tempo risparmiato: ~10 ore per evento내가 배운 것
OnStage와의 협업에서 얻은 교훈
- 진정한 파트너는 100번의 인터뷰보다 가치가 있습니다. 누군가 실제 이벤트에 귀하의 제품을 사용하는 모습을 보면 어떤 설문조사에서도 알 수 없는 사실을 배울 수 있습니다.
- Agile은 사이드 프로젝트에도 작동합니다. 짧은 스프린트, 빈번한 피드백, 빠른 반복. 10명으로 구성된 팀은 필요하지 않습니다.
- 가장 고통스러운 문제부터 시작하세요. OnStage의 경우 회신 관리였습니다. 그 일보다 먼저 해결했어요.
- 단순성은 다음과 같은 특징입니다. 복잡함을 더할 때마다 "그런데 더 단순하게 만들 수는 없지?"라는 피드백이 있었습니다.
- 값은 저장된 시간으로 측정됩니다. 이벤트당 10시간 절약 = 실질적이고 측정 가능한 가치.
다음 기사에서
검증된 MVP와 만족스러운 파트너와 함께 이제 크게 생각해 보세요. 협회에서 다음으로 올라가는 방법 수백 명의 주최자?
다음 기사에서는 아키텍처 선택에 대해 설명하겠습니다. 내가 그 기술을 선택한 이유, 데이터베이스를 어떻게 구성했는지 성장을 지원하고, Play the Event의 미래.
이 기사의 핵심 사항
- 귀하의 제품을 사용하려는 실제 파트너를 찾으십시오
- 사이드 프로젝트에도 애자일 방법론을 사용하세요
- 솔루션을 제안하는 것이 아니라 경청을 통해 요구 사항을 수집합니다.
- 빌드, 표시, 피드백 수집, 반복
- 사용자에게 절약된 시간의 가치를 측정