在繼續談 The F2E 之前，我想要分享一下自己做專案的歷程。在以前我在前公司上班時，絕大部分的流程就是會先出系統分析書(SA)、系統設計書(SD)。都做好後，就會開始請工程師、設計需依序加入開發。
這種又會稱作瀑布式開發，也就是前面流程做好，後面就依序步驟繼續做下去。
但在以前跑專案時，都常會有以下問題：
你要說當初 SA、SD 人員沒規劃好嗎？但在系統開發上，自然會遇到一些開發時才出現的預期外的問題，所以可能在開發中期才提早發現。此時的文件又可能得再衡量是否要修改，或者是系統是否需要大幅度調整。
所以當我自己當 PM 後，也是看了很多專案管理論，最後我的結論是依照團隊與專案性質不同，來導入適合的方法。硬是代入管理方法，有時反而不進則退。這觀念就很像寫程式一樣，你用了很多設計模式，以為自己很高大上，但最後維護管理時，發現其實根本不需要用到這些東西，反而造成自己維護上的困難，是共同的道理。
這裡我就來分享一下，我自己在規劃專案時用到的兩個心法。
所謂的重要里程碑，就是一個專案執行過程中，有哪些是重要的完成項目，若完成就表示你有完成一個小里程碑，最終大里程碑可能就是結案收款。
這樣團隊成員在推動專案時，也可以依照這些小里程碑的執行項目，知道自己得先朝向目標前進。
所以在這個專案上，我就設置了兩個里程碑，也就是以下兩個
使用者故事是我很愛用來討論「需求訪談」的方法，
他可以分析出此服務有哪些「角色」，他們可以在這個服務上做哪些事情。
我們用人力銀行來說好了，分成廠商跟求職者的角色，我們就來看看這兩個角色可以在平台上做哪些事。
而針對以上的角色能做到的是，你就可以思考要開發哪些功能，以符合角色能夠在平台上能順利操作功能。
像是這次的 The F2E 依照里程碑的規劃 user story 則是：
有很多人看到這裡，或許會疑惑說，「為什麼不一次到位就好？」，通常來說一次到位會有個風險存在於說，你開了越多功能給使用者時，往往也會有很多潛在 BUG 問題會被挖出來。
與其如此，不如先上一個版本讓挑戰者先 run ，確保系統穩定度與動線都沒問題後，之後依序上新服務來說，也不會有太多問題。
所以和共同創辦人討論過後，就決定先讓大家報名順便熟悉系統，之後大家投稿自己的作品也不會有操作上的問題。
這其實也有個開發弊病在於說，老闆都會希望所有功能一次到位，但真正上線才發現問題一堆，花了很多大錢最後都打水漂。與其如此，不如思考先做個最小可行性 MVP，確保有其市場再繼續迭代開發，風險控管也較好。
下個章節我們就將開始進入到「產品漸進開發」的章節勒 :D
iThome鐵人賽
看影片追技術