EP05 - 需求重整與反思

重新整理需求

時間：2024年3月9日，上午7:00

今天一早 Inusan 和 Mojin 就到公司準備開始新的一天。前一天晚上的討論讓他們意識到，僅憑初步的設計和模糊的需求無法滿足 Bob 的期望。今天，他們決定重新整理需求，撰寫更詳細的產品需求文檔（PRD），以確保專案能夠順利推進。

Inusan 坐在桌前，打開 Ora，開始梳理從 Bob 那裡獲得的已知需求。他將所有功能按照優先級重新分類，確保核心功能能夠優先完成。

「我們需要更具體地定義每個功能的細節，這樣才能避免後續工程重工。」Inusan 對 Mojin 說。

Mojin 點頭表示同意，「對，尤其是 Bob 提到的禮盒組合推薦功能，我們需要確保我們做的體驗是 Bob 想要的。」

撰寫產品需求文檔（PRD）

時間：2024年3月9日，上午10:30

Inusan 和 Mojin 決定共同撰寫 PRD，將所有需求詳細記錄下來。他們分工合作，Inusan 負責產品描述和使用者故事 (User Story)，Mojin 則專注於技術實現細節。

「我們應該先從使用者故事開始，這樣可以更好地站在顧客以及 Bob 的角色思考。」Inusan 講得頭頭是道。

「好喔，那我一樣先做技術研究，確保我們的想做的內容是可行的。」Mojin 回應。

在撰寫過程中，他們不斷回顧前幾天所遇到的困難，確保 PRD 能夠涵蓋所有關鍵需求。

與 Bob 的需求確認會議

時間：2024年3月9日，下午2:00

下午，Inusan 和 Mojin 帶著完善的 PRD 再次與 Bob 進行會議，確認需求細節，確保雙方對專案目標有一致的理解。

「這次我們還整理了一份詳細的 PRD，希望能夠讓彼此理解的內容一致。」Inusan 開場說道。

Bob 翻閱著 PRD，搖了搖頭，「你這個東西字這麼多，我看不完啦，然後技術什麼的我也不懂，你們做得出來就好，還是你直接跟我用說的？ 尤其是禮盒推薦組合的部分。」

「痾....好，那這樣我帶你了解這份文件的內容，能夠避免彼此對設計誤解，也同時確認專案能在時間內完成。」Iunsan 尷尬的回答。

Bob 表示滿意，在聽的過程也提出了一些細節上的建議，Inusan 和 Mojin 記錄下來，準備在後續的開發中進行調整。

學習與優化工具使用

時間：2024年3月9日，下午4:00

會議結束後，Inusan 和 Mojin 回到公司，決定進一步了解更多 Ora 和 Figma 的使用技巧，以提高工作效率。

「我們應該更深入地學習 Ora 的進階功能，比如自動化任務分配和進度追蹤，這樣可以減少手動操作的錯誤。」Inusan 用食指把眼鏡往上推。

「那個好像是付費方案才會有的功能」Mojin 扶額回應。

「那...我們應該更深入地學習 Ora 的免費功能！」Inusan 精神喊話

「阿 Figma 的能夠迅速操作增加工作效率也很要，如果可以的話，把原型設計的功能摸熟，展示給 Bob 看的時候就可以更精確地知道他喜不喜歡。」Mojin 回應。

他們一起看了好多好多的 Youtube 影片，並嘗試應用新的技巧來優化專案管理和設計流程。隨著時間的推移，他們對這些工具的掌握逐漸加深，工作效率也稍稍的提升了。

晚上的反思與決心

時間：2024年3月9日，晚上9:00

一天的工作結束後，Inusan 和 Mojin 坐在公司的沙發上，針對今天進行複盤。

「今天整理需求和撰寫 PRD 還蠻順利的，至少跟 Bob 溝通時可以有文件輔助，讓溝通可以更順利。」Inusan 微笑著說。

「嘿阿，雖然 ChatGPT 免費額度不太夠用，但我一定可以克服技術上的困難。」Mojin 回應。

Inusan 深吸一口氣，堅定地說：「我們不能放棄，這個社會上充斥著形形色色的人，我們被客戶磨練，最後只剩下色色了，阿不是，我不是要說這個，我相信再怎麼雞雞歪歪的事情，我們都可以勇往直前，一定能克服。」

Mojin 也點頭表示同意，「你說的對，努力一定會有回報。」

他們相視而笑，對未來充滿了希望和信心。

但他們不知道的是，並非所有的努力都是有回報的。

☄️ 離開的 Inusan 爆炸後的回顧

可能影響專案成功的關鍵

1. 需求細節不清導致溝通不順

   • 在本集中，Inusan 和 Mojin 重新整理需求並撰寫了更詳細的 PRD，這有助於解決 EP04 中需求模糊的問題。如果在撰寫 PRD 時仍有細節遺漏或理解偏差，可能會再次導致溝通不順，影響專案進度和品質。

2. 需求擴張的風險

   • 雖然 Bob 的需求得到了更清晰的整理，但隨著專案的深入，客戶可能會繼續提出新的需求或修改現有需求，導致範圍擴張（Scope Creep）。這需要 Inusan 和 Mojin 在撰寫 PRD 時明確界定需求範圍，並與 Bob 保持持續的溝通和協商。

3. 工具使用與學習曲線的挑戰

   • Inusan 和 Mojin 決定深入學習 Ora 更多的免費功能和 Figma 的互動原型製作。若他們無法有效掌握這些工具的進階功能，可能會影響專案的管理效率和設計品質，進而影響專案的整體進度和成果。

4. 團隊資源有限

   • 作為只有兩人的創業團隊，Inusan 和 Mojin 在面對技術挑戰和需求管理時，資源相對有限。如果專案需求持續增加，可能會超出他們的負荷，影響專案的按時完成。

5. 技術實現的可行性

   • 雖然他們已經對新的需求進行了詳細的規劃，但在實際開發過程中，仍可能遇到技術實現上的困難或不確定性，這需要他們保持靈活性和創造力來解決問題。

工具學習要點

1. Figma（持續學習與應用）

   • 設計與原型工具的探索：Inusan 持續學習 Figma，嘗試製作更複雜的線框圖和互動介面，為未來的設計溝通奠定更堅實的基礎。
   • 製作視覺化設計：Inusan 通過 Figma 製作更具體的禮盒選擇和推薦組合的介面原型，確保設計能夠真實反映用戶體驗，並在後續與 Bob 的會議中展示這些設計。

2. Ora（功能應用）

   • 撰寫與維護 PRD：使用 Ora 將 PRD 中的需求分解為具體的任務和子任務，並在專案管理工具中追蹤其進展，確保每個需求都能被有效實現。

3. 撰寫產品需求文檔（PRD）

   • 需求分析與文檔撰寫：Inusan 和 Mojin 需要熟悉 PRD 的撰寫方法，確保所有需求都被清晰、詳細地記錄下來，並且易於理解和實施。
   • 版本控制與需求變更管理：建立 PRD 的版本控制機制，記錄所有需求的變更歷史，並確保每次需求變更都有明確的溝通和確認過程，避免混淆和誤解。