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

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

找外包。

老大，我缺測試。

自己頂上。

老大，我缺視覺。

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

老大，我缺項管。

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

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

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

一、需求層面

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

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

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

二、進度層面

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

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

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

三、質(zhì)量層面

外包項目開發(fā)中最怕的不是進度，而是質(zhì)量。因為他們可能會早早的打包給你，可是你能測出100個bug。

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

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

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

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

四、規(guī)范層面

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

內(nèi)部方面：

1、規(guī)范測試準入標準

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

（2）bugfix：

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

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

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

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

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

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

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

外包方面：

1、加強自測（配合我司的測試準入標準）

根據(jù)測試用例，加強自測減少打回和項目延期的風險。

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

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

3.加強溝通

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

五、溝通真的很重要

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

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

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

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

如果對需求有疑問，過程中應(yīng)該及時提出，需求評審時應(yīng)提出，兩端同學交流時更應(yīng)該提出，可是他們都沒有來找我，而我也理所應(yīng)該的以為他們理解了，會嚴格按照需求和交互實現(xiàn)。如果我在過程中主動對容易產(chǎn)生疑問的點進行溝通確認，也能避免這個問題?？墒俏覀兌紱]有！

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

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

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