作者：SherlFang 個人網站：iamsherl.com （轉載已取得作者授權）這篇文章也是對我自己這幾年產品做事方式的一個流程總結吧…… 先說一下背景，大廠和小廠都呆過。呆過野蠻生長的傳統集團的互聯網部門，呆過上市的中型二線互聯網公司，呆過 APPLE STORE 行業APP 排名第一的產品公司，現在呆在全球一萬多員工的超級獨角獸公司。 其實各個產品公司的迭代流程都大同小異，因為規范起來，迭代流程就是那一套。目前覺得差異比較大的就是使用的工具和具體管理的方式，這個也是很想跟大家一起討論的，看看有沒有更加高效的方式或工具。 這篇文章大概會從以下幾個方面分開講述，不排除我寫著寫著會修改大綱的可能： 一，需求收集 二，需求整理 三，優先級劃分 及?需求交付（直白地說就是怎么寫 PRD 文檔） 四，需求評審 及 產品評審 五，需求變動（針對由于其他特殊問題導致的需求變動，產品經理該如何做到“不背鍋”） 六，工具（滴答清單、為知筆記、confluence、JIRA、Axure） 如果感興趣的話，還有…… 七，如何更高效地跟交互、UI 設計、開發、測試 溝通和交流（這部分貌似沒人感興趣我就不寫了……） 下面開始，是正文。 〇，流程圖先看一下大概的流程圖，每個環節再具體解釋一，需求收集其實不同類型的產品，需求來源會不太一樣。這里會盡量列出所有可能的來源。 用戶反饋：產品中包含『用戶反饋』頁面，用戶通過『用戶反饋』入口，直接反饋過來的一手信息。 用戶研究：通過用戶調研、用戶訪談、用戶拜訪、可用性測試等方法獲得的用戶一手信息。 客服團隊：通過客服團隊收集并反饋的二手信息。 市場/商務/BD團隊：通過市場/商務/BD團隊接觸用戶時，獲得的用戶需求。 內部成員需求：測試團隊、開發團隊、運營團隊，針對產品提出的需求。 戰略型需求：來自競品的競爭壓力產生的需求，團隊制定的產品發展方向下的需求。 其他需求：老板需求。（牛逼的產品經理可以忽略這一項……） 其實看似需求來源很多，再綜合一下，分析出來就是兩種：1，外部需求；2，內部需求。 針對于外部需求，又分為『一手信息』獲得的需求和『二手信息』獲得的需求。『一手信息』就是產品經理直接從用戶方獲得的需求信息，是未中途經人加工過的。經過其他職能崗（如客服、市場、商務等）轉述給產品經理的信息稱為『二手信息』，這類需求相對而言質量沒有『一手信息』高，需要產品經理再進行處理和分析。建議產品經理都找到方式直接跟用戶進行溝通，而不是要假借他人之耳去聽取需求。 內部需求，就是我們非常熟悉的了，經常會從不同小組或者部門的同事那里獲得新的需求內容，一般這些功能是針對于產品功能的可用性或者優化的。再就是根據產品戰略制定的需求內容。 這兩部分需求其實獲取起來沒那么難，外部需求就是，想盡一切方法去接觸用戶、然后跟用戶溝通。內部需求就是，多跟同事們溝通，沒事兒多聊聊，問問看他們對于產品的看法。戰略型的需求內容就不說了，這個涉及到不同公司的管理方式，說出來又是長篇大論的東西，甚至免不了要吐槽…… 二，需求整理如果需求收集做的比較到位，到手的需求是多且雜的，基本是千奇百怪什么都有。這種情況下，要做的流程圖上已經比較詳細的說明了。 1，只保留有效需求剔除那些看上去很明顯不合理的需求。這個步驟需要依賴產品經理自身的經驗和對自己產品的了解程度。 『對自己的產品很了解』，這一條看上去簡單但挺難做到的，需要的不僅僅是產品經理自身的能力，還需要行業的經驗、在公司呆的時間足夠長。只有滿足這些條件后，產品經理才能夠很高效準確地做到『只保留有效需求』。 2，需求分類有效需求進一步分類就是：需討論的需求、需開發的需求、已有功能支持的需求

• 需討論的需求：對于是否需要做不是很確定，需要跟相關人員討論。

• 需開發的需求：需求強烈、跟當前規劃一致、對短期目標/長期目標有助力、……

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

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

3，標簽

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

現在比較常用的標簽大概是這幾類，當然最好是根據自己的公司和產品的情況進行分類，我這里只是提供一個思路：

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

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

• 功能優化類：產品流程上存在一些問題，導致轉化率、響應率等指標過低

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

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

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

三，優先級劃分 及?需求交付

這兩步其實占據了很多產品經理的很大一部分工作量和思考時間吧……

1，優先級劃分

哈哈，其實關于這個模塊，我之前寫過一些 文章/回答 也有講怎么進行優先級劃分。然后一直有跟大家推薦過一本書 Jeff Patton 的《用戶故事地圖》，我從中受益很多，也希望這本書能幫助到大家的工作。

需求的類型在這里可以大致分為3種：1，新功能；2，迭代優化；3，bug fix（這里的 bug 可能是開發代碼 bug、可能是產品流程 bug）

針對1和2如何確定優先級呢？首先需要搞清楚以下內容：

• 產品的長期/中期規劃是怎樣的

• 當前的 sprint 對于長期/中期規劃的意義是什么，是為了達到什么目標

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

對于3如何確定優先級呢？首先需要搞清楚以下內容：

• 有沒有觸碰高壓線

• fix 后能帶來什么

• 不 fix 能導致什么

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

再多說一句，我個人對于產品經理好壞的判斷標準，其中有兩個維度就是：

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

• 下決定的能力

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

優柔寡斷的產品經理，是我最忌諱的，不愿意深交。產品經理需要你能夠基于當前的所有信息，盡量快、準地做出判斷，并且你需要為你的判斷承擔相應的責任。

2，需求交付

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

目前，我們這邊的最完整的需求內容包括：

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

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

需求類型：不清楚的同學翻翻前面的標簽哈

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

需求目標

專業術語和縮寫解釋（非必須）

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

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

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

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

數據埋點（非必須）：哪些關鍵埋點是需要開發小伙伴幫你埋的呀，埋點名稱、埋點內容，都需要寫清楚

?公司的協作情況和產品需求的情況不同，可能需要寫的內容也會不同。大家看著用咯。

四，需求評審 及 產品評審

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

1，需求評審

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

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

• 方案不太確定的需求：產品經理對于方案有疑問，比如 不知道現在設計的方案在開發上是否可行、設計上是否可行、業務上是否可行；需要相關模塊更有經驗的人一起做決策

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

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

（2）目的

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

（3）參與人

產品經理，主力開發，主力設計，其他和需求相關的、具有話語權的人

（4）準備內容

原型稿 / 著急的話，草稿也可以 / 牛逼的話，方案裝腦子里，白板現畫也可以

總之，需要有一個相對全面的方案。不需要對細節進行描述，但各種情況需要考慮到。

（5）會議內容

產品經理可能會需要說到這些內容：

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

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

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

• 需求內容：開始講方案咯

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

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

2，產品評審

（1）什么需求需要進行產品評審

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

（2）目的

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

（3）參與人

產品經理，各執行開發，各執行設計，需求方（運營？業務方？等等），需求涉及到的協作方等。有些公司可能還會需要 leader 參會，這個就是看各個公司內部的協作方式咯……

（4）準備內容

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

• 交互稿：必備

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

（5）會議內容

產品經理可能會需要說到這些內容：

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

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

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

• 需求內容：開始講方案咯

• 確定方案：定下最終方案咯

• 確定協作：確定各個協作方做啥

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

五，需求變動

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

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

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

1，產品評審通過后，不再允許修改方案；

2，如果需求方需要再修改方案，很簡單：填張表，郵件發送給產品經理，抄送開發 leader 及各部門領導。

表內容需要包括：需求變更功能點，需求變更原因，需要重新開發的人力（幾人天），需求變更人。

六，工具

總結一下我自己比較常用的工具：

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

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

• confluence——產品文檔、工作文檔維護

• JIRA——項目內容記錄、追蹤、迭代維護

• Axure——PRD 工具

• ZEN——腦圖工具

1，滴答清單

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

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

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

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

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

2，為知筆記

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

3，confluence 和 JIRA

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

confluence 就是一個團隊協作的文檔管理軟件，可以用于整理團隊項目相關的所有文件內容。

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

• 比如，有樹形目錄管理，對于結構復雜的迭代型文檔是必須的功能了。

• 文檔內還 可以@團隊成員，并郵件通知到 ta。

• 文檔內還可以直接鏈接到其他文檔，被鏈接文檔標題修改后，鏈接文字自動同步修改，省去了同步維護的時間。

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

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

• 更關鍵的是，直接跟 JIRA 打通，鏈接到 JIRA 的某個單，當前單的狀態也能夠直接同步到 confluence 上。

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

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

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

直接可以通過 Epic 來管理項目，每個 Epic 還能看到每個 Sprint 的迭代。基本每個迭代需要完成的內容都能一眼都看清楚。

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

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

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

七，最后再多啰嗦幾句

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

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

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

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

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

最后，謝謝大家的支持！（鞠躬~）

最后也歡迎有問題的小伙伴加微信：chanpin628?溝通交流。

此外我們的官方網站也上線了，每日分享高質量的文章、原型素材和行業報告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點擊底部的閱讀原文直接查看，或者復制網址：www.dadaghp.com?打開。

更多干貨可關注微信公眾號：產品劉

想學習更多關于產品、職場、心理、認知等干貨，可長按右邊二維碼，關注我們。

··················END··················

RECOMMEND

推薦閱讀

產品經理的冬天來了嘛？

面試官重點考察求職者這5項能力

線下實戰2.0

面試題，你覺得產品經理的職責有哪些？

點擊“閱讀原文”

查看更多干貨

總結

以上是生活随笔為你收集整理的大厂的产品经理是怎样进行产品迭代的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。