軟體業善用專案管理思維做產品開發的時機點
這篇文章將帶您探索產品開發和專案管理的世界，就像我們一起踏上一段新的旅程一樣！我們將聚焦在敏捷和瀑布式管理，並分享如何在現實生活中應用這些方法。無論您是新手還是老手，這裡都有豐富的內容和實用的指南，幫助您應對各種挑戰。跟著我們一起探索，讓我們一起來發現成功的秘訣吧！
一、簡述產品開發與專案管理的方法
耳熟能詳專案管理方法不外乎敏捷式管理（Agile）、瀑布式管理（Waterfall）、精實管理、隕石管理等常見模式，今天這篇我們先著重 Agile 和 Waterfall 兩種模式可以做的變形。文至於此，可能會有讀者想到該不會又是來戰這兩個的優缺點，或是不就是敏捷式管理比較好能夠應對市場嗎。今天我們要談的是「當你遇到這種情境，或許可以用這樣的專案管理」。
首先我們都知道專案管理不外乎時程、成本、資源，當資源與時程被固定後，我們剩下能改動的只有範圍，如果範圍又不斷再蔓延，接下來就是不斷在有限的時間壓榨出更多的資源產出，這就是所謂的 Waterfall。當然這也是為何逐漸提倡 Agile，我們先把範圍固定，接下來就是依據每個 Sprint 的週期，看我們要有多少個週期與人數，逐漸地把這個範圍完成，交付給市場。
在真實的世界中，我們可能會遇到的是以下案例
- 案例A: 我們要做一個新的 2C 產品，老闆期待我們的產出
- 案例B: 我們要做一個 2B 的 SaaS 產品，但是某某客戶簽約要一年後完成，而且客戶還是有部分客製化要處理
這時候我們遇到的問題會是什麼，無論你是 Boss-driven, Market-driven, Customer-Driven 等因素，除了你是客戶簽約以外，沒有人會告訴你什麼時間會完成多少內容，可惜市場是無情的、老闆是深思熟慮的，在每個多變環境的心中都會有一把尺，所以這產品什麼時候要完成？
接下來的步驟，可能會進行的是，那我們開始規劃出 MVP，以及第一個 Sprint 的做什麼，如果這最小可交付範圍會到三個月後，那我們更不用管後面的功能或是 User Story。這說法，是對，也是不對。對的在於的確是依據市場期待而逐漸變化產品方向，不對的方向是什麼時間點才叫做好的時間點，半年後就可以給老闆滿意嗎？一年後就可以準時交給客戶嗎？
在這時機點，必然會有人說，敏捷管理就是不適合 B2B 的交付模式啊，除非客戶願意跟我們一起跟著 Sprint 交付，並且合約也是依據 Sprint 而改動。理想是美好的，現實是骨感的。當沒有這樣的客戶時，我們又該怎麼樣在有限的時間下完成老闆或客戶的期待呢？當我們是以 Sprint 的方式給老闆與客戶，我們能知道這個開發的投報率是多少嗎？或是客戶如果同意固定範圍下的敏捷做事，不就是根據 Sprint 給錢，就是買團隊的時間，而未必是團隊的價值嗎？（當然會依據跟客戶的簽約模式）
二、實作方式
Step 1: 畫線範圍，講出期待
MVP具象化是正確的第一步，但首要目標是要明確認定MVP的範圍。這個範圍可能由老闆、市場或客戶來定義，因此我們需要知道MVP的具體內容。然而，描述MVP的方式是一個挑戰，太過粗略會使其缺乏細節，而太過細節則可能會導致後續開發過程變得過於僵化。細節層面的決定則需要不斷與利害關係人進行溝通和調整。
原則一：展開大類別功能並且簡述要有什麼效益，目標是以大類別功能為主，並簡要描述其效益，這種描述方式可以視為Epic層級。例如，我們可以設想要實現購物車功能以方便用戶最終完成信用卡支付，或者設計商品展示頁面讓用戶可以收藏、評論等。
原則二：不要將產出限制在SPEC或PRD上，而是進行項目拆解。因此，在這個階段只需要少數的設計師和工程師站在他們的角度來評估最合適的描述方式。
Step 2: 估不準的估時還是要做
當我們畫出100個大功能時，接下來的步驟是請工程師們估時。雖然這時候的估時可能還不夠細節或完善，但這是有意義的。這樣做的目的是為了了解我們畫出的線與預期的基準線之間的大致差距，以及開發所需的時間和資源。因此，這一步的原則是讓核心團隊估點並確定關鍵的相依性，這樣我們才能更好地理解還有哪些模糊地帶需要釐清。例如：這個開發是 10 個人月、100 個人月、500 個人月的哪個等級呢。
好的假使我們這時候得到 Backend 是 50 個人月、Web 80 個人月、iOS/Android 各為 40 個人月，並且知道這 100 個功能都是怎麼被分佈的。
原則：請核心團隊估點並且寫出關鍵相依性。這才會讓我們知道原來還有哪些關鍵的模糊地帶必須釐清，否則會大幅度影響我們的產品規劃。
Step 3: 計算團隊的能耐
估時完成後，開始普遍專案管理的計算方式，如果我們要交付的是 6 個月後，則 QA 驗證單位是一次性驗證還是階段性驗證，假設最後整合驗證需要 1 個月，則我們只有 5 個月的開發時間，很明顯可以計算出 Backend 需要 10 個人、Web 16 個人、iOS/Android 8 個人。喔不，這不就是人月神話嗎，團隊怎麼可能剛好用人月的角度去開發，而且每個開發者的能力不同，這樣用怎麼會有意義。
原則：讓我們看到大致情境後來做 Step 4 的資源與範圍調整
Step 4: 初步計算目標達成的可能性
數字很重要、數字很重要、數字很重要。
有數據支持才能向老闆爭取資源、在內部討論時調整範圍、向客戶提出階段性交付的建議。即使估算不準確，至少我們有一個基準來評估。在第三步中，每個團隊所需的人力需求相當可觀，我們需要考慮公司是否擁有足夠的人力資源來滿足這些需求。如果不夠，我們可以採取以下措施。
- 砍期望：改變一下思路，我們可以先列出優先順序，如果我們提前完成了高優先項目，再來專注處理較低優先項目。
- 取資源：當無法減少期望或減少的幅度不夠時，就意味著我們實在無法完成所有任務。這時，我們可以採取一些行動，如調配內部專案資源、外包協助、招聘新人等。
- 調整時間：由於總有無法完成的任務，因此與客戶或老闆協商在合約或市場期望上的階段性交付至關重要。Step 5: 開始開發後的調整
Step 5: 依據 Sprint 調整團隊的資源、期望的範圍
敏捷開發中，Refinement和Planning都是必不可少的。當然，我們也需要對規格進行細化後的估點，以便比較此時的估點與第二步的估時之間的差距。此外，在Sprint結束後，我們還需要檢查團隊是否能夠如期完成認領的工作點數。如果工作無法如期完成，則可能是由於開會過多、功能複雜度高、溝通不暢、資源不足等原因所致。這些問題可以在Retrospective會議中或平時被反映出來，而這些反饋也都有了數據支持，可以進一步根據 Step 3 和 Step 4 進行調整。
三、結論
過去有網友的經驗在某些公司沒有透過這種方式實作產品，最後多是產品 1–2 年後甚至更久才做完，原因很簡單的是，沒有數字所以團隊成員常常被拉去更有錢的專案或產品開發、沒有人知道到什麼才是合適的一段落就不斷做做做、等到做到一段落才發現不符合市場需求而砍掉重練。
有機會再跟讀者們分享筆者我的經驗，至少用這些方式去滿足老闆、客戶、市場的期待是滿有用的。
如果你喜歡這篇文章，歡迎多拍拍手👏，讓我們多多互動。
1. 👏[1個拍手] — 如果你單純路過
2. 👏👏[2-N個拍手] — 如果你喜歡這篇文章
3. 👏👏👏[50個拍手] — 如果你希望看到類似的內容
有任何互動或想法，歡迎寄信聯絡我：ctianchen886@gmail.com
