在繼續談 The F2E 之前，我想要分享一下自己做專案的歷程。在以前我在前公司上班時，絕大部分的流程就是會先出系統分析書(SA)、系統設計書(SD)。都做好後，就會開始請工程師、設計需依序加入開發。

這種又會稱作瀑布式開發，也就是前面流程做好，後面就依序步驟繼續做下去。

但在以前跑專案時，都常會有以下問題：

• 需求時常變更，搞得大家人仰馬翻。
• 最後準備要結案時，規劃的項目不符合業主需求，Loading 全都壓在最後面的時間，加班變成常態

你要說當初 SA、SD 人員沒規劃好嗎？但在系統開發上，自然會遇到一些開發時才出現的預期外的問題，所以可能在開發中期才提早發現。此時的文件又可能得再衡量是否要修改，或者是系統是否需要大幅度調整。

所以當我自己當 PM 後，也是看了很多專案管理論，最後我的結論是依照團隊與專案性質不同，來導入適合的方法。硬是代入管理方法，有時反而不進則退。這觀念就很像寫程式一樣，你用了很多設計模式，以為自己很高大上，但最後維護管理時，發現其實根本不需要用到這些東西，反而造成自己維護上的困難，是共同的道理。

這裡我就來分享一下，我自己在規劃專案時用到的兩個心法。

重要里程碑

所謂的重要里程碑，就是一個專案執行過程中，有哪些是重要的完成項目，若完成就表示你有完成一個小里程碑，最終大里程碑可能就是結案收款。

這樣團隊成員在推動專案時，也可以依照這些小里程碑的執行項目，知道自己得先朝向目標前進。

所以在這個專案上，我就設置了兩個里程碑，也就是以下兩個

• 第一階段 (6/10發佈活動)
  • 挑戰者可以註冊平台，並報名第二屆活動
  • 第一屆舊資料倒入平台，並可以觀察歷史資料
• 第二階段 user story(7/8正式開賽 - 以投稿流程與分享進行優化)

user story (使用者故事)

使用者故事是我很愛用來討論「需求訪談」的方法，

他可以分析出此服務有哪些「角色」，他們可以在這個服務上做哪些事情。

我們用人力銀行來說好了，分成廠商跟求職者的角色，我們就來看看這兩個角色可以在平台上做哪些事。

廠商

• 可以在平台上刊登職缺
• 可以管理有應徵的人才們，並透過平台邀請他們來面試
• 可以觀看履歷系統，主動尋找人才

求職者

• 可以在平台上撰寫履歷
• 可以在平台上尋找職缺
• 可以投遞履歷給廠商

而針對以上的角色能做到的是，你就可以思考要開發哪些功能，以符合角色能夠在平台上能順利操作功能。

像是這次的 The F2E 依照里程碑的規劃 user story 則是：

• 第一階段 user story (6/10發佈活動)
  • 挑戰者可以註冊平台，並報名第二屆活動，並可以選擇要參加的類別(前端、UI 組)
• 第二階段 user story
  • 我已報名，針對關卡進行投稿 (7/8正式開賽 - 以投稿流程與分享進行優化)
    • UI 設計師
      • 關卡
      • 線上標示文件網址
      • og:image(1200*628)
    • 前端工程師
      • 關卡
      • codepen網址
  • 我可以對 UI 設計師的作品
    • 按愛心
    • 採用
  • 我可以對前端工程師的作品
    • 按愛心

小結

有很多人看到這裡，或許會疑惑說，「為什麼不一次到位就好？」，通常來說一次到位會有個風險存在於說，你開了越多功能給使用者時，往往也會有很多潛在 BUG 問題會被挖出來。

與其如此，不如先上一個版本讓挑戰者先 run ，確保系統穩定度與動線都沒問題後，之後依序上新服務來說，也不會有太多問題。

所以和共同創辦人討論過後，就決定先讓大家報名順便熟悉系統，之後大家投稿自己的作品也不會有操作上的問題。

這其實也有個開發弊病在於說，老闆都會希望所有功能一次到位，但真正上線才發現問題一堆，花了很多大錢最後都打水漂。與其如此，不如思考先做個最小可行性 MVP，確保有其市場再繼續迭代開發，風險控管也較好。

下個章節我們就將開始進入到「產品漸進開發」的章節勒 :D