中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：一款產(chǎn)品從需求到落地需要經(jīng)歷什么樣的流程？這篇文章通過積分管理的案例，梳理了完整的需求落地流程、各個角色負責(zé)的事務(wù)，以及各個環(huán)節(jié)中的難點。希望對大家有所幫助。

剛剛?cè)胄械漠a(chǎn)品新人在面試時，被問最多的一句話就是：一款產(chǎn)品從需求到落地需要經(jīng)歷什么樣的流程？

通過網(wǎng)課和實習(xí)項目的學(xué)習(xí)，大部分人能夠較為準(zhǔn)確的回答出「需求收集-需求分析-方案設(shè)計-開發(fā)-跟進上線」這個最為核心的流程。但是當(dāng)面試官再追問細節(jié)時，缺少豐富實戰(zhàn)經(jīng)驗的新人就難以準(zhǔn)確地進行回答。

背下這個流程或者按照這個流程直接執(zhí)行似乎不難。但如果想要認(rèn)真做好每一個環(huán)節(jié)，保證上線后的產(chǎn)品能夠高度貼合用戶的需求、對用戶真正產(chǎn)生價值卻是一個永恒的難題。

筆者經(jīng)歷過數(shù)十次迭代上線，其中有1-2周的優(yōu)化版本，也有長達數(shù)月的大功能版本，也算是在當(dāng)前階段沉淀出了一些經(jīng)驗。

因此，本文希望能夠結(jié)合理論和實踐，通過一個容易理解的案例——積分管理來幫大家梳理完整的需求落地流程，并給出每個流程和環(huán)節(jié)中的重點和難點，幫助大家形成更為立體的認(rèn)知、避免踩坑。

首先，我們來看看一次完整的迭代需要經(jīng)歷什么？

下圖為一個相對較為通用的迭代流程（建議放大看）：

（常見的迭代流程圖）

1. 業(yè)務(wù)：提出需求
2. 產(chǎn)品：需求調(diào)研&分析
3. 產(chǎn)品&UI：產(chǎn)品設(shè)計之后，產(chǎn)品輸出PRD、設(shè)計輸出UI稿
4. 產(chǎn)品&UI&研發(fā)&測試：產(chǎn)品主導(dǎo)需求評審，設(shè)計主導(dǎo)UI評審，研發(fā)和測試為參與方
5. 研發(fā)：進入開發(fā)
6. 測試：研發(fā)提測后進入測試環(huán)節(jié)
7. 運營：進行運營方案設(shè)計
8. 業(yè)務(wù)&產(chǎn)品：對開發(fā)出來的產(chǎn)品進行驗收
9. 上線：由運維主導(dǎo)版本上線
10. 運營：產(chǎn)品上線后，運營方案上線
11. 項目復(fù)盤：整個迭代組進行項目復(fù)盤

上圖清晰地描述了一次迭代流程中，對應(yīng)的7個角色核心要做的事情。其中，灰色豎欄為產(chǎn)品需要主負責(zé)的，共包含5件事：需求調(diào)研&分析、產(chǎn)品設(shè)計、需求評審、驗收及項目復(fù)盤。而其余5件事（提出需求、開發(fā)、測試、上線、運營方案設(shè)計&上線）則是產(chǎn)品需要跟進和關(guān)注的。

以上為一個較為通用的迭代流程，但由于各公司的業(yè)務(wù)、組織架構(gòu)、團隊規(guī)模等不同，部分流程可能會更簡略或更細致。

例如，有些公司業(yè)務(wù)和產(chǎn)品均由產(chǎn)品經(jīng)理來負責(zé)，產(chǎn)品經(jīng)理需要自己主動收集需求并進行分析設(shè)計；而另外一些公司沒有專門的運維崗，這個時候可能會選擇用后端工程師來替代進行上線發(fā)布。

因此，我們看上面這張流程圖時，不用糾結(jié)于公司是否有具體對應(yīng)的崗位，而應(yīng)該從該角色的職責(zé)范圍來看，這樣才能對各角色職責(zé)邊界有更清晰的理解。

在掌握整個迭代框架后，下面我們從每一個具體的環(huán)節(jié)切入，來學(xué)習(xí)如何能夠很好地將一個需求落地上線。

一、業(yè)務(wù)：提出需求

大廠一般都配備有業(yè)務(wù)部門，而規(guī)模稍小一些的公司或者個別行業(yè)可能就沒有單獨的業(yè)務(wù)部門。例如筆者所在的公司就沒有單獨業(yè)務(wù)部門，那么需求從哪里來呢？

因為筆者從事B端SaaS行業(yè)，其實是有相對明確的業(yè)務(wù)來源的，那就是公司的銷售及售后部門。對B端產(chǎn)品而言，大部分的需求來自于銷售和售后部門，其他則可能來自于客戶、老板、競品等。

第一步雖然是由業(yè)務(wù)方來提出需求，但通常，產(chǎn)品都需要提前制定相關(guān)的需求收集方式和模板，便于高效地收集到能夠為自己所用的需求。

關(guān)于需求收集的方式，有些公司選擇自建內(nèi)部系統(tǒng)，有些公司選擇使用現(xiàn)有的需求管理工具（例如禪道）。

而考慮到錄入的方便、簡單和可上手性，我們團隊使用了騰訊文檔-在線收集表（見下圖）。銷售和售后的同事在遇到需求時，可以直接填寫該表。表格設(shè)計的很簡單，但卻包含了較為關(guān)鍵的信息。

（問題收集表）

填好之后，會在系統(tǒng)后臺默認(rèn)生成一個「問題池列表」，在那里就可以非常直觀地查看和管理問題池內(nèi)的所有需求了。

二、需求調(diào)研&分析

在完成第一步需求收集之后，我們在問題池中發(fā)現(xiàn)銷售同事在售賣SaaS系統(tǒng)時，錄入了這樣一條需求：

問題標(biāo)題：積分功能

問題描述：希望系統(tǒng)有積分功能，學(xué)生可以用積分抵扣學(xué)費

問題緊急程度：需7日內(nèi)回復(fù)

客戶希望達到的目的：想降低線下發(fā)積分卡和管理積分卡的成本

當(dāng)前客戶如何解決該問題：線下手動發(fā)積分卡片

（線下積分卡片）

那么，接下來我們就需要對這條需求進行調(diào)研和分析，了解客戶為什么要該功能，具體想做成什么樣子。

1. 調(diào)研

在一次迭代中，常見的調(diào)研包含行業(yè)調(diào)研、競品調(diào)研和客戶調(diào)研這3種。

關(guān)于行業(yè)調(diào)研，大家可以通過如下3種方式進行長期的積累：

• 艾瑞咨詢、IT桔子等各類行業(yè)報告平臺的調(diào)研報告
• 加入行業(yè)社群
• 關(guān)注行業(yè)自媒體，如公眾號、知乎大v等
• 閱讀行業(yè)相關(guān)書籍

行業(yè)調(diào)研是一個需要長期投入和關(guān)注的長線工程，雖然有些迭代會包含一部分行業(yè)調(diào)研，但主要還是以競品調(diào)研和客戶調(diào)研為主。因此，這里我們不展開看行業(yè)調(diào)研，而是以競品和客戶調(diào)研為主。

（1）客戶調(diào)研

這里再著重強調(diào)一些客戶調(diào)研核心關(guān)注的相關(guān)內(nèi)容?？蛻粽{(diào)研的本質(zhì)，就是在反復(fù)溝通中明確需求的核心3要素：用戶、場景、目標(biāo)。

那么將其代入到積分管理的例子中，我們就需要弄清楚：

• 什么人要用到積分？
• 這些人在什么場景下會用積分？
• 他們的目標(biāo)是什么？

在明確調(diào)研方向之后，就可以選用相對合理的調(diào)研方式了，例如問卷、一對一訪談、現(xiàn)場觀察等。

問卷適用于有一定的用戶規(guī)模、調(diào)研深度較淺的需求，雖然節(jié)約時間但效果容易被問卷設(shè)計所干擾；一對一訪談和現(xiàn)場觀察適用于更為深入和直接的調(diào)研，成本高但調(diào)研效果更為可靠。

（2）競品調(diào)研

經(jīng)常會有人問「如何做好一次競品調(diào)研」，這個問題的范圍其實很大。因為，只給出競品這一個關(guān)鍵詞，是很難框定競品調(diào)研的目標(biāo)和范圍的。

就像leader命令你去調(diào)研一個人，在沒有任何調(diào)研目的的情況下，其實是很難聚焦來得到有效結(jié)論的?！溉恕购汀父偲贰挂粯?，都是對象，因此，競品調(diào)研的關(guān)鍵點就在于競品調(diào)研的目的！只有明確了目的，才能清楚的框定范圍、選擇合適的調(diào)研內(nèi)容和方式。

那么，對于一次迭代而言，競品調(diào)研的主要對象就是一個明確的功能或者業(yè)務(wù)，目標(biāo)就是明確競品是否有實現(xiàn)這個需求？實現(xiàn)了哪些？實現(xiàn)到了什么程度？

以積分管理為例，下圖為一張競品積分功能對比的簡單清單，供大家參考：

（競品功能對比清單）

競品調(diào)研已經(jīng)有非常成熟的方法體系了，鑒于篇幅，這里不展開討論。除了上述內(nèi)容之外，再和大家分享2個非常重要的點：

第一，在看競品實現(xiàn)之前，提前思考自己會怎么做。

當(dāng)我們直接打開競品開始體驗，會先入為主的接收到很多信息，并且會將很多細節(jié)自然地忽略掉。這其實會阻礙我們很好地把握競品的調(diào)性和設(shè)計目的。

筆者的大哥曾經(jīng)教過我這樣一個很實用的辦法：那就是打開競品之前，提前想想自己會怎么做。思考半個小時后再簡單畫一個模型或圖。隨后，拿著自己的圖去和競品做對照，這樣就能夠非常有效的關(guān)注到差異點。

例如，客戶有積分管理的需求，那我們先將業(yè)務(wù)拆分為獲取、消耗和規(guī)則這3大需求，在滿足客戶核心場景的基礎(chǔ)上沒有太多延伸。

拿著這個思維導(dǎo)圖的框架，我們再去對照競品，看它做了哪些、哪些沒做，并猜測對方的出發(fā)點是什么。

例如下圖，我們發(fā)現(xiàn)競品額外還做了禮品兌換的功能。

這個時候，我們就發(fā)現(xiàn)競品有一個和自己預(yù)想不一樣的功能點：為什么競品的積分功能還支持做禮品兌換呢？

此時，我們就可以回過頭來想想：是因為自己對場景了解不充分，客戶有這樣的需求，自己卻沒有了解到？還是因為對方希望引導(dǎo)客戶去進行禮品兌換，從而通過提供商品購買渠道來增加變現(xiàn)方式呢？

經(jīng)過這樣的對比和沖突，才會讓我們對競爭對手的思考更加集中和聚焦。

第二，關(guān)注競品和自身在該功能上的競爭力對比

競品調(diào)研時，我們很容易陷入功能和交互，忽略了背后的競爭力。

當(dāng)我們的功能真的投入到市場接收客戶的考驗時，產(chǎn)品功能的完整性、覆蓋度，各個功能的競爭力、短板和優(yōu)勢都會被客戶拿到一起來進行赤裸裸地對比。

而如果我們在做競品調(diào)研時，只考慮看對方的實現(xiàn)，沒有關(guān)注競手對該功能的宣傳口徑以及競爭力時，可能某種程度上會做出缺少競爭力的產(chǎn)品。當(dāng)銷售和售后部門去進行售賣和續(xù)費時，也難以給出能夠打動客戶的優(yōu)勢點。

當(dāng)然，一個saas產(chǎn)品賣的好壞并不只是因為產(chǎn)品的競爭力，某種程度上也取決于公司的客戶資源、行業(yè)地位等等。但是對于產(chǎn)品經(jīng)理而言，做好自己份內(nèi)之事，積少成多，某種程度上也能帶來持續(xù)而穩(wěn)定的影響。

2. 分析

雖然在調(diào)研過程中，我們也會隨著調(diào)研的結(jié)果產(chǎn)生各種碎片化的思考。但這里的分析則指的是在調(diào)研結(jié)束之后，將全部信息進行統(tǒng)一整合、整合后再通過思考提煉得出結(jié)論的過程。

最近在看《人人都是產(chǎn)品經(jīng)理3.0》，里面提到了需求分為一手需求/二手需求，以及直接需求/間接需求，其實也就引出了筆者在這里想說的點：在真正分析開始之前，先要對用戶的描述打破砂鍋問到底，明確真實的信息，減少信息熵。

例如，客戶說“我想要一個積分功能，我看其他門店都有，自己沒有就落后了”。這類表述對我們想要明確積分功能本身的價值沒有太多幫助，頂多讓我們知道積分已經(jīng)變成了一個相對比較普遍的營銷方式。

因此，我們還需要繼續(xù)追問客戶：如果你們自己有了這個積分之后，會考慮拿來怎么用呢？只有不斷地追問客戶5個w，才能從客戶那里挖掘到真正的需求。

在客戶調(diào)研中，最大的坑就是還沒弄明白真正的需求，就直接按照表面需求或者二手需求開始設(shè)計方案了。

以積分管理功能為例，我們通過數(shù)十份客戶電話訪談，歸類得到了客戶想要積分功能的幾大原因：

• 想通過出勤發(fā)積分，提升機構(gòu)出勤和課消率
• 想通過一些活動發(fā)積分，促進家?；雍蜏贤?/li>
• 想通過積分抵扣學(xué)費，促進家長續(xù)報的積極性

然后，再根據(jù)上述調(diào)研結(jié)果給客戶的出發(fā)點做一個整理和優(yōu)先級的排序。在整理后我們發(fā)現(xiàn)：促進出勤和課消是80%客戶的需求，促進續(xù)報有60%機構(gòu)都需要，而促進家?；又挥?0%。

那么，我們便可以得出一個初步的結(jié)論：大部分機構(gòu)使用積分功能主要用來促進營收，而出勤獲得積分和續(xù)報抵扣積分是2個需要重點滿足的核心場景。

接下來，我們需要把客戶使用積分的場景整理出來。便于在需求評審時，和整個團隊講清楚需求的背景和滿足的場景。同時，再結(jié)合與競品的對比，確認(rèn)我們是否需要在這個方面投入更多的資源來提升競爭力，還是暫時持平即可、把資源投入其他方面的建設(shè)上去。

三、產(chǎn)品設(shè)計

如何把用戶的需求從一個清單list變成一個有樣式交互、有業(yè)務(wù)邏輯的完整PRD，并不是掌握了畫原型的技巧那么簡單的事情。

在筆者剛剛開始從事產(chǎn)品時，每次分析需求，都需要先手繪一張原型稿出來。只有看著原型稿，才知道怎么樣去倒推需求背后的邏輯，否則大腦就是一片空白。

但慢慢隨著經(jīng)驗的增長，現(xiàn)在，基本能夠脫離對原型稿的依賴，先考慮場景和業(yè)務(wù)邏輯。在完整的梳理完業(yè)務(wù)邏輯后，再開始考慮樣式和交互的具體實現(xiàn)。

那么，一個相對通用的產(chǎn)品設(shè)計流程應(yīng)該是怎樣的呢？

其實整個產(chǎn)品設(shè)計流程和需求評審是高度結(jié)合的，因為需求評審就是不同階段產(chǎn)品設(shè)計成果的里程碑。

在筆者此前寫過的需求評審文檔中，詳細介紹了需求評審的3個階段：范圍評審、低保真評審、方案評審。相應(yīng)的，PRD的落地過程也需要對應(yīng)分為3個階段：需求范圍稿、低保真稿、最終方案稿。

1. 需求范圍稿

首先，我們需要和團隊明確想做哪些東西、大致優(yōu)先級是怎樣的，即定義好需求的邊界和優(yōu)先級。

根據(jù)前述的調(diào)研，我們能夠基本對客戶的需求和競手對該需求的滿足情況有一個大致的了解。綜合各方面的信息后列出一個簡單的需求范圍和優(yōu)先級。

如下圖所示，這是一個簡單積分管理的需求清單：

（需求清單）

關(guān)于優(yōu)先級的制定，網(wǎng)上也有非常多的方法：有使用KANO（基本型、期望型、興奮型）進行大致歸類判斷的，也有各類按照公式進行精準(zhǔn)計算的。但對于剛?cè)腴T的產(chǎn)品而言，能夠基本按照KANO模型和重要/緊急四象限去進行區(qū)分就已經(jīng)足夠了。

（網(wǎng)圖，圖源見水?。?/p>

舉個例子，在本次積分管理中，能夠按照學(xué)員出勤情況自動為其進行加分屬于基本型需求，這是客戶需要該功能的核心場景。

而得來的積分能夠再用于在線上兌換禮品，則屬于期望型需求。這類需求越多越好，能夠有效促進學(xué)員獲得積分的積極性。

而如果該學(xué)員長期沒有出勤，系統(tǒng)能夠自動告訴該學(xué)員：因為沒有出勤，你有190個積分即將流失。通過這種自動提醒方式，有效喚醒學(xué)員出勤。那么，這將會是一種超出客戶意料之外的興奮型需求，因為系統(tǒng)具備了一定的智能召回能力。

當(dāng)然，一個需求的優(yōu)先級絕不僅僅局限于需求本身，可能還關(guān)聯(lián)到該需求的實現(xiàn)成本、商業(yè)價值等。

比如，雖然客戶認(rèn)為該需求非常緊急和重要，但實現(xiàn)成本極高；又比如，有甲方爸爸說加重金必須要實現(xiàn)某一個性化功能。當(dāng)遇到這兩種情況后，某種程度上，我們的需求優(yōu)先級就會受到一定影響。

但是對于新人而言，判斷需求本身的業(yè)務(wù)價值是最重要和核心的能力，所以這里暫時只和大家提及這一點。

綜上，我們在需求調(diào)研&分析階段得出了含有優(yōu)先級的需求清單。接下來，我們就要按照這個需求清單進行下一步的設(shè)計了。

2. 低保真稿

在低保真稿中，我們需要確定業(yè)務(wù)核心的邏輯、流程、交互和樣式。

（1）核心業(yè)務(wù)邏輯

核心業(yè)務(wù)邏輯指我們需要找出功能中涉及到的實體有哪些、實體關(guān)系如何，當(dāng)需要設(shè)計表時，表字段應(yīng)該包含哪些等等。

例如，在積分管理的業(yè)務(wù)中，學(xué)員、校區(qū)和積分賬戶的關(guān)系就可以列出至少如下3種方式。

現(xiàn)在看起來，似乎不同的方式?jīng)]有太大區(qū)別。但是如果實體關(guān)系和表結(jié)構(gòu)沒有設(shè)計好，后期就很難在此基礎(chǔ)上進行業(yè)務(wù)的更新和優(yōu)化了，甚至?xí)锌赡軐?dǎo)致重構(gòu)。

（2）核心流程

在理清楚實體及實體關(guān)系后，我們就可以開始來梳理整個業(yè)務(wù)的核心流程了。

在積分管理中，有加積分流程、扣積分流程、積分規(guī)則配置流程等等，我們以下圖最為簡化的加積分流程為例：

通過這張圖，我們就能很清晰的了解：完成一次加積分大致需要經(jīng)過哪些步驟，需要哪些前置數(shù)據(jù)，最終一系列操作完成后，又會產(chǎn)生哪些數(shù)據(jù)。

這樣，我們就能對整個積分業(yè)務(wù)中的核心路徑有了很好的把握，同時也能關(guān)注到信息和數(shù)據(jù)的流轉(zhuǎn)。

（3）核心交互和樣式

相較于C端產(chǎn)品，B端產(chǎn)品會更關(guān)注業(yè)務(wù)邏輯和功能易用性。而頁面交互往往都會傾向于使用通用的框架。

因此，在設(shè)計交互和樣式時，B端產(chǎn)品經(jīng)理最主要的是需要熟知團隊內(nèi)部是否有統(tǒng)一的組件和交互。如果有，需要盡量去遵循已有組件。

同時，也需要熟知市面上常見的一些交互框架，例如Ant Design、Material Design等等。這些交互框架能夠有效提升我們畫原型的效率。

當(dāng)然，并不是不鼓勵創(chuàng)新。只是說對于B端產(chǎn)品而言，某種程度上，能幫助客戶把事情高效辦成才是最重要的事情，而常見的交互樣式框架某種程度上也降低了用戶的學(xué)習(xí)成本，使他們能夠花更多的精力專注在完成任務(wù)上面。

例如，下圖就是在設(shè)置加分規(guī)則時的一個低保真頁面。頁面的tab式導(dǎo)航、按鈕位置、表格樣式、表頭內(nèi)篩選都是遵照了團隊的統(tǒng)一交互。那么，后續(xù)UI基本不需要重新出圖，而前端也可以直接引用團隊現(xiàn)有的組件進行快速實現(xiàn)。

此外，新人都十分關(guān)注交互的實現(xiàn)，好像實現(xiàn)了一個很酷炫的交互是一件很有成就感的事情。雖然也存在部分公司要靠成熟可交互的產(chǎn)品demo去談項目，但大部分B端產(chǎn)品的交互都十分簡單。個人建議不必要花太多心思去學(xué)習(xí)axure、墨刀這類軟件上的交互部分，掌握基礎(chǔ)交互即可。

3. 最終方案稿

在完成了核心邏輯、流程、樣式和交互之后，最終方案稿就是在補全其他場景的內(nèi)容。

例如，在上一步驟低保真稿中，我們在積分設(shè)置中出現(xiàn)了積分規(guī)則的列表和新增加分規(guī)則的按鈕。那么，在方案評審稿中，我們就需要明確寫出列表和按鈕的對應(yīng)相關(guān)邏輯，便于研發(fā)可以直接拿來開發(fā)。

如下圖所示，就是一個加分規(guī)則列表的邏輯和交互說明：

到了這一步，我們基本就結(jié)束了產(chǎn)品設(shè)計這一階段的全部工作。

四、項目管理（開發(fā)&測試&驗收）

在完成最終一次的需求評審之后，產(chǎn)品就可以短暫的舒一口氣了，因為剩下的主要工作將由研發(fā)和測試來完成。

那研發(fā)和測試具體都在這段時間做什么呢？

對于沒有技術(shù)經(jīng)驗的筆者而言，剛?cè)胄挟a(chǎn)品時，就一直覺得研發(fā)的工作像一個黑盒：扔進去需求文檔，過一段時間就收獲了可使用的功能。但其實隨著經(jīng)驗的增長，了解完整的研發(fā)過程是很有必要的。

下圖就描述了一個常見的從開發(fā)到上線的過程（感謝研發(fā)&測試同事們提供的素材）：

通過這張圖，我們能很清晰地看出每個角色在其中的工作職責(zé)：

前后端需要評估&閱讀需求、技術(shù)方案設(shè)計、技術(shù)方案評審、排期、開發(fā)和代碼審查、聯(lián)調(diào)、提測以及解bug。

測試需要閱讀&評估需求、設(shè)計測試用例、評審測試用例、冒煙測試、正式測試、確認(rèn)達到初步上線標(biāo)準(zhǔn)、輸出測試報告。

運維需要準(zhǔn)備發(fā)布環(huán)境、檢查發(fā)布環(huán)境，并負責(zé)發(fā)布上線（如果你對上述專業(yè)技術(shù)詞匯不甚熟悉，建議善用搜索，或不妨直接找關(guān)系還不錯的技術(shù)同學(xué)請杯奶茶聊一聊～）。

上面說了研發(fā)測試的核心工作，那在這個期間，產(chǎn)品就閑著摸魚什么事都沒有了嗎？

那肯定不會。

在研發(fā)埋頭苦干期間，產(chǎn)品需要對整個迭代進行項目管理。同時，當(dāng)研發(fā)出現(xiàn)需求疑問時，需要及時給予需求澄清和解答；當(dāng)然，產(chǎn)品需求文檔也不能保證100%正確，當(dāng)自己有需求bug時，也要配合測試進行處理。

在這幾件事中，最核心的就是進行項目管理。

首先，一次迭代本質(zhì)上是一個項目，即一個需要在固定時間內(nèi)按照明確標(biāo)準(zhǔn)進行交付的工程。而產(chǎn)品經(jīng)理除了自身進行需求調(diào)研和產(chǎn)品設(shè)計之外，還要肩負項目經(jīng)理的工作，即管控整個迭代。

而大多數(shù)產(chǎn)品在最開始做迭代的時候，其實是缺少項目管理知識和經(jīng)驗的。因此，我們需要先建立對一個迭代（項目）的完整認(rèn)知，了解到一個迭代到底需要從哪些地方進行關(guān)注、形成項目管理的框架、有更全面和宏觀的視野；之后再對我們需要做的事情進行一步步案例拆解。

那么，理論篇我們就引入項目管理中2個非常熟知的理論框架：PDCA戴明環(huán)和項目管理理論中的十大管理。

1. PDCA戴明環(huán)

在筆者剛剛自學(xué)轉(zhuǎn)行產(chǎn)品經(jīng)理時，就常常聽說PDCA這樣一種思想，這也是相對很好入門的一種項目管理思路。

• P=plan
• D=do
• C=check
• A=action

首先做一件事，我們要有計劃性plan、做好計劃后開始執(zhí)行do、執(zhí)行完成后時刻進行檢查check、檢查復(fù)盤后若有問題，則持續(xù)的進行改進act。

這就和我們要減肥是一樣的，為了要減肥我要做哪些健身計劃，做好計劃后就開始按照計劃執(zhí)行。執(zhí)行一段時間后回過頭來看看效果怎么樣，如果減肥反而越減越肥，那就該找找問題看看怎么樣去優(yōu)化了。

PDCA看起來就是簡單的4個動作，但代入到迭代來看，其中其實蘊含了3層大部分人都做不到的簡單道理：

1. 凡事要有計劃性。迭代開始之前，需要有明確的目標(biāo)、行動、衡量，在做事之前如果能夠想清楚計劃，那么也就成功了一半；
2. 迭代上線后不能就扔在那里不管了，而需要及時進行復(fù)盤和檢查。當(dāng)發(fā)現(xiàn)問題后，也要行動起來進行優(yōu)化。很多產(chǎn)品新人做迭代，方案設(shè)計好或者上線之后就不管了，這其實是一種思維和行動懶惰的表現(xiàn)；
3. PDCA是一個循環(huán)，強調(diào)我們不僅要把這個事情按照PDCA做完，還要持續(xù)的去循環(huán)這4個動作，才能不斷地進行優(yōu)化和提升。這是戴明環(huán)對于迭代的一個非常重要的指導(dǎo)思想。

2. 十大管理

筆者之前考過軟考系統(tǒng)高級項目管理師，其實考試是一個借機學(xué)習(xí)項目管理知識很好的方式。

在沒有學(xué)習(xí)系統(tǒng)的項目管理知識之前，其實對一個迭代的認(rèn)知是非常窄的：只會關(guān)注用戶的需求是什么、bug多不多能不能最終上線，只關(guān)注「需求-功能-實現(xiàn)」這一條單線程的管理。

而在學(xué)完項目十大管理之后，筆者發(fā)現(xiàn)自己看待整個項目的視角立體了很多。

例如，會開始關(guān)注研發(fā)同事的人員流動大不大，會不會有人力風(fēng)險，也會去關(guān)注某個需求的實現(xiàn)成本，而不是一味任性的說“我不管，這個需求必須要做”。

那么十大管理都指哪幾個方面呢？

十大管理包含整體管理、范圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、風(fēng)險管理、采購管理、干系人管理。

（網(wǎng)圖，圖源見水印）

這里不展開細講，感興趣的同學(xué)可以直接搜索「十大管理」關(guān)鍵詞進行詳細了解。

十大管理中，我們最常關(guān)注的是時間管理、成本管理、人力資源管理和質(zhì)量管理，最容易忽略的是溝通管理、風(fēng)險管理和干系人管理。

為什么溝通、風(fēng)險和干系人管理是比較容易忽視的呢？這是因為相較于范圍、時間、成本等，后面的溝通、風(fēng)險和干系人一般都比較隱性，不會非常直接的影響上線，但卻很容易埋下大坑，一旦積攢到某一時刻就會爆發(fā)，從而影響整個迭代。

所以，當(dāng)我們學(xué)習(xí)了十大管理的知識之后，就能夠跳出產(chǎn)品和需求的單一視角，從整個項目的多個維度去看待一次迭代，也能夠在一定程度上更大地提升迭代的成功率和團隊合作的效率。

通過上述的理論學(xué)習(xí)，我們對項目管理有了一個初步的框架。那么，下面我們就來具體說說怎么進行項目管理。

3. 項目管理流程

那么，要做好一次迭代的項目管理，應(yīng)該按照什么樣的步驟去展開呢？

其實這里還是以PDCA戴明環(huán)的4個步驟為主，其中因為產(chǎn)品偏向于管理，因此更多以plan、check和act為主。

（1）整體計劃

有計劃才能識別變化，因此，在開發(fā)開始之前，我們就要列出一個明確的迭代計劃。計劃的內(nèi)容需要包含項目基本情況、項目描述、項目里程碑計劃、評價標(biāo)準(zhǔn)、項目假定與約束條件、項目主要利益干系人等。

（表格來自華為項目管理10大模板）

在列出基本策劃之后，我們對整個項目就有了一個大致的框架，同時也有了明確清晰的評價標(biāo)準(zhǔn)。接下來，就要進行進度方面的監(jiān)控了。

下圖是一個簡單的甘特圖，用于進行進度管理和風(fēng)險預(yù)估。通過這張表，我們就能很清晰的核對出項目的進度，大致哪個環(huán)節(jié)出現(xiàn)了問題、哪個環(huán)節(jié)未來可能會出現(xiàn)風(fēng)險。當(dāng)我們找到問題后，就能夠進行跟進和問題處理了。

（表格來自華為項目管理10大模板）

例如，后端同事在開發(fā)某一個模塊時，因為家里有事要請假1周，為了保證按時上線，是選擇臨時借調(diào)其他項目組的后端來頂替，還是等該同事回來之后再加班處理？這些處理方案沒有絕對正確，都需要依照具體的項目和業(yè)務(wù)來進行處理。

當(dāng)然，剛剛?cè)腴T的新人都缺乏一定的跨部門協(xié)作經(jīng)驗，不要擔(dān)心，作為過來人，筆者在這里給你2個衷心的建議：

1. 產(chǎn)品需要對結(jié)果負責(zé)。因此，需要積極主動去幫助解決灰色地帶的問題，不要遇事就甩鍋。
2. 先自己獨立思考處理方式，思考后再和直系leader或者同部門同事請教。這樣，既能保證自己有一定思考有所成長，也能與內(nèi)部同事核對之后再對外協(xié)作和處理，讓事情處理的更「漂亮」一些。

當(dāng)然，在上線之前，整個PCA都會是一個持續(xù)循環(huán)的3個動作。

上線，是一個特別令人激動和緊張的時刻，也是功能第一次真正面向客戶投入市場的一個終極里程碑。稍微成熟一點的公司一般都會有對應(yīng)的上線檢查表，這里也給出一個簡單的參考，但具體上線的檢查清單要根據(jù)具體的業(yè)務(wù)來。

（圖源邱岳《產(chǎn)品訓(xùn)練營》）

五、項目復(fù)盤

還記得我們前面說過「千萬不能上線后就不管了」，一個負責(zé)的產(chǎn)品經(jīng)理既要管生，也要管養(yǎng)。當(dāng)然，不一定全盤都是自己養(yǎng)，但是一定要注意跟進和復(fù)盤。

下圖為《復(fù)盤》這本書中給出的復(fù)盤模板，我們自己團隊也在使用該模板進行復(fù)盤：

（《復(fù)盤》書中提供的復(fù)盤模板）

上線后的項目復(fù)盤應(yīng)該分為2個方面，第一類是項目本身進行復(fù)盤，第二類是產(chǎn)品復(fù)盤。

項目復(fù)盤更關(guān)注過程，即我們要對團隊內(nèi)每個人的工作效率/質(zhì)量、互相之間的協(xié)作等整個項目進行復(fù)盤。而產(chǎn)品復(fù)盤則更關(guān)注結(jié)果和價值，指我們要對上線功能的可用性、實際產(chǎn)生的價值等進行復(fù)盤。

對于B端產(chǎn)品而言，功能反饋不一定非常及時，因為系統(tǒng)內(nèi)大部分功能都是沒有人在用的。因此，一般需要等2-4周再進行數(shù)據(jù)的收集，而數(shù)據(jù)收集的方式分為埋點和回訪2類，這和我們?nèi)ミM行客戶調(diào)研的方法是有些類似的。

下圖是積分管理功能中，真實的一次產(chǎn)品設(shè)計組項目復(fù)盤的內(nèi)容截圖：

（項目復(fù)盤截圖）

在這次積分迭代中，產(chǎn)品和UI組分別就目標(biāo)和結(jié)果做了對照評估，并從中提煉出了出現(xiàn)問題的關(guān)鍵原因，同時也給出了后續(xù)的行動計劃。

當(dāng)然，本處只有產(chǎn)品和設(shè)計部門的復(fù)盤內(nèi)容，整個參與迭代的前端、后端、測試等都需要分別列出自己的復(fù)盤內(nèi)容，并由產(chǎn)品組織在項目復(fù)盤會上統(tǒng)一進行交流。

通過這樣一個成體系的復(fù)盤思考，能夠讓我們不僅僅完成了眼前的迭代，還能在同樣時間的項目經(jīng)驗里收獲成倍的經(jīng)驗，從而在未來的迭代中舉一反三。

以上就是一個完整的需求迭代過程了，我們再來回顧一下。整個需求迭代的參與角色包含業(yè)務(wù)、產(chǎn)品、研發(fā)、測試和運營。產(chǎn)品經(jīng)理主要負責(zé)產(chǎn)品設(shè)計和項目管理2大方面，包含需求調(diào)研分析、產(chǎn)品設(shè)計、需求評審、驗收和項目復(fù)盤。

最后，在文中也穿插了非常多的難點和避坑點提醒，這些都是筆者的血淚史～相信讀完本文的你，已經(jīng)對一次迭代建立了較為完整而全面的認(rèn)知框架，也同時掌握了足夠落地的技巧和方法，那就快去實戰(zhàn)操練下吧！

作者：冰冰醬；公眾號：setmefree

本文由 @冰冰醬 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議