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

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

下面，我們仔細(xì)分析每一個(gè)節(jié)點(diǎn)需要處理的事情和一些需要注意的事項(xiàng)。

策劃：

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

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

例：

需求方A想在這一版本中賣(mài)會(huì)員，方式是走自己的交易系統(tǒng)進(jìn)行結(jié)算；

需求方B希望在這一版中賣(mài)虛擬道具，方式是使用自己產(chǎn)品的虛擬貨幣體系M幣來(lái)進(jìn)行結(jié)算。

當(dāng)前的情況是客戶(hù)端上沒(méi)有接入任何交易體系。在這個(gè)case的背景下，作為端的項(xiàng)目管理者就要思考：既然大家都有支付的需求，是否值得做（接入）一套支付體系來(lái)整體承接。比如接入貨幣體系M幣，所有的支付需求都走M(jìn)幣結(jié)算，用戶(hù)僅需購(gòu)買(mǎi)M幣就可在這個(gè)產(chǎn)品上兌換所有的付費(fèi)服務(wù)。

在這個(gè)環(huán)節(jié)，這種例子不勝枚舉，大家可以舉一反三去處理實(shí)際遇到的問(wèn)題。總的思路就是眼界要寬一些，能重復(fù)利用的盡量重復(fù)利用，能協(xié)調(diào)到一塊的就盡量協(xié)調(diào)，以節(jié)約開(kāi)發(fā)成本。關(guān)鍵點(diǎn)是讓產(chǎn)品從用戶(hù)的角度看不會(huì)感覺(jué)明顯割裂，體驗(yàn)是完整的。

舉個(gè)反例：如果單純的滿(mǎn)足上例A、B方的需求并上線(xiàn)，某用戶(hù)C需要購(gòu)買(mǎi)A、B方的東西，他充值M幣之后用來(lái)購(gòu)買(mǎi)B方提供的虛擬道具；剩下的M幣想買(mǎi)A方提供的會(huì)員，卻發(fā)現(xiàn)無(wú)法用M幣支付。此時(shí)，體驗(yàn)就是割裂的，不完整的，用戶(hù)會(huì)迷失。這種情況非常嚴(yán)重，大家一定要重視，竭力避免。

交互、視覺(jué)：

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

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

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

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

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

做設(shè)計(jì)的時(shí)候一定要去考慮細(xì)節(jié)，不然后期可能因?yàn)橐粋€(gè)很小的點(diǎn)（致命）而導(dǎo)致大返工。

例：

假如我來(lái)設(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é)。試問(wèn)如果產(chǎn)品考慮得不夠細(xì)致和全面，那最后產(chǎn)品還是會(huì)被QA同學(xué)不停的追問(wèn)。那么你的整個(gè)工作節(jié)奏肯定會(huì)被打斷，每天被瑣事纏身，工作效率下降。對(duì)于QA同學(xué)而言，寫(xiě)case的時(shí)間也會(huì)成倍增加。

評(píng)審：

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

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

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

1. 文檔寫(xiě)清楚版本號(hào)，方便多次修改、調(diào)整后各方都還能明明白白；
2. 文檔做好留檔工作，日后追查線(xiàn)上功能時(shí)，有據(jù)可依。

*PRD大家都有自己的玩法，我就不獻(xiàn)丑了，feature list我提供一點(diǎn)點(diǎn)想法：

還是按照上文的例子進(jìn)行舉例

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

評(píng)審開(kāi)兩次，第一次小范圍（負(fù)責(zé)各需求的PM、項(xiàng)目管理者、UI負(fù)責(zé)人、RD負(fù)責(zé)人、QA負(fù)責(zé)人）評(píng)審和討論；第二次全體（所有置身于項(xiàng)目中的人）評(píng)審和討論。

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

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

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

跟進(jìn)：

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

要積極幫助雙方推動(dòng)事情，解決問(wèn)題，關(guān)鍵的時(shí)候需要能站出來(lái)拍板并承擔(dān)責(zé)任。很多有明顯交叉的地方（不屬于此版本中任意一個(gè)需求方，但是又必須要做）需要項(xiàng)目管理者來(lái)進(jìn)行處理。

例：

需求A的開(kāi)發(fā)、測(cè)試時(shí)間是8.1-8.10，需求方是B，開(kāi)發(fā)是C。

• 情況1：B和C就某一細(xì)節(jié)爭(zhēng)執(zhí)起來(lái)了，你需要根據(jù)評(píng)審時(shí)的結(jié)論以及端的規(guī)則來(lái)協(xié)調(diào)雙方達(dá)成共識(shí)
• 情況2：需求A較復(fù)雜，還要協(xié)調(diào)另一個(gè)team加入工作。這時(shí)還是得盯著時(shí)間，做出決策和應(yīng)變。如果可以，結(jié)論最好告知雙方老大，這對(duì)雙方而言是一種約束（跨團(tuán)隊(duì)、跨部門(mén)、跨公司協(xié)作這種事情應(yīng)情況而異，我個(gè)人的秘訣就是要保持理智和耐心，積極的扛起責(zé)任和處理事情，無(wú)止境的抱怨是無(wú)濟(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ī)劃。如果不影響，那見(jiàn)機(jī)行事；如果有影響，就要考慮精簡(jiǎn)，砍掉這個(gè)需求或者是延長(zhǎng)開(kāi)發(fā)時(shí)間（簡(jiǎn)單來(lái)說(shuō)遇到這種情況盡量精簡(jiǎn)需求或者是delay此項(xiàng)目吧，棄車(chē)保帥。保證整個(gè)版本的時(shí)間計(jì)劃不被打亂才是最重要的）

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

驗(yàn)收：

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

• 驗(yàn)收要有科學(xué)的方法：拿著feature list保證不會(huì)漏看，根據(jù)PM和QA同學(xué)寫(xiě)的腦圖（case）驗(yàn)收每一種情況是否都符合預(yù)期。最后按照用戶(hù)可能的使用路徑做無(wú)規(guī)則體驗(yàn)。
• 驗(yàn)收分為分個(gè)驗(yàn)收和總驗(yàn)收兩種情況。在跟進(jìn)環(huán)節(jié)時(shí)，每做好一個(gè)需求就拉上相應(yīng)的PM進(jìn)行驗(yàn)收，確認(rèn)每個(gè)分塊沒(méi)問(wèn)題。最后組織一次大的整體驗(yàn)收，多邀請(qǐng)一些角色（運(yùn)營(yíng)、交互、UI設(shè)計(jì)師、用研同學(xué)、銷(xiāo)售同學(xué)等），從不同角度來(lái)體驗(yàn)和驗(yàn)收。
• 驗(yàn)收時(shí)發(fā)現(xiàn)有問(wèn)題一定要及時(shí)跟進(jìn)并解決。如果是由于PM特別是項(xiàng)目管理者自身失誤導(dǎo)致的問(wèn)題，一定不要推卸責(zé)任，勇敢的擔(dān)下來(lái)并尋求彌補(bǔ)方案。人都會(huì)犯錯(cuò)，關(guān)鍵是把結(jié)果達(dá)成。但是如果出現(xiàn)的是重大問(wèn)題…那一定是工作沒(méi)做到位，回去慢慢反思吧。

灰度：

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

• 就產(chǎn)品方案進(jìn)行A/B test，基于測(cè)試結(jié)果來(lái)判斷使用哪種方案；
• 投放給客戶(hù)端小規(guī)模的用戶(hù)，觀(guān)測(cè)crash（閃退）率以及用戶(hù)對(duì)于版本新功能（改變）的態(tài)度來(lái)決定是否做出改變等。

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

比如：

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

灰度的具體實(shí)施方法：

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

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

上線(xiàn)：

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

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

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

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

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

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

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

補(bǔ)充：

客戶(hù)端規(guī)范：

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

在此提供一種思路：項(xiàng)目管理者協(xié)調(diào)好交互和UI設(shè)計(jì)師，從文案、按鈕、導(dǎo)航欄、文字樣式及大小、詢(xún)問(wèn)彈窗、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è)紅色的東西出來(lái)吧？標(biāo)題用XX號(hào)字，摘要用YY號(hào)字，你不能反過(guò)來(lái)吧？雙擊是點(diǎn)贊，你不能設(shè)計(jì)成刪除吧？）這部分細(xì)節(jié)很多，只提供一個(gè)大體的思路，就不展開(kāi)進(jìn)行講述了，大家把握好關(guān)鍵點(diǎn)：大的客戶(hù)端一定有個(gè)圈，大家都得遵守規(guī)則，跳舞不能跳出這個(gè)圈。

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

客戶(hù)端發(fā)展到需要多個(gè)開(kāi)發(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)收通過(guò)后方可進(jìn)行灰度），從開(kāi)啟合并到封版的這段時(shí)間中各需求方將需求（提前將規(guī)范交由需求方，可以是準(zhǔn)入文檔等一類(lèi)的東西，整個(gè)開(kāi)發(fā)過(guò)程可以適當(dāng)進(jìn)行檢查，確保他們是沒(méi)跑偏的）合并入主干，過(guò)時(shí)不候。

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

本文由 @蕭尼瑪 原創(chuàng)授權(quán)人人都是產(chǎn)品經(jīng)理發(fā)布 ，未經(jīng)作者許可，禁止轉(zhuǎn)載。