【流程】外包产品经理的自我修养——甲方爸爸篇

编辑导语：产品经理在面对外包项目时，需要注意一些容易踩坑的操作，对于项目的需求都需要不断地进行调研确认，确保在进行外包对接的时候可以顺利进行；本文作者分享了关于自己在外包中的一些经验，我们一起来了解一下。

最近半年在疯狂对接外包公司，做了2次乙方、3次甲方在这半年的过程中，筛选了数十个外包，反复沟通无数次，埋过坑也填过坑，希望自己的经验能帮到在产品路上摸爬滚打的你。

不论是外包还是自己公司实现项目都离不开需求确定、研发测试、项目验收。

相较于常规项目外包项目增加了与外包对接的环节，项目管理的流程一般分为四步：前期准备、外包筛选、研发测试、项目验收。

• 前期准备：前期准备主要是在公司内部，是需求确认的一个过程。主要流程为需求调研→需求分析→原型设计→需求完善->内部评审->需求确认。
• 外包筛选：外包筛选是筛选外包、反复沟通、明确需求的过程，主要流程为外包初筛→需求沟通→疑问梳理→确定需求→价格和工期确定→合同签订→进入开发（UI设计、产品开发）。
• 研发测试：研发测试的工作主要在外包公司。
• 项目验收：项目验收是对成品最终把握的节点。主要流程为：培训→项目验收→文档/代码交接→尾款。

一、前期准备

前期准备主要是在公司内部，是需求确认的一个过程。主要流程为需求调研→需求分析→原型设计→需求完善->内部评审->需求确认。

而这一套流程与公司需求评审流程一致，具体流程再次就不再赘述，在此只对产出物进行介绍。

1. 系统语言/框架

针对外包系统因为不同的公司的能力和代码不同，所以对方提供的语言/框架也是不相同的。作为甲方需要根据自身需要提前考虑语言和框架。

考虑语言是否可维护、考虑框架的兼容性。但是这一块内容也可以让外包推荐，不过公司内部可以有一个预方案。

如公司仅有Java程序员，则可以要求甲方使用Java语言进行相关内容的编辑。

如公司常用layui框架，则要求外包使用该框架减少对接难度和后期维护人力成本。

如公司对产品语言要求不高，只对价钱和工期敏感，可由乙方推荐语言，如PHP语言等（一般Java工期长花费多，PHP工期短，工期又决定了价格等）。

2. 产品相关文档

1）业务流程图

在与第三方对接时，需要描述一下自家产品的使用场景和业务流程，而一份完善的业务流程图是最为高效的对接方式。

业务流程图比单纯的文字要清晰，比语音更容易留存，可以极大的减少与甲方反复沟通的过程。

2）页面流程图

页面流程图主要是介绍一下页面跳转逻辑，通过业务流程图可以提前明确有多少个页面，有多少个功能点。

通过页面流转图，在与外包对接工时等内容时更有话语权。

3）详细需求文档

详（一）细（份）的需求文档是良好的背书的内容，而且一份需求文档决定了沟通时的反复次数与乙方交付产品的好坏。

3. 工作量评估表

工作量评估表是由内部人员对需求评估的结果。

在与乙方的沟通时，可以更加容易评估对方的工期与价钱是否合理，是否可以按时交付等。

二、外包筛选

外包筛选是筛选外包、反复沟通、明确需求的过程，主要流程为外包初筛→需求沟通→疑问梳理→确定需求→价格和工期确定→合同签订→进入开发（UI设计、产品开发）。

而在这一套流程中，筛选外包到价格和工期确定是一个反复的过程，在时间充裕或者没有固定外包的情况下，反复筛选和确认是必不可少的流程。

1. 外包初筛

外包初筛实际上是简版的竞品分析的过程，通过简单的查看外包的资历和服务，排除明显不符合预期的外包，再联系外包初步沟通的过程。

注：初筛主要是对明显不符合需求的外包公司排除，同时也是了解己方需要产品在外包行业的行情。

而外包初筛可以通过查看外包的资质和历史案例来确认外包是否符合预期，以减少反复沟通的次数。

2. 需求沟通

需求沟通时前期准备的内容尤为重要，前期准备有完备的资料可以极大减少沟通成本。

1）项目简介

在与外包的初次沟通中不可能说是一个个功能细节去对。作为甲方爸爸可以提前考虑已经有了什么功能、有了什么业务，仍需要什么功能，需要什么服务，业务流程流转是怎么样的。

而甲方爸爸可将自己准备内容，编辑成简短的文字供乙方初步了解，让乙方对自己的内容有预期，同时也可避免自己介绍功能点有遗漏。

备注：过于详细的需求文档**让对方把握不到重点，在前期需求沟通的时候可以先讲明白需求的大概，保证乙方明白需求内容的大概之后再给予详细的需求文档让对方根据需求评估工时和价格。

2）业务流程图+页面原型图

业务流程图和页面原型图可以在与外包沟通开始就给予外包，让外包更易理解需求和功能。

3. 疑问梳理、确定需求

疑问梳理和确认需求是同一步流程，在外包初步了解需求后，可以沟通详细需求内容、解决乙方疑惑、确认最终需求范围、确认需求优先级和项目进展。

注：必要时可以和外包一点点讲解需求，保证需求的沟通无误。

4. 价格和工期确定、合同签订

需求确定之后，对方**根据需求内容在内部评估工期和价格，甲方爸爸可以根据自己内部的工期表做一个比对，在多次对比确认乙方之后可以签订合同。

5. 补充

在疑问梳理、确定需求时不仅是乙方在提问题，甲方也可以针对一些资历、工期等内容进行提问。

特别是需要乙方研发一整套系统、使用乙方SASS系统时，可以通过试用乙方产品来了解乙方的真正实力。而在试用过程中若出现疑问，也可尽早提出和沟通避免签订合同后出现不可预期问题。

不论是外包还是自己公司实现项目都离不开需求确定、研发测试、项目验收。

相较于常规项目外包项目增加了与外包对接的环节，项目管理的流程一般分为四步：前期准备、外包筛选、研发测试、项目验收。

1. 前期准备：前期准备主要是在公司内部，是需求确认的一个过程。主要流程为需求调研→需求分析→原型设计→需求完善->内部评审->需求确认。
2. 外包筛选：外包筛选是筛选外包、反复沟通、明确需求的过程，主要流程为外包初筛→需求沟通→疑问梳理→确定需求→价格和工期确定→合同签订→进入开发（UI设计、产品开发）。
3. 研发测试：研发测试的工作主要在外包公司。
4. 项目验收：项目验收是对成品最终把握的节点。主要流程为：培训→项目验收→文档/代码交接→尾款。

三、研发测试

研发测试的工作主要在外包公司，甲方能参与的有项目跟进、问题解决、需求确认等。

而问题解决和需求确认都是乙方提出问题、甲方确认。

真正需要甲方主动参与的工作就是项目跟进，项目跟进的常见两个办法是分步验收和内容同步。

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协议