在互联网行业的项目管理中，项目经理们面对的通常是多条业务线并行的项目集。因为资源共享，业务依赖等原因，多线并行、相互影响造成事故的现象普遍存在，是必须要防范的深层次风险（下文简称“多线风险”）。多线风险如果控制不当，一条业务线上出现问题，则可能影响到整个业务的进行。下文是对于“多线风险”控制话题的讨论。

初识，多线风险危害

多线风险，可能给团队带来多种问题：

（1）延期问题

首先，多线会使得不确定因素增多，不仅要考虑业务线本身的不确定性，还要考虑相关依赖业务线的不确定性，以及共享资源的不确定性，一个不确定点控制不当就可能造成业务目标延期。

其次，一条线出现延期，可能会引发连锁反应，造成所有依赖业务线延期，从而造成大量延期情况。

（2）资源冲突问题

多条线同时进行，都需要资源的投入，而在一段时期内，团队的资源是极其有限的，易引发各线的资源争夺形成内耗。团队的部分人也无法避免要应对来源于多条业务线的工作，多条业务线间的切换也会造成额外的成本，加剧资源的紧张情况。

（3）沟通问题

首先，人在多线间切换，信息来源就会复杂，加上信息传递过程中的失真，可能不同渠道来的信息之间就是相互冲突的。比如：一个外出参加展会的目标，开发从产品团队得到的需求是在时间点前上线功能，而从内容制作团队得到的信息是要制作一个精良的Demo向客户展示。

而实际上参展目标是要让参会者体验该新功能，功能要上线，也要有能展示的体验内容，来源于两条线的需求既相互联系——都是为了参展，又相互排斥——时间点前不允许同时完成上线和精品内容。

再次，因同一人要同时完成功能和内容两个目标，该人就成了产品和内容需要争夺的资源，为保证质量和效果，一起协商是难免的，无形中增加了沟通的成本。而且不管最后如何确定，对两条线原本的目标或多或少都是打了折扣，严重的就可能影响到原先的业务规划。

（4）团队成长

以上问题如果长期发生，必然会阻碍团队的发展。比如：频繁延期，会不断降低团队的工作完成承诺度，成员对完成工作愈发没有信心，士气持续低落，出现不稳定情绪和离职，团队整体绩效可能不断恶化……资源争抢和沟通障碍，会增加完成工作的阻力。长此以往，团队中将会弥漫无力感，进而降低成员工作的主动性……

总的来说，这些问题如果长期存在，会使团队发展陷入恶性循环。

分析，寻找问题根源

多线风险的存在对于项目发展非常不利，我们需要通过现象定位问题，再找到问题根源，并分析可能引发风险的关键部分，然后针对性的地解决。

首先，需要识别出项目中存在多线并行的风险，其表现现象与上文提到的危害依存，以上提到的问题出现则可反推是否存在多线并行的风险，总结主要呈现如下特性：

1. 团队内存在多条目标独立的业务线在同时进行，且目标完成时间是受限制的；
2. 业务线间在逻辑上存在耦合，即存在一条业务线逻辑变动影响到另外一条业务线逻辑的情况；
3. 整体资源是有限的，即存在业务线间共享资源的情况，并且业务线发展会受到资源投入情况的影响。

当发现有这些多线相互影响的情况出现，我们可以从以下几个问题寻找问题的根源：

1. 业务目标是否聚焦，是否在同一时间想达成多个目标，而策略和资源跟不上；
2. 工作的优先级是否明确，是否在出现冲突时能快速决策，保证价值最大化；
3. 技术上，是否实现各模块“高内聚，低耦合”；
4. 人力资源是否匹配了业务发展需求，是否原本计划中的人员没有到位；
5. 组织结构是否清晰，人员权责利是否明确，每项工作的负责人是否确定；
6. 人员技能是否需要提升，人员能力是否能应对多种的需求。

解决，减小多线影响

通过分析，找到多线并行及相互影响的问题根源后，能根本上解决问题是最理想的结果。但是，实际情况中，往往很难定位问题根源，或者很难快速解决。这时需要平衡解决风险的成本和收益，选择合适的风险控制方法。

比如在迭代的各个阶段，可以实施如下一些风险控制方法：

（1）在需求分析阶段

需要判断产品给出的需求是否描述清晰，其他团队成员是否完全理解了需求意图，是否安排了需求澄清环节。再是，这些需求是否存在对其他工作的依赖，这些依赖如何处理，是否有明确的负责人和明确的交付时间？

为了控制这些问题的风险，PM需要在需求评审时，邀请所有干系人，特别是会相互影响业务线的负责人参会，逐一落实以上问题的风险控制措施。

（2）在设计阶段

包括交互、视觉和技术架构设计等，需要确认设计是否符合需求的目标，尽早识别设计和需求的不一致；再是，设计是否产生了新的依赖，是否有和其他线的参照依赖，或者技术上的数据依赖等。

（3）在排期阶段

需要考虑如何提升任务估算的准确性，准确识别出关键路径和各节点时间要求及缓冲配置；再是，考虑迭代内任务及资源的依赖关系，如任务是否有固定的前后置关系，人力资源是否存在冲突。排期是团队达成一致承诺的过程，排期结果需要同步到所有干系人，并取得一致同意。

（4）在研发阶段

鉴于多线情况下变更影响更加复杂，需要特别注意需求变更的发生，一旦发生需要考虑其对整体业务的影响，慎重执行变更和影响分析；再是，利用每日站会等形式，跟踪任务的进行状态，是否有新增、变更或评估偏差的任务被发现，及早识别可能造成影响的因素，减小控制成本。

（5）在测试、上线阶段

需要再次明确需要多线间的依赖，不仅要做某版本的测试，如果依赖较多，还需要增加对整个业务逻辑的测试；另外，上线前需要各方对结果进行确认，开发需要确认代码分支，产品需要确认完成结果，QA需要确认完成质量等。

除此之外，关系人管理需要贯彻始终——获取共识，同步风险，应急处理等；同时，不同角色的关系人间需要充分协作，各司其职：

1. Boss：应制定出清晰的业务规划，并向团队传达明确的期望，与团队充分协作为团队提供资源支持；而PM需要帮助Boss厘清未来众多业务线的发展规划，搭建沟通渠道，层层分解和传递团队目标，凝聚团队实现共同目标。
2. 需求方：根据目标制定产品RoadMap，明确各项工作优先级，并和团队就优先级达成共识；
3. 研发人员：负责工作包拆解、估算、技术设计和依赖分析，根据优先级实现需求；
4. 测试人员：测试工作与开发工作对齐，在多线环境下减少测试工作的拥堵，提升需求流动效率，减小需求从开发到上线的周期；
5. PM：管理各干系人期望，协调团队向共同目标努力，构建沟通渠道做到信息透明，及风险把控，变更管理等工作；
6. HR：掌握业务人力资源缺口，定义岗位职责，建立专业技能矩阵等。

作者：王游，网易杭研院项目管理部项目经理，PMP，曾任职于大型国企，现任网易AR项目经理，关注团队成长，致力于在新技术场景下的项目管理实践。

本文由 @网易杭研项目管理（微信公众号：NetEasePM） 原创发布于人人都是产品经理。未经许可，禁止转载。

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