關於網際網路新產品設計開發流程

整理了一下這幾年做產品的心得，整理出了一個簡單的產品工作流程，水平有限不對的地方還請各位海涵。

方法/步驟

1

戰略規劃

作為一些產品的負責人，鑰匙從沒有參與戰略方向的制定，僅有幸以旁聽的形式進行過極少的戰略討論，這些討論會與其說是戰略討論會，不如說是公司領導極力說服大家朝某個戰略方向走，也就是戰略思想灌輸。看過很多同行朋友的說法，似乎對於產品經理來說這是一個普遍現象，也不難理解，一個產品要有大的投入，做與不做甚至做成什麼樣都是老闆非常關心的問題，因此產品經理在戰略制定的時候能起到的作用很小。

不過戰略規劃也是需要總結和分析的，雖說網際網路行業瞬息萬變、時不我待、快馬加鞭、緊趕慢趕~~~但是要開拓一個新產品還是需要完成這個產品的簡單分析和戰略的描述。

2

前期分析

產品的前期分析不分高低貴賤都要做，大到一個完整意義上的產品，小到一個新功能，前期的分析都是非常關鍵。這個前期分析首先是要了解這個產品，以及產品相關服務的生態系統(ecosystem)，一個產品經理在這個階段所要做的就是了解整個領域的情況，競爭對手，使用者，甚至需要關注一下國家政策。其次在這個階段需要給產品一個定位，要回答的問題諸如“使用者是誰?”，“滿足使用者的什麼需要?”，“我們應該提供哪些功能(內容)滿足他們?”等等，當然了，這些問題在這個階段我們只需要一個定性的分析就可以了。

3

使用者研究

使用者研究包含的範圍很廣，《贏在使用者》這本書有經典的描述，從前期的使用者訪談到可用性測試直到上線後產品運營時對資料的分析，都屬於使用者研究的範疇，這裡僅僅討論產品開發前期的使用者研究。在前期首先要對整個業界這個方向產品的情況做調研，收集情報，這期間有很多方法，土一點的比如從CNNIC、IResearch等處尋找調研結論直接Copy，好一點的選取目標使用者進行訪談、發放問卷、尋找專家進行訪談等等。

鑰匙想說的是，想要做好一個使用者研究需要花費的精力很多，尤其是在一個沒有專門使用者研究人員的網際網路公司裡，能給你這麼多時間與資源來做這件事實在是一個奢侈的想法，不過在有限的投入下獲得最大的成果是決定產品經理能力高低的體現，所以也沒什麼可怨天尤人的。在這個階段需要搞清楚一些問題，比如“我們的使用者到底是誰?”“他們有什麼樣的需求?”“如何才能有效的實現他們的需求?”。

4

概念設計

概念設計是一個產品的靈魂體現，這部分的實現產品經理可以要求UED與你一同完成，不過很多公司可能沒有專門的UED做這件事，所以只能自己擼起袖子乾的。簡單的把概念設計分為三個階段：

第一個階段：需求概念。概念設計的開始往往伴隨著頭腦風暴會，選出一些靠譜的功能(內容)的設計，然後由產品經理給出一個功能範圍定義，最好能附上部分核心功能的互動流程。這時最好開一個會議，會議內容就是找上老大們敲定下來我們的功能範圍，這點非常重要，一定要有記錄，否則會出現專案進行中老大跳出來要改方向的事故(當然，有記錄老大也可能會跳出來，但是如果這樣你能爭取到對應的自由度)。

第二個階段：概念原型。此時就要體現產品經理資源整合的能力了，最理想的狀態是拉來一個人幫你完成一個高保真的功能原型，鑰匙見過比較牛的是找一個Flash牛人，做一個純粹的Flash實現的高保真原型，那叫一個真!往往伴隨著高保真原型的出現，會重複上面說到的使用者研究，但不論怎樣這東西最終的目的是給公司老大們彙報，讓老大們看看這東西原來就長這個樣子，同時也讓老大們用一用，敲定產品的一些具體實現。如果上第一階段是設計產品的骨架，那麼這一階段就是給骨架上添點肉了。

第三個階段：完成 MRD(市場需求文件)。這個階段主要是總結一下上兩個階段東西，拼湊成一個完整意義上的MRD，這裡就是考驗產品經理畫餅的功力了，以文件和原型的方式告訴公司領導層你要做的這個東西是什麼樣子，為什麼做成這個樣子，能解決使用者的什麼問題，這樣做了再市場競爭對手間有什麼優勢，未來有什麼樣的發展預期，當然，最最重要的是你通過這個階段的彙報，能為你爭取到多少資源。

5

需求確定

這部分內容應該是業內大部分的產品經理都在做的事情，有了上面的積累一個產品的樣子已經在產品經理的腦袋裡鮮活的出現了，產品經理所要做的就是撰寫一系列的文件將這個鮮活的影像記錄下來，所謂PRD和UI詳細設計就是這個階段的產出物。此時你的產品已經放在了紙面上，你要把他小心的交給專案經理了，再由專案經理分解你的需求寫成一個FSD(功能詳細說明文件)這個文件是給開發人員看的，他們可以拿到這樣的文件直接開始開發。

需要注意的是，很多網際網路公司往往沒有專案經理，或者有也是在管理開發團隊無數個專案的專案進度的監管員。鑰匙的文章是要麼會有一個架構師來分解你的需求，要麼直接拿你的需求給開發，伴隨著開發不斷的騷擾和自由發揮把專案完成。

鑰匙遇到的一般是有一個專案進度監管員，且無人幫你分解需求的情況，這種情況只能是產品將PRD寫的儘量的細緻，除此之外，還要在腦海裡有一個非常完整，非常細節的情境，在開發針對你PRD中某部分有疑問的時候清清楚楚的告訴他這裡應該是什麼樣子的。

6

專案預算

這部分暫時不涉及財務問題，僅僅從專案管理的角度看，我們需要由一個WBS(工作分解結構)，一個甘特圖，一個資源直方圖，這是最少的配置，可以清晰的'顯示出你的專案進度與所需資源的關係。這專案管理方面內容理論較多，在這裡不做贅述。

7

實施開發

開發的過程比較考驗你前面的工作，基本上你在甘特圖上應該有不止2個的檢查點，到時檢查專案的進度是否符合預期，如果出現了問題也要想辦法保證進度。如何保證呢?基本上有加班和砍功能兩種辦法，砍功能這點是開發痛快，產品痛苦的事情，而加班正好相反。不論你最終選擇了什麼方法，最最核心的就是記住你這個產品所服務的使用者是誰?他們是不是用不到你想砍掉的功能。

8

產品上線

我所經歷的產品上線都是悄悄的上線，並沒有大張旗鼓的做市場活動，我想這是大部分網際網路產品上線的情況吧。悄悄上線是好處多多的，由於網際網路產品邏輯複雜，流程多樣，所以在沒有大量的使用者使用並做幾次迭代改進前，很難說會存在哪些問題。在這方面鑰匙有一次慘痛的教訓，記得有一次鑰匙負責的一個產品上線，上線成功的信在公司內部研發中心群發，信裡感謝了一堆的同事，搞的特別煽情，結果是大家感興趣的上網一看，哇塞!隨便點點就發現一堆的BUG，群情激奮的同事們立馬用發信表達自己的不滿，看到那些兩位數的關於產品BUG的信，鑰匙當時我只有一個願望，就是切腹自~

這個慘痛的文章讓我明白了，誰都不能為你的產品負責，即便有強大的測試團隊告訴你你的產品OK，完全達到上線的指標，也要自己在上線前狠狠的測試一下，畢竟沒有那個測試人員比你還了解產品&使用者。

9

產品運營

以前有位老大曾經說過，網際網路產品是一個蘿蔔一個坑，一個新產品開起來了，一個人砸下去就一直在這個坑裡挖了，挖的深了還得多拉幾個人下水，如果想再開一個新產品只能找另一個人來挖坑。這句話可以體現大多數網際網路產品的情況，也說明了產品運營的重要性，在整個產品生命週期裡絕大多數的時間都是在做運營。

說到做運營鑰匙感慨良多，各種型別的網際網路產品之間的運營方式千差萬別，而且每種產品的運營都有很多技巧在裡面。比如新聞類產品，Sohu的首頁新聞是每五分鐘觀察一下點選資料，點選差的就往下撤，同時運營人員也以點選量為考核目標;再比如論壇類產品，運營的工作主要是和人打交道，論壇的斑竹、分類的管理員、總管理員，層層的組織都要有運營老大建立，建立完畢了還需要自己在裡面用馬甲發帖，頂貼直到找到一些不錯的意見領袖，形成一個良好的討論氛圍，論壇類產品的考核目標是UV和PV/UV雙重指標;再再比如鑰匙做過最多的搜尋引擎的運營，不停的訂指標，寫規範，做評估，最後推動開發改進，搜尋類產品的指標就不單是PV、UV這麼簡單了，各種效能都有自己的指標，根據產品所處階段衡量指標不同。

總而言之，運營才是一個產品能否成為優秀產品的核心!

注意事項

記錄了一遍我所理解的新產品開發流程的流水賬，這個流水賬其實是一個比較理想的東西，在實際操作過程中經常會剪掉其中某幾塊的內容，PRD可能在壓根沒有做使用者調研的情況下寫出來，專案預算也可能根本不用做，所以請大家僅作參考之用，不要太深究其中的細節。