作為碼農在電商圈、O2O、互金行業和產品需求糾纏了多年，做過一些好的產品需求，也做過很多失敗的產品需求，好的產品需求即使不成也未嘗不是一種探索嘗試，結果應該是讓人有所收獲的。好的產品邏輯清晰，產品價值明確，有效的解決了一部分問題，經的起團隊各方的挑戰。反之產品經理需求沒想好，邊界條件沒想清楚，最后需求被砍，不光程序員時間白白浪費，配套的設計資源、測試資源甚至運營資源都要打水漂。砍需求如果沒有一套可參考的標準，雙方“討價還價”可能就顯得失去了正義的立場。

MVP

MVP就是一種科學砍需求的方法。我們先看一下什么是MVP。
MVP（minimum viable product，最小化可行產品） 概念最早由硅谷創業家Eric Rise提出，刊載于哈弗商業評論，并有出版物《精益創業》-書中提出了“精益創業”（Lean Startup）的理念，其核心思想是，開發產品時先做出一個簡單的原型——最小化可行產品（Minimum Viable Product, MVP），
快速地構建出符合產品預期功能的最小功能集合，這個最小集合所包含的功能足以滿足產品部署的要求并能夠檢驗有關客戶與產品交互的關鍵假設。然后通過測試并收集用戶的反饋，快速迭代，不斷修正產品，最終適應市場的需求。

MVP的目的——更快的接觸客戶
按照常規的開發方式，從調研、到設計、到開發再到推向市場，會是一個漫長的過程，而且很難有人會保證成功率。但當換一種方式，以MVP進行小樣調研，快速進入市場、接觸客戶并得到反饋。透過反饋不斷修改原型，并進行不斷地的迭代開發，極大減少了試錯成本。

MVP非常適合互聯網產品，下面我分析一下常見的問題產品需求，如何制定一套MVP砍需求的方法來應對。

找出問題

如果PM有以下情節的可能會引起程序員的不適，牙根直發麻，手指骨節癢，想揍他一頓

先做出來看看吧

我就要這種效果，怎么實現是你的問題

這應該很簡單吧，不就是XXX，然后XXX嗎

這個需求，先這樣這樣，再那樣那樣，用XX技術很快就搞定了

你就說能不能做吧

我有一個絕妙的idea，什么都準備好了，就差一個寫代碼的了

這個需求老大已經同意了，你照著做就是了

以上情節只要出現3條及以上，程序員不打你PM，那你真的很幸運。

經典案例：

這個案例完美的承包了上面所說的7中情節，出現打架情況實屬正常。面對這種極品PM，我想不出更好的反擊方式。

問題一：需求不清

首先產品經理應當把需求講清楚，通過需求評審會讓與會者清晰的了解需求是什么，需求從哪里來，對現有業務有什么影響，預期收益是什么；
讓技術及測試對產品方案有詳細的了解，以便后續開發更高效，沒有誰愿意在后續的編寫測試用例及開發階段再去反復溝通確認，畢竟那是非常低效的做法，當然，特殊情況除外；
讓與會者清晰的知道自己在整個方案落地過程中處于什么位置，職責是什么，需要做什么，準備什么，提供什么幫助，對各自負責部分的實現難度及排期有一定的心理預期；
評估產品方案的技術難度及實現周期，一期實現，還是分期實現，投入產出比怎么樣？畢竟互聯網產品講究小步快跑，快速驗證迭代，怎么樣權衡產品設計（用戶體驗），技術成本以及商業利益是產品經理主要工作之一。

問題二：倒排的項目

“這個需求是XX領導主抓的，屬于公司戰略性的項目”

• 通常聽到這句話，內心是狂躁的，尼瑪又拿老板壓迫勞動人民。
• 首先要承認通常情況下高層眼界比較開闊，未必所有的事情是所有人都理解才能開始做。
• 試錯機會，如果項目最終失敗了，最重要的是收獲了結果，但風險我要提前講出來。
• 跟自己的上級溝通項目細節，讓老板幫你背書工作。
• 如果一個公司全部都是這種需求，要么就是這家公司處在特殊時期，要么就趕緊閃人吧

問題三：互相看不上

程序員和產品經理之間的矛盾，主要原因無非就在兩方經常有矛盾出現，而矛盾出現顯然是因為雙方一邊是需求提供方，一邊是需求實現方。通常發生的情況是，產品經理不懂技術規則亂下需求，而程序員自恃技術在手，不尊重產品經理的創作用心，雙方自然互看不爽，都覺得對方沒資格跟自己合作。另一方面，需要投入的資源和發布時間是固定的，所以產品經理和程序員只能在“砍功能”、“降低質量要求”和“程序員加班加到死”這三個選擇上“相愛相殺”了。

研發如何思考最小可行性產品方案

1.owner意識

不管你負責整個產品，還是某個方向，甚至一個小活動，你都必須把自己看成這個事的owner，為結果負責。
關心自己的產品，是否對公司有價值，是否對用戶有價值、是否對合作方有價值。

2.找到最小可行的產品需求

就拿陌陌APP來做一個分析

需求的層次

• 核心功能：陌生人之間的社交
• 基本功能：短視頻、直播、游戲、交友；通過人群聚類解決宅男宅女、缺少生活社交的一群人的社交問題
• 用戶期望功能：陌生男女由陌生到熟悉的過程
• 超出預期的功能：留言檔（陌生人也可以留言）,留言檔只可以看最近的8條狀態（保護了我自己的信息，卻勾起了陌生人想要跟我交流的想法，留存了老用戶，勾引來了新用戶，并且還激勵了活躍度）消息的讀取狀態（可以清晰的明白，我們發出的消息，對方有沒有閱讀了，凸顯了我們發出消息的目的性）, 隱身（關閉我們的距離，但是卻可以讓別人看到我是隱身狀態，給我一個保護，給陌生人一個期待）
• 潛在功能：社交+ 電商、游戲、O2O 這個就比較多了，這里不就列舉了

核心功能和基本功能就是這款APP的最小產品需求部分

可行性

產品的可行性，需要從三方面考慮：技術可行性、經濟可行性和社會可行性。

• 技術可行性：競爭對手功能比較，研究同行業有多少類似產品，有哪些功能、功能異同點。通過競品分析可以了解對方技術特點、產品特點、發展空間、市場行情、用戶喜愛程度及我們的突破點等信息。　易用性及用戶使用門檻，產品的易用性，用戶群體分析，產品是否會有使用難度。
• 經濟可行性：人力成本，產品從調研、分析、設計、開發、測試、運維等需要多少人力，多少人月，每個人月平均成本是多少。市場開拓、廣告、運營成本，產品投放市場后的推廣、營銷方式，需要的推廣、營銷成本，廣告成本等。
• 社會可行性：道德方面、法律方面、社會方面，社會影響力，通過產品的推廣，產品將會給公司帶來哪些社會效益，增加多少社會影響力。

最后才是找出產品需求和可行性的交集部分。小的產品需求要考慮的層面和這里所講的可能差別比較大，這里只是拋磚引玉的梳理一下思路。

3.對項目進度、項目質量負責

上圖是一個MVP的周期，有沒有覺得似曾相識，沒錯MVP和敏捷開發有異曲同工的作用。

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

可見項目進度管理是多么的重要。需求過多造成開發周期過長，一定要果斷的分階段。

大家都嗑過瓜子，嗑瓜子，因為是嗑一個，吃一個，反饋的周期很短，差不多兩秒鐘瓜子就能到嘴里了，所以不覺得累。而工作學習的反饋周期就很長了，你不知道你學的這個東西什么時候才有提高，什么時候才能派上用途。

做一件事情，反饋的周期越短，越有可能上手。而一件大事情，我們也可以把它拆分成一個個小事情，然后給予每一個小事情一個短周期的反饋，這樣我們做起來難度就小多了。

我們的在校學習，因為距離實踐太遙遠，所以反饋周期太長，導致我們疲乏，不愿意迷茫的學習，憑著自律性去學習，導致學霸很少、學渣很多。

判斷好優先級、性價比、重要緊急程度，在項目初期打下一個基礎，明確能做的部分和可能的風險，才有可能完成整個項目。

4.總結復盤

技術人員在團隊中的價值除了技術層面還有綜合能力方面的價值，尤其是軟素質。能較好的完成任務，還要解決好各個環節的異常問題，只有技術是遠遠不夠的。

最核心的是自驅力，是一個人內在的東西。
我們說一個人是不意愿成長，一個人是不是自律，指的就是他的自驅力，自驅力是一個人成長的源動力，自驅力好的人后面發展的潛力也會比較好。

總結復盤的能力，項目上線后要及時關注數據，要和之前定下的指標去對應。對項目中產生的問題要及時的總結經驗，復盤的目的是從之前的經歷（可能是成功的經歷，也可能是失敗的經歷）中總結可供指導后續工作的經驗。一個人的能力就是這個人過去所有成功經歷的總和。總結復盤的方式也多種多樣，但萬變不離其宗，主要還是圍繞下面幾個內容：目標回顧、進展評估、原因分析、經驗總結。

5.對自己負責

一個產品設計的價值 = 全部TPU價值的加和，參與產品設計環節、體現自我價值。

砍需求難免會遇到各種分歧，如何應對呢？ 我總結有下面三個層次：

信息對齊

信息對稱是一門很大的學問題，經濟學家米爾利斯和維克里因研究這一理論而獲諾貝爾獎。這是工作中最基本的部分，掌握更多的信息可以增加個人在職場中的價值壁壘，從而贏得更多的話語權。 要想保持自己的優勢起碼要做到以下3點：

• 1.對自己的工作內容或者說業務很熟悉；
• 2.善于總結所有的工作過程中的每一步;
• 3.善于向過來人去請教經驗.

原則對齊

如果不能通過信息對齊解決問題，那么就要考慮一下原則部分，公司使命、產品價值等等， 大家的目標應該都是想做出一款好的產品，只要基于這個原則去探討問題就容易找到答案。

利益對齊

產品做得好了，大家都有功勞，該晉升的晉升，該分錢分錢，該團建團建。大家都知道跟你做事不吃虧，時間長了，靠譜的人會愿意持續跟你配合，你的口碑和職場信譽也就建立起來了。
最好的方式是讓參與的人有共同的利益，這事成了，大家都獲利，而不只是單純的部門之間工作配合或者幫忙而已。
但如果總想著利用別人，占點便宜，也許一時可以，長久都是不奏效的。

## 結束語

本文從MVP方面進行了一次拓展式的思考，砍需求不是目的，做成好產品，體現個人價值，使自己的職場路徑能更加穩健才是我想和大家探討的問題。

當然，MVP也并不適用于任何時候。MVP模式的問題在于，它并不總是開發顛覆性技術的最好辦法。如果喬布斯發布的是最小可用的 iPhone，我們是不是會得出結論說大家更喜歡鍵盤？如果 Tesla（電動車）制造的是最小可用汽車，還有沒有人去開它？因為與 web 服務不同，就好像不可能有人會花幾萬塊買一輛最小可用的車一樣，硬件不是免費的，而且不能快速方便更新。當然，這不是＂最小可用＂理念本身的問題，只是有些市場不合適。產品到底可以做到多好或者做到什么程度最好？答案或許永遠也找不到。這種模式也不一定就是做大事情的最好方式。有些產品是小調，有的則是交響曲，而有時候你還是要先讓音樂演奏起來。

行文倉促，難免以偏概全，歡迎各位斧正！

總結

以上是生活随笔為你收集整理的程序员必备技能-科学砍需求的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。