作者簡介：網(wǎng)名蕭尼瑪，曾負(fù)責(zé)過巨頭互聯(lián)網(wǎng)公司千萬級(jí)日活客戶端產(chǎn)品的項(xiàng)目管理工作，同時(shí)也是一名苦逼的產(chǎn)品經(jīng)理。

客戶端產(chǎn)品相較PC、移動(dòng)web而言，更重、更繁瑣，需要綜合考慮的因素多。因此有一個(gè)系統(tǒng)、全面的項(xiàng)目管理流程是很有必要的。特別是用戶量到達(dá)一定級(jí)別之后，產(chǎn)品和項(xiàng)目會(huì)變得愈加復(fù)雜，如果項(xiàng)目管理跟不上，就會(huì)導(dǎo)致開發(fā)效率下降，產(chǎn)品方案實(shí)際落地與預(yù)期偏差大、溝通復(fù)雜且困難，團(tuán)隊(duì)內(nèi)部矛盾加深等問題。一個(gè)客戶端產(chǎn)品如果想高效而穩(wěn)定的進(jìn)行迭代和版本開發(fā)，科學(xué)的項(xiàng)目管理方法至關(guān)重要。接下來的文章就本人的經(jīng)歷和思考提供一些解決方案，以供參考。

既然是項(xiàng)目管理，當(dāng)然就得按一定方法將項(xiàng)目從起始到結(jié)束的整個(gè)流程切分為一個(gè)個(gè)的節(jié)點(diǎn)，然后根據(jù)各個(gè)節(jié)點(diǎn)的情況來提煉共性并輸出指導(dǎo)方法論，就像打游戲一樣，哪一關(guān)的boss應(yīng)該如何打。以下提供一種思路做參考。將客戶端產(chǎn)品項(xiàng)目的產(chǎn)品需求調(diào)研、收集及策劃定為項(xiàng)目開始，版本穩(wěn)定上線設(shè)為結(jié)束，這就是一個(gè)完整的流程，中間的環(huán)節(jié)及順序見下圖：
下面，我們仔細(xì)分析每一個(gè)節(jié)點(diǎn)需要處理的事情和一些需要注意的事項(xiàng)。

策劃：

作為一個(gè)項(xiàng)目管理者，在這個(gè)階段需要做的就是明確各個(gè)需求方的需求，從大的角度（整個(gè)APP）去審視各個(gè)需求方的方案是否存在短視的行為。比如：是否遵循了端的設(shè)計(jì)交互、設(shè)計(jì)規(guī)范（后文會(huì)補(bǔ)充說明），是否有可以合并實(shí)現(xiàn)以降低開發(fā)成本的交叉區(qū)域，是否有現(xiàn)階段做不合適的需求等。

從細(xì)節(jié)展開來講就是先了解清楚各個(gè)需求方的需求、優(yōu)先級(jí)和產(chǎn)品預(yù)期，然后經(jīng)過全盤的思考后，給出意見和輸出結(jié)論。

例：

需求方A想在這一版本中賣會(huì)員，方式是走自己的交易系統(tǒng)進(jìn)行結(jié)算；需求方B希望在這一版中賣虛擬道具，方式是使用自己產(chǎn)品的虛擬貨幣體系M幣來進(jìn)行結(jié)算。當(dāng)前的情況是客戶端上沒有接入任何交易體系。在這個(gè)case的背景下，作為端的項(xiàng)目管理者就要思考：既然大家都有支付的需求，是否值得做（接入）一套支付體系來整體承接。比如接入貨幣體系M幣，所有的支付需求都走M(jìn)幣結(jié)算，用戶僅需購買M幣就可在這個(gè)產(chǎn)品上兌換所有的付費(fèi)服務(wù)。

在這個(gè)環(huán)節(jié)，這種例子不勝枚舉，大家可以舉一反三去處理實(shí)際遇到的問題。總的思路就是眼界要寬一些，能重復(fù)利用的盡量重復(fù)利用，能協(xié)調(diào)到一塊的就盡量協(xié)調(diào)，以節(jié)約開發(fā)成本。關(guān)鍵點(diǎn)是讓產(chǎn)品從用戶的角度看不會(huì)感覺明顯割裂，體驗(yàn)是完整的。舉個(gè)反例，如果單純的滿足上例A、B方的需求并上線，某用戶C需要購買A、B方的東西，他充值M幣之后用來購買B方提供的虛擬道具，剩下的M幣想買A方提供的會(huì)員，卻發(fā)現(xiàn)無法用M幣支付。此時(shí)，體驗(yàn)就是割裂的，不完整的，用戶會(huì)迷失，這種情況非常嚴(yán)重，大家一定要重視，竭力避免。

交互、視覺：

和交互、視覺同學(xué)打交道，要注意自己的溝通和闡述方式，注重輸出需求本身而不是浮于形式，這個(gè)很關(guān)鍵。比如，告訴設(shè)計(jì)師你要做這件事的初衷以及期望達(dá)到的產(chǎn)品目的（例：通過附近的人來為陌生人創(chuàng)造場(chǎng)景，提供沉淀關(guān)系的機(jī)會(huì)），而不是直接告訴他照著微信（陌陌）抄。

有很多公司PM本身就兼任交互設(shè)計(jì)師，那么在這種情況下在產(chǎn)品設(shè)計(jì)過程中建議多跟視覺同學(xué)溝通，保持信息通暢，原型設(shè)計(jì)過程中盡量別帶干擾因素（上色、限制死元素尺寸等）。

溝通過程中一定要以目標(biāo)為導(dǎo)向，不要沉溺于形式。比如：某一個(gè)地方兩種設(shè)計(jì)方式都能達(dá)到目標(biāo)，且效果評(píng)估相近，設(shè)計(jì)師贊同A，產(chǎn)品贊同B，這種時(shí)候可適當(dāng)妥協(xié)。

設(shè)計(jì)方案過程中產(chǎn)品一定要有邏輯、有體系的去檢查各個(gè)頁面的細(xì)節(jié)盡量減少后期返工的可能性（問題前置一定比后置要好）。

例：設(shè)計(jì)好方案后將其拆解為幾個(gè)大方向，分別去檢查case是否健全，有無遺漏情況，下面分享一個(gè)檢查表，大家可以根據(jù)參照這個(gè)思路去進(jìn)行產(chǎn)品設(shè)計(jì)的檢查。

做設(shè)計(jì)的時(shí)候一定要去考慮細(xì)節(jié)，不然后期可能因?yàn)橐粋€(gè)很小的點(diǎn)（致命）而導(dǎo)致大返工。
例：
假如我來設(shè)計(jì)網(wǎng)易新聞中新聞tab下頭條tag中的新聞卡片。例圖如下：

我會(huì)從UI、交互、緩存、異常這幾個(gè)關(guān)鍵點(diǎn)入手對(duì)產(chǎn)品方案做細(xì)節(jié)梳理，梳理腦圖（case）如下：



上述腦圖（case）只是舉例，大家可以按照自己的實(shí)際情況及偏好借鑒這個(gè)思路去做變形或延展，但是在做產(chǎn)品設(shè)計(jì)時(shí)一定要考慮，不然后期可能會(huì)因?yàn)椴淮_定性因素造成delay甚至是大返工。在跟需求提出方對(duì)方案時(shí)，最好也按很細(xì)的角度，思維去檢查。

很多產(chǎn)品同學(xué)認(rèn)為case是QA同學(xué)負(fù)責(zé)的，自己不用在意，其實(shí)這種思路非常錯(cuò)誤和不負(fù)責(zé)。試問如果產(chǎn)品考慮得不夠細(xì)致和全面，那最后產(chǎn)品還是會(huì)被QA同學(xué)不停的追問，那么你的整個(gè)工作節(jié)奏肯定會(huì)被打斷，每天被瑣事纏身，工作效率下降。對(duì)于QA同學(xué)而言，寫case的時(shí)間也會(huì)成倍增加。

評(píng)審

評(píng)審是產(chǎn)品全流程中的分水嶺，理論上講評(píng)審過后則需求凍結(jié)（不能再改了）。作為項(xiàng)目管理者，在這個(gè)階段一定要確定好游戲規(guī)則并嚴(yán)格執(zhí)行，在各方心中建立信任度。評(píng)審過程越激烈越好，大家充分的提出自己的想法和觀點(diǎn)，以及自己預(yù)判的一些風(fēng)險(xiǎn)點(diǎn)，在評(píng)審中一定要盡量暴露問題（問題前置）。如果需求評(píng)審會(huì)一團(tuán)和氣，那一般情況下后期開發(fā)、驗(yàn)收過程中都會(huì)存在大量撕逼、扯皮、delay的情況。

個(gè)人提供一種規(guī)則思路：

1、項(xiàng)目管理者收集匯總各方的prd及feature list，統(tǒng)一交付給評(píng)審參與者。有兩點(diǎn)較為重要：

1）文檔寫清楚版本號(hào)，方便多次修改、調(diào)整后各方都還能明明白白；
2）文檔做好留檔工作，日后追查線上功能時(shí)，有據(jù)可依。
*PRD大家都有自己的玩法，我就不獻(xiàn)丑了，feature list我提供一點(diǎn)點(diǎn)想法：
還是按照上文的例子進(jìn)行舉例

方向是指需求提出方，模塊是指屬于客戶端哪個(gè)部分，頁面就是功能所在的頁面，需求點(diǎn)是需求的提綱和概述，優(yōu)先級(jí)是指緊急程度，負(fù)責(zé)人是跟進(jìn)這個(gè)需求的PM（有問題就找他了解、協(xié)助推進(jìn)）。有了feature list后可以保證版本需求很繁瑣時(shí)不出現(xiàn)遺漏，減少了很多后期的風(fēng)險(xiǎn)，也方便開發(fā)人員快速找到需求的接口人，提高溝通效率。所以作為項(xiàng)目負(fù)責(zé)人有必要讓各需求方按照統(tǒng)一的方式提交feature list。
2、評(píng)審開兩次，第一次小范圍（負(fù)責(zé)各需求的PM、項(xiàng)目管理者、UI負(fù)責(zé)人、RD負(fù)責(zé)人、QA負(fù)責(zé)人）評(píng)審和討論，第二次全體（所有置身于項(xiàng)目中的人）評(píng)審和討論；

3、第二次評(píng)審結(jié)束，開發(fā)和測(cè)試就此版本需求情況進(jìn)行排期，輸出每個(gè)需求的開始及結(jié)束時(shí)間節(jié)點(diǎn)以及最后完成版本開發(fā)（封版）的時(shí)間節(jié)點(diǎn)。

4、第二次評(píng)審出結(jié)論后，即是產(chǎn)品、開發(fā)對(duì)此次項(xiàng)目達(dá)成共識(shí)。對(duì)產(chǎn)品而言意味著需求不能再改（增）。當(dāng)然了，如果砍需求，我相信開發(fā)們會(huì)很樂意（所以PM同學(xué)在這之前一定要仔細(xì)考慮清楚需求和邊界情況）；對(duì)開發(fā)而言需要?jiǎng)t是要對(duì)輸出的完成時(shí)間點(diǎn)、功能實(shí)現(xiàn)負(fù)責(zé)。后期存在delay，需求無法實(shí)現(xiàn)的情況都是需要開發(fā)同學(xué)背鍋的（所以開發(fā)同學(xué)評(píng)審時(shí)一定要了解透徹，認(rèn)為不靠譜的地方一定要在這個(gè)環(huán)節(jié)提出并解決）

這個(gè)環(huán)節(jié)的重點(diǎn)是在于不保留的提出問題，明確劃分好權(quán)責(zé)，把之前階段所有不透明、不明確的因素全部解決好。

跟進(jìn)：

這個(gè)階段的重點(diǎn)在于按照之前的協(xié)議卡好時(shí)間節(jié)點(diǎn)來開展相關(guān)工作。項(xiàng)目管理者在這個(gè)階段需要雙眼盯好時(shí)間點(diǎn)，一切為時(shí)間服務(wù)。項(xiàng)目管理者在此階段是需求提出方和開發(fā)方的接口人，

要積極幫助雙方推動(dòng)事情，解決問題，關(guān)鍵的時(shí)候需要能站出來拍板并承擔(dān)責(zé)任。很多有明顯交叉的地方（不屬于此版本中任意一個(gè)需求方，但是又必須要做）需要項(xiàng)目管理者來進(jìn)行處理。
例：
需求A的開發(fā)、測(cè)試時(shí)間是8.1-8.10，需求方是B，開發(fā)是C。
情況1：B和C就某一細(xì)節(jié)爭執(zhí)起來了，你需要根據(jù)評(píng)審時(shí)的結(jié)論以及端的規(guī)則來協(xié)調(diào)雙方達(dá)成共識(shí)

情況2：需求A較復(fù)雜，還要協(xié)調(diào)另一個(gè)team加入工作。這時(shí)還是得盯著時(shí)間，做出決策和應(yīng)變。如果可以，結(jié)論最好告知雙方老大，這對(duì)雙方而言是一種約束（跨團(tuán)隊(duì)、跨部門、跨公司協(xié)作這種事情應(yīng)情況而異，我個(gè)人的秘訣就是要保持理智和耐心，積極的扛起責(zé)任和處理事情，無止境的抱怨是無濟(jì)于事的）

情況3：由于高優(yōu)項(xiàng)目插入或人力出現(xiàn)變動(dòng)，導(dǎo)致項(xiàng)目有delay風(fēng)險(xiǎn)。這種情況需要判斷delay風(fēng)險(xiǎn)是否會(huì)影響整個(gè)版本的總體時(shí)間規(guī)劃。如果不影響，那見機(jī)行事；如果有影響，就要考慮精簡，砍掉這個(gè)需求或者是延長開發(fā)時(shí)間（簡單來說遇到這種情況盡量精簡需求或者是delay此項(xiàng)目吧，棄車保帥。保證整個(gè)版本的時(shí)間計(jì)劃不被打亂才是最重要的）

上述列舉了一些頻發(fā)的情況，其他的就不一一贅述了，大家見機(jī)行事。決策原則是少扯皮、多扛事，眼睛盯住deadline。

驗(yàn)收：

此環(huán)節(jié)對(duì)經(jīng)驗(yàn)的要求很高，大家平日一定要多積累，見多就識(shí)廣了。Demo拿在手上體驗(yàn)一會(huì)就知道哪里有問題，哪里要返工。個(gè)人的經(jīng)驗(yàn)也說說，大家可以自行判斷和參考：

1、驗(yàn)收要有科學(xué)的方法：拿著feature list保證不會(huì)漏看，根據(jù)PM和QA同學(xué)寫的腦圖（case）驗(yàn)收每一種情況是否都符合預(yù)期。最后按照用戶可能的使用路徑做無規(guī)則體驗(yàn)。

2、驗(yàn)收分為分個(gè)驗(yàn)收和總驗(yàn)收兩種情況。在跟進(jìn)環(huán)節(jié)時(shí)，每做好一個(gè)需求就拉上相應(yīng)的PM進(jìn)行驗(yàn)收，確認(rèn)每個(gè)分塊沒問題。最后組織一次大的整體驗(yàn)收，多邀請(qǐng)一些角色（運(yùn)營、交互、UI設(shè)計(jì)師、用研同學(xué)、銷售同學(xué)等），從不同角度來體驗(yàn)和驗(yàn)收

3、驗(yàn)收時(shí)發(fā)現(xiàn)有問題一定要及時(shí)跟進(jìn)并解決。如果是由于PM特別是項(xiàng)目管理者自身失誤導(dǎo)致的問題，一定不要推卸責(zé)任，勇敢的擔(dān)下來并尋求彌補(bǔ)方案。人都會(huì)犯錯(cuò)，關(guān)鍵是把結(jié)果達(dá)成。但是如果出現(xiàn)的是重大問題…那一定是工作沒做到位，回去慢慢反思吧。

灰度：

灰度主要有兩個(gè)用途：

1、就產(chǎn)品方案進(jìn)行A/B test，基于測(cè)試結(jié)果來判斷使用哪種方案；

2、投放給客戶端小規(guī)模的用戶，觀測(cè)crash（閃退）率以及用戶對(duì)于版本新功能（改變）的態(tài)度來決定是否做出改變等。

需要注意的坑：用戶反饋的不一定就是對(duì)的，一定要有自己的判斷力，實(shí)在拿不準(zhǔn)就去聯(lián)系這些用戶問清楚場(chǎng)景和他們吐槽的問題。

比如：

1）用戶說的不一定是事實(shí)：用戶反饋新版本字太小看不見；你一改，另外一撥用戶馬上又來反饋說字太大。

2）好的不一定是對(duì)的：某個(gè)東西大家都覺得好。從理論上推導(dǎo)更簡單、更順暢，從視覺上更漂亮、更精致。上線以后用戶狂噴…..原因是用戶已經(jīng)養(yǎng)成習(xí)慣了，你去挑戰(zhàn)他的習(xí)慣，他當(dāng)然要反抗。這一點(diǎn)，有個(gè)高人曾經(jīng)給過指導(dǎo)：好鋼用在刀刃上。做得爛的趕緊改，做得好的擴(kuò)大優(yōu)勢(shì)，做得一般的千萬別動(dòng)它（要么你下定決心把它下線了，要么就等他爛透了再動(dòng)）

灰度的具體實(shí)施方法：
Android的話有很多應(yīng)用商店，可以選擇其中一兩個(gè)作為灰度渠道，發(fā)出新版的包，然后再收集用戶的反饋意見。比如在百度手機(jī)助手、應(yīng)用寶發(fā)布灰度包。

iOS的話可以在一些越獄渠道放灰度包進(jìn)行測(cè)試，同時(shí)可以使用官方的testflight測(cè)試（大致幾百到一千用戶可以提前體驗(yàn)未上架App Store的包并進(jìn)行反饋）

上線：

灰度一兩周后，確定該解決的問題都OK了，沒有重大的問題或者是大量的集中反饋就可以正式發(fā)布啦（如果灰度時(shí)還有很多問題，比如crash率很高，那建議修復(fù)后再次進(jìn)行灰度，確保不出問題）。

循環(huán)節(jié)奏：

如果你們的產(chǎn)品穩(wěn)扎穩(wěn)打，節(jié)奏較慢，那么在上述流程走完之后，進(jìn)入下一次大循環(huán)即可。

如果你們需要敏捷開發(fā)、快速迭代，那么下一個(gè)版本的完整流程應(yīng)該從當(dāng)前版本中間時(shí)就啟動(dòng)，在此提供一種思路：

其實(shí)非常簡單，當(dāng)前版本進(jìn)入灰度時(shí)，下一個(gè)版本的流程剛好走到評(píng)審即可，

整體的環(huán)節(jié)不變。這樣做的好處是對(duì)于開發(fā)來說，一直處于

的節(jié)奏中。正常的版本迭代，進(jìn)入灰度之后開發(fā)的時(shí)間相對(duì)會(huì)充裕起來，任務(wù)基本是解當(dāng)前版本需求的bug，空出來的時(shí)間可以開始下個(gè)版本需求的調(diào)研工作。

補(bǔ)充客戶端規(guī)范：

產(chǎn)品大了以后涉及到多團(tuán)隊(duì)并行設(shè)計(jì)和開發(fā)，有一套大家共同遵循的客戶端設(shè)計(jì)規(guī)范就顯得尤為重要了，這是保障客戶端用戶擁有完整體驗(yàn)的必要手段。

在此提供一種思路：項(xiàng)目管理者協(xié)調(diào)好交互和UI設(shè)計(jì)師，從文案、按鈕、導(dǎo)航欄、文字樣式及大小、詢問彈窗、toast、icon使用規(guī)范（描邊？實(shí)體？彩色？）、基礎(chǔ)設(shè)置、手勢(shì)操作等制定出一套詳細(xì)的要求發(fā)給各個(gè)團(tuán)隊(duì)，各個(gè)團(tuán)隊(duì)在進(jìn)行產(chǎn)品設(shè)計(jì)時(shí)，涉及到上述元素時(shí)只可在規(guī)則許可的范圍內(nèi)進(jìn)行自由發(fā)揮（比如app主題色是藍(lán)色，你不能搞個(gè)紅色的東西出來吧？標(biāo)題用XX號(hào)字，摘要用YY號(hào)字，你不能反過來吧？雙擊是點(diǎn)贊，你不能設(shè)計(jì)成刪除吧？）這部分細(xì)節(jié)很多，只提供一個(gè)大體的思路，就不展開進(jìn)行講述了，大家把握好關(guān)鍵點(diǎn)：大的客戶端一定有個(gè)圈，大家都得遵守規(guī)則，跳舞不能跳出這個(gè)圈。

多開發(fā)團(tuán)隊(duì)并行開發(fā)：

客戶端發(fā)展到需要多個(gè)開發(fā)團(tuán)隊(duì)進(jìn)行協(xié)作配合時(shí)，項(xiàng)目管理的方式需要有一些調(diào)整，在此提供一個(gè)思路：

其中一個(gè)（或獨(dú)立）團(tuán)隊(duì)負(fù)責(zé)版本的合并和發(fā)版工作。定一個(gè)灰度時(shí)間點(diǎn)，根據(jù)灰度時(shí)間點(diǎn)倒推出封版時(shí)間點(diǎn)（間隔時(shí)間應(yīng)情況而異，這段時(shí)間QA同學(xué)整體回歸所有的需求，驗(yàn)收通過后方可進(jìn)行灰度），從開啟合并到封版的這段時(shí)間中各需求方將需求（提前將規(guī)范交由需求方，可以是準(zhǔn)入文檔等一類的東西，整個(gè)開發(fā)過程可以適當(dāng)進(jìn)行檢查，確保他們是沒跑偏的）合并入主干，過時(shí)不候。

客戶端管理雖然是一件繁瑣的事情，但是相比較產(chǎn)品工作而言不確定性更少?；緦儆谡莆湛茖W(xué)方法、經(jīng)過一定的時(shí)間運(yùn)行并優(yōu)化后即可掌握的技能，有很多的細(xì)節(jié)只可意會(huì)不可言傳，所以在文章中不贅述。大家可以按照這個(gè)思路去衍變出適合自己情況的管理方案。

本文為作者蕭尼瑪投稿PMCAFF產(chǎn)品經(jīng)理社區(qū)（pmcaff.com），轉(zhuǎn)載請(qǐng)注明來源。

推薦閱讀

《PMCAFF 2015上半年干貨精選》

PMCAFF各類精品群

招聘群|PMCAFF lizimao-candy

電商PM圈|PMCAFF 396981669

工具PM圈|PMCAFF JaneYu81

互聯(lián)網(wǎng)O2O圈|PMCAFF Nicole_0928

互聯(lián)網(wǎng)金融圈|PMCAFF erhuoyimei

旅游PM圈|PMCAFF lizheng_legend

社交PM圈|PMCAFF liyilin1263

視頻PM圈|PMCAFF EsDark_guiga

智能硬件圈|PMCAFF Johnson727543

唯一B端產(chǎn)品群|PMCAFF ssparker

入群規(guī)則

1、入群需參與一次群分享（話題內(nèi)容不限）

2、敲門磚：姓名+公司+可以分享的話題

投稿請(qǐng)發(fā)送至郵箱：tougao@pmcaff.com

商務(wù)合作請(qǐng)聯(lián)系：xiaoxi@pmcaff.com

PMCAFF合作媒體：Chinaz

總結(jié)

以上是生活随笔為你收集整理的PMCAFF|百度客户端产品：高效开发客户端产品的正确姿势的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。