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

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

老大，我缺開發。

找外包。

老大，我缺測試。

自己頂上。

老大，我缺視覺。

協調資源。

老大，我缺項管。

一陣可怕的安靜之后，老大笑著對我說“產品經理是什么？產品經理就是發現問題，解決問題。優秀的產品經理必須在缺少測試、設計、項管情況下自己承擔起來?！?/p>

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

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

一、需求層面

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

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

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

二、進度層面

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

可是僅有deadline也是不夠的，畢竟功能的開發存在不確定性，聯調時間、測試時間、debug時間無法保障，如果僅有deadline，很容易將全部風險往后堆積，最后的結果只能是項目延期，產品經理被批！

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

三、質量層面

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

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

要保證質量，首先是開發的自測。當然如果你是技術大牛，對自己寫的代碼極其有自信，不自測也罷。可是大多數外包人員水平其實并沒有那么高，那么自測是必要的，自測階段可以發現不少問題，至少避免出現功能未實現便提測的情況。

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

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

四、規范層面

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

內部方面：

1、規范測試準入標準

（1）階段性功能提測：確保基本業務流程走通才能提測；

（2）bugfix：

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

2、外包合同中規定測試輪數

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

3、規范代碼review機制

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

4、規范產品需求

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

外包方面：

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

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

2、規范外包響應機制

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

3.加強溝通

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

五、溝通真的很重要

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

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

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

幾個疑問都直指一個方向——缺少溝通，開發之間缺少溝通，開發和產品之間缺少溝通，開發和交互之間缺少溝通！

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

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

愿大家都成為一個能溝通，會溝通，善溝通的產品經理！

本文由 @edgar1990 原創發布于人人都是產品經理?，未經許可，禁止轉載。