編輯導語：當產品已經臨近上線時，領導又提出了另一個需求，而技術也沒有額外的人力支持時，產品經理該怎么做呢？本文作者分享了產品項目推進的不可能三角形，從時間、成本、質量三個方面分析，希望對你有所幫助。

“新增這個功能，必須跟最近的版本一起這周就上！”

“可是……技術沒有額外的人力支持……”

“我不管，這是老板要的?！?/p>

“……”

相信PM們都常常遇到上述對話的情況，明明已臨近上線時間，熊熊又追加了一個“老板”提的需求，領導要求一定要滿足，但技術同學已經疲憊不堪，這時身為PM的你該怎么辦呢？

這里無法用短短的一篇文字教會大家與領導溝通的技巧，但可以教給大家一個推動產品項目要素衡量的思路及框架，在與工作伙伴協調時，可通過這個框架，合理地平衡各方利益、并梳理項目情況讓工作伙伴明白，進而最大化地順利推進產品上線。

01 產品項目推進的不可能三角形

從來沒有一個項目可以在時間、成本、質量三方面最優的情況下完成產品上線。如果有，肯定是在你沒察覺的地方有所埋坑。

在成本投入最少時，想要保證高質量，則勢必需要拉長開發時間；而在要求高質量、時間周期短的情況下，則勢必需要投入更多成本。

三個要素中，固定任意要素后，另外兩要素有具有負相關，無法兩者同時達到最優。

而三個要素匯總仍可進一步細分為以下幾點。

1. 成本

• 人力成本：這個人力成本，不單只是投入人力的數量、工時，也包含了人力的質量，人力的投入多寡，便能影響產品完成的時間周期及質量。
• 資金成本：這產品開發是否有項目獎金的激勵？是否有對績效考核的明確影響？是否有足夠的服務器或設備投入？是否有資金請外援或第三方工具協作？
• 合作成本：項目能否復用公司內部的現有的資源？是否有關聯的中間件或SDK工具可以直接接入？是否能從第三方獲取資源節省開發成本？是否需配合內部或外部第三方協作開發？

2. 時間

• 設計時間：產品設計、UI設計、研發架構設計周期時間。

• 溝通時間：各類需求對接溝通、評審會等溝通時間。

• 開發時間：實際研發周期、測試周期等時間。

3. 質量

• 功能數量：需實現的迭代或新增的產品數量。

• 服務器效能：功能實現所消耗的服務器效能多寡。

• 代碼質量：代碼是否足夠簡潔？代碼邏輯是否自洽？代碼耦合度如何？是否有預留后續擴展空間？注釋是否清晰？

02 實際運用

當我們掌握了上述的框架后，如遇到開頭的情況：老板新增功能、上線時間不變，那么對應到不可能三角形上，我們就很清楚地知道能從這三方面著手思考。

1. 時間

通常上線時間，除非是有明確的時間節點（如雙十一、六一八、周年慶），或與公司內部其他部門協作，或與外部第三方協作，必須在固定的日期上線。不然正常新增需求下，都是可以要求增加開發周期的時間。

2. 質量

老板要求新增功能，領導也發話一定要開發了，【減少功能數量】那么是否在這個迭代版本中，是否有優先級不高的功能或需求可以暫緩呢？

而如果是到了最后收尾的階段，那么也沒有任何需求可以舍去的空間，那么也只能從資源上著手。

3. 成本

• 人力：是否能從其他部門調用更多人力投入研發、測試？
• 資金：是否有額外的項目獎金，激勵研發人員投入開發？
• 合作：老板要的新功能，是否能從公司內部或外部索取到相關組件，進行支持？

所以遇到老板追加需求、又要求時間按期上線，那么只能從資源這塊著手去溝通、協調。

向領導、技術leader或公司索要追加投入成本來完成，如果沒有順利索要到資源的話，你需明確地反饋給領導，功能實現的質量可能會不如預期，即使功能還是實現，還是會有以下的問題存在。

對技術而言，要將一個功能實現有很多方式能搞，在時間緊、意愿不高的情況下，通常就是功能實現方式耗能過高，在用戶大量使用下容易造成服務器崩潰。

或者，代碼沒有預留數據擴展性，造成后續迭代的難度增加，甚至需要重新設計數據表、刷數據庫等情況，為將來埋下一個大坑。

03 總結

雖然這次分享的內容看起來比較簡單，只要從三大方面去思考項目推進的情況，便能很容易地確定協調的方向及平衡各方要素的辦法。

但是實際執行時，還是很可能會受到其他的因素影響，不一定能順利推動項目達到預期的結果。

對于剛開始能獨立推進項目的PM，還是提供了最底層操作邏輯及基本的思考框架，能夠在遇到項目突發情況時，透過這個三角形的框架下，做出快度的判斷及方向，進行項目的溝通及協調。

本文由 @有趣的宣宣仔 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議