入职5个月:B端产品新人总结工作方法论

6 评论 5114 浏览 14 收藏 12 分钟

导读:小白进入产品经理行业,总会有些迷茫,想要寻求前辈的经验。对本文将从产品的整个策划流程进行写作,包括需求调研分析、范围层和结构层梳理、交互原型设计几个工作节点,根据时间比例个人总结为532工作法。

一、目的

不知不觉已经整整毕业5个月,成为产品界菜鸟新人5个月了,通过这篇文章总结一下5个月来自己从0-1的成长,也总结积累一下个人的工作方法,为之后进阶为产品小白菜打下基础。

说实话,刚接触产品策划这个岗位时我是比较慌、恐的。慌是因为陌生,我之前是做产品运营的,主要的业务是如何让产品更好的为公司创造价值,是使用产品这个介质,不是创造介质,对我而言产品策划是个陌生的领域;恐是因为未知,我不知道我能在产品这条路上走多远,也不知道这条路到底适不适合我,只能带着未知坚定而又慌恐的向前走。

从进入公司通过MNI项目从0到1进行产品策划,转正后又通过已有的项目进行从1-N的迭代优化,这5个月对我而言真的是翻天覆地的变化,产品领域博大精深,涉及的知识领域数不胜数,这5个月看的书籍堪比我大学四年的数量。我也在实践中初步总结出了属于自己的工作方法,其中包括需求调研分析、范围层和结构层梳理、交互原型设计几个工作节点,按照时间比例我个人总结为532工作法。

二、工作方法

做过产品的人都知道B端和C端有本质上的区别,C端重视体验,且是一类用户多种属性,而B端重视效率,是多种角色、多种业务,重视对业务逻辑和流程的把握。如果想B端产品设计好,那么需求的分析和调研是最重要的部分。

1. 需求调研分析

需求调研分析是很考验产品专业的一项技能,可以说需求调研分析做好了,产品策划工作就做好了一半。我一般会用策划周期一半的时间去做需求调研分析,这就是“532工作法”中的“5”。

需求调研有多种方法,如问卷、访谈、岗位实践、数据分析等,不过对于B端个人推荐访谈和实践的方法,毛主席曾说过:实践是 检验真理的唯一标准,想要弄懂弄透需求,不是你去实践,就是你去访谈实践的人。

1)需求分析

当你接到一个需求的时候,不能直接就去想要做成什么功能,一定要先通过调研的方式把握需求的产生原因、涉及的业务逻辑和流程、以及想要得到的效果(涉及管理层面的规范和标准,一定要不能光看业务,业务只是管理的执行表现,管理层面的规范逻辑才是核心)。

以本质思维为思考方式,以追问法进行自问自答自分析,举个例子,现在有1需求是想做一个采购管理的功能,用来解决采购流程不规范、采购数据追溯困难的问题。

那首先设置几个问题,

  1. 这个需求是要解决什么问题?
  2. 要解决的问题涉及到了哪些业务?
  3. 现有的业务流程是怎样的?所涉及的相关人员都有哪些?
  4. 想要的效果是怎样的?

那么我们自己回答一下这些问题,

  1. 这个需求要解决采购流程不规范、数据追溯困难的问题
  2. 涉及到了物品采购业务
  3. 现有的业务流程是先向采购员提出物品采购需求,通过后采购员进行线下的比价议价,采购负责人负责线下审批比价单,通过后采购员进行下单、向财务请款,最后收货给到申请人;所涉及的相关人员有申请人、采购员、采购负责人、财务
  4. 想要的效果是将此业务流程规范化、将线下进行仅有部分人可见的业务数据放到线上,可供业务流程上的相关人员进行协作,可快速追溯数据,让监察能随时监管

那么分析过需求,对需求的产生原因、涉及的业务流程和要得到的效果有一定了解后,就可以进行调研进行验证了

2)需求调研

需求调研的目的是为了进一步理解需求,验证、补充完善预先分析的结果,调研的方法我基本上会选用访谈的方式。

访谈一般对于初级的产品来说是比较困难的,一是级别不够,很难能将所有的相关人都一起访谈,二是经验不足,可能无法通过一次/几次访谈就能调研透彻。所以个人建议是初级的产品可以通过自己部门领导去组织访谈会议,同时预先做好分析,多维度总结一些要提问问题。

就我个人而言,访谈步骤基本上是

  1. 预先估算一个会议时间,把会议室先预先定出来
  2. 然后联系部门领导和其他相关人,根据重要的人的时间调整会议安排
  3. 访谈过程:询问需求背景—涉及的业务有哪些—现有的业务流程是怎样的—涉及哪些角色—各个角色在其中起到哪些作用—各个角色所涉及的业务细节—想要达到一个什么样的效果/规范—提出自己的解决思路和完善流程的想法—总结会议的共识和后续跟进的相关事项和人员

调研不是通过一次访谈能彻底解决的,访谈会议基本上能解决大部分的问题,但不能解决全部问题,需要后续有更多的交流,个人建议是涉及相关人较多/需要确定的共识性问题组织相关人员进行访谈会议,相关人较少/仅涉及部分业务的问题尽量通过聊天产品进行文字交流。

3)需求梳理

需求梳理是需求调研分析的收尾部分,也是最重要的部分。这是一个承上启下的部分,需求梳理不好前面的需求分析、需求调研就会没有任何用处。

就我个人而言,一般情况我会根据相关业务流程去做需求梳理,以要解决的问题为中心,以业务流程为框架,以角色涉及的需求为填充。通过梳理需求,分析出解决方案,并根据业务核心程度简单判定优先级,同时判断难易程度。

个人使用的需求调研分析的表格字段:序号、提书方、提出人、业务场景、业务需求、解决方案、难易程度、优先级、备注

2. 范围层和结构层梳理

范围层指的是解决需求所需要拥有的能力,结构层是能力外在体现的功能。需求梳理阶段的分析出的解决方案是初步的解决方案梳理,具体的范围层和结构层的梳理需要更加精细化。这一步是需要根据需求调研梳理出将要做的系统能力和功能,还需梳理出需要关联的外部系统,关联方法、功能权限、数据权限、字段权限、审批流程、审批权限等等。这一步我一般会用策划周期10分之3的时间去做,这是“532”工作法中的“3”。

具体步骤如下:

  1. 首先梳理出业务需求所需的能力导图,这一步一定要细致,能力基础决定上层建筑
  2. 然后根据能力去分解功能、设计功能,一定不能通过需求直接设计功能,那一定会有疏漏,一气呵成永远比缝缝补补要好得多
  3. 梳理字段,将功能所涉及的字段一个不漏的梳理出来,不要偷懒、不要偷懒、不要偷懒
  4. 梳理系统权限和流程,权限梳理一定要考虑数据的敏感性和角色的权限,有必要的话要将功能、字段、数据区分开,流程设置的话要考虑后续是否会有相似的路程,可以单独设计出一个配置项,后续可复用

范围层和结构层梳理最好是输出思维导图,比较清晰,在设计原型的时候超级方便。

3. 交互原型设计

交互原型设计包括三部分:原型、交互、规则。原型是结构层的外部体现,交互是与用户做交流的系统表达,规则是在这个系统上的玩法以及与其他系统要怎样玩。前面的工作如果都可以尽善尽美的做完,那么交互原型设计就会特别快,我一般会用策划周期的10分之2的时间去做,这是“532”工作法中的“2”。

原型设计这里无法总结太多,我个人画原型一般是画低保真,规则要写尽可能的完善,可参考一些阿里、腾讯的交互设计,B端对于交互原型没有那么高的要求,只要高效、便捷就是好的,个人推荐采用简洁的设计。(可以读一读《简约至上》这本书。)

三、结论

我个人目前处在产品的初级阶段,大多数情况只能考虑到业务和管理层面,我很清晰的能感知到。产品经理一般有两种模型要掌握,一是初级产品经理要掌握的用户模型(对于B端,此“用户”多数指的是业务需求),二是高级产品经理要掌握的交易模型。以后的日子还长,诸君共勉。

 

本文由 @神明大人呐 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 你好,我是刚要进入b端做产品经理的新人,根据你的文章内容有什么书籍推荐吗

    回复
    1. 刚入行的可以看一下《决胜B端》,可以系统性的了解B端的工作

      回复
    2. 谢谢您

      回复
  2. 虽然在这个行业做了有点时间了,但还是感觉自己是菜鸟,好多知识都不太丰富

    回复
    1. 大家都是菜鸟,互相学习,向上奔嘛

      回复
    2. 我也是,新人入职5个月了,工作过程中发现自己好多不懂。

      回复