小公司产品经理:如何改善“野路子”,构建自己的方法论?

所谓“野路子”,即没有规范的工作方式,做事情没有依据,想到哪做哪,做到哪算哪,经常会陷入自己不知道干嘛的境地,这样的工作状态会极大的降低工作效率,长期以往甚至会影响自己的工作情绪。

如何改善“野路子”,即流程化、标准化做事,最佳的方法就是定义Standard Operating Procedure(标准作业程序),以下简称SOP,让自己在遇到问题时有所依据。

下面我将结合个人经验,详细阐述产品工作中如何通过定义SOP,改善野路子,形成自己的产品方法论。

一、定义与同事配合的工作流程

1. 了解互联网公司需求迭代的流程

如图:

产品经理,产品经理网站

2. 明确自己需要做以上流程中的哪些事

根据自己公司的情况细化,明确自己需要做以上流程中的哪些事,比如我司就需要产品做需求调研、产品设计、产品方案宣讲、研发过程跟进、收集反馈这几类事情。

3. 确定以上的事情需要哪些人(WHO)对接,以及如何(HOW)和他们对接

(1)需求调研

需求调研根据需求来源一般分为两种:

一种是内部需求,一种是外部需求。内部需求对接人包括BOSS、研发、测试、运营、市场,这些需求调研的工作和他们约好时间,反复沟通直到双方都没有异议就可以了;

外部需求一般对接人是客户,要复杂一点,懂得随机应变,不要当场答应实现需求,只要做好访谈记录,回来可以和决策人(一般小公司是boss,有些是产品总监或者技术总监)讲清楚大概需求,至于要不要做,怎么做,什么时间做(需求优先级的问题),这些问题留给决策人。

(2)产品设计

产品设计一般情况下是初级产品经理最重要的工作,设计过程中的对接人主要是需求方,有时也要需要技术参与讨论方案可行性,最重要的是和需求方反复确认以保证最终的方案过关,这一点会在定义自己工作的SOP中详细讨论。

(3)产品方案宣讲(评审会)

产品方案宣讲,一般对接人包括UI/研发/测试,有时需求方也会参与。这时候要提前预约时间,准备好产品方案的产出物,比如流程图、功能架构图、原型图、PRD文档,如果涉及项目管理,要在禅道等团队协作的工具中建好需求号,便于开发人员领任务。

宣讲的顺序一般是先业务流程图,再功能架构,然后根据业务流讲一遍原型图,至于文档就不用讲了。记得讲完一定要同步,如果团队有同步的软件,比如svn,git,也可以用邮箱,我们公司用的git,然后在群里发一句,“**原型图V1.0.0,PRDV1.0.0已经更新至git,请有需要的小伙伴自取”。

【PS:请在每次需求变更后,及时更新为原型图和PRD文档,并同步给相关同事,必要时重新开会强调变更,这一点尤为重要】

(4)研发过程跟进

研发过程中可能会出现各种各样的情况,对接人一般是开发和测试。比如开发、测试不理解需求,你要解释;开发、测试发现需求有些情况没有考虑到或者有规则不清晰的,你要补充需求(这种情况虽不能完全避免,但越少越好);甚至,前后端联调出现问题,需要你定义接口。总之,就是在开发过程中一切的问题你需要负责解释。

(5)收集反馈

收集反馈一般对接人是运营或者用户,这里主要是记录上线后出现的问题,为后续产品迭代提供依据。

以上的5点是仅为个人总结的内容,不同公司的情况可能略有不同。

二、定义自己的工作流程

最重要的就是产品设计SOP的定义,这个过程需要自己反复思考总结每一阶段都有相应的输出物,并且在平常工作中不断实践才有效果,以我总结的产品设计SOP为例:

需求调研→业务模型搭建→流程图→产品功能架构→原型图→PRD文档

1. 需求调研

这一步需要尽可能多的收集需求的信息点,包括需求的目的,参与的角色,上线时间,很多细节的想法等等。如果只是需求方只是一个人,那么他会提关于很多需求的描述,尽可能记下来;如果是头脑风暴式的需求,那么有不同的人提出不同的需求描述。

以PCG(Professionally-generated Content)的课程APP为例,A可能说课程要能定义属性(视频/文档),包括价格,名称等,B可能说课程要能下架,下架后前台就看不到了,C说用户要能够选课程,购买课程,D说要有购物车,只要是会上没有发现有明显问题的信息,统统记下来;我一般用onenote分点记,很多人喜欢用思维导图。

示例:

产品经理,产品经理网站

推荐工具:onenote

2. 业务模型搭建

根据需求调研记录的信息点搭建业务模型,最重要的是梳理主流程,听起来好像很难,但实际操作比较简单,在草稿本上列两点:参与角色、每个角色涉及的操作

同样以上述课程APP为例,涉及到的角色:包括平台运营人员、用户,涉及到的操作:平台运营人员上架课程,用户选择并购买商品;注意,这里涉及的操作不是要列系统中详细的操作,而是业务过程中完整的闭环操作(包括线上、线下)。PCG的内容是自己生产的,所以线下还包括制作流程,那么完整的业务模型应该是:

运营人员制作课程→运营人员上架课程→用户选择并购买商品

注意:业务模型的搭建一定要闭环,所谓的闭环就是实现最终的效果,比如C端的产品一定是要通过用户直接购买/广告/增值服务赚钱的,B端产品一定是要解决闭环解决问题的,一定要考虑系统层面做到哪一步,作为需求的边界。

我一般只会粗略的列,因为这个时候列得太细反而会干扰自己的思考。

推荐工具:草稿纸,笔

3. 流程图

一般画三种业务流程图,功能流程图,任务流程图。

业务流程图一般用泳道图(如有并行则用UML),主要是根据搭建的业务模型,在相应的泳道里按照顺序画出每个角色的操作。切记,不要想一步把所有流程画在一个业务流程图中,只需要把整个过程中最关键的一条/多条业务流画出来即可,否则适得其反。

示例:

产品经理,产品经理网站

功能流程图:主要是为了实现某种具体的功能,比如支付功能的验证流程,需要给出不同情况下的结果说明,包括支付成功的流程,支付失败的各种异常流程,开发很有可能拿着你的流程图去写逻辑判断的,测试可以直接拿着流程图写测试用例;

示例:

产品经理,产品经理网站

任务流程图:是为了实现某种任务的整个流程,只会在关键节点做判断,主要是为了让开发和测试知晓用户的核心使用路径。

示例:

产品经理,产品经理网站

推荐工具:ProcessOn

3. 产品功能架构

产品功能架构是就是用思维导图呈现,该产品需求包含哪些模块,这些模块包含哪些功能;

示例:

产品经理,产品经理网站

推荐工具:X-mind

4. 原型图

用界面化的方式展现元素,一般分角色,把对应的模块列在相应角色的文件夹下,先把框架搭起来,再从数据流的角度一个一个页面去画,我一般会把页面跳转和一些动态面板的交互画出来,比只画静态页面要直观很多。

过程中会有很多创意和想法,记录下来,画完自己按照流程跑一遍,看下有没有流程上的障碍,如果有的话,记录下优化的点,逐个优化。

原型图需要保留版本,每更新一个版本同步更新给团队成员。

示例:

产品经理,产品经理网站

产品经理,产品经理网站

产品经理,产品经理网站

推荐工具:axure

5. PRD文档

PRD文档每个人写法不同,不必按照别人的模板生搬硬套,现在很多团队敏捷开发直接在原型旁边标注,看起来很方便。我一般是在原型旁边注明重要的逻辑,另外再写一份Word文档。文档需要做一个目录,方便后期定位,还有每次更改的记录,最好在相应的位置标上最新更改的时间并显红,内容主要包括流程图、功能架构图、功能描述、原型图。

(1)流程图

把业务流程图贴在PRD文档的总述里,记得axure第一页也贴一份,功能流程图、任务流程图贴在相应的功能描述下。

(2)功能架构图

功能架构图在PRD文档综述里贴一份。

(3)功能描述

功能描述需要分角色、分模块,分页面,一般是一个页面一段描述,弹窗放在同一段描述,但也不绝对,也可以用功能点划分,比如列表、增、删、改、查,规则就是用MECE(互相独立,完全穷尽)的原则分清楚,具体描述主要包括三个方面:

  1. 数据的呈现,这个页面呈现的数据是哪里来的;
  2. 每个原型每个元素的描述,按照原型的页面,从左到右,从上到下撸一遍,每个UI/字段代表什么意义,有哪些规则,每个操作相应的页面变化是什么,数据变化是什么,想清楚,写出来;
  3. 描述异常情况,每种异常情况对应的页面是怎么样的,提示是什么。功能描述就是穷尽所有你能想到的注意点,如果你自己都觉得哪些规则好像不对劲,那一定是哪里没想清楚,一定要静下心来好好理理,否则开发和测试后面会找你的。

(4)原型图

在每段功能描述下贴上相应的原型图。

PRD需要记录版本,每一版本记录修改的地方、时间等,而且每次变更及时修改并同步给团队成员。

示例:

产品经理,产品经理网站

产品经理,产品经理网站

在小公司没人指导一定要勤于总结经验并运用在以后的工作中,不断调整,最终形成自己的方法论,这样一方面可以提高自己工作的效率,另一方面不论是转行或是跳槽都能很快的适应,为以后的工作打下坚实的基础。

以上。

 

本文作者 @娃哈哈 。

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部