砍需求可以，不要砍我啊……

產品不是功能的集合，每個產品都存在其精神的部分。一個產品要加多少的功能，才能成為一個垃圾產品啊！——Allen Zhang

初識這句話的時候，沒有什麼很大的感觸，現在卻想拍手叫絕，深以為然。

時光退回到一年以前，在當時參與的一個項目中，為了提高用戶的使用頻次，增加用戶黏度，產品上線了一些新功能。然而上線之後卻發現新功能使用率慘淡，換言之，我們做了一些對用戶沒什麼價值的功能。

當初以為這只是個別的現象，後來在和其他同行交流的時候發現這種情況其實還是比較常見的，最終導致的結果就是稀里糊塗的做了不少功能，整體的投入產出比卻很低。

所以我就在想有些需求能不能根本就不做，或者說在資源排期過滿的情況下就適當的砍一些需求。很多情況下資源本身可能就是一直不充足的，排期過滿導致的直接結果可能就是要經常加班，那加班如果也解決不了怎麼辦？通常的做法就是加人，而加人在很多時候可能也解決不了問題…

首先加人是需要額外成本的，其次加人也不一定能夠保證效率和進度，而且加人之後團隊協作的成本會更高，甚至可能會引發團隊內部衝突，那怎麼辦？所以我就在想，從源頭上入手是否可行，也就是合理的去砍掉一些需求。

為什麼要砍需求

可能大家都聽過一些段子，比如什麼這個需求很簡單，怎麼實現我不管，明天上線。比如砍我可以，不要砍需求…比如這個需求根本實現不了等等，似乎大家聽到的大都是關於如何提需求的，而很少聽到砍需求的，所以我就闡述一下我認為要砍需求的理由。

二八法則

二八法則指出在任何一個東西中， 最重要的部分只佔一小部分，約佔20%左右，剩下的80%，雖然是多數的，但卻是次要的。（PS：不一定是嚴格的20%與80%的關係，也可能是10%與90%或者30%與70%的關係）

二八法則的核心思想在於少數關鍵原則，即佔比較少的一部分反而可能是比較關鍵的，其實這種冪律法則是一個具有普適性的規則。不信你可以粗略的去看下全世界80%的財富集中在約幾%的人手中，互聯網與移動互聯網80%以上的市場份額被幾%的公司佔據，一個公司80%的利潤來源於幾%的業務…

洋洋洒洒扯了那麼多，就是為了引出二八法則這個理論，可以看下你們家的產品的使用情況，是不是約20%的功能佔據了用戶使用時長的近80%，是不是約20%的用戶貢獻了近80%的營收呢，前者通常被我們叫做核心功能，後者通常被我們稱為核心用戶。

既然這樣，那我們是不是需要優先打磨這20%的功能，優先滿足這20%核心用戶的核心需求呢。產品並不是簡單的功能堆砌，用戶體驗也不是簡單的功能疊加，我們需要先將核心功能打磨到90分，然後再想辦法優化其他的功能，而不是做一堆60分的功能給用戶。

在現在這個豐饒經濟的時代，產品早就面臨著功能/性能過剩的局面，用戶不太可能因為你的功能較多而使用你的產品了，最重要的是你能滿足用戶的哪些需求以及對應需求的滿足程度如何…

你是願意選擇一款功能多而齊全，但是樣樣都不精的瑞士多功能軍刀呢，還是願意選擇一款小而美的軍刺呢?

素材來源於互聯網

限制與聚焦

理論和實際之間有一個非常大的區別，那就是理論通常是建立在各種假設基礎之上的，屬於非常理想化的情景，而實際情況可能面臨著各種各樣的制約條件，比如沒各種資源、沒人力、沒物力、沒財力、甚至時間窗口都可能也快過了…

此外對於一個項目而言，資源也肯定是有限的，而時間、成本和範圍又構成了項目的鐵三角。在特定的時間和資源內，想要完成某些任務，那就只能縮減範圍或者說犧牲質量。但是從長遠的角度來看，犧牲質量帶來的危害可能會更大…

從另一個角度來看，用戶體驗中的「多、快、好、省」本身也是相互制約的，很難同時滿足這些。

以淘寶為例，淘寶早期主推的是多和省，所以早年的淘寶經常是假貨不斷，因為物品數量上去之後就很難保證質量了，也就是說很難同時保證既多又好…後來京東來了，主推的是快與好，成功的實現了與淘寶的差異化競爭，再後來天貓也加入了戰場，主推的也是快與好。

用戶體驗裡面的多快好省這幾個東西本身是有衝突的，而且不同用戶關注的重點肯定是不同的，此外在不同的階段內我們需要重點關注的東西也肯定是不一樣的，但是資源永遠都是有限的，這個時候就只能去聚焦。聚焦於什麼，聚焦於那20%的核心要素。

從上面兩小節我們可以看到，只有少數的要素才是最為關鍵的，而資源永遠是有限的，所以我們優先需要做的是最重要的事情。但是上面提到的都是比較抽象的概念或者說是在我們實際工作中很難感受到的東西，所以下面的小結就談下我們工作中能夠真真切切感受到的東西。

人月神話

之所以會提出來砍需求這種觀點，一方面是基於優先順序和資源限制的考慮，另一方面是從人的角度來考慮的。基本上開發和設計資源都是很緊張的，一旦協調不充分，就可能面臨著延期的風險，即使資源協調的很充分，往往也可能會面臨延期的風險。

通常情況下，我們安排的工期都是基於一個錯誤的假設，那就是一切都會良好的運轉，每一項任務都只會花費它應該花費的資源和時間，然而這在很多情況下都只是希望而已。

實際上每一項任務都可能會延期，可能是預估難度不足，也可能是團隊成員發生了各種狀況，更有甚者可能因為某個人的離職而耽誤了整體的進度。而每一個任務的延誤，都可能會導致產品整體交付的延誤，最終甚至可能會導致產品的失敗…

那進度延誤了怎麼辦？常見的手段無外乎加班和加人，前面這種方式大家可能也都習慣了，而且經常也會聽到互聯網公司說996…所以我們就重點說一下後面的這種方式，僅從人員成本的角度來考慮，不考慮其他的成本。

向進度落後的項目中增加人手，只會使進度更加落後。——《人月神話》

這個觀點可能違背大多數人的常識，多數人可能覺得進度落後了多加幾個人不就可以解決了么？然而實際上並沒有這麼簡單…根據我的一次教訓來看，加人能夠在一定程度上推進項目進度，但是效果有限，甚至可能會起到反作用，加入新成員後整體的產出情況可參見下圖。

素材來源於互聯網

對於加入的新成員而言，需要一定的學習成本，同時也需要能夠快速融入到現有的項目團隊中來，對於舊成員來說，需要在新成員身上花額外的時間來溝通，來說明項目情況，甚至還可能需要培訓新人員，所以剛開始時整體的產出應該是負的，之後才會慢慢增加。

隨著項目成員的增加，團隊成員之間的溝通成本會成幾何倍數增加，由溝通成本增加造成的效率降低甚至可能會大於人員增加帶來的效率提升…那就相當於整體的產出還下降了。

另外當任務分解到一定程度時，可能就無法繼續分解了，因為有些任務之間會存在依賴關係，沒辦法並行去做。也就是說，增加人員的效果是有限的，當任務細化到無法分解的地步時，增加新人員是不會帶來效率的進一步提升的，甚至還可能會降低效率。

所以，在項目的進度落後時，即使加人也不一定能夠趕上進度。

更何況可能根本就沒有開發餘量，那怎麼辦？我也很絕望啊…只能看看能不能砍掉一些需求，或者放到下一個版本再來做了，那怎麼判斷需求的優先順序呢，也就是如何去判斷哪個不該做、哪個該做、什麼時候做、需要投入多少資源來做呢？

需求優先順序的定義

首先需要明確優先順序是怎麼定義的，因為不同團隊定義優先順序的標準肯定是不同的。我先簡單談下在其他地方看到的優先順序定義的方法論或者自己想到的一些判斷方法…應該是足以滿足日常工作需要的

優先順序

主要就是確定判斷的維度，可以從很多的維度來定義，比如可以粗略的分為緊急Bug修復>功能優化>新增功能，也可以從用戶量與使用頻次上來定義，優先滿足用戶量大且使用頻次較高的需求，具體的落地方法可結合四象限法去分析…

性價比

性價比主要是從投入和產出這兩個方面來進行評估的，一方面需要從需求的實現成本來出發，一般主要指設計、開發或者運營推廣成本，另一方面是從需求的效果，也就是商業價值出發，優先做性價比高的需求。

重要緊急程度

重要緊急程度可以分為兩方面，一方面是重要程度，一方面是緊急程度。重要程度又能夠從使用人數、使用頻次、需求重要性這幾個維度來進行量化分析，比如可使用如下公式來量化：

使用頻次=使用總次數/使用人數；

需求重要性=功能使用用戶百分比（用戶使用率）×功能使用次數百分比（功能或內容使用率）×類別重要性百分比（期望型需求、興奮型需求）

緊急程度主要是從時間的角度來考慮的，一方面是基於上線的時間點來倒推，另一方面是基於開發的實現難度，當然還可以加入影響範圍，可以做一張表格，讓相關人員依次為各維度打分，基於各自的得分情況再來確定最終的優先順序。

需求路徑

這個主要可以從三方面來考慮，主要是需求大小、需求全過程以及需求一致性。需求大小主要是從量級上來判斷的，有多少人有這樣的需求、這些用戶是不是目標用戶，對我們有沒有價值。

需求全過程指的是功能能否很好的滿足用戶需求的全過程，以購票看電影為例，整體流程為在線選座下單支付線下取票觀影，對用戶而言這就是需求的全部過程。只有掌握了整體的需求流程，才能完成需求的閉環，進而去保證穩定而良好的用戶體驗。或許這就是美團電影早期願意自己做線下取票機以及京東自建物流的原因吧…

需求一致性指的是新功能是否與用戶的主線需求相一致，是否是必須添加的，依然以購票看電影為例，滿足購票流程的就是主線的需求，如果偏離了用戶的主線需求，需慎重決策，比如新增一個簽到甚至換膚功能什麼的（還真有人在類似產品的第一個版本提換膚的需求，手動微笑）。

其他

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！