互联网项目中,业务多线并行风险管理如何防范?

3周带你玩转Excel!在行第一行家手把手带学+作业实战+答疑辅导,升职加薪快人一步,了解一下>>

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

初识,多线风险危害

多线风险,可能给团队带来多种问题:

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

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 楼主好人,借楼发个小广告哈,各位产品,运营大大们,杭州各种产品,技术,运营方向的职位,有兴趣的朋友欢迎加微信(nevinlwj)私聊哈

    回复