在互联网行业的项目管理中，项目经理们面对的通常是多条业务线并行的项目集。因为资源共享，业务依赖等原因，多线并行、相互影响造成事故的现象普遍存在，是必须要防范的深层次风险（下文简称“多线风险”）。多线风险如果控制不当，一条业务线上出现问题，则可能影响到整个业务的进行。下文将记述杭研PM们对于“多线风险”控制话题的讨论。
初识，多线风险危害
多线风险，可能给团队带来多种问题。
一是延期问题
首先，多线会使得不确定因素增多，不仅要考虑业务线本身的不确定性，还要考虑相关依赖业务线的不确定性，以及共享资源的不确定性，一个不确定点控制不当就可能造成业务目标延期。其次，一条线出现延期，可能会引发连锁反应，造成所有依赖业务线延期，从而造成大量延期情况。
二是资源冲突问题
多条线同时进行，都需要资源的投入，而在一段时期内，团队的资源是极其有限的，易引发各线的资源争夺形成内耗；团队的部分人也无法避免要应对来源于多条业务线的工作，多条业务线间的切换也会造成额外的成本，加剧资源的紧张情况。
三是沟通问题
首先，人在多线间切换，信息来源就会复杂，加上信息传递过程中的失真，可能不同渠道来的信息之间就是相互冲突的。比如一个外出参加展会的目标，开发从产品团队得到的需求是在时间点前上线功能，而从内容制作团队得到的信息是要制作一个精良的Demo向客户展示。而实际上参展目标是要让参会者体验该新功能，功能要上线，也要有能展示的体验内容，来源于两条线的需求既相互联系——都是为了参展，又相互排斥——时间点前不允许同时完成上线和精品内容。再次，因同一人要同时完成功能和内容两个目标，该人就成了产品和内容需要争夺的资源，为保证质量和效果，一起协商是难免的，无形中增加了沟通的成本，而且不管最后如何确定，对两条线原本的目标或多或少都是打了折扣，严重的就可能影响到原先的业务规划。
四是团队成长
以上问题如果长期发生，必然会阻碍团队的发展。比如，频繁延期，会不断降低团队的工作完成承诺度，成员对完成工作愈发没有信心，士气持续低落，出现不稳定情绪和离职，团队整体绩效可能不断恶化……资源争抢和沟通障碍，会增加完成工作的阻力，长此以往，团队中将会弥漫无力感，进而降低成员工作的主动性……总的来说，这些问题如果长期存在，会使团队发展陷入恶性循环。
分析，寻找问题根源
多线风险的存在对于项目发展非常不利，我们需要通过现象定位问题，再找到问题根源，并分析可能引发风险的关键部分，然后针对性的地解决。首先，需要识别出项目中存在多线并行的风险，其表现现象与上文提到的危害依存，以上提到的问题出现则可反推是否存在多线并行的风险，总结主要呈现如下特性：
1.团队内存在多条目标独立的业务线在同时进行，且目标完成时间是受限制的；
2.业务线间在逻辑上存在耦合，即存在一条业务线逻辑变动影响到另外一条业务线逻辑的情况；
3.整体资源是有限的，即存在业务线间共享资源的情况，并且业务线发展会受到资源投入情况的影响；
当发现有这些多线相互影响的情况出现，我们可以从以下几个问题寻找问题的根源：
1.业务目标是否聚焦，是否在同一时间想达成多个目标，而策略和资源跟不上；
2.工作的优先级是否明确，是否在出现冲突时能快速决策，保证价值最大化；
3.技术上，是否实现各模块“高内聚，低耦合”；
4.人力资源是否匹配了业务发展需求，是否原本计划中的人员没有到位；
5.组织结构是否清晰，人员权责利是否明确，每项工作的负责人是否确定；
6. 人员技能是否需要提升，人员能力是否能应对多种的需求；
解决，减小多线影响
通过分析，找到多线并行及相互影响的问题根源后，能根本上解决问题是最理想的结果。但是，实际情况中，往往很难定位问题根源，或者很难快速解决。这时需要平衡解决风险的成本和收益，选择合适的风险控制方法，比如在迭代的各个阶段可以实施如下一些风险控制方法：
在需求分析阶段：
需要判断产品给出的需求是否描述清晰，其他团队成员是否完全理解了需求意图，是否安排了需求澄清环节。再是，这些需求是否存在对其他工作的依赖，这些依赖如何处理，是否有明确的负责人和明确的交付时间？为了控制这些问题的风险，PM需要在需求评审时，邀请所有干系人，特别是会相互影响业务线的负责人参会，逐一落实以上问题的风险控制措施。
在设计阶段：
包括交互、视觉和技术架构设计等，需要确认设计是否符合需求的目标，尽早识别设计和需求的不一致；再是，设计是否产生了新的依赖，是否有和其他线的参照依赖，或者技术上的数据依赖等。
在排期阶段：
需要考虑如何提升任务估算的准确性，准确识别出关键路径和各节点时间要求及缓冲配置；再是，考虑迭代内任务及资源的依赖关系，如任务是否有固定的前后置关系，人力资源是否存在冲突。排期是团队达成一致承诺的过程，排期结果需要同步到所有干系人，并取得一致同意。
在研发阶段：
鉴于多线情况下变更影响更加复杂，需要特别注意需求变更的发生，一旦发生需要考虑其对整体业务的影响，慎重执行变更和影响分析；再是，利用每日站会等形式，跟踪任务的进行状态，是否有新增、变更或评估偏差的任务被发现，及早识别可能造成影响的因素，减小控制成本。
在测试、上线阶段：
需要再次明确需要多线间的依赖，不仅要做某版本的测试，如果依赖较多，还需要增加对整个业务逻辑的测试；另外，上线前需要各方对结果进行确认，开发需要确认代码分支，产品需要确认完成结果，QA需要确认完成质量等。
除此之外，关系人管理需要贯彻始终——获取共识，同步风险，应急处理等；同时，不同角色的关系人间需要充分协作，各司其职：
1.Boss：应制定出清晰的业务规划，并向团队传达明确的期望，与团队充分协作为团队提供资源支持；而PM需要帮助Boss厘清未来众多业务线的发展规划，搭建沟通渠道，层层分解和传递团队目标，凝聚团队实现共同目标。
2.需求方：根据目标制定产品RoadMap，明确各项工作优先级，并和团队就优先级达成共识；
3.研发人员：负责工作包拆解、估算、技术设计和依赖分析，根据优先级实现需求；
4.测试人员：测试工作与开发工作对齐，在多线环境下减少测试工作的拥堵，提升需求流动效率，减小需求从开发到上线的周期；
5.PM：管理各干系人期望，协调团队向共同目标努力，构建沟通渠道做到信息透明，及风险把控，变更管理等工作；
6.HR：掌握业务人力资源缺口，定义岗位职责，建立专业技能矩阵等；
本文作者
