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

10 评论 9052 浏览 70 收藏 15 分钟

编辑导读:产品经理属于新兴职业,没有太多职场老鸟能带人,除了少数大厂拥有完备的产品体系,大部分产品人都是摸着石头过河,也就是所谓的“野路子”。那么,作为一个小公司产品经理,该如何改善野路子习惯,构建自己的方法论呢?本文作者依据自身产品实践中的所思所想,结合案例对上述问题展开了分析探究,与大家分享。

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

如何改善“野路子”,即流程化、标准化做事,最佳的方法就是定义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需要记录版本,每一版本记录修改的地方、时间等,而且每次变更及时修改并同步给团队成员。

示例:

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

以上。

 

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

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

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 收藏了。

    回复
  2. 这种感觉不适合快速迭代的产品

    回复
  3. 写的很不错,期待您的更多作品!

    回复
  4. 应该是PGC吧,另外流程图部分判定的时候用,动名词表达会更清晰,自己会理解,但是其他人是需要一点思考的,比如账单存在这是一个表示肯定,建议换成账单是否存在然后yes or no,如果其他部门同学理解的话其实也无所谓了哈哈

    回复
    1. 感想指正!

      回复
  5. 通过读完这篇文章,我已经清楚的知道自己还是产品渣渣了,做了两年居然还是渣渣,咋办啊

    回复
    1. 不要轻易否定自己,尝试复盘项目,总结经验,你一定可以找到属于自己做产品的套路。

      回复
    2. 我以前也是渣渣,自从我静下心学习一门程序语言后,你会发现新世界。我现在台头已经是高级产品经理了,祝你好运

      回复
  6. 很不错,自成体系。

    回复
  7. 已经很完整了,很不错,感觉已经像大公司的流程了

    回复