如果要开发一套和第三方公司进行联动的系统，那么应该在什么时间与对方开始联调呢？
功能开发完成50%?
75%?
还是100%完成后立马开始呢？
（我认为）答案应该是，在功能开发之前，应该和开发同等优先的并行。接口设计完成后，就应该开始制造模拟功能的demo，和第三方尝试对接。
开发人员经常会天然的把“技术含量最高”的开发工作作为最优先的部分，迫不及待的投入到编码中。“等我先扣完，等我扣的差不多再说”，这样的回答，常用来应对产品经理和项目经理的询问。这样是不对的，为什么呢？
这就涉及到项目管理知识中的两个很重要的概念：
风险
沟通
在软件开发领域，除了少数高精尖的科研项目如火箭制导、云计算基础平台服务，少数性能要求史无前例的项目如双十一秒杀，大多数项目并不存在特别高的技术难度。
大多数情况下，都是难者不会，会者不难。
团队成员有同类开发项目经验，或者善于利用互联网工具进行调研，大多数技术问题或架构问题并不难解决。特别是在现在开源框架和开源中间件极大丰富的时代，软件开发或者互联网开发，并不是什么了不得的高端科学（Science），基本上还属于工程学（Engineering）的范畴。
因此，如果是熟悉的团队，对团队成员的能力有所了解，单纯的技术风险相对而言是很小的。但是如果有和第三方的协作，则需要打起十二分精神提高警惕。为什么呢？
系统间的风险，天然的大于系统内的风险。
这里的系统间和系统内，是一个相对的概念。
- 如果一个人是系统，则需要成员与成员之间协作才能完成的项目的风险，高于一个人就能独立完成的项目；
- 如果把一个团队看作一个系统，则需要团队合作的项目，无疑难度和风险更大；
- 如果把一套软件产品看作一个系统，那么需要和其他异构软件进行数据互换的情况其风险更高。
简单来说，需要更多沟通的地方，就是更易于发生风险的地方。
西语有云，他人即地狱。这句话含义很多，在这里可以理解为，不能将自己的判断，建立在对他人的无条件信任的基础上。中国谚语说的更通俗易懂：三个和尚没水吃。
如果所开发之产品，需要和第三方进行联调，则可能遇到下列的这种情况：
- 对方接口根本没有技术文档，对接时才发现，什么都要一点一点问；
- 对方提供了技术文档，但是有错或者版本太旧，误导了你，最后测试才发现；
- 对方技术文档没问题，但是你的业务需求，恰好触发了对方系统的某个问题，对方需要很久才能解决；
- 对方公司对你这个项目的优先级设得很低的，指派的对接人员很不好说话，完全不顾你的死活。
稍作推论可知，第三方的风险主要来自于不可知：不知对方的人，不知对方的事。因此解决这个问题的方法很简单，就是“尽量早，尽量深入的和对方进行沟通”，通过沟通，尽早识别对方的人员水平和态度，识别对方的文档和产品质量，有针对性的及早采取对策。
早期进行demo联调，不但可以尽早验证对方的产品，还可以尽早建立和对方人员的联系，判断对方人员的水平和态度。
将风险及早识别，尽快想办法克服，叫做风险前置。如果项目前期假定“这是一个可以完全信任的第三方”，导致项目后期的返工延期，项目负责人是万万不能抱屈“都是xxx导致的延期”的，这代表项目负责人缺乏风险意识，项目经验不足，这样说，上级对其能力水平，难免要打个问号。
大型的，需要多个组织协作的项目，是最危险的，所以会有一些耗时数十年，耗资几十亿的大型企业系统或者银行项目失败的案例。
大型企业系统和银行业务是最典型的增删改查系统，数据量级虽然大一些，但是在当前的软硬件基础下，并不是不可逾越的难关，但是，这种项目可能牵扯到数以千计的银行分行，异地分公司，数十年来积攒的各种异构系统和数据，上百业务部门的不同需求，数十家层层转包分包的项目开发实施公司。
- 不同的组织对项目重要性认识不一致，配合力度不同；
- 不同业务部门的人员能力不一，难以准确表达需求，或者由于自身利益对项目本身有抵制情绪；
- 各种历史系统不但没有技术文档而且技术古老或者代码质量惨不忍睹；
- 开发承包商聘用大批临时工冒充高级工程师
...等等，对于有经验的项目负责人，这些都是可以预见到的并且几乎肯定会发生的风险。但是由于种种原因，这样的大型项目，并不是肯定能指派到合格的项目负责人，或者负责人没有得到过充分授权，不得不带着镣铐跳舞。
一步棋可以暴露棋手的水平；开发进度安排中对风险的预判和对策，也可以体现项目负责人的能力和经验。如果计划中对于第三方这种常见风险的考虑毫无体现，这位项目负责人若不是天生乐观派，就是新手了。对于真正的新晋项目负责人，不可不察。
ps：
PMP培训中有一道经典的问题：项目经理工作中，沟通的占比是多少？
不是三分之一，也不是一半，是80%。
原文链接