研发运营合体后，项目管理何去何从

在当今的数字化时代，随着数字化技术对企业内部的组织和流程影响的逐步加深，研发和运营部门逐渐的合二为一，研发运营部门基于持续交付理论进行软件平台的升级改造，并且负责运营的同事也在团队之中，运营和研发无缝结合。如下图所示

image.png

而传统的项目管理，讲究的是项目的实效性，最终项目要移交到运营手里，这也标志着项目的结束。但是这一过程，在持续交付的流程中被淡化了，项目没有明显的结束边界，也没有明显的开始边界，那么传统的项目管理方法立项-规划-实施-监督-收尾该何去何从，即使是敏捷交付，也有明显的开始和结束时间，在持续交付的过程中，“项目”的概念应该如何理解呢？

image.png

在经典理论中，项目的初衷是实现组织战略的落地，因此，在持续交付的运作机制中，如何让组织战略作地，如何实现各个持续交付产品线的协同与规划，这个命题可以做为上面命题的解读。

持续交付的最大优势

• 研发团队和运营人员可以一起工作，无缝衔接；
• 对用户的需求和反馈以最快的速度相应；

传统项目管理的最大优势

• 产品研发和运营的目标清晰，工作相对独立；
• 产品的研发方向、进度、资源可以很好的管控，是战略落地的利器；

结论似乎是，好综合二者的优势，即，做有目标有规划的持续交付；

如果当前的持续交付团队没有规划以及需求分解、优先级的排序的能力，那么这个工作就需要一个专人来做，为持续交付团队增加目标和规划能力；这个人需要对接运营和研发团队，承接需求，梳理需求，规划产品，传递给研发团队。

这个专职的角色对于一个孵化期的产品可能不是必须的，一般的互联网公司，一个产品的孵化阶段，更像是一个探索阶段，基本上也就1～2个人来做，所以这个阶段的产品和技术并没有严格的区分，而当产品发展到一个阶段以后，可以说孵化阶段结束，进入发展阶段，那么专业的事情就需要找专业的人来做了，团队的结构也会从单一的条线转变为更加细分的职能划分；需求和反馈也会从原来直接传达给研发团队变为通过运营和产品人员传达给研发团队；运营和产品人员承接了产品的长期规划以及各个产品之间横向整合的责任。