适合新人:企业内B端产品的调研和运营方法

笔者目前就职于一家电商公司,岗位Title是“项目经理(流程分析)”。职能是接收或提出系统需求、规划业务流程设计、业务培训和运营效果跟踪。

这个岗位在互联网电商公司比较少见,一般的电商公司由产品经理负责接收需求和出方案。这个岗位类似传统IT的需求分析师,但因为电商行业比较年轻,目前我工作内容还不像传统需求分析师那么规范,于是更多是自行在摸索岗位流程和深挖岗位技能。所以这篇文章除了分享自己所识所解,也是对自己几年工作的方法论沉淀。欢迎交流。

笔者目前归属业务部门而非产研团队,所属业务部门负责公司的产品开发,公司的主营行业是服装饰品。

这篇文章主要是介绍大的工作流程和框架思路,往后再有其它文章展开具体案例。文章内容适合产品经理、业务分析师、需求分析师等岗位对于需求的调研和挖掘,也适用于产品经理、项目经理对项目的安排,以及产品运营岗位的用户运营。

一、基本工作流程(一个闭环)

六个流程参考了 芭芭拉·A·卡克诺德的《7步掌握业务分析》、《PMP项目管理》,以及了解市场类似岗位工作流程,结合自己的工作,总结而出,仅作为参考。另外这个闭环比较适用于单个项目或需求,当有多个流程共同进行时,会同时穿插不同阶段的项目,以后再讲。

产品经理,产品经理网站

1. 环节一:发掘和接收需求

这一环节主要目的是判断当前阶段重点,结果是识别需求。通常很多岗位会定义为这一阶段为“接收需求”,但对于一位注重业务流程的分析师,这一阶段更重要的是自己挖掘需求。

2. 环节二:需求理解和引导

此环节的主要目的是确认具体需求的背景、目标(最好可衡量),和业务共同梳理流程和细节,确保达到业务预期目的。通常业务人员首次提出的都是一个具体的功能,往往要深入探讨后得出可实现可落地的具体方案。和第一阶段的区别主要是具体功能的深入探讨。此阶段的难点是建立信任度和专业度。

3. 环节三:解决方案设计和评估

这环节的目的是和产品输出最终落地方案,主要是探讨最终实现方式。此过程最重要的是对当前产研部门工作重心的了解,将业务的预期涵盖和嵌入开发计划中,可能面临业务目标的阶段性分拆。

4. 环节四:排期和项目管理

此环节主要由产品先和开发人员评估技术实现方案和排期,需求分析人员主要的工作是确保时间符合业务预期,更多是作为一个项目经理的角色进行资源协调。

5. 环节五:上线验收和推广

环节五接近流程尾部,主要确保上线操作符合业务期望,验收完成后进行培训和推广。此环节可能会发现很多开发前的漏洞,如遇到,需要考虑功能是否仍可上线。如上线需要和业务讨论可接受度,并安排进下一次迭代。如果可能的话,最好组织业务间的经验分享。

6. 环节六:目标的复盘和纠偏

最后一个环节,其实也是下一大阶段的起点。这一阶段主要是复盘业务使用效果,评估和初始目标的偏差。

此阶段很容易被忽视(尤其当需求未正式立项时),但又是一个很重要的事。因为这一阶段才能真正积累对业务流程的认知,如果效果不进行复盘,很容易沦为一个实现需求的机器,无法在今后过程中真正引导业务和把控需求的主动权。

二、各环节的具体流程

这一部分是对六个环节的细致解说,主要介绍每一环节的细致步骤、具体技术和方法。参考同样来自《7步掌握业务分析》、《PMP项目管理》,以及自己的实践。涉及的技能技术以后的文章再详细展开案例。

产品经理,产品经理网站

1. 发掘和接受需求

1)理解业务和部门现在和未来阶段的目标 

  • 目的:保证自己对公司大方向战略规划的理解正确。
  • 操作:了解公司公式的OKR、内部战略分享文件、外部对公司的报道、公司财报,以及竞争对手的动作。
  • 技术技能:公司共有文件发布渠道的了解、对信息的敏锐、开放的信息吸收、不断地学习。

2)理解自己所在部门对于机构的价值

  • 目的:确保自己的价值和优势地位(尤其是当刚到新公司新岗位时)。
  • 操作:公司组织架构和管理层级了解、部门当前工作在汇报中的重要程度。
  • 技术技能:对隐形信息的判断。

3)了解干系人

  • 目的:岗位的影响者及被影响者。流程分析这一岗位,涉及的有项目发起人、项目经理、用户、用户上级、QA、专家、开发人员、数据库人员、供应商等等。
  • 操作:了解组织架构,了解工作流程涉及的人。浅层的了解只是知道人名、岗位、工作内容。而深层的了解则是了解影响力、性格、能力、喜好、人员关系链等内容。
  • 技术技能:干系人评估(内容过大,以后的文章中会具体展开)。

4)接收需求,记录需求池

  • 目的:好记性不如烂笔头。另外对需求进行归类和优先级排序。
  • 操作:EXCEL表或在线文档都可。

产品经理,产品经理网站

5)根据目标和现状差异梳理疑问

  • 初级阶段操作:从自己角度输出对公司业务的理解,和对现状的疑问,从宏观角度输出现状思考。此环节不一定会和外部交流,当然有会更好。
  • 深入阶段操作:当入职2-3个月后,已经初步了解公司问题,可以从中间层和微观层梳理业务问题,列出清单,进一步准备落地的优化改善方案。

2. 需求理解和引导

1)了解业务目标、达成情况

  • 目的:重点是业务管理层对于现状的理解和未来预期,当然操作层也会有指标,但更重点要关注宏观要求。
  • 操作:单纯地了解情况不难,难点更在于如何与管理层建立良性关系和信任感,因为要了解的是业务的核心指标。一般可以通过从上(更上层管理者)到下的引荐,或者从下(对操作层的支持)而上的渗透沟通来慢慢建立深层关系。
  • 技术技能:干系人评估、沟通管理。

2)理解业务部门操作流程、运营方法

  • 目的:重点是了解执行层的操作方式和运营步骤。操作流程指系统或线下的一个个步骤。而运营方式更多是他们操作背后的管理方法和思路,可能是隐性不可直接获知的。
  • 操作:访谈、轮岗、梳理流程图(注意观察业务实际操作可能和描述的不一致)。
  • 技术技能:业务流程记录模板、需求核心组件记录(数据、过程、规则、主题)、根本原因分析(5WHY)、问正确的问题、有效地记录。

3)明确需求目的,尽量量化出可衡量指标

  • 目的:确认业务需要解决的问题,因为实现方式很可能会偏离目标。
  • 操作:单个流程中多个需求优先级排序,多个流程的优先级排序。
  • 技术技能:KANO模型。

4)流程梳理

  • 目的:明确方案的主流程和分支,尤其分支非常容易遗漏。
  • 操作:每个分支点都要做横向扩充,需要考虑有无需要反向流程的场景;主流程为主,副支需要考虑频率概率。
  • 技术技能:矩阵分析、决策树、概率树。

5)考虑整条流程上的所有干系人操作

目的:为了可能提升全流程效率,除了内部用户,也尽可能考虑外部用户使用流程。

6)明确干系人中有效的决策者

  • 目的:确认当前方案的所有影响相关方,尤其是企业内组织结构复杂时。
  • 操作:每个最小颗粒度组织单位中,都需要确认四类用户RACI,即决定者、执行者、(辅助)监督者、知情者。有时候这些人员的职能并不明确也不明显,还需要流程人员确认相似职能者,或推动业务负责人确认相关人员。
  • 技术技能:干系人评估。

3. 解决方案设计和评估

1)和业务讨论初步解决方案

  • 目的:尽可能梳理出多个方案和业务碰,以便和产研讨论时可做选择。
  • 技术技能:头脑风暴、HMW分析、元素拆分法。

2)梳理系统流程,和产研输出实现方式

目的:此步骤主要由产研团队输出可执行方案,需要1-3周左右,最重要是确认实现方案符合业务目的(不一定能符合预期)。

3)风险预估

目的:评估流程风险和设置应对方案。

4)和重要干系人(对接职能人员、资深用户)确认

  • 目的:和重要干系人确认最终方案和交互效果。
  • 技术技能:词汇库、用例、原型。

5)确认效益指标需要的数据埋点

  • 目的:尽可能确保需求上线后需要的效果可观测。
  • 操作:跟产研确认数据埋点是否可统计(简单覆盖量统计)、是否落数仓(较多且复杂的明细数据,不适合直接从操作系统导出)。

4. 排期和项目管理

1)评估WBS、排序、历时估算、沟通机制、风险

  • 目的:保证项目、需求,按时、按质、按量交付。
  • 技术技能:参考《PMP项目管理》。

2)组织定期的需求反馈方式、协调优先级、安排资源

  • 目的:和业务、产研双方分别开展定期的需求讨论会,重新明确当前问题点和需求优先级。
  • 技术技能:80/20规则、时间盒。

3)需求和项目的具体排期

目的:需要产研侧输出具体的开发、测试、上线时间,并知悉业务。

5. 上线验收和推广

1)验收:产研验收、流程人员验收、重点业务人员验收

  • 目的:确保产品功能性无异常、大流程符合业务操作。
  • 注意点:确保产研验收通过后,再进行业务验收。和重点业务提前1-2天预约。

2)正式上线推广培训

  • 目的:面向所有用户教授其使用方法,B端产品功能性比较复杂,都需要专门的培训。
  • 操作:面授培训或者线上培训。面授试用于复杂功能、运营要求比较深的功能、创新性高不确定使用效果的小范围测试。线上培训适用于人数众多的小功能培训,最好不要超过半个钟。
  • 注意点:当流程改动比较大或过于复杂时,最好找部分业务人员先试行,再全面推广,因为可能会出现意料不到的问题。

3)组织业务间的深度分享

目的:开展分享会,鼓励资深用户分享自己的操作和运营方法。一方面真实用户的分享信服度更大,有利于推广产品的使用。另一方面大带小,真正地推动提升用户的运营能力。

6. 目标复盘、纠偏

1)效益评估,和目标差距的复盘

  • 目的:确认效果是否和预期相符,如果不相符需要总结经验教训,落到下一个迭代的计划中。
  • 操作:一般是统计相关指标,在前面第二步“需求理解——明确可衡量效益”已确定的。复盘周期根据项目实际情况安排,可以日、周、月不同的维度进行统计。

2)定期汇报

  • 目的:让项目相关方了解项目进展和目前问题。
  • 操作:根据项目需要,一般以周或双周频率展开项目会议,重要性特别高的项目还需要以周维护展开。当项目进入平稳运行阶段后,可以月维度进行。
  • 注意点:出色地呈现、接受批评性建议、认识你的弱点并克服它们。

3)项目交付

  • 目的:明确项目可完结,资源可投入其它项目中。
  • 操作:当项目按时按质按量完成后,即可与发起人确认是否结项。如可结项,需要召开正式的结项会议,和各相关方正式公布项目结束。如尚无法达到交付条件,则需要讨论项目是否需要延期,以及需要哪些人员支持。

三、总结

以上是个人五年工作的一些总结和输出,和市面上常见的方法论、岗位职能并不一定匹配。目前的困境也是在于未来的岗位定位和规划,但有趣也在于可以不断去探讨新的认知。如果我梳理的内容和你有所共鸣,欢迎一起探讨^_^

 

本文作者 @我叫更更 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部