關鍵詞: MVP 最小可實現產品 砍需求
作為碼農在電商圈、O2O、互金行業和產品需求糾纏了多年，做過一些好的產品需求，也做過很多失敗的產品需求，好的產品需求即使不成也未嘗不是一種探索嘗試，結果應該是讓人有所收穫的。好的產品邏輯清晰，產品價值明確，有效的解決了一部分問題，經的起團隊各方的挑戰。反之產品經理需求沒想好，邊界條件沒想清楚，最後需求被砍，不光程式設計師時間白白浪費，配套的設計資源、測試資源甚至運營資源都要打水漂。砍需求如果沒有一套可參考的標準，雙方“討價還價”可能就顯得失去了正義的立場。
我會持續分享一些知識整理，如果文章對您有幫助記得點贊鼓勵一下哦?~，也可以通過郵件方式聯絡我
文章列表： juejin.im/user/5bc8b9…
郵箱地址: 595506910@qq.com
目錄
- MVP
- 找出問題
- 問題一：需求不清
- 問題二：倒排的專案
- 問題三：互相看不上
- 研發如何思考最小可行性產品方案
- 1.owner意識
- 2.找到最小可行的產品需求
- 需求的層次
- 可行性
- 3.對專案進度、專案質量負責
- 4.總結覆盤
- 5.對自己負責
- 資訊對齊
- 原則對齊
- 利益對齊
- 結束語
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 服務不同，就好像不可能有人會花幾萬塊買一輛最小可用的車一樣，硬體不是免費的，而且不能快速方便更新。當然，這不是＂最小可用＂理念本身的問題，只是有些市場不合適。產品到底可以做到多好或者做到什麼程度最好？答案或許永遠也找不到。這種模式也不一定就是做大事情的最好方式。有些產品是小調，有的則是交響曲，而有時候你還是要先讓音樂演奏起來。
行文倉促，難免以偏概全，歡迎各位斧正！
補充
2019-06-13 補充：
重溫俞軍的3條核心產品方法論
從12條軍規縮減到3條
1.PM首先是使用者；
2.站在使用者角度看待問題；
3.使用者體驗是一個完整的過程；
4.追求效果，不做沒用的東西；
5.發現需求，而不是創造需求；
6.決定不做什麼，往往比決定做什麼更重要；
7.使用者是很難被教育的，要迎合使用者，而不是改變使用者；
8.關注最大多數使用者，在關鍵點上超越競爭對手，快速上線，在實踐中不斷改進；
9.給使用者穩定的體驗預期；
10.如果不確定該怎麼做，就先學別人是怎麼做的；
11.把使用者當作傻瓜，不要讓使用者思考和選擇，替使用者預先想好；
12.不要給使用者不想要的東西，任何沒用的東西對使用者都是一種傷害。
複製程式碼新三條
1.產品價值分析法：產品價值=(新體驗-舊體驗)-換用成本
2.使用者樣本量：使用者即需求，使用者是自然人的某一類需求，使用者不是自然人，隨著內外部場景變化會發生變化。
3.懷疑精神：自我迭代。
複製程式碼O2O平-臺是各種店鋪管理方式的統一整合，並且創造出不同的新方式。B端的上單管理，行業、套餐、優惠策略、服務時間等人為管理方法改成統一的流程式管理。
2019-06-18 補充：
工作量評估方法
為每一個活動和整個工程的工作量做一個最初的評估。有很多可用的技巧用於評估工作量，包括任務分解（工作細分結構）、專家意見、類推等， 大型專案工作量評估過程：
- 梳理產品需求和互動,接下來的工作自己做或著分工讓別人去做都要能夠講清楚邏輯
- 方法論意識：建立幾種文件，涉及到的系統列表，串聯業務的流程圖、每一步各種狀態表格，總分和細節都能覆蓋到。像埋點、監控這類必要的工作應直接預留在模板中。
- 完善產品方案：多留疑問，儘量多的擴充套件問題，避免上游遺漏的需求，造成最後的工作量失控
- 粗略工作量評估（叫‘初估’比較好一點）：一定要有一版粗略評估，PM也不能保證需求充分考慮以及不會變更和增加需求，細節都交給RD完善呢，好意思要精確的評估工作量？ 沒有工作評估這一說,只有粗略工作量評估和較精確工作量評估這兩種，要讓PM知道自己要什麼。
- 新增意外事故時間：一定不是所有的需求評估時都有解的，這些不可控的因素會有臨時變動，風險是要講出來的。時間越長可變係數越大，人員離職、臨時請假都有可能影響專案進度，這種情況是沒法對外要求專案延遲的，只能自己把控好。
- 方案產出邏輯梳理並且文件化：要確保你的評估看起來是合理的，並且準備好反擊那些反對的觀點。文件化所有設想。你永遠不會確切地瞭解一項工程的所有細節，因此，文件化所有你做出的設想和評估，這一點很重要。
2109-06-20 補充
不可能三角
- 設計領域：好看，便宜，快速
- 專案管理：TQR，時間，質量，資源
- 投資領域：收益，風險，規模（即容量、流動性）
- 區塊鏈領域：安全，效率（即環保，低耗能），去中心化
- 運動攝影領域：快門，光圈，感光度
- 錢多 活少 離家近
- 位高 權重 責任輕
- 要馬兒跑的快，又要馬兒不吃草（所有有了廣告：高效率、低能耗）
- 古典的說法就是——有得必有失，魚與熊掌不可兼得。