程序員必備技能-科學砍需求

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

MVP

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

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

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

找出問題

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

1. 先作出來看看吧
2. 我就要這種效果，怎麼實現是你的問題
3. 這應該很簡單吧，不就是XXX，而後XXX嗎
4. 這個需求，先這樣這樣，再那樣那樣，用XX技術很快就搞定了
5. 你就說能不能作吧
6. 我有一個絕妙的idea，什麼都準備好了，就差一個寫代碼的了
7. 這個需求老大已經贊成了，你照着作就是了

以上情節只要出現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 服務不一樣，就好像不可能有人會花幾萬塊買一輛最小可用的車同樣，硬件不是免費的，並且不能快速方便更新。固然，這不是＂最小可用＂理念自己的問題，只是有些市場不合適。產品到底能夠作到多好或者作到什麼程度最好？答案或許永遠也找不到。這種模式也不必定就是作大事情的最好方式。有些產品是小調，有的則是交響曲，而有時候你仍是要先讓音樂演奏起來。

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