關鍵詞: 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 服務不同，就好像不可能有人會花幾萬塊買一輛最小可用的車一樣，硬體不是免費的，而且不能快速方便更新。當然，這不是＂最小可用＂理念本身的問題，只是有些市場不合適。產品到底可以做到多好或者做到什麼程度最好？答案或許永遠也找不到。這種模式也不一定就是做大事情的最好方式。有些產品是小調，有的則是交響曲，而有時候你還是要先讓音樂演奏起來。
行文倉促，難免以偏概全，歡迎各位斧正！