起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識送給剛入行的產品經理們，我的需求之見
對于互聯網項目來說，第一步是要做什么呢？
如果比較專業的肯定會回答你，肯定是做市場調研啊，搞搞MRD，BRD什么，搞明白了自己要做什么。
然而對于現在大多數互聯網企業或者稱之為剛剛從傳統企業轉型的互聯網新貴來說，做一個份產品的需求才是真正他們需要的。
在這里我先說一個故事，故事的主人公是我的一個朋友。最近他們公司開始要涉足一下互聯網，這是很多傳統企業準備和喜歡做的事情，于是他們公司找了一家外包公司來做這個事情。有一天他說他很忙，要去外包公司對接項目，也是這個時候我才知道他們公司是安排他在做這個“產品經理”。一個從來沒有接觸過互聯網的人來做產品經理，看似完全沒有道理的事情，但是我相信這個事情絕對不是個例。
所以今天這篇文章不是寫給大神產品，小神產品或者是入門產品看的，因為你們可能對需求的理解比我還深入，所以我只是獻丑的給那些完全是新手的產品經理寫下這份東西，希望能夠共勉，也希望能夠真正的幫助到你們。如果大家覺得我寫得差，歡迎給出意見指出。
一：什么是需求？
我們首先來明確一下需求到底是什么？是給誰看的？
這里我們來解釋一下不同的需求文檔。
BRD文檔
BRD文檔從字面的意思是“商業需求描述”，是探討產品的市場價值的東西，是給老板看的。
MRD文檔
MRD文檔從字面的意思是“市場需求描述”，是探討產品市場的東西，是給所有參與項目的人看的。
PRD文檔
PRD文檔從字面的意思是“技術需求文檔”，是描述產品研發的東西，是給研發部門人看的。
而在大多數的人看來，需求文檔指的便是PRD文檔，說得簡單明白一點就是告訴技術人員怎么開發這個東西的文檔。
而今天，我們主要講一下PRD文檔。
二：開發模式之談
在訴說PRD文檔的形式前，我們要講述一下和PRD文檔發展息息相關的東西—–開發模式。
在我們大家的印象中，最為熟悉的開發模式有兩種，一種是瀑布的開發模式，一種是敏捷開發的模式。這里我們先來說明一下瀑布開發和敏捷開發到底是什么？
瀑布開發：
如圖所見，瀑布流開發是一個完整的非環形開發模式，旨在一次性進行完整產品的設計和開發。成本較高，周期較長，但是項目需求的問題則非常小，后期維護的成本較低。
敏捷開發：
如圖所見，敏捷開發是一個環形開發模式，旨在快速的迭代，簡化的進行開發。成本較低，周期較短，但是項目需求的問題則比較大，后期維護的成本高，或者說，敏捷開發是一種一直持續的過程，而不存在后期維護的說法。
兩者區別：
然后我們再來看看我找到一張圖來說明兩者之間的區別，我覺得很形象。
瀑布開發就是傳統開發，是一大堆文檔后進行開發最后變成一顆大樹，而敏捷開發則是一步一步的成長成一朵成熟花朵。
總結來說就是瀑布開發是前期花很大一段時間來進行項目需求的討論，形成非常標準以及專業的文檔來進行開發。而敏捷開發則是設計開發同步進行，一邊開發一邊進行設計。
三：產品開發之談
上一節介紹了兩種不同的開發模式，這一節我們來說一說產品的開發到底選擇什么樣的開發模式是比較科學的。當然，這里的科學并不是完全科學，因為這個世界不存在完全科學的東西…..Orz。
在當今的互聯網世界當中，人人都知道一點，對于一個產品最重要的是時間。古話說得好：“一鼓作氣再而衰三而竭”。這個典故我相信經歷過義務教育的人都知道是什么意思。對的，對內來說無論是研發團隊還是產品團隊亦或是任何一個職能團隊來說，時間越長項目的風險越大。對外來說，一個產品久久不能上線面臨的是市場的快速競爭和資本屆的質疑。所以天下武功唯快不破的秘訣在當今的互聯網世界是絕對的真理。
所以現在的互聯網世界的產品開發更多使用的便是敏捷開發的模式，快速的版本迭代來解決上一個版本的問題。
這里套用我看到過的一句話：“產品的第一個版本只要主要流程能跑通，馬上上線！”。
四：版本之談
說完了敏捷開發，那么注定避免不了版本的問題，所以在產品一開始的設計時候，產品經理就需要對每一個版本進行一個初步的設計，研究產品節點，溝通開發周期。
那么問題來了，到底怎么來規劃這個版本呢？
接下來就是小弟的愚見了，我們大致的可以把版本這么來劃分：
- 第一個版本：主要流程。
- 第二個版本：優化主要流程。
- 第三個版本：根據運營數據增加功能。
當然，你可以不把他看成是第一第二第三版本，而是看成一個順序，而對于剛開始做的產品，請牢記一句話“不要做太多的功能，你是做什么的，能讓用戶體驗你這個了，就上線”。
五：需求形式之談
說完了模式，談完了版本，我們來說說最后的一個話題，到底怎么做PRD需求文檔。
當然，今天我們并不討論需求文檔怎么做，那是技術活也是哈姆雷特，每個人寫出來都是不一樣的。所以沒有應該怎么寫，寫成什么形式，也沒有誰寫得好，誰寫得差。只要是研發團隊看得懂的就是好需求。
可是，如果不用說怎么寫，那還談什么需求形式呢？
哈哈哈，我們這里雖然不談怎么寫需求，但是的的確確是要說一下需求的表現形式，接下來我給大家說一下常見的需求形式：
1.文檔形式
故名思議，文檔形式就是以文檔的形式把開發的需求展示出來以供研發團隊進行閱讀。
Good：
文檔形式的需求文檔是非常詳細的，當然如果水平不行也會出現漏洞，這里我們就忽略水平問題。
文檔形式以文字描述項目的各個功能以及開發的流程，對于任何一個研發團隊來說都是能夠輕松閱讀，并且對于項目的驗收可以作為很有效的驗收工具。
Bad：
壞處就是，太難讀了。
我敢保證，現在90%的研發團隊成員看見需求文檔頭都是大的，而且受限于技術水平，在文檔上描述的時候會存在理解上的誤讀。
還有就是，形成文檔形式的需求對于項目設計人員來說是需要比較高的要求，也需要很長的時間才能做好的。所以世面上你只聽說過“線框仔”而沒有聽過“打字仔”。
2.原型形式
原型我就不多說了，原型設計的出現是很早的事情了，具體想了解的話去百度吧！原型呢就和我們小時候寫的看圖寫話一樣，一張圖描述出我們要做什么，簡單易懂。
Good：
原型這個東西，效率高，描述準確，理解誤差小。而且能很好的直接進行操作，還原設計流程。
而且原型上手快，當然，你要做到很牛逼，那還是很難的。
Bad：
細節上的描述對于原型來說還是差強人意，需要進行非常高保真的原型設計才能完美重現細節設計，這對于原型制作者的要求比較高。
其他壞處我暫時還沒有想到，希望大家可以補充，哈哈哈！
注：下面我們就不進行優劣對比了
3.文檔+原型形式
這個是什么，我就不說了，你要是這個都不知道話，請你給我打電話！
這種表現形式可以說是當今開發界最完善的開發形式了，不但在可視化上進行了描述，也在文字閱讀中進行了描述。對于流程，頁面的細節也是很能把握到位，而唯一的缺點就是需要花費的時間比較長。按照現在產品開發的周期來看的話，除非產品經理不吃不睡，才能不耽誤開發進度！真的，做過的人才知道。
所以，我們說完了三種展現形式，這個時候選擇哪一種就需要產品經理自己考慮了，而推薦幾點參考標注：
- 產品開發周期。
- 技術團隊水平。
- 產品經理水平。
好了，今天的文章就寫到這里?？偠灾褪谴蟾诺慕榻B了一下需求這個東西，也沒說什么有營養的話，權當看著好玩吧。
如果有什么寫得不好的地方，請發送給我郵件督促我改進，謝謝各位看官。
本文系起點學院成都160123期優秀學員?@張衡?(郵箱地址:kame@bsanjia.com) 原創發布，未經作者許可，禁止轉載。
我覺得寫文章上傳圖片也應該考慮用戶體驗，字辣么小 ? ? ?
??
贊一下
??