中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

我所謂的異地的產品團隊，可能會和遠程工作有較大區別。遠程工作是大部分人員都不在一起工作，就像《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開發[githooks][5]讓開發可以通過標準格式的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，場景有點差別：

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

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

基于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還不能自定義，另外國內連接性真是很堪憂，也就能翻墻用…

五. 確認開發任務分配

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

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

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

后記

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

作者：王超（微信號arnold_wangchao），創業者，5年互聯網產品管理經驗。本文轉自我個人的blog，有其他一些我自己的感悟和實踐，歡迎大家吐槽：）

本文由 @王超 原創發布于人人都是產品經理?，未經許可，禁止轉載。