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

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

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

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

“……”

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

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

01 產(chǎn)品項目推進(jìn)的不可能三角形

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

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

三個要素中，固定任意要素后，另外兩要素有具有負(fù)相關(guān)，無法兩者同時達(dá)到最優(yōu)。

而三個要素匯總?cè)钥蛇M(jìn)一步細(xì)分為以下幾點。

1. 成本

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

2. 時間

• 設(shè)計時間：產(chǎn)品設(shè)計、UI設(shè)計、研發(fā)架構(gòu)設(shè)計周期時間。

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

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

3. 質(zhì)量

• 功能數(shù)量：需實現(xiàn)的迭代或新增的產(chǎn)品數(shù)量。

• 服務(wù)器效能：功能實現(xiàn)所消耗的服務(wù)器效能多寡。

• 代碼質(zhì)量：代碼是否足夠簡潔？代碼邏輯是否自洽？代碼耦合度如何？是否有預(yù)留后續(xù)擴(kuò)展空間？注釋是否清晰？

02 實際運用

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

1. 時間

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

2. 質(zhì)量

老板要求新增功能，領(lǐng)導(dǎo)也發(fā)話一定要開發(fā)了，【減少功能數(shù)量】那么是否在這個迭代版本中，是否有優(yōu)先級不高的功能或需求可以暫緩呢？

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

3. 成本

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

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

向領(lǐng)導(dǎo)、技術(shù)leader或公司索要追加投入成本來完成，如果沒有順利索要到資源的話，你需明確地反饋給領(lǐng)導(dǎo)，功能實現(xiàn)的質(zhì)量可能會不如預(yù)期，即使功能還是實現(xiàn)，還是會有以下的問題存在。

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

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

03 總結(jié)

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

但是實際執(zhí)行時，還是很可能會受到其他的因素影響，不一定能順利推動項目達(dá)到預(yù)期的結(jié)果。

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

本文由 @有趣的宣宣仔 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議