大廠的產(chǎn)品經(jīng)理是怎樣進(jìn)行產(chǎn)品迭代的
作者：SherlFang 個(gè)人網(wǎng)站：iamsherl.com （轉(zhuǎn)載已取得作者授權(quán)） 這篇文章也是對我自己這幾年產(chǎn)品做事方式的一個(gè)流程總結(jié)吧…… 先說一下背景，大廠和小廠都呆過。呆過野蠻生長的傳統(tǒng)集團(tuán)的互聯(lián)網(wǎng)部門，呆過上市的中型二線互聯(lián)網(wǎng)公司，呆過 APPLE STORE 行業(yè)APP 排名第一的產(chǎn)品公司，現(xiàn)在呆在全球一萬多員工的超級獨(dú)角獸公司。 其實(shí)各個(gè)產(chǎn)品公司的迭代流程都大同小異，因?yàn)橐?guī)范起來，迭代流程就是那一套。目前覺得差異比較大的就是使用的工具和具體管理的方式，這個(gè)也是很想跟大家一起討論的，看看有沒有更加高效的方式或工具。 這篇文章大概會(huì)從以下幾個(gè)方面分開講述，不排除我寫著寫著會(huì)修改大綱的可能： 一，需求收集 二，需求整理 三，優(yōu)先級劃分 及 需求交付（直白地說就是怎么寫 PRD 文檔） 四，需求評審 及 產(chǎn)品評審 五，需求變動(dòng)（針對由于其他特殊問題導(dǎo)致的需求變動(dòng)，產(chǎn)品經(jīng)理該如何做到“不背鍋”） 六，工具（滴答清單、為知筆記、confluence、JIRA、Axure） 如果感興趣的話，還有…… 七，如何更高效地跟交互、UI 設(shè)計(jì)、開發(fā)、測試 溝通和交流（這部分貌似沒人感興趣我就不寫了……） 下面開始，是正文。 〇，流程圖
先看一下大概的流程圖，每個(gè)環(huán)節(jié)再具體解釋 一，需求收集
其實(shí)不同類型的產(chǎn)品，需求來源會(huì)不太一樣。這里會(huì)盡量列出所有可能的來源。 用戶反饋：產(chǎn)品中包含『用戶反饋』頁面，用戶通過『用戶反饋』入口，直接反饋過來的一手信息。 用戶研究：通過用戶調(diào)研、用戶訪談、用戶拜訪、可用性測試等方法獲得的用戶一手信息。 客服團(tuán)隊(duì)：通過客服團(tuán)隊(duì)收集并反饋的二手信息。 市場/商務(wù)/BD團(tuán)隊(duì)：通過市場/商務(wù)/BD團(tuán)隊(duì)接觸用戶時(shí)，獲得的用戶需求。 內(nèi)部成員需求：測試團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)、運(yùn)營團(tuán)隊(duì)，針對產(chǎn)品提出的需求。 戰(zhàn)略型需求：來自競品的競爭壓力產(chǎn)生的需求，團(tuán)隊(duì)制定的產(chǎn)品發(fā)展方向下的需求。 其他需求：老板需求。（牛逼的產(chǎn)品經(jīng)理可以忽略這一項(xiàng)……） 其實(shí)看似需求來源很多，再綜合一下，分析出來就是兩種：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)理再進(jìn)行處理和分析。建議產(chǎn)品經(jīng)理都找到方式直接跟用戶進(jìn)行溝通，而不是要假借他人之耳去聽取需求。 內(nèi)部需求，就是我們非常熟悉的了，經(jīng)常會(huì)從不同小組或者部門的同事那里獲得新的需求內(nèi)容，一般這些功能是針對于產(chǎn)品功能的可用性或者優(yōu)化的。再就是根據(jù)產(chǎn)品戰(zhàn)略制定的需求內(nèi)容。 這兩部分需求其實(shí)獲取起來沒那么難，外部需求就是，想盡一切方法去接觸用戶、然后跟用戶溝通。內(nèi)部需求就是，多跟同事們溝通，沒事兒多聊聊，問問看他們對于產(chǎn)品的看法。戰(zhàn)略型的需求內(nèi)容就不說了，這個(gè)涉及到不同公司的管理方式，說出來又是長篇大論的東西，甚至免不了要吐槽…… 二，需求整理
如果需求收集做的比較到位，到手的需求是多且雜的，基本是千奇百怪什么都有。這種情況下，要做的流程圖上已經(jīng)比較詳細(xì)的說明了。 1，只保留有效需求
剔除那些看上去很明顯不合理的需求。這個(gè)步驟需要依賴產(chǎn)品經(jīng)理自身的經(jīng)驗(yàn)和對自己產(chǎn)品的了解程度。 『對自己的產(chǎn)品很了解』，這一條看上去簡單但挺難做到的，需要的不僅僅是產(chǎn)品經(jīng)理自身的能力，還需要行業(yè)的經(jīng)驗(yàn)、在公司呆的時(shí)間足夠長。只有滿足這些條件后，產(chǎn)品經(jīng)理才能夠很高效準(zhǔn)確地做到『只保留有效需求』。 2，需求分類
有效需求進(jìn)一步分類就是：需討論的需求、需開發(fā)的需求、已有功能支持的需求
需討論的需求：對于是否需要做不是很確定，需要跟相關(guān)人員討論。 需開發(fā)的需求：需求強(qiáng)烈、跟當(dāng)前規(guī)劃一致、對短期目標(biāo)/長期目標(biāo)有助力、…… 已有功能支持的需求：這個(gè)是需要反思的，一般出現(xiàn)這種情況說明要么是功能的可見性做的有問題，要么是引導(dǎo)做的有問題，要么是功能不太符合用戶的認(rèn)知模型。有一些需求是合理的要求就需要進(jìn)行功能的優(yōu)化，甚至重新確定方案。
3，標(biāo)簽
基礎(chǔ)體驗(yàn)類：體驗(yàn)上有問題了，這個(gè)一般是需要修改交互或者 UI，要求比較高的公司/產(chǎn)品可能還存在響應(yīng)速度、流暢性等方面的優(yōu)化 運(yùn)營支持類：運(yùn)營活動(dòng)支持 功能優(yōu)化類：產(chǎn)品流程上存在一些問題，導(dǎo)致轉(zhuǎn)化率、響應(yīng)率等指標(biāo)過低 新需求類：嗯……就是新需求 數(shù)據(jù)分析類：埋點(diǎn)需求啊，或者一些公司有大數(shù)據(jù)部之類的部門還會(huì)存在，報(bào)表需求啊 技術(shù)架構(gòu)類：這個(gè)類別其實(shí)產(chǎn)品經(jīng)理比較少管，屬于架構(gòu)師負(fù)責(zé)的內(nèi)容，之所以寫在這里是因?yàn)橛幸恍μ厥獾哪K，技術(shù)架構(gòu)的修改會(huì)影響到很多功能的開發(fā)進(jìn)度和產(chǎn)品設(shè)計(jì)。產(chǎn)品經(jīng)理對于這些需求的掌握是有助于產(chǎn)品規(guī)劃的。（簡單解釋一下啥是特殊模塊：比如，移動(dòng)辦公軟件的『簽到』功能，用 戶量大且存在 上下班的流量高峰期；由于是基礎(chǔ)功能、對于穩(wěn)定性要求更高，一發(fā)生異常狀況基本就是要罰錢的…；存在各種情況，比如什么類型的考勤、進(jìn)沒進(jìn)圈、連沒連網(wǎng)、打沒打上等等，產(chǎn)品邏輯很負(fù)責(zé)；做過定位的人都知道，定位的技術(shù)手段太多，而且還有漂移、偏差矯正等，所以技術(shù)邏輯也復(fù)雜）
三，優(yōu)先級劃分 及 需求交付
1，優(yōu)先級劃分
產(chǎn)品的長期/中期規(guī)劃是怎樣的 當(dāng)前的 sprint 對于長期/中期規(guī)劃的意義是什么，是為了達(dá)到什么目標(biāo) 達(dá)到目的的 MVP 需要哪些功能
有沒有觸碰高壓線 fix 后能帶來什么 不 fix 能導(dǎo)致什么
對于『情報(bào)』的收集和分析能力 下決定的能力
2，需求交付
迭代記錄：版本號(hào)、修改時(shí)間、改了啥、為啥改、修改人（誰知道需求中途會(huì)不會(huì)換人呢，前面的人挖了個(gè)坑，也好去追責(zé)啊對不對？） 人員職能（非必須）：產(chǎn)品、交互、UI、前端、后端、客戶端（iOS Android） 分別是哪些小伙伴。大公司必備，特別是我們這種組織架構(gòu)完全看不到的公司…… 需求類型：不清楚的同學(xué)翻翻前面的標(biāo)簽哈 需求背景：你不說清楚這個(gè)，開發(fā)和設(shè)計(jì)心里絕對會(huì)懷疑做這個(gè)需求的意義。部分產(chǎn)品經(jīng)理是不是覺得開發(fā)和設(shè)計(jì)的小伙伴不怎么配合你的工作??？仔細(xì)想一下，自己在這部分的『忽悠』是不是不夠到位… 需求目標(biāo) 專業(yè)術(shù)語和縮寫解釋（非必須） 功能列表：這個(gè)就是一張大表了，需要包含 功能點(diǎn)名稱、所在模塊、使用場景描述、風(fēng)險(xiǎn)點(diǎn)（風(fēng)險(xiǎn)一定要提前暴露，引起大家的注意，大家能一起想辦法規(guī)避）、備注（這個(gè)你就愛寫啥寫啥，覺得啥重要寫啥） 流程圖 及 邏輯圖：這個(gè)不用多說吧…… 文案：呵……如果你的 APP 包含有3種及以上的語言，你不寫個(gè)文檔保存試試……而且有文檔的話，比較利于 APP 在文案上的一致性 合作內(nèi)容（非必須）：你是跟哪個(gè)部門合作了啊，對接人是誰啊，用了他們的哪些接口啊 數(shù)據(jù)埋點(diǎn)（非必須）：哪些關(guān)鍵埋點(diǎn)是需要開發(fā)小伙伴幫你埋的呀，埋點(diǎn)名稱、埋點(diǎn)內(nèi)容，都需要寫清楚
四，需求評審 及 產(chǎn)品評審
1，需求評審
大型需求：需求功能多，一個(gè)人設(shè)計(jì)可能會(huì)考慮不周全，需要人幫忙補(bǔ)充完善，讓產(chǎn)品設(shè)計(jì)盡量全面 方案不太確定的需求：產(chǎn)品經(jīng)理對于方案有疑問，比如 不知道現(xiàn)在設(shè)計(jì)的方案在開發(fā)上是否可行、設(shè)計(jì)上是否可行、業(yè)務(wù)上是否可行；需要相關(guān)模塊更有經(jīng)驗(yàn)的人一起做決策 與其他部門 / 模塊耦合較深：涉及其他部門 / 模塊的業(yè)務(wù)，需要跟兩方一起進(jìn)行溝通商議 敏感需求：恩……這個(gè)只能說是自行體會(huì)了……不是每個(gè)公司每個(gè)產(chǎn)品都會(huì)有敏感需求，而且敏感的點(diǎn)可能也會(huì)不一樣，可能是跟政府相關(guān)（比如 微博/抖音/快手/頭條 等面臨的整改要求）、可能是跟國家政策相關(guān)（比如 金融類產(chǎn)品？）、甚至是跟國外的政策相關(guān)（哈哈 比如我現(xiàn)在的公司…）、有的可能只是跟公司內(nèi)部相關(guān)（比如，有些公司老板說的需求某種程度上也算敏感需求，哪怕是改個(gè) icon 大家也要一起腦暴……）
開場白：簡單說明組織這次討論 / 會(huì)議的原因 需求背景：恩，這個(gè)一般情況下是需要說的，如果參會(huì)人員全部對于背景都非常了解了，也可以不說 需求目的：你做這個(gè)方案，是為了達(dá)到什么目的 需求內(nèi)容：開始講方案咯 拋出問題：具體描述組織這次會(huì)議的原因，及需要他人哪些支持
2，產(chǎn)品評審
PRD：主要是，需求列表、流程圖、邏輯圖。當(dāng)然，如果邏輯比較簡單的話，交互稿就夠了 交互稿：必備 視覺稿：這個(gè)要是來不及的話，有多少看多少
開場白：簡單說明組織這次討論 / 會(huì)議的原因 需求背景：絕大多數(shù)情況下，大部分開發(fā)是第一次聽到這個(gè)需求，說明背景很有必要 需求目的：你做這個(gè)方案，是為了達(dá)到什么目的 需求內(nèi)容：開始講方案咯 確定方案：定下最終方案咯 確定協(xié)作：確定各個(gè)協(xié)作方做啥 給個(gè) deadline：讓各方給個(gè) deadline 咯，要不怎么催進(jìn)度
五，需求變動(dòng)
六，工具
滴答清單——日常工作梳理、管理、記錄 為知筆記——個(gè)人知識(shí)庫維護(hù) confluence——產(chǎn)品文檔、工作文檔維護(hù) JIRA——項(xiàng)目內(nèi)容記錄、追蹤、迭代維護(hù) Axure——PRD 工具 ZEN——腦圖工具
1，滴答清單
2，為知筆記
3，confluence 和 JIRA
比如，有樹形目錄管理，對于結(jié)構(gòu)復(fù)雜的迭代型文檔是必須的功能了。 文檔內(nèi)還 可以@團(tuán)隊(duì)成員，并郵件通知到 ta。 文檔內(nèi)還可以直接鏈接到其他文檔，被鏈接文檔標(biāo)題修改后，鏈接文字自動(dòng)同步修改，省去了同步維護(hù)的時(shí)間。 權(quán)限管理也很強(qiáng)大，可以精確到某個(gè)子頁面是否允許讀或編輯。 跟郵箱綁定后，當(dāng)你關(guān)注的文檔有了修改還能通過郵件通知到你具體修改了哪些部分。 更關(guān)鍵的是，直接跟 JIRA 打通，鏈接到 JIRA 的某個(gè)單，當(dāng)前單的狀態(tài)也能夠直接同步到 confluence 上。
七，最后再多啰嗦幾句
點(diǎn)擊“閱讀原文”
查看更多干貨
評論
圖片
表情