上文提到了產(chǎn)品經(jīng)理要頻繁跟工程師溝通需求延蟹，這種需求的溝通是有跡可循的评矩。絕不是漫無目的、東榔頭西錘子等孵，一有什么想法就跑過去吧啦吧啦說一大通稚照。

需求溝通要做到有跡可循，離不開需求管理俯萌。

互聯(lián)網(wǎng)上有各種資料和文章論述如何需求管理果录，每家公司每個團隊的工作方式各有不同，需求管理的具體實現(xiàn)方式也有差別咐熙。

不需要過于拘泥形式弱恒，只要遵循一些基本要點，結(jié)合實際情況去實施棋恼，能幫助團隊提高效率就行返弹。畢竟，鞋子合不合適爪飘，自己說了才算义起。

以下，筆者結(jié)合工作經(jīng)驗和Scrum的一些原則师崎，粗略談?wù)剬π枨蠊芾淼睦斫狻?/p>

需求管理涉及了需求池默终、產(chǎn)品需求、迭代需求列表犁罩、需求優(yōu)先級劃分齐蔽。

1. 需求池

需求池記錄了各種來源的需求，不僅僅是產(chǎn)品經(jīng)理床估，團隊任何人都可以記錄含滴。

比如頭腦風(fēng)暴時，研發(fā)部丐巫、市場部谈况、運營部、客服部递胧、管理層的人員會提各種想法碑韵，這時候鼓勵他們都記錄下來。我們用Confluence建立了需求池谓着，里面有基本的書寫格式，包括編號坛掠、需求描述赊锚、提交時間治筒、備注等等，需求提出者按格式填寫就行舷蒲。

Confluence記錄的好處是耸袜，團隊里每個人都能在需求池編輯，并且所有的內(nèi)容都是公開牲平、可追溯的堤框。這就相當(dāng)于提供了一個公共場所，在里面大家可以暢所欲言纵柿，有助于激發(fā)團隊溝通需求的活力蜈抓。

而如果用Excel之類的，往往就產(chǎn)品經(jīng)理一人在維護昂儒，即使把Excel發(fā)給成員填寫沟使，這郵件一來一回，然后產(chǎn)品經(jīng)理還要統(tǒng)一歸整渊跋，效率和效果都大打折扣腊嗡。

當(dāng)然，需求池里面的內(nèi)容拾酝，主要還是產(chǎn)品經(jīng)理在操心燕少。

用戶調(diào)研的材料收集、用戶的反饋意見蒿囤、競品分析時看到有價值的點或者解決方案客们，產(chǎn)品經(jīng)理都要一一記錄，提防遺忘蟋软。

2. 產(chǎn)品需求

需求池記錄的是原始的需求材料镶摘，來源五花八門，這些材料是無法直接交給程序員的岳守。產(chǎn)品經(jīng)理通過對原始材料的加工提取凄敢，寫成一個一個的用戶故事，就形成了產(chǎn)品需求湿痢。按照Scrum的說法涝缝，個人理解產(chǎn)品需求列表對應(yīng)于Product Backlog。

產(chǎn)品需求譬重，就完全由產(chǎn)品經(jīng)理寫了拒逮。

產(chǎn)品需求，書寫格式包括了編號臀规，需求池編號滩援，迭代版本號，用戶故事塔嬉，需求優(yōu)先級玩徊，行動項租悄，備注，需求狀態(tài)恩袱，Jira工作項等等泣棋。

編號

編號就是需求列表的順序號，主要是作為當(dāng)前需求的唯一性標(biāo)識畔塔。

需求池編號

產(chǎn)品需求對應(yīng)的需求池來源潭辈。

迭代版本號

需求被納入在哪個版本里實現(xiàn)。

用戶故事

按照慣例澈吨，三段式寫法：“作為……把敢，希望……，以便……”棚辽，作為后面是角色技竟，有些產(chǎn)品可以細(xì)化到游客、注冊用戶屈藐、付費用戶榔组、不同級別的用戶等，希望后面寫用戶想要的功能联逻，以便后面寫價值搓扯，即實現(xiàn)了功能，能夠給用戶帶來什么價值包归。

比如朋友圈的某個用戶故事锨推，“作為旅行達人，希望用照片和文字記錄我的足跡公壤，以便查看和分享”

需求優(yōu)先級

這部分后續(xù)文章重點敘述

行動項

記錄實現(xiàn)用戶故事需要的條件和步驟换可，這部分內(nèi)容主要給工程師查閱。

備注

其它任何信息厦幅，如：需求期望完成時間沾鳄、被拒絕原因、暫緩原因确憨。

需求狀態(tài)

我們只用了兩個狀態(tài)記錄需求的完成情況译荞，TBD表示待辦，DONE表示完成休弃。

Jira工作項

用戶故事對應(yīng)的開發(fā)內(nèi)容吞歼。Jira工作項里面詳細(xì)描述了需求內(nèi)容，UI和交互細(xì)節(jié)塔猾，這些信息是經(jīng)過團隊需求評審后的終稿篙骡，不但程序員的開發(fā)，測試工程師的驗證工作也嚴(yán)格依照J(rèn)ira工作項進行。

Jira是任務(wù)跟蹤的好工具糯俗，同上面提到的Confluence一樣慎皱，都出自Atlassian公司，不少企業(yè)喜歡用Confluence+Jira的組合進行知識庫管理和項目管理叶骨。

3. 迭代需求列表

這部分工作項內(nèi)容來源于產(chǎn)品需求，對應(yīng)于Scrum的Sprint Backlog祈匙。另外還有各種Bug忽刽，有些是產(chǎn)品經(jīng)理從以前遺留的Bug里挑選的、需要在本次迭代解決的夺欲，有些來自測試人員在本次版本發(fā)現(xiàn)而提出的跪帝。在這個需求列表里所有工作項和Bug，理論上都需要在本次迭代發(fā)布前全部解決些阅。

按照Scrum的工作方式伞剑，產(chǎn)品經(jīng)理從Product Backlog里移動產(chǎn)品需求到一個Sprint里，一個Sprint就是一個迭代周期市埋。

在一個迭代周期里黎泣，產(chǎn)品需求是確定的。這種確定性體現(xiàn)在：

第一缤谎、工期抒倚、任務(wù)范圍、干系人是明確的

第二坷澡、產(chǎn)品需求是經(jīng)過團隊評審確定的

總之托呕，有了確定性，產(chǎn)品經(jīng)理和工程師的溝通就能夠在一個頻道上進行频敛，剩下的项郊，就是工作過程中細(xì)節(jié)的推進了。

4. 結(jié)語

產(chǎn)品經(jīng)理跟程序員能不能愉快的溝通斟赚，需求管理這個環(huán)節(jié)是少不了的了着降。整個研發(fā)、測試團隊后續(xù)的工作都依賴于產(chǎn)品需求汁展，產(chǎn)品驗收鹊碍、發(fā)布的標(biāo)準(zhǔn)也依賴于此。

當(dāng)然食绿，需求管理不是固化的板塊侈咕，它是動態(tài)更新的。我們基本上是每天更新器紧，因為除了有源源不斷的需求進來耀销，研發(fā)每天在Jira完成的工作狀態(tài)也會反映到需求管理里，這樣，產(chǎn)品迭代的進度就一目了然熊尉。