先說一下背景，大廠和小廠都呆過。呆過野蠻生長的傳統(tǒng)集團的互聯(lián)網(wǎng)部門，呆過上市的中型二線互聯(lián)網(wǎng)公司，呆過APPLE STORE行業(yè)APP排名第一的產(chǎn)品公司，現(xiàn)在呆在全球一萬多員工的超級獨角獸公司。

其實各個產(chǎn)品公司的迭代流程都大同小異，因為規(guī)范起來，迭代流程就是那一套。目前覺得差異比較大的就是使用的工具和具體管理的方式，這個也是很想跟大家一起討論的，看看有沒有更加高效的方式或工具。

這篇文章大概會從以下幾個方面分開講述，不排除我寫著寫著會修改大綱的可能：

一、需求收集

二、需求整理

三、優(yōu)先級劃分 及?需求交付（直白地說就是怎么寫 PRD 文檔）

四、需求評審 及 產(chǎn)品評審

五、需求變動（針對由于其他特殊問題導(dǎo)致的需求變動，產(chǎn)品經(jīng)理該如何做到“不背鍋”）

六、工具（滴答清單、為知筆記、confluence、JIRA、Axure）

如果感興趣的話，還有……

七、寫在最后

下面開始，是正文。

流程圖

先看一下大概的流程圖，每個環(huán)節(jié)再具體解釋

一、需求收集

其實不同類型的產(chǎn)品，需求來源會不太一樣。這里會盡量列出所有可能的來源。

用戶反饋：產(chǎn)品中包含『用戶反饋』頁面，用戶通過『用戶反饋』入口，直接反饋過來的一手信息。

用戶研究：通過用戶調(diào)研、用戶訪談、用戶拜訪、可用性測試等方法獲得的用戶一手信息。

客服團隊：通過客服團隊收集并反饋的二手信息。

市場/商務(wù)/BD團隊：通過市場/商務(wù)/BD團隊接觸用戶時，獲得的用戶需求。

內(nèi)部成員需求：測試團隊、開發(fā)團隊、運營團隊，針對產(chǎn)品提出的需求。

戰(zhàn)略型需求：來自競品的競爭壓力產(chǎn)生的需求，團隊制定的產(chǎn)品發(fā)展方向下的需求。

其他需求：老板需求。（牛逼的產(chǎn)品經(jīng)理可以忽略這一項……）

其實看似需求來源很多，再綜合一下，分析出來就是兩種：

1、外部需求；

2、內(nèi)部需求。

針對于外部需求，又分為『一手信息』獲得的需求和『二手信息』獲得的需求?！阂皇中畔ⅰ痪褪钱a(chǎn)品經(jīng)理直接從用戶方獲得的需求信息，是未中途經(jīng)人加工過的。經(jīng)過其他職能崗（如客服、市場、商務(wù)等）轉(zhuǎn)述給產(chǎn)品經(jīng)理的信息稱為『二手信息』，這類需求相對而言質(zhì)量沒有『一手信息』高，需要產(chǎn)品經(jīng)理再進行處理和分析。建議產(chǎn)品經(jīng)理都找到方式直接跟用戶進行溝通，而不是要假借他人之耳去聽取需求。

內(nèi)部需求，就是我們非常熟悉的了，經(jīng)常會從不同小組或者部門的同事那里獲得新的需求內(nèi)容，一般這些功能是針對于產(chǎn)品功能的可用性或者優(yōu)化的。再就是根據(jù)產(chǎn)品戰(zhàn)略制定的需求內(nèi)容。

這兩部分需求其實獲取起來沒那么難，外部需求就是，想盡一切方法去接觸用戶、然后跟用戶溝通。內(nèi)部需求就是，多跟同事們溝通，沒事兒多聊聊，問問看他們對于產(chǎn)品的看法。戰(zhàn)略型的需求內(nèi)容就不說了，這個涉及到不同公司的管理方式，說出來又是長篇大論的東西，甚至免不了要吐槽……

二、需求整理

如果需求收集做的比較到位，到手的需求是多且雜的，基本是千奇百怪什么都有。這種情況下，要做的流程圖上已經(jīng)比較詳細的說明了。

1、只保留有效需求

剔除那些看上去很明顯不合理的需求。這個步驟需要依賴產(chǎn)品經(jīng)理自身的經(jīng)驗和對自己產(chǎn)品的了解程度。

『對自己的產(chǎn)品很了解』，這一條看上去簡單但挺難做到的，需要的不僅僅是產(chǎn)品經(jīng)理自身的能力，還需要行業(yè)的經(jīng)驗、在公司呆的時間足夠長。只有滿足這些條件后，產(chǎn)品經(jīng)理才能夠很高效準(zhǔn)確地做到『只保留有效需求』。

2、需求分類

有效需求進一步分類就是：需討論的需求、需開發(fā)的需求、已有功能支持的需求

需討論的需求：對于是否需要做不是很確定，需要跟相關(guān)人員討論。

需開發(fā)的需求：需求強烈、跟當(dāng)前規(guī)劃一致、對短期目標(biāo)/長期目標(biāo)有助力……

已有功能支持的需求：這個是需要反思的，一般出現(xiàn)這種情況說明要么是功能的可見性做的有問題，要么是引導(dǎo)做的有問題，要么是功能不太符合用戶的認知模型。有一些需求是合理的要求就需要進行功能的優(yōu)化，甚至重新確定方案。

其中，確定開發(fā)的需求就能順利的進入到需求池了。需求池字面上來講就是管理需求的大池子，我覺得這形容詞挺形象的。在這個大池子里，你需要對需求進行優(yōu)先級的維護，方案的制定、補充、完善?，F(xiàn)在我是通過?JIRA + confluence?來進行管理和維護的，JIRA 和 confluence?簡直是神器好么，配合起來用簡直無敵。這個之后會在【六，工具】篇中進行具體的介紹。

3、標(biāo)簽

當(dāng)需求過多的時候，也可以給需求打上標(biāo)簽。如果說按照迭代排期來進行需求分類是基于時間線的縱向管理的話，打標(biāo)簽則是橫向管理。可以讓你更清晰的看到現(xiàn)在的需求在每一個模塊所占的比例和待做的內(nèi)容。

現(xiàn)在比較常用的標(biāo)簽大概是這幾類，當(dāng)然最好是根據(jù)自己的公司和產(chǎn)品的情況進行分類，我這里只是提供一個思路：

基礎(chǔ)體驗類：體驗上有問題了，這個一般是需要修改交互或者 UI，要求比較高的公司/產(chǎn)品可能還存在響應(yīng)速度、流暢性等方面的優(yōu)化

運營支持類：運營活動支持

功能優(yōu)化類：產(chǎn)品流程上存在一些問題，導(dǎo)致轉(zhuǎn)化率、響應(yīng)率等指標(biāo)過低

新需求類：嗯……就是新需求

數(shù)據(jù)分析類：埋點需求啊，或者一些公司有大數(shù)據(jù)部之類的部門還會存在，報表需求啊

技術(shù)架構(gòu)類：這個類別其實產(chǎn)品經(jīng)理比較少管，屬于架構(gòu)師負責(zé)的內(nèi)容，之所以寫在這里是因為有一些對特殊的模塊，技術(shù)架構(gòu)的修改會影響到很多功能的開發(fā)進度和產(chǎn)品設(shè)計。產(chǎn)品經(jīng)理對于這些需求的掌握是有助于產(chǎn)品規(guī)劃的。（簡單解釋一下啥是特殊模塊：比如，移動辦公軟件的『簽到』功能，用戶量大且存在上下班的流量高峰期；由于是基礎(chǔ)功能、對于穩(wěn)定性要求更高，一發(fā)生異常狀況基本就是要罰錢的…；存在各種情況，比如什么類型的考勤、進沒進圈、連沒連網(wǎng)、打沒打上等等，產(chǎn)品邏輯很負責(zé)；做過定位的人都知道，定位的技術(shù)手段太多，而且還有漂移、偏差矯正等，所以技術(shù)邏輯也復(fù)雜）

三、優(yōu)先級劃分及需求交付

這兩步其實占據(jù)了很多產(chǎn)品經(jīng)理的很大一部分工作量和思考時間吧……

1、優(yōu)先級劃分

其實關(guān)于這個模塊，我之前寫過一些 文章/回答 也有講怎么進行優(yōu)先級劃分。然后一直有跟大家推薦過一本書 Jeff Patton 的《用戶故事地圖》，我從中受益很多，也希望這本書能幫助到大家的工作。關(guān)于這本書，還寫過一系列的文章，算是我超級用心寫的第一篇文章了，我把鏈接貼在下面，感興趣的可以看一看：

「用戶故事地圖」能幫助產(chǎn)品經(jīng)理做的 6 件事情

這篇文章之前是分段發(fā)出來的，結(jié)果發(fā)現(xiàn)有些影響閱讀體驗，所以合成一篇了…大家將就看……

需求的類型在這里可以大致分為3種：

1、新功能；

2、迭代優(yōu)化；

3、bug fix（這里的 bug，可能是開發(fā)代碼 bug、可能是產(chǎn)品流程 bug）

針對1和2如何確定優(yōu)先級呢？首先需要搞清楚以下內(nèi)容：

產(chǎn)品的長期/中期規(guī)劃是怎樣的

當(dāng)前的 sprint 對于長期/中期規(guī)劃的意義是什么，是為了達到什么目標(biāo)

達到目的的 MVP 需要哪些功能

對于3如何確定優(yōu)先級呢？首先需要搞清楚以下內(nèi)容：

有沒有觸碰高壓線

fix 后能帶來什么

不 fix 能導(dǎo)致什么

比如我現(xiàn)在的公司，『安全』就是高壓線，如果發(fā)現(xiàn)什么問題對于『安全』因素有影響，哪怕可能性不是那么大，優(yōu)先級都是 P0。

再多說一句，我個人對于產(chǎn)品經(jīng)理好壞的判斷標(biāo)準(zhǔn)，其中有兩個維度就是：

對于『情報』的收集和分析能力

下決定的能力

產(chǎn)品經(jīng)理必須要能夠很快速的收集到關(guān)于當(dāng)前問題的盡可能多的『情報』，因為你所有的判斷都是需要依靠這些情報的。

優(yōu)柔寡斷的產(chǎn)品經(jīng)理，是我最忌諱的，不愿意深交。產(chǎn)品經(jīng)理需要你能夠基于當(dāng)前的所有信息，盡量快、準(zhǔn)地做出判斷，并且你需要為你的判斷承擔(dān)相應(yīng)的責(zé)任。

2、需求交付

應(yīng)該有很多人期待這個部分？看到好多文章都是在教產(chǎn)品經(jīng)理如何寫需求文檔。我這邊就不細說了？列個大綱，大家看看有沒有幫助吧，如果需要細說，請在評論區(qū)留言，我再根據(jù)留言補充一下內(nèi)容……

目前，我們這邊的最完整的需求內(nèi)容包括：

迭代記錄：版本號、修改時間、改了啥、為啥改、修改人（誰知道需求中途會不會換人呢，前面的人挖了個坑，也好去追責(zé)啊對不對？）

人員職能（非必須）：產(chǎn)品、交互、UI、前端、后端、客戶端（iOS Android） 分別是哪些小伙伴。大公司必備，特別是我們這種組織架構(gòu)完全看不到的公司……

需求類型：不清楚的同學(xué)翻翻前面的標(biāo)簽哈

需求背景：你不說清楚這個，開發(fā)和設(shè)計心里絕對會懷疑做這個需求的意義。部分產(chǎn)品經(jīng)理是不是覺得開發(fā)和設(shè)計的小伙伴不怎么配合你的工作啊？仔細想一下，自己在這部分的『忽悠』是不是不夠到位…

需求目標(biāo)

專業(yè)術(shù)語和縮寫解釋（非必須）

功能列表：這個就是一張大表了，需要包含 功能點名稱、所在模塊、使用場景描述、風(fēng)險點（風(fēng)險一定要提前暴露，引起大家的注意，大家能一起想辦法規(guī)避）、備注（這個你就愛寫啥寫啥，覺得啥重要寫啥）

流程圖 及 邏輯圖：這個不用多說吧……

文案：?如果你的 APP 包含有3種及以上的語言，你不寫個文檔保存試試……而且有文檔的話，比較利于 APP 在文案上的一致性

合作內(nèi)容（非必須）：你是跟哪個部門合作了啊，對接人是誰啊，用了他們的哪些接口啊

數(shù)據(jù)埋點（非必須）：哪些關(guān)鍵埋點是需要開發(fā)小伙伴幫你埋的呀，埋點名稱、埋點內(nèi)容，都需要寫清楚

公司的協(xié)作情況和產(chǎn)品需求的情況不同，可能需要寫的內(nèi)容也會不同。大家看著用咯。

四、需求評審及產(chǎn)品評審

不是所有的需求都需要進行需求評審的，只有一些相對『難搞』的需求才會進行需求評審。這個是需要靠產(chǎn)品經(jīng)理自己進行把控的。

1、需求評審

（1）什么需求需要需求評審

大型需求：需求功能多，一個人設(shè)計可能會考慮不周全，需要人幫忙補充完善，讓產(chǎn)品設(shè)計盡量全面

方案不太確定的需求：產(chǎn)品經(jīng)理對于方案有疑問，比如 不知道現(xiàn)在設(shè)計的方案在開發(fā)上是否可行、設(shè)計上是否可行、業(yè)務(wù)上是否可行；需要相關(guān)模塊更有經(jīng)驗的人一起做決策

與其他部門 / 模塊耦合較深：涉及其他部門/模塊的業(yè)務(wù)，需要跟兩方一起進行溝通商議

敏感需求：這個只能說是自行體會了，不是每個公司每個產(chǎn)品都會有敏感需求，而且敏感的點可能也會不一樣，可能是跟政府相關(guān)（比如：微博/抖音/快手/頭條 等面臨的整改要求）、可能是跟國家政策相關(guān)（比如 金融類產(chǎn)品？）、甚至是跟國外的政策相關(guān)（哈哈 比如我現(xiàn)在的公司…）、有的可能只是跟公司內(nèi)部相關(guān)（比如，有些公司老板說的需求某種程度上也算敏感需求，哪怕是改個 icon 大家也要一起腦暴……）

（2）目的

確認需求的必要性；粗略地確認方案的可靠性和可行性。

（3）參與人

產(chǎn)品經(jīng)理，主力開發(fā)，主力設(shè)計，其他和需求相關(guān)的、具有話語權(quán)的人

（4）準(zhǔn)備內(nèi)容

原型稿（著急的話），草稿也可以（厲害的話），方案裝腦子里，白板現(xiàn)畫也可以，總之，需要有一個相對全面的方案。不需要對細節(jié)進行描述，但各種情況需要考慮到。

（5）會議內(nèi)容

產(chǎn)品經(jīng)理可能會需要說到這些內(nèi)容：

開場白：簡單說明組織這次討論 / 會議的原因

需求背景：恩，這個一般情況下是需要說的，如果參會人員全部對于背景都非常了解了，也可以不說

需求目的：你做這個方案，是為了達到什么目的

需求內(nèi)容：開始講方案咯

拋出問題：具體描述組織這次會議的原因，及需要他人哪些支持

接下來就是，各種討論咯……

2、產(chǎn)品評審

（1）什么需求需要進行產(chǎn)品評審

都需要，大需求大說，小需求小說。

（2）目的

讓需求涉及到的所有成員，都能夠全面的了解到這個需求的方案、流程、細節(jié)，并完全確定最終方案；開發(fā)的同事需要對需求進行評估，給出排期和工時；確定后續(xù)各方的工作內(nèi)容；預(yù)知的風(fēng)險點也需要暴露。

（3）參與人

產(chǎn)品經(jīng)理，各執(zhí)行開發(fā)，各執(zhí)行設(shè)計，需求方（運營？業(yè)務(wù)方？等等），需求涉及到的協(xié)作方等。有些公司可能還會需要 leader 參會，這個就是看各個公司內(nèi)部的協(xié)作方式……

（4）準(zhǔn)備內(nèi)容

PRD：主要是，需求列表、流程圖、邏輯圖。當(dāng)然，如果邏輯比較簡單的話，交互稿就夠了

交互稿：必備

視覺稿：這個要是來不及的話，有多少看多少

（5）會議內(nèi)容

產(chǎn)品經(jīng)理可能會需要說到這些內(nèi)容：

開場白：簡單說明組織這次討論/會議的原因

需求背景：絕大多數(shù)情況下，大部分開發(fā)是第一次聽到這個需求，說明背景很有必要

需求目的：你做這個方案，是為了達到什么目的

需求內(nèi)容：開始講方案

確定方案：定下最終方案

確定協(xié)作：確定各個協(xié)作方做啥

給個 deadline：讓各方給個 deadline 咯，要不怎么催進度

五，需求變動

如果是由于自己考慮不周到導(dǎo)致的需求變動，那就只能自己想辦法了，請開發(fā)兄弟們多吃頓飯，反思一下為什么會導(dǎo)致這個問題，然后讓自己下次不再犯錯。

但是，如果說你是作為服務(wù)方，需要對接多個公司內(nèi)部的『甲方』，當(dāng)需求方頻繁的變更需求，又該怎么處理呢？

其實，說出來的話，方法挺簡單的。

1、產(chǎn)品評審?fù)ㄟ^后，不再允許修改方案；

2、如果需求方需要再修改方案，很簡單：填張表，郵件發(fā)送給產(chǎn)品經(jīng)理，抄送開發(fā) leader 及各部門領(lǐng)導(dǎo)。

表內(nèi)容需要包括：需求變更功能點，需求變更原因，需要重新開發(fā)的人力（幾人、天），需求變更人。

六、工具

總結(jié)一下我自己比較常用的工具：

滴答清單——日常工作梳理、管理、記錄

為知筆記——個人知識庫維護

confluence——產(chǎn)品文檔、工作文檔維護

JIRA——項目內(nèi)容記錄、追蹤、迭代維護

Axure——PRD 工具

ZEN——腦圖工具

1、滴答清單

滴答清單是我現(xiàn)在正在使用的，類似的 GTD 工具還有奇妙清單、todoist、Microsoft to-do等，選擇自己習(xí)慣的就好。

GTD 工具，能夠歸納現(xiàn)在手頭待做的事情，按順序安排好你之后一周每一天的工作內(nèi)容。

當(dāng)工作內(nèi)容太多了之后，就很容易就不知道做什么。每天花3分鐘，排好今天需要工作的內(nèi)容，工作效率就會高很多。并且，給任務(wù)設(shè)置好提醒時間，你也不容易漏掉重要的事情。

再有就是，可以根據(jù)項目或產(chǎn)品進行工作內(nèi)容的整理，可以很清楚的知道，每個項目當(dāng)前是什么進度，后續(xù)需要做什么。當(dāng)你能夠在視覺上區(qū)分各個項目/ 產(chǎn)品后，你的大腦里對于各個任務(wù)之間的關(guān)系和邏輯也就會更加清晰了。

再有就是，不知道大家的公司有沒有需要寫周報或者日報。是不是有時候不知道寫什么？那是因為你從來沒很好的記錄你今天到底做了些什么。有了 GTD 工具，也很容易進行工作總結(jié)，能夠很清晰的知道你這周做了些啥。回顧的時候，也會有成就感，感覺這周沒白過。

2、為知筆記

這個沒啥好說的了……筆記類的工具都差不多，關(guān)鍵是要找到合適自己的記錄方式，并要堅持去維護。其實我身邊有很多朋友做的比我好太多了。我就貼張圖吧，大家看看就得。關(guān)鍵還是要自己去試去做。

3、confluence 和 JIRA

confluence 和 JIRA?是Atlassian?這家公司出品的兩個軟件系統(tǒng)。

confluence?就是一個團隊協(xié)作的文檔管理軟件，可以用于整理團隊項目相關(guān)的所有文件內(nèi)容。

類似于現(xiàn)在的在線文檔協(xié)作平臺，石墨啊、騰訊文檔啊，N 個人可以同時對文檔進行編輯。但是?confluence?的功能更加強大。

比如，有樹形目錄管理，對于結(jié)構(gòu)復(fù)雜的迭代型文檔是必須的功能了。

文檔內(nèi)還 可以@團隊成員，并郵件通知到 ta。

文檔內(nèi)還可以直接鏈接到其他文檔，被鏈接文檔標(biāo)題修改后，鏈接文字自動同步修改，省去了同步維護的時間。

權(quán)限管理也很強大，可以精確到某個子頁面是否允許讀或編輯。

跟郵箱綁定后，當(dāng)你關(guān)注的文檔有了修改還能通過郵件通知到你具體修改了哪些部分。

更關(guān)鍵的是，直接跟?JIRA?打通，鏈接到?JIRA?的某個單，當(dāng)前單的狀態(tài)也能夠直接同步到?confluence?上。

這些都是非常實用并且能提高效率的功能。

JIRA?是一個需求管理、開發(fā)管理、項目管理的平臺。功能強大到可怕，隨你怎么用。目前我還沒發(fā)現(xiàn)我想做但是它做不了的。

由于這個截圖太難打馬賽克了，所以我直接從網(wǎng)上下載了一些圖，也能夠說明?JIRA?的強大。

直接可以通過Epic來管理項目，每個Epic還能看到每個Sprint的迭代?；久總€迭代需要完成的內(nèi)容都能一眼都看清楚。

還能根據(jù)自己團隊的迭代方式建立迭代階段，比如常見的是：需求池——交互設(shè)計——視覺設(shè)計——開發(fā)分配——開發(fā)中——測試——回歸。有些團隊可能在開發(fā)階段會再進行一些細分，這個根據(jù)團隊來就好。

還能很好的進行版本管理，哪些版本現(xiàn)在處于什么狀態(tài)、共有多少個需求/bug、完成了多少、還剩多少，都能一眼看清楚。

Axure 和 ZEN 我就不說啦~ 都是大家都非常了解的軟件了。

七、最后再多啰嗦幾句

如果你問我現(xiàn)在的迭代啊、管理啊、是不是完全按照上面說的內(nèi)容來的，我肯定要說：當(dāng)然不是啊……有一些項目還是沒有按照這個方式走的……

每個團隊和產(chǎn)品所處的狀態(tài)都不一樣，以上的方法不是一定都要按照這些東西做或者說這些方法就是最好的。

比如，當(dāng)團隊一共就一個產(chǎn)品經(jīng)理、一個設(shè)計、兩個開發(fā)，并且坐的很近回頭就能看到的情況，用這些方式效率可能就會太低了。像小團隊協(xié)作，如果大家都是靠譜的人，每天一個10分鐘內(nèi)的站會基本就能擺脫 jira 的需求了。產(chǎn)品經(jīng)理文檔也不需要寫這么復(fù)雜，需求點說清楚、關(guān)鍵時間點標(biāo)清楚就夠了。

之所以寫這些是希望，如果你在團隊協(xié)作或者迭代方面存在一些問題或者疑惑的時候，這篇文章能夠給到你一些參考。

希望每個產(chǎn)品經(jīng)理都能夠跟團隊配合的好好地、不要吵架，能很順暢的一起把產(chǎn)品越做越好~

最后，謝謝大家的支持?。ň瞎獈）

作者：SherlFang

鏈接：http://coffee.pmcaff.com/article/1258539500543104/pmcaff?utm_source=forum

來源：PMCAFF

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。