起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識【流程】外包產品經理的自我修養——甲方爸爸篇
編輯導語：產品經理在面對外包項目時，需要注意一些容易踩坑的操作，對于項目的需求都需要不斷地進行調研確認，確保在進行外包對接的時候可以順利進行；本文作者分享了關于自己在外包中的一些經驗，我們一起來了解一下。
最近半年在瘋狂對接外包公司，做了2次乙方、3次甲方在這半年的過程中，篩選了數十個外包，反復溝通無數次，埋過坑也填過坑，希望自己的經驗能幫到在產品路上摸爬滾打的你。
不論是外包還是自己公司實現項目都離不開需求確定、研發測試、項目驗收。
相較于常規項目外包項目增加了與外包對接的環節，項目管理的流程一般分為四步：前期準備、外包篩選、研發測試、項目驗收。
- 前期準備：前期準備主要是在公司內部，是需求確認的一個過程。主要流程為需求調研→需求分析→原型設計→需求完善->內部評審->需求確認。
- 外包篩選：外包篩選是篩選外包、反復溝通、明確需求的過程，主要流程為外包初篩→需求溝通→疑問梳理→確定需求→價格和工期確定→合同簽訂→進入開發（UI設計、產品開發）。
- 研發測試：研發測試的工作主要在外包公司。
- 項目驗收：項目驗收是對成品最終把握的節點。主要流程為：培訓→項目驗收→文檔/代碼交接→尾款。
一、前期準備
前期準備主要是在公司內部，是需求確認的一個過程。主要流程為需求調研→需求分析→原型設計→需求完善->內部評審->需求確認。
而這一套流程與公司需求評審流程一致，具體流程再次就不再贅述，在此只對產出物進行介紹。
1. 系統語言/框架
針對外包系統因為不同的公司的能力和代碼不同，所以對方提供的語言/框架也是不相同的。作為甲方需要根據自身需要提前考慮語言和框架。
考慮語言是否可維護、考慮框架的兼容性。但是這一塊內容也可以讓外包推薦，不過公司內部可以有一個預方案。
如公司僅有Java程序員，則可以要求甲方使用Java語言進行相關內容的編輯。
如公司常用layui框架，則要求外包使用該框架減少對接難度和后期維護人力成本。
如公司對產品語言要求不高，只對價錢和工期敏感，可由乙方推薦語言，如PHP語言等（一般Java工期長花費多，PHP工期短，工期又決定了價格等）。
2. 產品相關文檔
1）業務流程圖
在與第三方對接時，需要描述一下自家產品的使用場景和業務流程，而一份完善的業務流程圖是最為高效的對接方式。
業務流程圖比單純的文字要清晰，比語音更容易留存，可以極大的減少與甲方反復溝通的過程。
2）頁面流程圖
頁面流程圖主要是介紹一下頁面跳轉邏輯，通過業務流程圖可以提前明確有多少個頁面，有多少個功能點。
通過頁面流轉圖，在與外包對接工時等內容時更有話語權。
3）詳細需求文檔
詳（一）細（份）的需求文檔是良好的背書的內容，而且一份需求文檔決定了溝通時的反復次數與乙方交付產品的好壞。
3. 工作量評估表
工作量評估表是由內部人員對需求評估的結果。
在與乙方的溝通時，可以更加容易評估對方的工期與價錢是否合理，是否可以按時交付等。
二、外包篩選
外包篩選是篩選外包、反復溝通、明確需求的過程，主要流程為外包初篩→需求溝通→疑問梳理→確定需求→價格和工期確定→合同簽訂→進入開發（UI設計、產品開發）。
而在這一套流程中，篩選外包到價格和工期確定是一個反復的過程，在時間充?；蛘邲]有固定外包的情況下，反復篩選和確認是必不可少的流程。
1. 外包初篩
外包初篩實際上是簡版的競品分析的過程，通過簡單的查看外包的資歷和服務，排除明顯不符合預期的外包，再聯系外包初步溝通的過程。
注：初篩主要是對明顯不符合需求的外包公司排除，同時也是了解己方需要產品在外包行業的行情。
而外包初篩可以通過查看外包的資質和歷史案例來確認外包是否符合預期，以減少反復溝通的次數。
2. 需求溝通
需求溝通時前期準備的內容尤為重要，前期準備有完備的資料可以極大減少溝通成本。
1）項目簡介
在與外包的初次溝通中不可能說是一個個功能細節去對。作為甲方爸爸可以提前考慮已經有了什么功能、有了什么業務，仍需要什么功能，需要什么服務，業務流程流轉是怎么樣的。
而甲方爸爸可將自己準備內容，編輯成簡短的文字供乙方初步了解，讓乙方對自己的內容有預期，同時也可避免自己介紹功能點有遺漏。
備注：過于詳細的需求文檔會讓對方把握不到重點，在前期需求溝通的時候可以先講明白需求的大概，保證乙方明白需求內容的大概之后再給予詳細的需求文檔讓對方根據需求評估工時和價格。
2）業務流程圖+頁面原型圖
業務流程圖和頁面原型圖可以在與外包溝通開始就給予外包，讓外包更易理解需求和功能。
3. 疑問梳理、確定需求
疑問梳理和確認需求是同一步流程，在外包初步了解需求后，可以溝通詳細需求內容、解決乙方疑惑、確認最終需求范圍、確認需求優先級和項目進展。
注：必要時可以和外包一點點講解需求，保證需求的溝通無誤。
4. 價格和工期確定、合同簽訂
需求確定之后，對方會根據需求內容在內部評估工期和價格，甲方爸爸可以根據自己內部的工期表做一個比對，在多次對比確認乙方之后可以簽訂合同。
5. 補充
在疑問梳理、確定需求時不僅是乙方在提問題，甲方也可以針對一些資歷、工期等內容進行提問。
特別是需要乙方研發一整套系統、使用乙方SASS系統時，可以通過試用乙方產品來了解乙方的真正實力。而在試用過程中若出現疑問，也可盡早提出和溝通避免簽訂合同后出現不可預期問題。
不論是外包還是自己公司實現項目都離不開需求確定、研發測試、項目驗收。
相較于常規項目外包項目增加了與外包對接的環節，項目管理的流程一般分為四步：前期準備、外包篩選、研發測試、項目驗收。
- 前期準備：前期準備主要是在公司內部，是需求確認的一個過程。主要流程為需求調研→需求分析→原型設計→需求完善->內部評審->需求確認。
- 外包篩選：外包篩選是篩選外包、反復溝通、明確需求的過程，主要流程為外包初篩→需求溝通→疑問梳理→確定需求→價格和工期確定→合同簽訂→進入開發（UI設計、產品開發）。
- 研發測試：研發測試的工作主要在外包公司。
- 項目驗收：項目驗收是對成品最終把握的節點。主要流程為：培訓→項目驗收→文檔/代碼交接→尾款。
三、研發測試
研發測試的工作主要在外包公司，甲方能參與的有項目跟進、問題解決、需求確認等。
而問題解決和需求確認都是乙方提出問題、甲方確認。
真正需要甲方主動參與的工作就是項目跟進，項目跟進的常見兩個辦法是分步驗收和內容同步。
1. 分步驗收
針對外包項目，最常見的問題就是項目拖期，因為前期工作量評估有誤、需求變更、交付質量不過關等問題，在外包項目中很容易出現項目延期交付的情況。而避免項目延期交付的方法之一就是分布驗收。
1）驗收方法
驗收方法主要有兩個方法：
方法一是項目拆分，將項目拆分成多個里程碑的模塊，每一個模塊有自己的驗收時間，在規定時間對模塊進行驗收，通過保證每個模塊的研發時間和質量都符合預期來保證最終產品符合預期。
方法二是提前查驗，針對沒辦法拆分模塊的項目，且乙方未同步進度，在項目進展2/3和研發結束測試前兩個時間節點對項目進行提前查驗來保證最終產品符合預期。
2）驗收方式
針對不同的驗收方法有不同的驗收方式：
針對項目拆分項目，可以在驗收前幾天和對方確認驗收時間與內容，到約定日期時根據里程碑節點進行驗收。
針對無法拆分的項目，在項目初期主動詢問對方需求有什么疑問，有沒有什么技術難點。在項目中期做好查驗的準備和信息同步，同時確保問題的及時同步。在項目后期針對需求細節，明確驗收細節。
3）優點
分布驗收主要有三個優點：
- 風險前置：通過項目驗收節點前置，將風險前置，既可以保證項目準時驗收，又可保證項目的質量。
- 功能一致：再完善的需求文檔和溝通都無法避免實現和需求不一致的情況，通過分布驗收，可以將不一致的內容及時修復，保證最終產品和需求的一致性。
- 提前施壓：作為一個項目團隊很容易出現前期松、后期緊的情況，通過分布驗收將后期緊時間提前，預留出更加充足時間解決不可知問題。
2. 進度同步
乙方內部也會有相應的項目進度文檔，通過每周或每雙周同步一次進度的形式查驗乙方的進度完成情況。
進度同步和分布驗收的區別時進度全部由乙方把握，甲方只需要在固定節點同步一下乙方的進度，判斷一下和預估進度是否有過大偏差或嚴重延期的情況。
四、項目驗收
項目驗收是對最終成品把握的最終流程，也是保證產品質量，保證設計達到預期的最后保障。
主要流程為：培訓→項目驗收→文檔/代碼交接→尾款。
1. 培訓
若是購買了乙方的一套系統，或甲方未提供詳細的需求文檔，可以要求乙方對系統的內容進行簡單培訓和講解。
通過培訓可以減少交接內容理解成本，同時根據對方描述可以有一個驗收前的溝通。
注：也有可能發現乙方待實現或者實現有問題的地方。
2. 項目驗收
項目驗收時需要根據最終驗收內容進行不同的驗收，而根據前期溝通的內容
1）源代碼驗收
如果需要交付源碼則需要研發對代碼質量、邏輯、語言等進行驗收。
2）功能驗收
功能驗收是測試和產品都參與的過程。產品在拿到外包交付內容時會進行準入驗收，查驗一下乙方產品是否達到測試標準，在準入驗收通過后由測試介入。
測試對功能點和性能進行驗收，具體的流程和內容與內部測試一致，在此就不單獨贅述了。
在測試通過后，如果時間允許還可進行一個最終驗收，以用戶的角度去驗收。
3. 文檔/代碼交接（項目交付）
文檔/代碼交接（項目交付）的內容理論上是在項目初期就定好的內容，這一部分內容每個公司要求不一樣，每一次和外包溝通之后的驗收內容不一樣，在此小正就列出部分關鍵文檔。
1）需求列表及變更記錄
在與外包交接時會提供需求文檔，而在實際開發中會因為甲方和乙方的原因導致需求變更，從而導致需求和最后不一致。
而甲方和乙方理應記錄每一次變更內容，這樣可以減少最后的battle環境。
2）代碼交接
代碼交接的內容包含：編碼規范與數據庫設計規范、代碼文件架構說明書、數據庫設計說明書、接口設計說明書、數據庫、源代碼等內容。
通過交接代碼相關文件和代碼可供甲方留檔和二次開發使用。
注：代碼架構和源代碼很重要，一個外包項目有代碼和無代碼的價錢相差很多，而代碼質量的好壞決定了后期的維護容易程度，也決定了這部分錢到底值不值。
小正曾遇到過代碼不過關導致后期內部無法維護、整體廢棄做的項目，也遇到過數據庫設計不合理且缺失相關文檔導致歷史數據難以遷移的項目。而每一次遇到這些項目都是淚兩行。
3）測試用例及執行結果（測試報告）
已經交付的項目在對方內部肯定已進行過內部測試，而對方測試的測試用例及執行結果（測試報告）可以供內部驗收測試時參考和檢驗完整性。
4）BUG管理記錄與追蹤
這個內容可提供可不提供，如果有可做歸檔用，不做強要求。
5）使用部署說明
使用部署說明是針對一套單獨系統提供的內容，針對需要遷移和反復使用的系統可提供使用部署說明，便于二次遷移使用。
6）系統操作手冊與培訓手冊
系統操作手冊和培訓手冊一般和培訓掛鉤，是培訓時對方交付的相關文檔，供己方業務人員或技術支持使用/部署時使用。
4. 尾款交接
在所有的內容均驗收交際之后便可以跟對方結尾款。
5. 補充
上文的項目驗收是只列出了部分內容，而整體的項目驗收還可以分類的方式介紹。
1）驗收方式
- 交付型驗收：將系統/軟件部署完成，并完成調試和上線。
- 功能型驗收：業務驗收人員根據需求明細列表實現情況進行驗收評價，研發驗收人員根據以下內容進行驗收評價。使用人員經過培訓后熟練使用軟件并已解決前期使用相關問題。
2）文檔驗收
- 文檔齊全：前期溝通或后期要求的文檔對方已全部提供。
- 文檔準確：文檔內容描述準確，無缺少內容或錯誤內容。
3）功能驗收
- 功能：根據功能列表驗收相關內容，如接口、頁面、數據庫等。
- 測試用例：乙方集成測試的測試用例和測試結果。
- 性能：乙方提供性能測試報告，并達到相關預期。
4）用戶驗收
用戶驗收是指以用戶的角度去驗收系統，從用戶使用，用戶操作，實際數據接入等方面進行驗收。
5）安全驗收
- 安全性過關：軟件安全性符合相關規定。
- 日志保存：軟件有運行日志和操作日志。
五、其他
1. 風險
項目外包的風險是不可避免的，前期反復溝通（溝通清楚需求等內容），中期項目跟蹤（分布驗收等），后期仔細驗收（內容完備且符合預期）可以極大的減少風險的發生。
同時這些操作也可為一些不可預估的風險做好防范如：甲方內部需求反復變更、乙方進度異常緩慢等。
2. 實際操作
在本文中列出的內容是一個比較規范化的流程，在某些時候可能因為項目著急上線或者實際需求不明確，有一些步驟省略或者埋坑。
但是不論什么樣的步驟歸根到底還是想要一份符合預期的預期軟件/系統
3. 感觸
自己總結了外包產品的流程和自己公司內部的流程，發現流程實際上是一樣的。但是在細節上的差別影響了最終的成品，其中最影響的是：外包篩選、需求對接、需求文檔、項目管理。
1）外包篩選
公司內部的團隊基本上是固定的，技術是固定，外包團隊的不熟悉且可挑選，導致了很多不可控的因素，而在和外包對接過程中產品經理是出和入的一環，所以更多的考慮，更細致的出和入可以避免后期很多問題
2）需求對接
在外包篩選提前對接時，可以通過大量的內容來減少溝通成本。
3）需求文檔
需求文檔理論上內部和外部的要求是一樣的，但是小正在對接時遇到一個問題就是公司內部有現成工具和規范，自己寫需求文檔就直接寫使用XXX工具實現，然后給外包之后就出現了外包按他的思路開發，導致貨不對板的情況。
而與外包對接需求文檔時盡可能詳細，且如果使用內部內容，需要將內部內容描述清楚或額外提供相關文檔。
4）項目管理
外包項目項目管理和內部項目管理是相似的，但其中最主要也最影響成品的部分是在外包公司是黑盒的，此時就需要格外注意項目進展，保證項目正常延期；而公司內部人員熟悉，所以進度把握更容易。
本文由 @文靜的小正 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
很使用的文章，解決了我的燃眉之急，謝謝樓主分享;-)
很實用