產品無法順利推進怎么辦?一個三角形替你排憂解難
編輯導語:當產品已經臨近上線時,領導又提出了另一個需求,而技術也沒有額外的人力支持時,產品經理該怎么做呢?本文作者分享了產品項目推進的不可能三角形,從時間、成本、質量三個方面分析,希望對你有所幫助。
“新增這個功能,必須跟最近的版本一起這周就上!”
“可是……技術沒有額外的人力支持……”
“我不管,這是老板要的。”
“……”
相信PM們都常常遇到上述對話的情況,明明已臨近上線時間,熊熊又追加了一個“老板”提的需求,領導要求一定要滿足,但技術同學已經疲憊不堪,這時身為PM的你該怎么辦呢?
這里無法用短短的一篇文字教會大家與領導溝通的技巧,但可以教給大家一個推動產品項目要素衡量的思路及框架,在與工作伙伴協調時,可通過這個框架,合理地平衡各方利益、并梳理項目情況讓工作伙伴明白,進而最大化地順利推進產品上線。
01 產品項目推進的不可能三角形
從來沒有一個項目可以在時間、成本、質量三方面最優的情況下完成產品上線。如果有,肯定是在你沒察覺的地方有所埋坑。
在成本投入最少時,想要保證高質量,則勢必需要拉長開發時間;而在要求高質量、時間周期短的情況下,則勢必需要投入更多成本。
三個要素中,固定任意要素后,另外兩要素有具有負相關,無法兩者同時達到最優。
而三個要素匯總仍可進一步細分為以下幾點。
1. 成本
- 人力成本:這個人力成本,不單只是投入人力的數量、工時,也包含了人力的質量,人力的投入多寡,便能影響產品完成的時間周期及質量。
- 資金成本:這產品開發是否有項目獎金的激勵?是否有對績效考核的明確影響?是否有足夠的服務器或設備投入?是否有資金請外援或第三方工具協作?
- 合作成本:項目能否復用公司內部的現有的資源?是否有關聯的中間件或SDK工具可以直接接入?是否能從第三方獲取資源節省開發成本?是否需配合內部或外部第三方協作開發?
2. 時間
- 設計時間:產品設計、UI設計、研發架構設計周期時間。
- 溝通時間:各類需求對接溝通、評審會等溝通時間。
- 開發時間:實際研發周期、測試周期等時間。
3. 質量
- 功能數量:需實現的迭代或新增的產品數量。
- 服務器效能:功能實現所消耗的服務器效能多寡。
- 代碼質量:代碼是否足夠簡潔?代碼邏輯是否自洽?代碼耦合度如何?是否有預留后續擴展空間?注釋是否清晰?
02 實際運用
當我們掌握了上述的框架后,如遇到開頭的情況:老板新增功能、上線時間不變,那么對應到不可能三角形上,我們就很清楚地知道能從這三方面著手思考。
1. 時間
通常上線時間,除非是有明確的時間節點(如雙十一、六一八、周年慶),或與公司內部其他部門協作,或與外部第三方協作,必須在固定的日期上線。不然正常新增需求下,都是可以要求增加開發周期的時間。
2. 質量
老板要求新增功能,領導也發話一定要開發了,【減少功能數量】那么是否在這個迭代版本中,是否有優先級不高的功能或需求可以暫緩呢?
而如果是到了最后收尾的階段,那么也沒有任何需求可以舍去的空間,那么也只能從資源上著手。
3. 成本
- 人力:是否能從其他部門調用更多人力投入研發、測試?
- 資金:是否有額外的項目獎金,激勵研發人員投入開發?
- 合作:老板要的新功能,是否能從公司內部或外部索取到相關組件,進行支持?
所以遇到老板追加需求、又要求時間按期上線,那么只能從資源這塊著手去溝通、協調。
向領導、技術leader或公司索要追加投入成本來完成,如果沒有順利索要到資源的話,你需明確地反饋給領導,功能實現的質量可能會不如預期,即使功能還是實現,還是會有以下的問題存在。
對技術而言,要將一個功能實現有很多方式能搞,在時間緊、意愿不高的情況下,通常就是功能實現方式耗能過高,在用戶大量使用下容易造成服務器崩潰。
或者,代碼沒有預留數據擴展性,造成后續迭代的難度增加,甚至需要重新設計數據表、刷數據庫等情況,為將來埋下一個大坑。
03 總結
雖然這次分享的內容看起來比較簡單,只要從三大方面去思考項目推進的情況,便能很容易地確定協調的方向及平衡各方要素的辦法。
但是實際執行時,還是很可能會受到其他的因素影響,不一定能順利推動項目達到預期的結果。
對于剛開始能獨立推進項目的PM,還是提供了最底層操作邏輯及基本的思考框架,能夠在遇到項目突發情況時,透過這個三角形的框架下,做出快度的判斷及方向,進行項目的溝通及協調。
本文由 @有趣的宣宣仔 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議
文章很棒,上次看到之后有個印象在團隊協調時候用到了,今天回來再讀一遍,加強了印象
確實是,有時候真的就感覺到很無奈,看見這篇文章,對其他的事情也有了一些醒悟的呢。
贊~~ 很高興能讓你有些啟發
開心??