产品工作流程:如何定义自己的流程和同时配合的流程

1 评论 472 浏览 1 收藏 8 分钟

在产品工作中,有时候会遇到需要定义自己工作流程的情况,以及处理好与自己配合的流程;这时候,如何做好此类工作?看看作者的经验吧。

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

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

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

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

3. 确定以上的事情需要哪些人(WHO)对接,以及如何(HOW)和他们对接——此处略重点哦~

(1)需求调研

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

一种是内部需求,一种是外部需求。

  • 内部需求对接人包括BOSS、项目经理、运营、市场、产研团队,这些需求调研的工作和他们约好时间,反复沟通直到双方都没有异议就可以了;
  • 外部需求一般对接人是客户,要复杂一点,懂得随机应变,不要当场答应实现需求,只要做好访谈记录,回来可以和决策人讲清楚大概需求,至于要不要做,怎么做,什么时间做,这些问题留给决策人。

(2)产品设计

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

(3)研发过程跟进

研发过程中可能会出现各种各样的情况,对接人一般是开发和测试。比如:

  • 开发、测试不理解需求,你要解释;
  • 开发、测试发现需求有些情况没有考虑到或者有规则不清晰的,你要补充需求;
  • 甚至,前后端联调出现问题,需要你定义接口。

总之,就是在开发过程中一切的问题你需要负责解释。

(4)收集反馈

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

二、定义自己的工作流程

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

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

1. 需求调研

这一步需要尽可能多的收集需求的信息点,包括需求的目的,参与的角色,上线时间,很多细节的想法等等。

如果只是需求方只是一个人,那么他会提关于很多需求的描述,尽可能记下来;如果是头脑风暴式的需求,那么有不同的人提出不同的需求描述。

以PCG(Professionally-generated Content)的课程APP为例

  • A可能说课程要能定义属性(视频/文档),包括价格,名称等,
  • B可能说课程要能下架,下架后前台就看不到了,
  • C说用户要能够选课程,购买课程,
  • D说要有购物车,

只要是会上没有发现有明显问题的信息,统统记下来;一般用onenote分点记,很多人喜欢用思维导图。

2. 业务模型搭建

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

同样以上述课程APP为例,涉及到的角色:包括平台运营人员、用户,涉及到的操作:平台运营人员上架课程,用户选择并购买商品;

注意,这里涉及的操作不是要列系统中详细的操作,而是业务过程中完整的闭环操作(包括线上、线下)。PCG的内容是自己生产的,所以线下还包括制作流程,那么完整的业务模型应该是:

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

推荐工具:草稿纸,笔

3. 流程图

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

  1. 业务流程图一般用泳道图(如有并行则用UML),主要是根据搭建的业务模型,在相应的泳道里按照顺序画出每个角色的操作。
  2. 功能流程图:主要是为了实现某种具体的功能,比如支付功能的验证流程,需要给出不同情况下的结果说明,包括支付成功的流程,支付失败的各种异常流程。
  3. 任务流程图:是为了实现某种任务的整个流程,只会在关键节点做判断,主要是为了让开发和测试知晓用户的核心使用路径。

4. 产品功能架构

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

5. 原型图

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

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

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

6. PRD文档

PRD文档每个人写法不同,不必按照别人的模板生搬硬套,现在很多团队敏捷开发直接在原型旁边标注,看起来很方便。

文档需要做一个目录,方便后期定位,还有每次更改的记录,最好在相应的位置标上最新更改的时间并显红,内容主要包括流程图、功能架构图、功能描述、原型图。

本文由 @苏逸轩 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 这个大概架构说的挺详细,我认为最重要的是客户调研,客户需求一直是亘古不变的话题嘛。

    来自广东 回复