复盘总结：和外包开发对接的那些事儿

最近一年的工作，作为一个产品经理，前后共面向2个外包团队，经历了2个产品的5次对接、开发、测试、上线，每次项目周期为1~3个月。感触颇深，想记录一下这段时间的一些事情，对自己的工作进行复**总结，也给有需要的人参考。

在正式说明之前，先对所接触的外包团队进行简单的介绍：

基于公司的整体情况（严控成本，对项目周期没有严格的时间线），我们在选择外包团队时，启用了个人外包（不知道专业叫法，姑且这么称呼吧），每个团队都有独立注册的公司，但是同样也有自己的本职工作，完成我们的需求需要在本职工作之余进行。

所以本次的经验主要基于这类团队，如果大家选择非常有经验的全职外包团队，经历可能**有些许差别，仅供参考。

接下来将从以下五个方面进行说明：

1. 外包项目中产品经理的定位；
2. 项目流程；
3. 外包团队的选择；
4. 工作中出现的几个共性现象；
5. 几点反思和总结。

一、外包项目中产品经理的定位

一年的外包项目中，作为产品经理，除了要负责产品的相关工作，同样需要负责项目的管理工作。

当然，外包团队**有一个主要的项目负责人，而自己则需要结合自己公司、产品需求以及所选外包团队的情况进行整体的项目管理，这个的项目管理重在项目进度以及产品质量的把控。

二、项目流程

每一次的产品需求是在锁定外包团队前公司内部确定的，内部在需求确定（调研、分析、排期）→原型设计→内部评审之后，**开启和外包公司的对接。

和外包公司的对接主要流程为需求沟通→疑问梳理→确定需求→价格和工期确定→合同签订→进入开发（UI设计、产品开发）。

三、外包团队的选择

一年来，5次和外包团队对接，涉及两个产品，其中3次为同一个产品的需求迭代。

对于外包团队的选择，原则上主要遵循以下几点：

1. 外包团队的选择，第一匹配度当然是开发团队熟悉的业务领域和需求的业务匹配度，如果能够高度匹配，**大大降低沟通成本和技术实现成本；
2. 此外，同一个产品的优化迭代，**尽量选择同一个团队，可以大大降低沟通成本，尤其是业务性比较强的，**大大减少外包方对业务的熟悉时间。同一个时期，不同产品的需求，为了保证项目的顺利交付，尽量选择不同的团队；
3. 在保证质量的基础上尽量控制成本。每次定价基本都**经过2~3轮的反复（这个相信大家都懂）。在开发定价前，内部**根据市场情况对本次需求的开发工期进行基本的评估，当然，每次评估结果都比较保守，开发的价格**在内部评估的基础上上升30%左右。钱的问题，只要合理，且公司可以接受就是ok的。

四、对接过程中出现的共性现象

进入开发阶段，和外包的对接更多的在于以沟通为主的日常项目的跟进以及需求答疑，由于非全职外包，无法保证团队人员百分之百对项目用心，且把每一次沟通内容放在心上。

总结目前碰到的几个问题，主要表现在以下几点：

1. 沟通无效、需求的反复：不论是项目初期，还是项目过程中出现的问题，在达成一致后的一段时间，总是**不定时反复出现（开发提出）、需要反复沟通确定。
2. 实现效果达不到预期：即使前期需求沟通再明确，prd文档写的再详细，开发过程中总**因为各种原因出现不如预期的情况。没有经过系统的测试，交付物漏洞百出；改一处bug，衍生新的bug。
3. 沟通时间：由于所选团队均为有本职工作的个人外包，外包团队工作时间均需在自身本职工作之余，这样就要求产品经理需要时刻准备着随时解答开发团队的问题，开发凌晨工作，产品一样需要凌晨待命（当然，这个不一定是每个人都**遇到）。
4. 项目拖期：或因为前期工作量评估有误差，或因为技术难点，或因为需求变更，或因为交付质量不过关，不可避免出现项目拖期的情况（开发团队为了钱，只要有需求就敢接的情况比比皆是）。
5. 因各种问题带来的负面情绪。难免**因为工作方式的不一致、磨合不到位、沟通不及时等等问题带来情绪的不稳定，在自己做到位的情况下，发现对方团队还是漏洞百出，这就**给自身带来一定的负面情绪（尤其本人一年来面对的开发团队情况，本人除了日常工作外，需要在非工作时间随时待命，活脱脱一只产品加班狗）。

五、几点反思和总结

1. 保证自己的业务能力

同和公司内部团队的沟通相似，在和外包团队沟通的过程中，主要是围绕需求、原型、文档展开，同时包括开发进度跟踪，所以作为产品经理首先需要保证自己的业务能力，不偷懒、把自己的本职工作做到位，多次确认需求之后交付，尽量不在开发过程中完善需求。

2. 合理进行项目排期，明确截止日期

开发过程的进度排期和阶段性计划由外包团队负责，产品人员只需要明确截止日期即可，但是在截止日期之前做到什么程度尤为重要。这样，为了保证核心功能如期上线，对需求进行排期尤为重要。

（因为对接外包，很难做到小步快跑，公司不可避免想要一个大而全的产品，而为了钱只要有需求就接的团队到处都是，直接导致的结果就是时间和质量难以保证。在设计阶段可以尽可能设计全面，但是面对实际开发，一定要有无法如期完成全部需求的准备。）

3. 对外包团队的选择机制

前文有提到选择外包的几点原则，如果可以，一定要选择业务匹配度较高的团队，尤其是专业性较强的需求，可以大大降低沟通成本、提高开发效率。在初次接触的时候，可以通过团队历史项目成功来对其业务匹配度进行评判。

4. 明确沟通机制

由于无法驻场一起工作，在项目初期最好根据团队情况提前约定双方沟通机制。

目前我们的做法是由开发团队定期（每周一次）提交项目进度，以及对整体进度的影响；开发期间重要问题当面沟通解决，避免单独沟通（尽量在项目群说明）。

5. 开发过程中随时做好验收工作

如果开发团队足够靠谱，在提测之后做验收即可。

然而一年来碰到的两个开发团队，均无法保证开发质量，这样就要求我们在开发过程中及时做好分布验收工作。

验收的目的不是发现问题后及时改正（这样可能**影响整体进度），重要的是双方意识到问题所在，重大问题及时调整。

对产品经理而言重要的是主动，做法主要表现在以下几个方面：

1. 项目初期，日常主动询问对需求的理解，可以主动抛出问题，询问某处是否有疑问，适当诱导开发提前抛出问题。
2. 项目中期，尽量引导开发将开发好的页面发布，不定时查看，提前确定问题，但是这个时候尽可能非重大问题不干扰开发，因为并不完善，很有可能影响开发进度，当然重要的是影响开发人员的情绪。
3. 项目后期，明确进度，已完成功能逐步测试，汇总问题。验收阶段，明确提测和解决问题的机制，尽量保证所有问题有去有回不反复。

6. 尽量减少无效沟通

尽量保证每一次沟通都有结果呈现，如果问题依旧需要反复，请保持耐心。

所谓的沟通结果，最好是文档的形式，确保问题、可能有的解决方案、各种解决方式的优缺点、重要的是双方就最终选择的解决方案达成一致。

这个文档，重要的是给内部使用，为自己梳理，目的是在问题反复出现的时候自己心中有数，而非追究责任。

此外，关于功能无法实现的问题，我们的原则是保证核心功能、用户体验不大打折扣的前提下，尽量和开发沟通确认当前状态下最优的实现方式。

7. 风险前置

项目外包，以不影响上线使用为核心，从最开始就需要提前评估风险，做好风险前置的工作。

公司决定项目外包前，提前明确外包项目的风险，比如团队的不稳定性、质量无法完全保证、周期较长、上线时间难以精确等，做到自己心里有数的同时，也要让公司团队清楚。

需求排期阶段，制订开发计划预留一定时间。根据需求的大小，尽量保证预估开发的上线时间比公司内部需要的时间提前一段时间，项目越大，需要提前的时间越多。

进入开发阶段，通过和开发的日常沟通，需要随机应变，及时确定项目每个阶段的开发情况对项目上线的影响，非自己能够解决的问题，提前做好planB和公司领导沟通确定。

8. 做好项目收尾工作，产品上线≠项目结束

无法保证对业务的深入理解是外包团队的固有属性，除了上线前已知的问题之外，因为测试不够充分，难免**有其他隐藏的问题，所以在和开发拟定的合同中也都**有两个时期：试运行阶段（根据需求大小，通常在上线后10-30天）、项目维护阶段（通常在正式运行完成后1年内）。

除此之外，我们在上线之后就需要对产品尽可能的多操作，做更多的正常和异常操作，发现问题及时提出，评估影响范围、及时安排开发解决，尽量避免带着未知问题结束项目。

9. 其他知识储备

决定启用外包团队时，同时也就决定了内部可以配合的人员，如果没有懂开发的人员跟进，就要求产品经理对数据库设计及开发框架有一定的了解，如果悲催的碰到像我一样的团队，都需要开始学习服务器的基础知识，也真的是心力交瘁。

10 稳定情绪

这个是最重要也是最难的一点，有合作就**有不合。

我相信所有的负面情绪都来源于事物的发展偏离预期，期望越大失望也就越大。我们必须知道，所有的负面情绪，并不**推动事情的良性发展。

对此，我只想说：尽我所能，做最全的准备，做最坏的打算，尽量保证项目周期，做到问心无愧！

最后：第一次把自己的经历写下来，不论过程是怎样的，也算是有收获，然而如果可以选择，不想再经历。

本文由 @绿小豆 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。