从运营角度出发,如何高效推进与PM的合作?

2

在很多公司,运营和产品是互为需求方和实现方的关系,因此在推进项目高效落地的过程中,离不开双方的努力和协作。今天我想要分享给大家的是,从运营角度出发,如何通过规范化的合作流程高效地推进与PM的合作。

这篇文章专注解决的问题是:

1.分类讨论双方的合作:一类是运营主导的项目,另外一类是产品主导的项目。

2.通过规范化双方的合作机制,推进项目的高效落地。

3.希望读者能够得到的收获是:

  • 少踩坑!踩浅坑!
  • 能够推动组内产出一个适合自己部门的合作规范。

运营主导的项目合作规范:

1.主要包括项目

  • 运营活动:为了提升运营数据(用户留存,拉新,转化,内容量级等)而开展的各项活动。
  • 运营后台:为提高效率,降低运营成本而搭建的运营后台,属于平台性工具。

2.项目流程

需求从产出到落地总共分为三个阶段,在不同阶段,运营和PM需要各司其职,为了需求高效高质量的落地而工作。项目流程如下:

【第一阶段:需求提出阶段】

流程:运营提出需求→PM明确需求→双方领导确认需求

注意:

  • 运营产出需求文档初稿,内部确认需求无误后,线上以邮件的形式周知项目参与人员,线下与PM沟通需求。
  • PM明确需求,产品根据需求文档明确运营需求,针对有争议点统一记录,寻找运营项目负责人沟通,双方确认无误后向各自领导报备需求,双方领导确认需求方式:直接以邮件流的形式回复确认需求。
  • 需求文档产出后,原则上不允许修改大方向,如需修改细节,以邮件的形式确认修改内容。

【第二阶段:MRD产出阶段】

流程:PM产出MRD初稿→运营确认MRD符合预期→双方领导确认实现方式

注意:

  • PM产出MRD阶段,如有常规问题,统一记录后与运营项目负责人沟通,紧急问题,可直接与运营项目负责人沟通。
  • MRD完成后,PM需以邮件流的形式反馈MRD给运营,运营项目负责人需要和领导沟通,确认是否接受需求的实现方式,如不接受,需和PM进一步沟通,优化实现方式。PM经过进一步修改,与运营接口人确定MRD后交由双方领导确认需求。确认方式:双方领导直接以邮件流的形式回复确认需求。
  • MRD文档产出后,原则上大方向不允许修改,如需修改细节,以邮件的形式确认修改点。

【第三阶段:研发介入阶段】

流程:PM召开评审会→修改MRD部分文档→研发正式介入开发→需求上线

注意:

  • PM召开评审会,运营项目负责人与运营领导参加即可。针对评审会议上研发提出的问题,运营需要解答并记录。
  • 根据研发同学的建议,PM与运营项目负责人确认修正要点后,项目评审会议结束后的两个工作日内,PM将定版MRD以邮件的形式周知项目参与人。
  • 需求上线后,产品及时同步运营,运营回归需求。

3.重点关注

  • 时间点:根据研发排期,提前两周产出需求文档,PM需提前一周产出MRD并完成交互图和ue图的准备。
  • 立项需求邮件流:需求文档与MRD要以邮件流的形式产出,避免出现需求更改而某一方不知情的现象。
  • 接口统一:功能变动、修改以及需求对接,统一与接口人沟通,非接口人不直接沟通和接手需求。所有需求,由接口人统一安排。
  • 项目负责人制度:具体项目,确定具体的负责人。负责人为项目节奏、项目效果负责。
  • 节点信息及时同步:功能上线,下线,更改需要及时同步运营。

PM主导、运营参与的项目合作规范

1.主要包括项目:

PM主导的项目,运营扮演着支持性的角色,但是在不同的项目,运营需要参与的力度会有所区别。为了降低沟通成本,提高沟通效率,保障项目高质量的上线,故采用区分运营参与力度的方式分类讨论

高参与度项目:PM主导的有关产品功能改进,产品功能优化中,需要运营后续投入大量的人力和资源去运营的项目。例如,图集与视频功能的上线。此类项目的特点是,项目上线前,PM承担主要工作内容,项目上线后,运营承担主要内容。

运营介入时间:全程跟进此类需求,主要工作根据运营的实际工作场景和需求提出修改意见。

中参与力度项目:PM主导的功能改进上,需要运营投入时间成本大于一个工作日的项目。(关于时间成本的评估,需要PM和运营线下沟通确认)

运营介入时机:PM提前3-5个工作日周知需求,运营评估需求时间成本介入需求。针对特殊的项目,需要特殊处理。

低参与度项目:PM主导的项目上,运营提供内容、文案以及部分策略参考的支持。

运营介入时间:PM提前1-3个工作日周知需求,运营评估需求时间成本介入需求。

2.推荐项目流程

  • 项目流程:PM整理需求→交付运营接口人评估需求→运营安排专人对接需求→完成需求→回归需求
  • 该项目流程中谈到的需求是指PM在产品功能的改进和优化上,需要的例如文案、内容、问题等方面的支持和确认。
  • 项目时间点明确原则:根据以往的合作经验来讲,PM在与运营沟通此类需求,需要明确各个阶段的时间点,小需求直接通过内部沟通工具明确时间点,大需求通过邮件流的形式确定各个阶段的时间点。

3.注意要点

  • 上线后运营需要强运营的项目,PM在产品规划阶段需提前与运营确认是否接受修改方向,如双方有不同意见,则进一步沟通确定最终可接受的实现方式;
  • 上线后需要运营维护的功能,例如Banner改版等,PM需在功能上线前一周邮件周知相关规范与预期上线时间,以及运营侧需要做的准备;
  • 接口统一:上线前需要运营提供内容、文案支持的功能,PM根据预计耗时提前与运营方向接口人沟通,由运营方向接口人统一安排时间。
  • 权责统一:因某一方的原因导致需求上线delay或者造成其他影响,应承担相应责任,根据项目的影响力度采取不同的处理方式。

写在最后

有些经验,必须亲身经历,方可学到。感谢你能阅读到最后,谢谢!

相关阅读:

作为运营新人,如何才能更好地与开发沟通需求?

 

发表评论

您的电子邮件地址将不会发布。

评论审核已启用。您的评论可能需要一段时间后才能被显示。