アイデアから最初のパートナーまで: OnStage
2024 年 11 月。アイデアはありましたが、検証のないアイデアは単なるアイデアです。 意見です。役に立つものを構築するには、次のことを行う必要があることはわかっていました 実際にイベントを主催している人たちに話を聞く.
幸運なことに、私はすでに誰かを知っていました：協会 文化的な ステージ上、愛好家のグループ 演劇と音楽はサレントで長年イベントを企画してきました。 夕方、ショー、レビュー。 年間数十のイベント.
この記事でわかること
- アイデアを検証する最初のパートナーをどのように見つけたか
- サイドプロジェクトに適用されるアジャイル手法
- コラボレーションから見えてきた真の要件
- 最初のスプリントと最初の機能
OnStage が最適なパートナーだった理由
OnStage は単なる協会ではありませんでした。彼らは ユースケース 理想的な イベントをプレイするため。
彼らのプロフィール
- 年間15～20のイベント
- 参加者は30名から200名まで
- 主催者チーム8名
- 予算は限られているが、実際のニーズは
- 専用ツールはありません
彼らの問題点
- WhatsApp 経由の出欠管理
- Excelシート上の参加者リスト
- 断片化されたコミュニケーション
- イベント履歴はありません
- 支払いの追跡が難しい
私は彼らに簡単な取引を提案しました。 あなたは私のベータテスターとして働いてくれます。 無料で楽器を作ります。彼らはそうするだろう オーダーメイドのプラットフォーム。実際のユーザーからのリアルなフィードバックがあったはずです。
「ついに、私たちが会社ではないことを理解してくれる人が現れました。
誕生日パーティーでもない。私たちは真ん中にいる、そして誰もいない
私たちのことを考えてください。」
— マルコ、オンステージ社長
サイドプロジェクトのためのアジャイル手法
週に 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 回会議: 要件の収集
OnStage との最初の出会いは啓発的なものでした。自己紹介をしました 「イベントプラットフォーム」という漠然としたアイデアがありました。 1人で出かけました のリスト 具体的な問題 解決するために。
会議の進め方
テクノロジーについては話さなかった。モックアップは見せませんでした。やった ただ一つだけ： 聞きました.
私が尋ねた質問
- 「あなたが最後に企画したイベントについて教えてください。」 最初のアイデアから最後まで、段階的に進めていきます。
- 「最もイライラしたことは何ですか?」 最も時間を無駄にしたのは何ですか?
- 「プロセスに関して 1 つだけ変更できるとしたら、何を変更しますか?」
- 「今日はどんな道具を使っていますか？」 まさになぜそれらなのでしょうか？
浮かび上がった問題
問題 #1: 確認の混乱
イベントごとに、WhatsApp、電子メール、メッセージを通じて確認を受け取りました インスタグラムや口頭で。 集中ポイントがない。 毎回、参加者リストを手動で再構築する必要がありました。
問題 #2: 架空の支払い
有料イベントは悪夢だった。 「誰が払ったのか？誰に借りがあるのか？」 まだ支払いますか？費用を賄えるまでどれくらいかかりますか？」オールオンワン 誰もリアルタイムで更新しなかった Excel シート。
問題 #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 オーガナイザー
「それで、リストは自動的に更新されますか? もう尋ねる必要はありません」
「誰が来るって言った？」毎回？"
— マルコ、オンステージ社長
スプリントレビューからのフィードバック
何がうまくいったのか
- ログインせずに共有可能なリンク
- ワンクリックで出欠確認
- リアルタイム参加者リスト
- シンプルなインターフェース
何が足りなかったのか
- +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 回以上のインタビューに値します。 実際のイベントで誰かがあなたの製品を使用しているのを見ると、調査では分からないことがわかります。
- アジャイルはサイドプロジェクトにも有効です。 短いスプリント、頻繁なフィードバック、迅速な反復。 10 人のチームは必要ありません。
- 最も厄介な問題から始めます。 OnStage の場合、それは RSVP 管理でした。何よりも先にそれを解決しました。
- シンプルさが特徴です。 複雑さを加えるたびに、「でももっとシンプルにできないの？」というフィードバックが返ってきました。
- 値は節約された時間で測定されます。 イベントごとに 10 時間節約 = 目に見える測定可能な価値。
次の記事で
検証された MVP と満足したパートナーがいると、次のことを行う時が来ました。 大きく考えてください。 協会からの登り方 何百人もの主催者？
次の記事では、アーキテクチャの選択について説明します。 なぜそのテクノロジーを選んだのか、データベースをどのように構築したか 成長をサポートするため、そして、 プレイ・ザ・イベントの今後。
この記事のポイント
- あなたの製品を使用してくれる真のパートナーを見つける
- サイドプロジェクトにもアジャイル手法を使用する
- 解決策を提案するのではなく、耳を傾けて要件を収集する
- 構築、表示、フィードバックの収集、反復
- ユーザーが節約できる時間の価値を測定する