聊聊針對異地團隊的需求協作和原型、設計的評審

摘要：做產品的都知道，需求是無處不在的，可能來自於使用者的反饋，業務團隊的反饋，使用者行為的挖掘，團隊內部的idea或者上級的要求，人人都是產品經理也就是人人都可以提需求吧…既然有需求就要細化需求文件，製作原型，設計介面，這是幾乎每個產品團隊都會做的流程，本文不涉及如何更好地寫需求文件，只聊一下作為異地的產品團隊怎麼針對需求文件、原型和設計評審進行協作。

一點背景

我所謂的異地的產品團隊，可能會和遠端工作有較大區別。遠端工作是大部分人員都不在一起工作，就像37Signals的暢銷書《Remote》說的那樣，而異地的產品團隊是說一個團隊裡產品開發人員和市場業務人員不在一個地方工作，這個在一些瞄準海外市場的早期產品團隊裡是比較常見的，我們就屬於這種情況。

在異地協作的創業團隊，尤其是存在時差的情況下，會遇到的最大的問題就是對於無論是需求，還是原型和設計，都存在一個非同步確認的過程，不能面對面吵一架解決，那就需要合理的協作機制能方便的討論，反饋和追蹤。

需求文件需要協作的內容

我這裡說的產品需求文件(PRD)就是對於一個產品或者某個單獨的功能，PM需要通過與整個團隊一起來協作完成的需求描述：

• 與使用者、客戶、業務人員或產品團隊內部的溝通後梳理出需要解決的User Story
• 細化功能需求的前置條件和後置條件，使用者流程和規則
• 完成產品原型
• 和設計師溝通輸出設計稿供團隊評審
• 開發前與開發團隊溝通資料模型和任務分配
• 上線前和市場推廣團隊一起確認功能的Tracking Goal

這個過程不同的團隊不盡相同，但都是需要整個團隊一起來協作完成產品需求文件(PRD)的過程。

以前遇到過的坑

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

• 第一，無數個版本的需求文件

我最早做過的一些專案幾乎都是用Word來寫PRD，無論是像中國電信這樣大型國企，還是在海豚這樣的創業團隊，在做需求的過程中就會發現一個需求來回討論確認是很常見，有時候僅僅就是對某個文案的修改，但來回溝通就要發郵件，新建一個版本，然後就會變成下面這樣…

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

• 第二，確認的需求文件開發人員根本不看

做需求文件的目的就是服務功能的開發，但長篇的需求文件真的對開發人員極不友好，對某個特定功能需求的搜尋和反饋都不方便。

• 第三，產品迭代中沒有人去維護需求文件

開發過程中的需求變更基本是每個專案都會碰到的，新的需求一般都當面或者郵件的形式溝通好直接就開發了，一段時間後就再也不知道這個需求是誰提出來的，什麼時候加的，因為PM很難及時去更新Word的PRD，而且保證每個開發都看最新的PRD開發。

基於文件協作平臺(Google Doc)的需求協作

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

我自己覺得這種輕量的協作方式適用的場景是和不太願意參與產品開發過程的客戶協作的時候使用，因為雖然解決了交流協作的問題，但對產品開發團隊內部來說依然存在複雜的長文件，小變更難以維護的問題。

基於專案管理平臺(Redmine)的需求協作

我們從5年前開始接觸專案管理平臺，開始就是需求文件做好以後通過專案管理工具(Redmine)進行任務分配和進度追蹤，大家做開發的都懂，寫程式碼大家都還挺high，但不停彙報進度就很煩躁了，我們通過Redmine REST API開發Git hooks讓開發可以通過標準格式的commit message提交程式碼就能更新任務進度來改進流程，得到了開發人員的推崇，這5年來經過不下50個開發人員都使用的很愉快，沒用什麼學習時間，大部分的開發任務都能拿到較完整的程式碼提交上下文。

但在做專案的過程中，我們還是不斷遇到上面說的需求協作的問題影響到開發效率，初創產品不斷改需求經常讓大家爭吵某個需求到底是什麼時候加進來的，在PRD上怎麼找不到。我們就思考是不是可以把整個PRD融入到Redmine上，這樣的話：

1. 可以用極簡的Wiki語法寫功能的需求文件，不用糾結格式，還能逐步加入功能相關的流程圖，原型和設計稿的連結和相應的開發任務，甚至每行相關程式碼的提交記錄。
2. 可以把特定需求的整個上下文都track下來，包括需求的描述，對應的原型和設計以及圍繞這些的討論，向下能包含所有相關開發任務和任務的完成度，向上又能追溯到關聯的需求，這樣團隊都能儘量focus在沒有討論過的問題和需要開發的任務，而不是重複地產生“這個我們以前確認過…”這樣的聲音了。

下面具體到需求協作的流程中來實際操作一下：

一. 記錄需要解決的User Story

摘要裡說過，需求是無處不在的，可能來自於使用者的反饋，業務團隊的反饋，使用者行為的挖掘，團隊內部的idea或者上級的要求，我們不可能拿到需求就開發，首先需要先記錄下來，我們的流程是由PM從各處彙總後在週會上討論，確認哪些是需要考慮放在哪個milestone來開發，哪些現在不考慮的會放在一個叫future version的虛擬版本里以後再考慮，這兩類都新建User Story放到Redmine上進行track。

然後我們對進入Redmine的所有User Story按照不同客戶端分為PRD-mobile，PRD-User Site，PRD-Web Admin，PRD-Wechat四類，有的團隊可能習慣按照功能模組來劃分分類，取決於專案規模，專案規模太大確實有必要。

最後在Redmine上我們會有自定義的Query來檢視這些User Story，可以按照狀態過濾出目前系統不同客戶端已經完成的所有功能，對內部人員來說相當於一個完整的產品需求文件。當然也可以按照不同milestone，是不是已經完成等各種條件來過濾檢視。

二. 細化和討論確定功能需求

對於確定要排入milestone的User Story，PM需要按計劃完成需求描述，通過協作和各方確認需求：

1. PM描述功能的使用者流程，使用者規則，說明前置條件和後置條件，包括補充流程圖和原型來說明。
2. 為User Story新增相關的業務，設計和開發人員作為Watchers，需求的協作流程和開發任務的類似，就是當User Story的狀態為Confirmed以後，大家可以通過評論來反饋來交流有問題的地方。
3. 最後，當討論確認需求和原型之後就得到下面這樣的最終的User Story，整個討論和修改的history都被記錄下來。

三. 流程圖和產品原型

製作流程圖或者低保真的產品原型都是為了向業務和設計團隊展示功能流程，在投入大量時間做設計和開發前得到早期反饋。

• 流程圖流程圖繪製工具很多，我一般用Xmind來做，和任務管理系統共同使用，做好流程後作為附件放到Redmine相應User Story的描述裡，通過Redmine的評論進行討論協作:
• 低保真產品原型製作低保真產品原型是的工具有很多，我習慣用Balsamiq和Axure，場景有點差別：
  1. 基於Balsamiq Mockup的原型和流程描述用Balsamiq Mockup製作原型用在Mobile專案上非常合適，因為對於我這種手殘的來說可以很輕鬆製作看起來還過得去的原型，我自己一般的用法是用把原型串成流程圖帶一些註解，其實以前有個工具designboard.cc可以線上這麼做，不過已經不維護了，反正原型都做了其實就是把幾個拼成一張流程就可以，做好流程後作為附件放到Redmine相應需求的描述裡，協作同樣通過Redmine完成：
  2. 基於Axure Share的原型評審和協作Axure還是原型界的老大，Dynamic Panel和全域性變數能滿足大部分複雜互動描述，Master模板可以加快原型製作速度，加上有著豐富的類庫可以選擇，更新也很及時，現在推出Axure Share之後可以做頁面級別的評審回覆，還是我目前主力使用的原型工具：

四. 基於InVision的設計稿評審

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

1. 設計稿的討論經常是針對一兩個比較細節的點來討論，每次討論都要描述到底在說哪裡
2. 如果針對一個流程做一系列設計稿，用檔案的方式組織就不如像原型一樣來的好理解

本來考慮過也是用Axure裡低保真原型替換為高保真的設計稿原型，不過因為Axure Share的評審功能還是基於頁面而不是元素，對於細節豐富的設計稿來說還是不太夠，後來試用了線上原型工具inVision，它的評審功能和Live Share討論比較驚豔，後來推出的Workflow也很實用，下面重點說一下我們基於inVision的設計評審和協作流程：

1. 相關的人員需要先註冊參與評審，一般來說User Story的Owner，設計師，核心開發人員都需要參與進來進行評審。
2. 由設計師在相應Project上傳設計圖。我們所有的設計素材都在Dropbox上，可以直接連線Dropbox上傳，繫結Slack進行評審人員通知，可以完全不用人工挨個通知。
3. inVision的Workflow將設計圖劃分為固定的幾個步驟，預設的Workflow並不是完全合適我們的稽核流程，我們給它的意義做了自定義：“待稽核(Need Review)”，“開發中(In Progress)”，“已稽核上線(Approved)”和“未來版本(On-hold)”，小團隊的話可以像我們一樣用這些預設的狀態，企業級使用者可以自定義更多狀態。
4. 由業務團隊和技術團隊對待稽核的設計稿進行評審，可以在Web點選任何元素來評論。
5. 對於Mobile版的評審，也有App可以獲得更真實的測試環境，進行錄屏和錄音反饋。
6. 開會討論時可以直接使用Live Share實時語音討論，在設計稿上白板演示。這是inVision一個主要賣點，不過可惜網速問題我們用得比較少。
7. 最後把確認好的設計稿都更新在inVision上，把設計稿連結放到Redmine相應User Story的描述內。

就安利到這裡，目前缺點就是付費版Workflow還不能自定義，另外國內連線性真是很堪憂，也就能翻qiang用…

五. 確認開發任務分配

當需求和設計都確認以後就是安排開發任務了，基於專案管理工具來做需求的好處就是可以將所有的任務作為User Story的子任務，這樣一個需求的完成度就能很容易的得到，這個更多是專案管理裡的部分。

六. 確認功能推廣目標如何記錄

在需求文件裡以前經常漏掉的一點，因為推廣運營過程中需要對一些資料進行記錄和分析，這個在開發之前要考慮好，保證是可以track的，免得上線之後發現一些資料無法獲取，浪費推廣資源。

後記

回過頭來總結為什麼團隊想這些方法去提高需求協作的效率，其實就是為了提高團隊的執行力，讓開發人員把精力放在開發上。既然不是專業做開發協作的，那肯定有很多疏漏或者不科學的地方，現在的流程只是目前的區域性最優方案，歡迎感興趣的與我交流。