如果我是一個(gè)技術(shù)大牛，極具產(chǎn)品sense，還湊巧精通Origami、AI、PS，我完全可以一個(gè)人做款A(yù)PP，并持續(xù)迭代！我做過技術(shù)，是建筑行業(yè)的技術(shù)；我會(huì)畫圖，都是用CAD和SkechUp；我很認(rèn)真的做產(chǎn)品，但剛滿一年而已。答案顯而易見，我一個(gè)人是無法做產(chǎn)品的！

老大，我缺開發(fā)。

找外包。

老大，我缺測(cè)試。

自己頂上。

老大，我缺視覺。

協(xié)調(diào)資源。

老大，我缺項(xiàng)管。

一陣可怕的安靜之后，老大笑著對(duì)我說“產(chǎn)品經(jīng)理是什么？產(chǎn)品經(jīng)理就是發(fā)現(xiàn)問題，解決問題。優(yōu)秀的產(chǎn)品經(jīng)理必須在缺少測(cè)試、設(shè)計(jì)、項(xiàng)管情況下自己承擔(dān)起來。”

我眨了眨眼，對(duì)老大說“那我是不是還要學(xué)編程？”然后在老大還沒來得及發(fā)火之前逃離了辦公室。

一個(gè)字形容我的項(xiàng)目——真的很缺人。說是一個(gè)人做有些夸張，但是在技術(shù)外包，交互、視覺、測(cè)試、項(xiàng)管全都兼職的情況下，我真的有些無力，項(xiàng)目也曾經(jīng)歷了上線延期，崩潰率過高，用戶差評(píng)無數(shù)的情況，好在這些都成為過去?，F(xiàn)在跟大家分享一下外包項(xiàng)目的注意事項(xiàng)，希望對(duì)同行們有所幫助。

一、需求層面

需求不明確，這是產(chǎn)品經(jīng)理的大忌，在這種情況下即便外包把下載做成上傳你都沒什么好說的，誰叫你需求不明確呢。

產(chǎn)品需求文檔是指導(dǎo)開發(fā)、測(cè)試的基本文檔，越明確越好。這里說的明確而不是詳細(xì)，因?yàn)闊o論是開發(fā)、交互，還是測(cè)試，都不愿意看大片的文字，在外包項(xiàng)目的第一個(gè)迭代中，我的PRD寫了23頁，封面、目錄、修訂記錄、產(chǎn)品介紹、功能性需求、非功能性需求外，還加上了其他和特別說明，一個(gè)需求評(píng)審走下來要一兩個(gè)小時(shí)，當(dāng)我講完后看到開發(fā)經(jīng)理滿臉茫然的表情，我知道這是一次失敗的評(píng)審會(huì)。

為了讓開發(fā)更好的理解產(chǎn)品需求，為了讓交互更好進(jìn)行設(shè)計(jì)，為了讓測(cè)試的test case更加完整，我司逐漸推廣“story+線框圖+標(biāo)注”模式的PRD，story務(wù)必條理清晰，線框圖和標(biāo)注務(wù)必簡(jiǎn)單明了，幾個(gè)迭代走下來，明顯感覺到外包對(duì)需求的理解準(zhǔn)確了不少。

二、進(jìn)度層面

沒有deadline是萬萬不行的，項(xiàng)目可能無限制延期。而我的第一個(gè)版本就吃了這樣的虧，由于我司一個(gè)模塊在開發(fā)中，release版本事件待定，就將產(chǎn)品交付事件擬定在8月中，可是最后延期了兩周，期間還有各種撕逼，好不難受。

可是僅有deadline也是不夠的，畢竟功能的開發(fā)存在不確定性，聯(lián)調(diào)時(shí)間、測(cè)試時(shí)間、debug時(shí)間無法保障，如果僅有deadline，很容易將全部風(fēng)險(xiǎn)往后堆積，最后的結(jié)果只能是項(xiàng)目延期，產(chǎn)品經(jīng)理被批！

你需要設(shè)置項(xiàng)目節(jié)點(diǎn)，階段性交付、階段性提測(cè)，把風(fēng)險(xiǎn)分散并提前。當(dāng)前在進(jìn)行的迭代我們?cè)O(shè)置了四個(gè)節(jié)點(diǎn)，兩個(gè)模塊化提測(cè)節(jié)點(diǎn)，兩個(gè)全功能提測(cè)節(jié)點(diǎn)，一個(gè)上線節(jié)點(diǎn)；雖然目前只進(jìn)行到首次全功能提測(cè)，但是按照節(jié)點(diǎn)走的感覺真的不賴。

三、質(zhì)量層面

外包項(xiàng)目開發(fā)中最怕的不是進(jìn)度，而是質(zhì)量。因?yàn)樗麄兛赡軙?huì)早早的打包給你，可是你能測(cè)出100個(gè)bug。

要想在把控這一塊，必須加強(qiáng)開發(fā)自測(cè)和代碼review。在上一個(gè)版本出現(xiàn)過“冒煙測(cè)試不通過”的情況，你知道那種外包如期把包給你，你開心的測(cè)試，可是居然無法下手的痛苦和無奈嗎？那一刻簡(jiǎn)直想把剛買的iPhone 6砸在他們臉上，這也提測(cè)，讓我怎么測(cè)！

要保證質(zhì)量，首先是開發(fā)的自測(cè)。當(dāng)然如果你是技術(shù)大牛，對(duì)自己寫的代碼極其有自信，不自測(cè)也罷?？墒谴蠖鄶?shù)外包人員水平其實(shí)并沒有那么高，那么自測(cè)是必要的，自測(cè)階段可以發(fā)現(xiàn)不少問題，至少避免出現(xiàn)功能未實(shí)現(xiàn)便提測(cè)的情況。

其次是內(nèi)部技術(shù)人員的代碼review，我們的iOS開發(fā)主管跟我說“代碼review必須階段性進(jìn)行，放在功能性測(cè)試之前，我們通過代碼就能review能找到很多問題，減輕測(cè)試工作量”，直到那一刻我才知道原來這么重要，代碼review不僅僅是看代碼是否合乎規(guī)范，更重要是看代碼的分層、封裝、碎片化是否足夠，是否有隱藏的bug，是否需要重構(gòu)等。

我對(duì)自己產(chǎn)品的期望是在功能性提測(cè)之前完成代碼review給到的建議，將功能性bug壓縮至10個(gè)以內(nèi)。

四、規(guī)范層面

前面提到了進(jìn)度，提到了質(zhì)量，但是這些都需要相應(yīng)的規(guī)范來保障，不然還是水中月夢(mèng)里花。下面是我在項(xiàng)目迭代中整理了部分規(guī)范，雖然不是很完善，但項(xiàng)目相對(duì)于之前確順了很多。

內(nèi)部方面：

1、規(guī)范測(cè)試準(zhǔn)入標(biāo)準(zhǔn)

（1）階段性功能提測(cè)：確保基本業(yè)務(wù)流程走通才能提測(cè)；

（2）bugfix：

• a、開發(fā)根據(jù)jira中的優(yōu)先級(jí)修改bug。
• b、開發(fā)打包提測(cè)前必須充分自測(cè)，驗(yàn)證所有bug，確保老bug改完、無衍生出的新bug。如測(cè)試人員驗(yàn)證下來bugfix失敗率>＝30%可直接打回。
• c、開發(fā)打包節(jié)奏，常規(guī)：一天打包一次，如一天內(nèi)所有bug都改完，改完就打包體測(cè)；如有特殊情況，由測(cè)試決定開發(fā)的打包節(jié)奏。

2、外包合同中規(guī)定測(cè)試輪數(shù)

根據(jù)1的打回機(jī)制，從測(cè)試輪數(shù)（5輪）和時(shí)間（規(guī)定的項(xiàng)目總時(shí)間）上制約外包。

3、規(guī)范代碼review機(jī)制

階段性的review外包代碼，如果老代碼不符合要求，預(yù)估時(shí)間和優(yōu)先級(jí)，根據(jù)緊急程度在開發(fā)中或后期維護(hù)期里修改掉。

4、規(guī)范產(chǎn)品需求

在PRD的story下面添加功能邏輯關(guān)系圖，以便其他人員更好理解需求

外包方面：

1、加強(qiáng)自測(cè)（配合我司的測(cè)試準(zhǔn)入標(biāo)準(zhǔn)）

根據(jù)測(cè)試用例，加強(qiáng)自測(cè)減少打回和項(xiàng)目延期的風(fēng)險(xiǎn)。

2、規(guī)范外包響應(yīng)機(jī)制

1. 迭代開始，外包側(cè)需要讓兩端的實(shí)際開發(fā)人員到場(chǎng)；
2. 代碼審核、緊急bug修復(fù)等關(guān)鍵時(shí)間節(jié)點(diǎn)，需要開發(fā)人員到場(chǎng)。（預(yù)計(jì)：2-3天）

3.加強(qiáng)溝通

避免出現(xiàn)安卓、iOS兩端對(duì)需求理解不一致的情況

五、溝通真的很重要

無論是PRD，還是項(xiàng)目節(jié)點(diǎn)；無論是代碼review，還是功能測(cè)試；都只是保障項(xiàng)目順利開展，如期上線的手段。最重要的還是項(xiàng)目人員的相互協(xié)作，溝通在這里至關(guān)重要。

我的項(xiàng)目曾出現(xiàn)過同一個(gè)需求和交互視覺，安卓和iOS做出了完全不同的功能。當(dāng)時(shí)有好幾個(gè)疑問飄在腦海里：

1. 需求是否不夠明確，以致開發(fā)同學(xué)理解有偏差；
2. 需求評(píng)審會(huì)是不是不夠細(xì)致，遺漏了這塊；
3. 開發(fā)同學(xué)是不是過于內(nèi)向，有疑問時(shí)不敢找我溝通；
4. 開發(fā)同學(xué)之間是不是也缺少交流，兩端各做各的。

幾個(gè)疑問都直指一個(gè)方向——缺少溝通，開發(fā)之間缺少溝通，開發(fā)和產(chǎn)品之間缺少溝通，開發(fā)和交互之間缺少溝通！

如果對(duì)需求有疑問，過程中應(yīng)該及時(shí)提出，需求評(píng)審時(shí)應(yīng)提出，兩端同學(xué)交流時(shí)更應(yīng)該提出，可是他們都沒有來找我，而我也理所應(yīng)該的以為他們理解了，會(huì)嚴(yán)格按照需求和交互實(shí)現(xiàn)。如果我在過程中主動(dòng)對(duì)容易產(chǎn)生疑問的點(diǎn)進(jìn)行溝通確認(rèn)，也能避免這個(gè)問題。可是我們都沒有！

上面僅是缺乏溝通導(dǎo)致的一個(gè)案例，類似的問題還有太多太多。各位同仁，關(guān)于產(chǎn)品經(jīng)理最核心競(jìng)爭(zhēng)力有太多討論，我這里也不妄下結(jié)論，但是溝通一定是非常重要的！

愿大家都成為一個(gè)能溝通，會(huì)溝通，善溝通的產(chǎn)品經(jīng)理！

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