大厂的产品经理是怎样进行产品迭代的
需討論的需求：對于是否需要做不是很確定，需要跟相關(guān)人員討論。
需開發(fā)的需求：需求強烈、跟當(dāng)前規(guī)劃一致、對短期目標(biāo)/長期目標(biāo)有助力、……
已有功能支持的需求：這個是需要反思的，一般出現(xiàn)這種情況說明要么是功能的可見性做的有問題，要么是引導(dǎo)做的有問題，要么是功能不太符合用戶的認(rèn)知模型。有一些需求是合理的要求就需要進(jìn)行功能的優(yōu)化，甚至重新確定方案。
其中，確定開發(fā)的需求就能順利的進(jìn)入到需求池了。需求池字面上來講就是管理需求的大池子，我覺得這形容詞挺形象的。在這個大池子里，你需要對需求進(jìn)行優(yōu)先級的維護(hù)，方案的制定、補充、完善。現(xiàn)在我是通過 JIRA + confluence 來進(jìn)行管理和維護(hù)的，JIRA 和 confluence 簡直是神器好么，配合起來用簡直無敵。這個之后會在【六，工具】篇中進(jìn)行具體的介紹。
3，標(biāo)簽
當(dāng)需求過多的時候，也可以給需求打上標(biāo)簽。如果說按照迭代排期來進(jìn)行需求分類是基于時間線的縱向管理的話，打標(biāo)簽則是橫向管理。可以讓你更清晰的看到現(xiàn)在的需求在每一個模塊所占的比例和待做的內(nèi)容。
現(xiàn)在比較常用的標(biāo)簽大概是這幾類，當(dāng)然最好是根據(jù)自己的公司和產(chǎn)品的情況進(jì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)師負(fù)責(zé)的內(nèi)容，之所以寫在這里是因為有一些對特殊的模塊，技術(shù)架構(gòu)的修改會影響到很多功能的開發(fā)進(jìn)度和產(chǎn)品設(shè)計。產(chǎn)品經(jīng)理對于這些需求的掌握是有助于產(chǎn)品規(guī)劃的。（簡單解釋一下啥是特殊模塊：比如，移動辦公軟件的『簽到』功能，用?戶量大且存在?上下班的流量高峰期；由于是基礎(chǔ)功能、對于穩(wěn)定性要求更高，一發(fā)生異常狀況基本就是要罰錢的…；存在各種情況，比如什么類型的考勤、進(jìn)沒進(jìn)圈、連沒連網(wǎng)、打沒打上等等，產(chǎn)品邏輯很負(fù)責(zé)；做過定位的人都知道，定位的技術(shù)手段太多，而且還有漂移、偏差矯正等，所以技術(shù)邏輯也復(fù)雜）
三，優(yōu)先級劃分 及?需求交付
這兩步其實占據(jù)了很多產(chǎn)品經(jīng)理的很大一部分工作量和思考時間吧……
1，優(yōu)先級劃分
哈哈，其實關(guān)于這個模塊，我之前寫過一些 文章/回答 也有講怎么進(jìn)行優(yōu)先級劃分。然后一直有跟大家推薦過一本書 Jeff Patton 的《用戶故事地圖》，我從中受益很多，也希望這本書能幫助到大家的工作。
需求的類型在這里可以大致分為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ī)劃的意義是什么，是為了達(dá)到什么目標(biāo)
達(dá)到目的的 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)理如何寫需求文檔。我這邊就不細(xì)說了？列個大綱，大家看看有沒有幫助吧，如果需要細(xì)說，請在評論區(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è)計的小伙伴不怎么配合你的工作啊？仔細(xì)想一下，自己在這部分的『忽悠』是不是不夠到位…
需求目標(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)品評審
不是所有的需求都需要進(jìn)行需求評審的，只有一些相對『難搞』的需求才會進(jìn)行需求評審。這個是需要靠產(chǎn)品經(jīng)理自己進(jìn)行把控的。
1，需求評審
（1）什么需求需要需求評審
大型需求：需求功能多，一個人設(shè)計可能會考慮不周全，需要人幫忙補充完善，讓產(chǎn)品設(shè)計盡量全面
方案不太確定的需求：產(chǎn)品經(jīng)理對于方案有疑問，比如 不知道現(xiàn)在設(shè)計的方案在開發(fā)上是否可行、設(shè)計上是否可行、業(yè)務(wù)上是否可行；需要相關(guān)模塊更有經(jīng)驗的人一起做決策
與其他部門 / 模塊耦合較深：涉及其他部門 / 模塊的業(yè)務(wù)，需要跟兩方一起進(jìn)行溝通商議
敏感需求：恩……這個只能說是自行體會了……不是每個公司每個產(chǎn)品都會有敏感需求，而且敏感的點可能也會不一樣，可能是跟政府相關(guān)（比如 微博/抖音/快手/頭條 等面臨的整改要求）、可能是跟國家政策相關(guān)（比如 金融類產(chǎn)品？）、甚至是跟國外的政策相關(guān)（哈哈 比如我現(xiàn)在的公司…）、有的可能只是跟公司內(nèi)部相關(guān)（比如，有些公司老板說的需求某種程度上也算敏感需求，哪怕是改個 icon 大家也要一起腦暴……）
（2）目的
確認(rèn)需求的必要性；粗略地確認(rèn)方案的可靠性 和 可行性。
（3）參與人
產(chǎn)品經(jīng)理，主力開發(fā)，主力設(shè)計，其他和需求相關(guān)的、具有話語權(quán)的人
（4）準(zhǔn)備內(nèi)容
原型稿 / 著急的話，草稿也可以 / 牛逼的話，方案裝腦子里，白板現(xiàn)畫也可以
總之，需要有一個相對全面的方案。不需要對細(xì)節(jié)進(jìn)行描述，但各種情況需要考慮到。
（5）會議內(nèi)容
產(chǎn)品經(jīng)理可能會需要說到這些內(nèi)容：
開場白：簡單說明組織這次討論 / 會議的原因
需求背景：恩，這個一般情況下是需要說的，如果參會人員全部對于背景都非常了解了，也可以不說
需求目的：你做這個方案，是為了達(dá)到什么目的
需求內(nèi)容：開始講方案咯
拋出問題：具體描述組織這次會議的原因，及需要他人哪些支持
接下來就是，各種討論咯……
2，產(chǎn)品評審
（1）什么需求需要進(jìn)行產(chǎn)品評審
都需要，大需求大說，小需求小說。
（2）目的
讓需求涉及到的所有成員，都能夠全面的了解到這個需求的方案、流程、細(xì)節(jié)，并完全確定最終方案；開發(fā)的同事需要對需求進(jìn)行評估，給出排期和工時；確定后續(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ā)是第一次聽到這個需求，說明背景很有必要
需求目的：你做這個方案，是為了達(dá)到什么目的
需求內(nèi)容：開始講方案咯
確定方案：定下最終方案咯
確定協(xié)作：確定各個協(xié)作方做啥
給個 deadline：讓各方給個 deadline 咯，要不怎么催進(jìn)度
五，需求變動
如果是由于自己考慮不周到導(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é)一下我自己比較常用的工具：
滴答清單——日常工作梳理、管理、記錄
為知筆記——個人知識庫維護(hù)
confluence——產(chǎn)品文檔、工作文檔維護(hù)
JIRA——項目內(nèi)容記錄、追蹤、迭代維護(hù)
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)品進(jìn)行工作內(nèi)容的整理，可以很清楚的知道，每個項目當(dāng)前是什么進(jìn)度，后續(xù)需要做什么。當(dāng)你能夠在視覺上區(qū)分各個項目/ 產(chǎn)品后，你的大腦里對于各個任務(wù)之間的關(guān)系和邏輯也就會更加清晰了。
再有就是，不知道大家的公司有沒有需要寫周報或者日報。是不是有時候不知道寫什么？那是因為你從來沒很好的記錄你今天到底做了些什么。有了 GTD 工具，也很容易進(jìn)行工作總結(jié)，能夠很清晰的知道你這周做了些啥。回顧的時候，也會有成就感，感覺這周沒白過。
2，為知筆記
這個沒啥好說的了……筆記類的工具都差不多，關(guān)鍵是要找到合適自己的記錄方式，并要堅持去維護(hù)。其實我身邊有很多朋友做的比我好太多了。我就貼張圖吧，大家看看就得。關(guān)鍵還是要自己去試去做。
3，confluence 和 JIRA
confluence 和 JIRA 是?Atlassian 這家公司出品的兩個軟件系統(tǒng)。
confluence 就是一個團(tuán)隊協(xié)作的文檔管理軟件，可以用于整理團(tuán)隊項目相關(guān)的所有文件內(nèi)容。
類似于現(xiàn)在的在線文檔協(xié)作平臺，石墨啊、騰訊文檔啊，N 個人可以同時對文檔進(jìn)行編輯。但是 confluence 的功能更加強大。
比如，有樹形目錄管理，對于結(jié)構(gòu)復(fù)雜的迭代型文檔是必須的功能了。
文檔內(nèi)還 可以@團(tuán)隊成員，并郵件通知到 ta。
文檔內(nèi)還可以直接鏈接到其他文檔，被鏈接文檔標(biāo)題修改后，鏈接文字自動同步修改，省去了同步維護(hù)的時間。
權(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ù)自己團(tuán)隊的迭代方式建立迭代階段，比如常見的是：需求池——交互設(shè)計——視覺設(shè)計——開發(fā)分配——開發(fā)中——測試——回歸。有些團(tuán)隊可能在開發(fā)階段會再進(jìn)行一些細(xì)分，這個根據(jù)團(tuán)隊來就好。
還能很好的進(jìn)行版本管理，哪些版本現(xiàn)在處于什么狀態(tài)、共有多少個需求/bug、完成了多少、還剩多少，都能一眼看清楚。
Axure 和 ZEN 我就不說啦~ 都是大家都非常了解的軟件了。
七，最后再多啰嗦幾句
如果你問我現(xiàn)在的迭代啊、管理啊、是不是完全按照上面說的內(nèi)容來的，我肯定要說：當(dāng)然不是啊……有一些項目還是沒有按照這個方式走的……
每個團(tuán)隊和產(chǎn)品所處的狀態(tài)都不一樣，以上的方法不是一定都要按照這些東西做或者說這些方法就是最好的。
比如，當(dāng)團(tuán)隊一共就一個產(chǎn)品經(jīng)理、一個設(shè)計、兩個開發(fā)，并且坐的很近回頭就能看到的情況，用這些方式效率可能就會太低了。像小團(tuán)隊協(xié)作，如果大家都是靠譜的人，每天一個10分鐘內(nèi)的站會基本就能擺脫 jira 的需求了。產(chǎn)品經(jīng)理文檔也不需要寫這么復(fù)雜，需求點說清楚、關(guān)鍵時間點標(biāo)清楚就夠了。
之所以寫這些是希望，如果你在團(tuán)隊協(xié)作或者迭代方面存在一些問題或者疑惑的時候，這篇文章能夠給到你一些參考。
希望每個產(chǎn)品經(jīng)理都能夠跟團(tuán)隊配合的好好地、不要吵架，能很順暢的一起把產(chǎn)品越做越好~
最后，謝謝大家的支持！（鞠躬~）
最后也歡迎有問題的小伙伴加微信：chanpin628?溝通交流。
此外我們的官方網(wǎng)站也上線了，每日分享高質(zhì)量的文章、原型素材和行業(yè)報告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點擊底部的閱讀原文直接查看，或者復(fù)制網(wǎng)址：www.dadaghp.com?打開。
更多干貨可關(guān)注微信公眾號：產(chǎn)品劉
想學(xué)習(xí)更多關(guān)于產(chǎn)品、職場、心理、認(rèn)知等干貨，可長按右邊二維碼，關(guān)注我們。
··················END··················
RECOMMEND
推薦閱讀
產(chǎn)品經(jīng)理的冬天來了嘛？
面試官重點考察求職者這5項能力
線下實戰(zhàn)2.0
面試題，你覺得產(chǎn)品經(jīng)理的職責(zé)有哪些？
點擊“閱讀原文”
查看更多干貨
總結(jié)
以上是生活随笔為你收集整理的大厂的产品经理是怎样进行产品迭代的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Sublime插件开发 启动Anacon
- 下一篇： Unity3D ShaderLab 物体