這篇文章在草稿躺了好久，好幾個月前想到這個主題，是因為自己手上剛好有幾個正準備大改版的產品，由於資源和時間有限，當初規劃時就有和主管討論到，是否可以不要一次到位，而是改用分批交付的方式實現這些需求。

文／MH

這篇文章在草稿躺了好久，好幾個月前想到這個主題，是因為自己手上剛好有幾個正準備大改版的產品，由於資源和時間有限，當初規劃時就有和主管討論到，是否可以不要一次到位，而是改用分批交付的方式實現這些需求。

如今過了一段時間，手上的產品陸續完成改版，總算有些實例和過程中學到的眉眉角角可以寫出來分享。不過，以下經驗僅限於網路產業（如網站、app 等形式的產品），硬體產品或其他產業就不一定那麼適用了。

為什麼要切階段？

一般來說，PM 會接到的需求粗分為 2 種：

1. 從零做出一個新產品
2. 既有產品的改版或迭代（優化某些功能、修 bug）

上述需求的規模可大可小，以 google map 這個產品舉例，如果今天收到的命題是「從零開始作出 google map」，這個需求是大還是小？

如果是要「做出有地圖功能、評價功能、在地嚮導社群、街景」的 google map，這個需求很大；但如果只是要「做出有地圖功能」的 google map，而先不要規劃到其他延伸的服務，那需求規模就稍微小了一點。

同樣地，如果今天接到的 google map 改版需求是「要增加對 c 端用戶收費的營利模式」，那這規模也不小，因為需要重新考量產品的整體策略，也得規劃該怎麼收費、哪些功能值得收費、定價方式等；但如果今天的需求只是「使用某 android 版本的用戶打開 google map、進行導航時會閃退」，這個 bug 相對明確，團隊要做的事情也有較清楚的輪廓，執行規模也比較小。

如果規模較大 — — 比如上面舉例的，要做出完整的 google map 以及要增加收費模式，因為其中涉及許多細節，模糊空間太多，團隊也很難給出所需人力與時間。再加上團隊的時間、人力、資金有限，在不確定成果的情況下，公司也不一定願意貿然一次投注這麼多資源到一個成果未知的案子，這時該怎麼辦才好？

什麼叫做「切階段」？

承接上一段，許多團隊的做法就是「切階段」。「切階段」大致上就是把一整個旅程（一個規模很大的任務）切出不同的步驟與里程碑，然後在每個步驟檢視其對應的目標。相較於一次到位，切階段的主要概念就是分批交付，也類似於「分期付款」的概念。

比如今天 A 欠了銀行 1,000 萬，但因為自己有一些理財規劃或侷限，比起一次清償 1,000 萬，「每月償還 5 萬」對於 A 會是較可行的做法，這也算是切階段概念的具體實現。

又或者繼續延伸上面的舉例，如果要把「做出完整的 google map」這項任務切階段，可以用功能分 — — 第一個月先做出地圖、第二個月再做導航、第三個月再做店家評價……等，也可以用地區分 — — 前半年先在美西上線，後半年擴大到美國其他地區，第二年才擴張到整個北美。

關於「切階段的方法」還有很多其他的方式，下面會舉其他例子。總之，「切階段」的目的就是要把原本規模太大、難以精準掌握並估算資源的任務給變小，以便團隊更精確地規劃每個階段要做的事情，並且能夠在更短的時間內看到該區間完成的成果。

切階段的幾種方式

上面講完了 what（什麼是切階段）和 why（為什麼要切階段），這段就來介紹 how（怎麼切階段）。

不過，切階段一定還有很多方式，每個產品與團隊也有各自的偏好和慣例，所以以下僅供參考，實際上的運用方式，仍得視情況而調整。

1. 依照功能＆重要性切分

就像前面提到的，如果在 2004 年的我們想要做出和此刻（2022）年有著一樣功能的 google map，要一次到位恐怕是有極高難度的，這時或許可以先把 google map 拆成不同的功能模塊，比如有搜尋、地圖、導航、店家評價等功能，然後先挑出比較核心的功能來做。

這個概念也類似於 “MVP (Minimum Viable Product，最小可行性產品)”，也就是先找出「這個產品非有哪個功能不可」、這個產品的核心功能是什麼，然後就先做好這個功能並把產品推上線。上線之後，再根據用戶的回饋和使用心得，進一步了解其使用情形，再繼續優化並迭代產品、增加其他功能。

再舉個例子，我目前負責的公司內部產品之一是目標訂定工具，目的是要讓公司員工可以在這個產品裡面設置團隊與個人的 OKR，並且追蹤其進度，進而讓團隊與組員間可以更了解彼此的目標，並且因此達到更好的團隊協作。

根據這個目標，我們在前期規劃的時候就決定，這個工具最核心的功能就是要讓用戶能夠設置並管理 OKR，其他延伸的功能 — — 如用戶可以針對其他人的 OKR 留言、公司內部的通訊軟體也要整合此工具，以便提醒用戶定期更新 OKR、用戶可設定自己的 OKR 要給哪些人看到等，我們先放進產品 backlog，等這個產品上線之後，再依照用戶反饋決定是否要往下做。

這樣做的好處是，產品團隊（PM、設計師、工程師等）都很清楚這個 OKR 產品的 MVP 會長成什麼樣子，因為功能很明確，設計與工程師可以給予精準的估時，也讓作為 PM 的我較能把控專案時程，減少產品延後上限或需要追加人力的情況。

此外，「切階段」也讓 PM 可以對主管做一些「需求管理」，因為產品範圍很明確了，主管知道第一期產品會有哪些功能、沒有哪些功能，所以也稍微可以預期用戶可能會有哪些反應（可能會抱怨為什麼沒有 XX 功能）。當大家的預期是一致的，便能在同一個基礎上溝通。

如今產品上線超過半年，我們後續也已進行了三、四次大大小小的迭代，有趣的是，有些新增的功能是我們當初沒有想過、後來根據用戶反饋才知道很重要的，有些功能則是當初放進 backlog 裡，後來也發現沒有用戶需要（或者需求程度沒有其他功能高），所以至今也沒拿出來做的。

2. 依照裝置切分

另一個常見的方式則是根據「裝置」來切階段，比如網站 vs. app、ios vs. android 等。比如我現在做的內部產品，可能因為用戶多半需要在這些工具裡面執行複雜的操作，比如訂定目標、寫年終考核、進行產品內容翻譯等，所以整體來說，大概超過 50% 的產品都只有桌面版網站，沒有手機版網頁也沒有 app。

不過，隨著這些內部產品被使用得越來越普及、用戶越來越熟悉，最近也開始有用戶反映希望能增設手機版網站或 app（PM：放過我吧……）。

我手上還有另一個內部產品，它的用途就是內部的 app store/google play，也就是讓內部員工可以下載公司旗下與內部相關的 ios/android app。在這個使用情境下，一般員工通常只需要登入手機版網站去搜尋和下載所需 app，電腦版網站則是留給需要管理 app 的人使用，比如編輯 app 名稱與描述、上傳或下架某個版本等。

根據上述情形，我們這陣子在做 UI 改版和後端程式碼重構時，就依此切出了 4 個階段：

1. 第 1 階段：桌面版網站的權限控管相關功能與頁面（比如新增或移除某些權限給指定用戶）
2. 第 2 階段：手機版網站的權限控管相關功能與頁面
3. 第 3 階段：桌面版網站的 app 管理相關功能與頁面（比如編輯 app 名稱與描述、上傳或下架某個版本）
4. 第 4 階段：手機版網站的 app 管理相關功能與頁面

值得一提的是，雖然團隊把「產品改版」這個大案子切成四個階段，但並非每完成一個階段就會先把這個階段的實作內容推上線，我們其實還是會一次把這四個階段推上線。有人可能會問：「既然這樣，為什麼還要切階段？」

當時的背景是剛好團隊的 QA 人力也不夠……如果一次要請 QA 測完四個階段，不只很花 QA 的時間，工程師可能也會一次要修一堆 bug，既然這樣，不如讓 QA 一次測一個階段，工程師一次會收到的 bug 回報也比較少，這樣也比較不會影響到後續其他幾個階段的開發時程。

如今團隊終於完成這四個階段，中間還發生一個小插曲，就是負責這個案子的工程師之一離職了……雖然很遺憾要跟一個夥伴說掰掰，但同時也慶幸最初規劃時有切階段，因為當時已經做完前三個階段的東西了，接手的工程師只要從第四階段開始就可以，進入狀況的門檻比較低，也不用花太多時間上手。

3. 依照需求端死線切分

另外一種我常（被迫）用的切階段方式，就是依照需求端壓的死線來切分。說白了就是「看需求端會先用到哪個功能，就先做哪個功能」。

或許有人會想說：「內部產品也會被死線追著趕嗎？」雖然大多數的內部產品沒有營收壓力，不用像電商或旅遊產業追著特定節慶或時事跑，但公司內部仍會有固定的時程，比如上市公司會有財報公佈的時間點、年度營收結算的時間點，訂定 OKR 也有每季或每月的時間點、員工考核則有半年或一年的時間點等，所以內部產品也會有對應的死線。

以我最愛又最恨的員工考核工具為例，最恨是因為它的死線不可撼動，公司就是要在某月某日開始全員考核，負責考核的人資壓力也很大，產品團隊壓力也很大，因為人資提出來再難搞的需求都得在那個時間點前完成；但最愛也是因為這樣（到底是多被虐），因為有很明確的時間線和需求，讓我和團隊也在更有壓力的情況下完成開發，而且開發的功能真的會有很多人用，所以其實蠻有挑戰性、也蠻有成就感的！

對於這類「死線嚴明」的產品，前兩種切階段的方式就不太實用了，因為對於人資來說，他們就是「我全都要」的真實寫照，不能用功能＆重要性切分，也不能用裝置區分，因為每個功能都要、每個功能都很重要！但偏偏時間就是不夠用（詳列下表），所以這時就得列出時程表，從開始全員考核的某月某日回推，逐步規劃產品團隊的時程。

情境：

• UX 估時 5 天
• UI 估時 5 天
• dev 估時 15 天（功能 1 估時 3 天、功能 2 估時 2 天…etc）
• QA 估時 8 天

然而，人資說公司的考核在 8/22 就得開始，若依照上述的估時，等於 dev 才剛做完 6 個功能後，QA 還沒有時間好好測試，就得把這些新功能推上線了……

這時解法有很多個：

(1) 壓縮各單位的估時

這應該是最常見也是對於 PM 最容易的解法，比如請 UX 和 UI 各少一天、dev 也少做幾天，這樣就有時間把 QA 塞進來，但這通常也是讓各單位壓力最大的解法，因為就等於逼迫大家加班或犧牲工作品質。

(2) 各單位同時工作

這跟「切階段」的概念有點類似，就是請各單位分批交付手上的東西，比如 UX 完成前三個功能後，就先交給 UI 去畫畫面，與此同時，UX 可以繼續規劃後面三個功能，等完成後，UI 的前三個畫面也畫完了，就可以接著做後面三個功能的畫面。同樣地，在 UI 畫最後三個畫面的時候，dev 也可以先做前三個畫面的東西，而當 dev 完成後、要接著做後三個畫面時，QA 也可以先測前三個畫面。

這個方法有時不失為一個好解法，但有時如果這些功能是環環相扣，甚至邏輯會彼此影響或有所關聯（比如改一會影響二、動三的邏輯會影響功能四的運作），那就不一定能切得這麼乾淨，這個方法就不適用了。

如果上述兩方法都不太合適，那或許可以先試試「把死線切階段」。

以上面的例子來說，即使人資要求這次考核系統中需要增加 6 個新功能，並且說 8/22 時要進行全員考核，但不代表「這 6 個功能得在 8/22 前，全部都做好並上線」。

「考核」聽起來是一個動作，但其實是一個牽涉許多階段的流程，包含但不限於：

員工寫考核 > 小主管瀏覽考核內容 > 員工和小主管一對一面談 > 大主管確認考核結果 > 人資統一公佈考核結果 > 員工瀏覽考核結果

所以可以依照這個流程，再去對照上述 6 個新功能是在哪一個階段會被需要用到，比如功能一是「員工在寫考核時，可以夾帶 word 檔與圖檔」、功能二是「小主管瀏覽考核內容時，可以另外撰寫評論」、功能三是「人資公佈考核結果時，可以順帶發出信件提醒」。

這樣看下來，會發現功能一會最早被使用者用到，其次是功能二，功能三則是在考核結果被公佈時，才會使用到的功能。也就是說，依照時程看來，功能一需要被最早完成並上線，功能二三則可以稍晚上線。

掌握這些「功能會被真正使用到」的關鍵資訊後，就會發現「死線不只有一個」，PM 就可以回頭跟人資（需求端）商量死線，比如 8/22 之前先完成功能一，等到 8/22 的下週一再完成功能二，以此類推。所以新的時程表可能會長這樣：

可以看到 UX、UI、dev 開發的時間一樣，但 dev 修 bug 以及 QA 測試的時間更寬裕了，且還是一樣能符合需求端期待的死線。

結語

比起壓縮每個單位的工作時間甚至犧牲品質，或者請各單位同時工作，上述 3 種（依照功能＆重要性切分、依照裝置切分、依照需求端死線切分）是我較偏好的切階段方式。

想另外強調的是，有時並不一定是受限於死線才切階段，而是產品團隊也想要「快速迭代、迅速驗證、小步試錯」，所以會刻意把開發時程切得比較碎，以便在短時間內完成某個規模小但重要的功能，藉此趕快收集到用戶使用心得。

不過也要注意的是：不要為了切階段而切階段。「快」並不一定好，也不一定適合每個團隊。或許有的團隊願意投注較多時間人力，長期打磨一個產品，直到近於完美才上線，所以「分批上線、逐步驗證」反而跟團隊追求的「職人精神」相悖。

總之，每個團隊與公司都有自己的開發文化與精神，也有自己的習慣和流程，所以還是老話一句：沒有一個方法能適用於所有團隊，所以也沒有所謂「最理想」的開發方式，最重要的還是找到最適合團隊的工作方式，大家用得順手、能達成集體目標，那才是對團隊最好的選擇。

這篇文章 被死線追到快瘋掉？專案規模太大？切階段的幾種方法 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

產品是由某個角色主導，還是大家討論出來有共識的結果？公司的文化是追求創意還是效率？今天這篇文章會先將職位依照象限來做劃分，然後再從工程師的角度跟大家分享話語權這件事。

文／林鼎淵

產品是由某個角色主導，還是大家討論出來有共識的結果？公司的文化是追求創意還是效率？今天這篇文章會先將職位依照象限來做劃分，然後再從工程師的角度跟大家分享話語權這件事。

ㄧ、認識職位象限

一個人可以走得很快，但一群人才能走得更遠；如果公司只有其中一個類型的人才，那在運營上面就很容易侷限在某個思維中。

二、公司的做事文化

在看完上面的象限後，我們回過頭來思考自己的公司是如何推出一個產品的。

➤ 會議上話語權過度集中
有些會議僅管邀請大家出席，但大多數的話語權還是掌握在「產品經理」身上，大家都是依照他的意志去完成任務。

這樣的做法會非常有「效率」，如果產品目標明確且沒有太多需要「思考」的地方是真的很棒。

但這樣的做法很容易會有盲點，因為「一個大腦」在面臨複雜需求時肯定會有考慮不周全的地方。

➤ 每個人捍衛自己的想法
在不同角色下，面對同一個問題，每個人可能都有自己的答案；這個答案站在各自的立場上可能「全部都是正確的」。

如果組織中缺乏一個有決斷力的角色將這些「創意」整合，往往會造成非常多的無效會議，或是專案過度設計。

所以要如何平衡兩者，真的就是看每間公司的智慧與業務取向了。

三、工程師的話語權

因為筆者與朋友都是工程師，所以會分享從現實生活中看到，工程師天生話語權較弱的問題。

➤ 工程師真的有話語權嗎？
因為曾經兼任過產品經理、專案經理，所以對這塊真的很有感受；當你提出的需求被工程師質疑時，在心理上會產生一種防衛狀態，這種狀態可能會刺激你堅持自己的主見，想辦法用其他證據說明自己是對的，卻忽略對方提出的可能也是對的。

大部分的工程師在自己提出的想法被拒絕後，絕大多數以後就不太會再提出想法了，因為他們會覺得反正都會被打槍，我為什麼還要沒事找事做，做好公司認為我的「本分」就好了。

➤ 工程師適合有話語權嗎？
工程師在收到奇耙的需求時，會覺得這個天馬行空的需求真的做下去肯定會出事，有責任心的工程師會跟產品經理反應這個需求不妥當，但大多數的狀況下，他們最容易收到的回覆是：「你不懂用戶跟數據，做就對了。」

有些需求是源自於用戶與數據，但並不是每個產品經理都會將這些來龍去脈都寫在需求文件上，大部分只是希望工程師按造自己的想法做事。

的確大部分的工程師光是開發就需要消耗非常多的時間，他們不了解用戶與數據是很正常的，但這塊的「資訊不對等」造就他們就算提出想法，也很容易被冠以「無知」做為結局。

➤ 工程師只要當個程式設計師嗎？
工程師（Engineer）跟程式設計師（Programmer）乍看之下非常像，但筆者認為兩者的職責是有差異的。

工程師（Engineer）更具備對於一個專案的宏觀思維，他會參與討論與規劃，別人也願意聽取他的意見來做分析；而程式設計師（Programmer）更像是聽命辦事，做好自己份內的工作，不具備組織內影響力。

➤ 資深工程師是一個很特殊的角色
不過如果你是一個對用戶、數據、產品都有深刻理解的「資深工程師」，很有可能擁有與眾不同的話語權，你的「江湖地位」讓其他人願意花更多的時間來聽你說話。

我覺得這就像是軍中的士官長僅管階級比軍官低，但軍官還是願意聽取士官長給的建議。

這篇文章 談談工程師的話語權 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。