摘要：做產(chǎn)品的都知道，需求是無處不在的，可能來自于用戶的反饋，業(yè)務(wù)團(tuán)隊(duì)的反饋，用戶行為的挖掘，團(tuán)隊(duì)內(nèi)部的idea或者上級的要求，人人都是產(chǎn)品經(jīng)理也就是人人都可以提需求吧…既然有需求就要細(xì)化需求文檔，制作原型，設(shè)計界面，這是幾乎每個產(chǎn)品團(tuán)隊(duì)都會做的流程，本文不涉及如何更好地寫需求文檔，只聊一下作為異地的產(chǎn)品團(tuán)隊(duì)怎么針對需求文檔、原型和設(shè)計評審進(jìn)行協(xié)作。

我所謂的異地的產(chǎn)品團(tuán)隊(duì)，可能會和遠(yuǎn)程工作有較大區(qū)別。遠(yuǎn)程工作是大部分人員都不在一起工作，就像《Remote》說的那樣，異地的產(chǎn)品團(tuán)隊(duì)是說一個團(tuán)隊(duì)里產(chǎn)品開發(fā)人員和市場業(yè)務(wù)人員不在一個地方工作，這個在一些瞄準(zhǔn)海外市場的早期產(chǎn)品團(tuán)隊(duì)里是比較常見的，我們就屬于這種情況。

在異地協(xié)作的創(chuàng)業(yè)團(tuán)隊(duì)，尤其是存在時差的情況下，會遇到的最大的問題就是對于無論是需求，還是原型和設(shè)計，都存在一個異步確認(rèn)的過程，不能面對面吵一架解決，那就需要合理的協(xié)作機(jī)制能方便的討論，反饋和追蹤。

需求文檔需要協(xié)作的內(nèi)容

我這里說的產(chǎn)品需求文檔(PRD)就是對于一個產(chǎn)品或者某個單獨(dú)的功能，PM需要通過與整個團(tuán)隊(duì)一起來協(xié)作完成的需求描述：

• 與用戶、客戶、業(yè)務(wù)人員或產(chǎn)品團(tuán)隊(duì)內(nèi)部的溝通后梳理出需要解決的User Story
• 細(xì)化功能需求的前置條件和后置條件，用戶流程和規(guī)則
• 完成產(chǎn)品原型
• 和設(shè)計師溝通輸出設(shè)計稿供團(tuán)隊(duì)評審
• 開發(fā)前與開發(fā)團(tuán)隊(duì)溝通數(shù)據(jù)模型和任務(wù)分配
• 上線前和市場推廣團(tuán)隊(duì)一起確認(rèn)功能的Tracking Goal

這個過程不同的團(tuán)隊(duì)不盡相同，但都是需要整個團(tuán)隊(duì)一起來協(xié)作完成產(chǎn)品需求文檔(PRD)的過程。

以前遇到過的坑

先說一下以前我自己碰到過的坑，也就是這些坑讓我們不斷思考如何更好的去協(xié)作：

第一，無數(shù)個版本的需求文檔

我最早做過的一些項(xiàng)目幾乎都是用Word來寫PRD，無論是像中國電信這樣大型國企，還是在海豚這樣的創(chuàng)業(yè)團(tuán)隊(duì)，在做需求的過程中就會發(fā)現(xiàn)一個需求來回討論確認(rèn)是很常見，有時候僅僅就是對某個文案的修改，但來回溝通就要發(fā)郵件，新建一個版本，然后就會變成下面這樣…

文檔里面還有更多小版本修改的說明，顯得很專業(yè)的樣子…但是word的評審功能都在本地完成，有時候一個細(xì)小的改動也要傳文件找修改，實(shí)在很out，而且以前的版本在那兒根本沒有人去看過，真的想去看討論中到底做了什么修改的話，做個Diff也是真的很困難。

第二，確認(rèn)的需求文檔開發(fā)人員根本不看

做需求文檔的目的就是服務(wù)功能的開發(fā)，但長篇的需求文檔真的對開發(fā)人員極不友好，對某個特定功能需求的搜索和反饋都不方便。

第三，產(chǎn)品迭代中沒有人去維護(hù)需求文檔

開發(fā)過程中的需求變更基本是每個項(xiàng)目都會碰到的，新的需求一般都當(dāng)面或者郵件的形式溝通好直接就開發(fā)了，一段時間后就再也不知道這個需求是誰提出來的，什么時候加的，因?yàn)镻M很難及時去更新Word的PRD，而且保證每個開發(fā)都看最新的PRD開發(fā)。

基于文檔協(xié)作平臺(Google Doc)的需求協(xié)作

碰到“無數(shù)個版本的需求文檔”問題很自然的想法就是通過在線的文檔協(xié)作平臺來解決，協(xié)作平臺選擇的是Google Doc，協(xié)作主要的方式就是由PM把整個PRD放上去，邀請相關(guān)核心的業(yè)務(wù)人員(可能就是Product Owner)，市場人員和開發(fā)人員參與討論，通過Comment的方式來協(xié)作完成PRD及相關(guān)文檔的審閱，用來組織周期性會議(Sprint Meeting)。

我自己覺得這種輕量的協(xié)作方式適用的場景是和不太愿意參與產(chǎn)品開發(fā)過程的客戶協(xié)作的時候使用，因?yàn)殡m然解決了交流協(xié)作的問題，但對產(chǎn)品開發(fā)團(tuán)隊(duì)內(nèi)部來說依然存在復(fù)雜的長文檔，小變更難以維護(hù)的問題。

基于項(xiàng)目管理平臺(Redmine)的需求協(xié)作

我們從5年前開始接觸項(xiàng)目管理平臺，開始就是需求文檔做好以后通過項(xiàng)目管理工具(Redmine)進(jìn)行任務(wù)分配和進(jìn)度追蹤，大家做開發(fā)的都懂，寫代碼大家都還挺high，但不停匯報進(jìn)度就很煩躁了，我們通過Redmine REST API開發(fā)[githooks][5]讓開發(fā)可以通過標(biāo)準(zhǔn)格式的commit message提交代碼就能更新任務(wù)進(jìn)度來改進(jìn)流程，得到了開發(fā)人員的推崇，這5年來經(jīng)過不下50個開發(fā)人員都使用的很愉快，沒用什么學(xué)習(xí)時間，大部分的開發(fā)任務(wù)都能拿到較完整的代碼提交上下文。

但在做項(xiàng)目的過程中，我們還是不斷遇到上面說的需求協(xié)作的問題影響到開發(fā)效率，初創(chuàng)產(chǎn)品不斷改需求經(jīng)常讓大家爭吵某個需求到底是什么時候加進(jìn)來的，在PRD上怎么找不到。我們就思考是不是可以把整個PRD融入到Redmine上，這樣的話：

1. 可以用極簡的Wiki語法寫功能的需求文檔，不用糾結(jié)格式，還能逐步加入功能相關(guān)的流程圖，原型和設(shè)計稿的鏈接和相應(yīng)的開發(fā)任務(wù)，甚至每行相關(guān)代碼的提交記錄。
2. 可以把特定需求的整個上下文都track下來，包括需求的描述，對應(yīng)的原型和設(shè)計以及圍繞這些的討論，向下能包含所有相關(guān)開發(fā)任務(wù)和任務(wù)的完成度，向上又能追溯到關(guān)聯(lián)的需求，這樣團(tuán)隊(duì)都能盡量focus在沒有討論過的問題和需要開發(fā)的任務(wù)，而不是重復(fù)地產(chǎn)生“這個我們以前確認(rèn)過…”這樣的聲音了。

下面具體到需求協(xié)作的流程中來實(shí)際操作一下：

一. 記錄需要解決的User Story

摘要里說過，需求是無處不在的，可能來自于用戶的反饋，業(yè)務(wù)團(tuán)隊(duì)的反饋，用戶行為的挖掘，團(tuán)隊(duì)內(nèi)部的idea或者上級的要求，我們不可能拿到需求就開發(fā)，首先需要先記錄下來，我們的流程是由PM從各處匯總后在周會上討論，確認(rèn)哪些是需要考慮放在哪個milestone來開發(fā)，哪些現(xiàn)在不考慮的會放在一個叫future version的虛擬版本里以后再考慮，這兩類都新建User Story放到Redmine上進(jìn)行track。

然后我們對進(jìn)入Redmine的所有User Story按照不同客戶端分為PRD-mobile，PRD-User Site，PRD-Web Admin，PRD-Wechat四類，有的團(tuán)隊(duì)可能習(xí)慣按照功能模塊來劃分分類，取決于項(xiàng)目規(guī)模，項(xiàng)目規(guī)模太大確實(shí)有必要。

最后在Redmine上我們會有自定義的Query來查看這些User Story，可以按照狀態(tài)過濾出目前系統(tǒng)不同客戶端已經(jīng)完成的所有功能，對內(nèi)部人員來說相當(dāng)于一個完整的產(chǎn)品需求文檔。當(dāng)然也可以按照不同milestone，是不是已經(jīng)完成等各種條件來過濾查看。

二. 細(xì)化和討論確定功能需求

對于確定要排入milestone的User Story，PM需要按計劃完成需求描述，通過協(xié)作和各方確認(rèn)需求：

1. PM描述功能的用戶流程，用戶規(guī)則，說明前置條件和后置條件，包括補(bǔ)充流程圖和原型來說明。
2. 為User Story添加相關(guān)的業(yè)務(wù)，設(shè)計和開發(fā)人員作為Watchers，需求的協(xié)作流程和開發(fā)任務(wù)的類似，就是當(dāng)User Story的狀態(tài)為Confirmed以后，大家可以通過評論來反饋來交流有問題的地方。

3. 最后，當(dāng)討論確認(rèn)需求和原型之后就得到下面這樣的最終的User Story，整個討論和修改的history都被記錄下來。

三. 流程圖和產(chǎn)品原型

制作流程圖或者低保真的產(chǎn)品原型都是為了向業(yè)務(wù)和設(shè)計團(tuán)隊(duì)展示功能流程，在投入大量時間做設(shè)計和開發(fā)前得到早期反饋。

流程圖

流程圖繪制工具很多，我一般用Xmind來做，和任務(wù)管理系統(tǒng)共同使用，做好流程后作為附件放到Redmine相應(yīng)User Story的描述里，通過Redmine的評論進(jìn)行討論協(xié)作:

低保真產(chǎn)品原型

制作低保真產(chǎn)品原型是的工具有很多，我習(xí)慣用Balsamiq和Axure，場景有點(diǎn)差別：

基于Balsamiq Mockup的原型和流程描述

用Balsamiq Mockup制作原型用在Mobile項(xiàng)目上非常合適，因?yàn)閷τ谖疫@種手殘的來說可以很輕松制作看起來還過得去的原型，我自己一般的用法是用把原型串成流程圖帶一些注解，其實(shí)以前有個工具designboard.cc可以在線這么做，不過已經(jīng)不維護(hù)了，反正原型都做了其實(shí)就是把幾個拼成一張流程就可以，做好流程后作為附件放到Redmine相應(yīng)需求的描述里，協(xié)作同樣通過Redmine完成：

基于Axure Share的原型評審和協(xié)作

Axure還是原型界的老大，Dynamic Panel和全局變量能滿足大部分復(fù)雜交互描述，Master模板可以加快原型制作速度，加上有著豐富的類庫可以選擇，更新也很及時，現(xiàn)在推出Axure Share之后可以做頁面級別的評審回復(fù)，還是我目前主力使用的原型工具：

四. 基于InVision的設(shè)計稿評審

一般來說需求階段很大一部分時間都是花在設(shè)計師將原型輸出為設(shè)計稿之后，往往大家對設(shè)計圖的評審討論是最多的，出問題概率最大的地方，之前我們也是設(shè)計完成之后放在Redmine來討論的，不過在實(shí)踐當(dāng)中還是發(fā)現(xiàn)兩個問題：

1. 設(shè)計稿的討論經(jīng)常是針對一兩個比較細(xì)節(jié)的點(diǎn)來討論，每次討論都要描述到底在說哪里
2. 如果針對一個流程做一系列設(shè)計稿，用文件的方式組織就不如像原型一樣來的好理解

本來考慮過也是用Axure里低保真原型替換為高保真的設(shè)計稿原型，不過因?yàn)锳xure Share的評審功能還是基于頁面而不是元素，對于細(xì)節(jié)豐富的設(shè)計稿來說還是不太夠，后來試用了在線原型工具inVision，它的評審功能和Live Share討論比較驚艷，后來推出的Workflow也很實(shí)用，下面重點(diǎn)說一下我們基于inVision的設(shè)計評審和協(xié)作流程：

1. 相關(guān)的人員需要先注冊參與評審，一般來說User Story的Owner，設(shè)計師，核心開發(fā)人員都需要參與進(jìn)來進(jìn)行評審。
2. 由設(shè)計師在相應(yīng)Project上傳設(shè)計圖。我們所有的設(shè)計素材都在Dropbox上，可以直接連接Dropbox上傳，綁定Slack進(jìn)行評審人員通知，可以完全不用人工挨個通知。
3. inVision的Workflow將設(shè)計圖劃分為固定的幾個步驟，默認(rèn)的Workflow并不是完全合適我們的審核流程，我們給它的意義做了自定義：“待審核(Need Review)”，“開發(fā)中(In Progress)”，“已審核上線(Approved)”和“未來版本(On-hold)”，小團(tuán)隊(duì)的話可以像我們一樣用這些預(yù)設(shè)的狀態(tài)，企業(yè)級用戶可以自定義更多狀態(tài)。

4. 由業(yè)務(wù)團(tuán)隊(duì)和技術(shù)團(tuán)隊(duì)對待審核的設(shè)計稿進(jìn)行評審，可以在Web點(diǎn)擊任何元素來評論。
5. 對于Mobile版的評審，也有App可以獲得更真實(shí)的測試環(huán)境，進(jìn)行錄屏和錄音反饋。
6. 開會討論時可以直接使用Live Share實(shí)時語音討論，在設(shè)計稿上白板演示。這是inVision一個主要賣點(diǎn)，不過可惜網(wǎng)速問題我們用得比較少。
7. 最后把確認(rèn)好的設(shè)計稿都更新在inVision上，把設(shè)計稿鏈接放到Redmine相應(yīng)User Story的描述內(nèi)。

就安利到這里，目前缺點(diǎn)就是付費(fèi)版Workflow還不能自定義，另外國內(nèi)連接性真是很堪憂，也就能翻墻用…

五. 確認(rèn)開發(fā)任務(wù)分配

當(dāng)需求和設(shè)計都確認(rèn)以后就是安排開發(fā)人物了，基于項(xiàng)目管理工具來做需求的好處就是可以將所有的任務(wù)作為User Story的子任務(wù)，這樣一個需求的完成度就能很容易的得到，這個更多是項(xiàng)目管理里的部分。

六. 確認(rèn)功能推廣目標(biāo)如何記錄

在需求文檔里以前經(jīng)常漏掉的一點(diǎn)，因?yàn)橥茝V運(yùn)營過程中需要對一些數(shù)據(jù)進(jìn)行記錄和分析，這個在開發(fā)之前要考慮好，保證是可以track的，免得上線之后發(fā)現(xiàn)一些數(shù)據(jù)無法獲取，浪費(fèi)推廣資源。

后記

回過頭來總結(jié)為什么團(tuán)隊(duì)想這些方法去提高需求協(xié)作的效率，其實(shí)就是為了提高團(tuán)隊(duì)的執(zhí)行力，讓開發(fā)人員把精力放在開發(fā)上。既然不是專業(yè)做開發(fā)協(xié)作的，那肯定有很多疏漏或者不科學(xué)的地方，現(xiàn)在的流程只是目前的局部最優(yōu)方案，歡迎感興趣的與我交流。

作者：王超（微信號arnold_wangchao），創(chuàng)業(yè)者，5年互聯(lián)網(wǎng)產(chǎn)品管理經(jīng)驗(yàn)。本文轉(zhuǎn)自我個人的blog，有其他一些我自己的感悟和實(shí)踐，歡迎大家吐槽：）

本文由 @王超 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。