昨天有个朋友问我经历过最规范的产品工作流程是什么？我沉思了很久告诉他——最有效的就是最规范的。
对于刚刚踏入产品岗的新人或者在该岗位工作过一段时间的伙伴，可能会发现一些问题，比如输出的内容不尽人意，各方配合不够到位，各种资料杂乱，各种背锅等等，经过一番思索发现可能是整个工作流不对，然后查阅各种信息，想学习怎么样的工作流是最好的。
为什么我会有开篇的“最有效的就是最规范的”概念，因为我跟大家一样，曾经也是网上各种查询，看各种大佬分享出来的工作流程，但是我发现都有一个通病，那就是“环境差异”。
大佬分享出来的内容肯定是有他们的经验，通过他们的经验累积产出的精华内容，所以从这方面讲他们给出来的流程是没有任何问题，最大的问题就是在于你跟大佬所处的环境，你公司的资源配置、人员素质、团队架构、工作模式、产品阶段等等，这些因素才是决定你需要的工作流程是什么，而不是照搬过来使用。
下面我要讲到的内容只是根据我的经历及朋友那里收集过来的一些经历，如果有什么冒犯或者不同意见的欢迎交流经验。
一、内容输出
二、内容评审
三、项目跟进
一、内容输出
作为产品岗来讲，输出内容尤其重要，因为是整个工作流的源头，从产品这个地方输出的内容如果有问题，在后面就是不停填坑。
那么通常来讲产品需求输出的内容是：功能脑图、流程图、原型图、PRD，大部分输出这些内容是足够了，那么来讲讲这几个文档输出到什么地步。
功能脑图
功能脑图是作为产品必须掌握的一个技能，除了作为后面原型图的基础以外，更多的是帮我们整理清楚思路，需求具体有哪些内容就是从功能脑图开始确认，那么我们在进行功能脑图绘制的时候要确保一个点：精确到每个字段，每个状态。研发一般会查看产品整理的功能脑图，涉及到他们对整个数据库的架构以及建表，所以功能脑图是越细化越好。
功能脑图示意
比如上方的脑图就细化到了每个功能点下面的每个操作，每个字段。
流程图
流程图这点我的方式是看公司当前的情况，这个需求你对公司的人员有一定的了解，他们做过的项目以及公司的积累，如果说开发人员经验丰富，那么只需要绘制核心的业务流程；如果说研发人员经验不足，那么在这种情况下就需要补充大量的流程图，甚至注册登录的流程图也需要绘制。
流程图示意
流程图的画法相信大家都会，所以就不讲怎么画，只是在流程上一定要注意两个点，第一是角色，第二是判断，在梳理流程上需要仔细思考这两个要素，在哪一步需要判断，这个流程点涉及到哪些角色，是否有角色并行的情况。
原型图/PRD
在这里我把原型图和PRD放在一起，并不是说既要出原型也要出PRD，我个人认为一部分公司是没必要出PRD文档的，PRD文档更偏向于一些saas系统，而作为一般的电商、社交、外包公司等等，PRD文档过于冗杂，需要太多的成本，不适合这种中小型公司。其实现在也有很多公司把PRD和原型图相结合，在原型上进行标注，这样也能达到PRD的效果，但是具体的标注细节视情况而定。
原型标注
以上是一个原型的标注内容示意，当然还可以写的更加全面，如果采用原型标注的方法我们要确保标注的内容至少要包含：
1）长度限制
2）输入限制
3）操作判断
4）操作跳转
5）异常状态
这样相结合配合流程图和功能脑图会减少一些后期填坑。
二、内容评审
需求评审
在需求评审阶段，一般来讲是产品整理好需求方的需求以后，再次确认需求是否有误，在这种情况下我们就需要参与人员了，一般来讲是根据需求涉及到的功能点来决定研发是否参加，如果说在整理该需求的过程中，发现涉及到很多技术点并且自己无法把握是否能够实现以及时间周期的情况下， 在这个会议上还需要邀请技术人员参加，确认需求的技术实现难度。（当然这里也涉及到砍需求，也可以在整理需求的过程中私下与研发人员确认，如果实现难度高需要砍需求那么在会议上由研发人员提出来会比较有信服力。）
在这个阶段最重要的就是需求确认了，这都是血泪教训啊，在每次需求评审完成之后一定要形成文档确认！！！一定要形成文档确认！！一定要形成文档确认！重要的事情说三遍！！！，我曾经就遇到没有确认最后再来倒打一耙说我们设计的没有按照需求来，这就只有背锅了。所以我们需要做的是将会议上确认好的需求，包括功能点和流程等内容，发放给参会人员，然后确认回复，形式不限可以纸质可以邮件形式，一定收到回复之后再开始，否则最后等着背锅。
原型评审
需求确认完成后我们就开始设计，补充脑图、流程图、原型图，在原型图绘制完成后我们也需要进行评审，在这个阶段需要参会的人员可能会增多，具体根据需求内容来，比如说提出需求的是市场人员，但是因为设计出来的需求功能可能会需要客服、运营他们操作，在这种情况下需要叫上相关人员一同参与，否则最后设计出来的他们操作不爽，最后又把锅扔过来。当然这个阶段必须要参加的还有研发人员和测试人员，研发人员是确认整个环节的技术难点，并且了解整个需求进行底层设计，而测试人员主要作用是了解需求整理和查漏补缺，以及听完需求可以进行测试用例的编写；
在原型评审的阶段会存在一个风险，就是需求方在最开始提出需求的时候可能只是知道我想要什么东西，但是具体的细节没有想好，怎么来实现，但是通过看到你的原型图后就开始脑子里闪灯泡了，有这样想法那样想法，这种情况下就需要产品自己来把控整个需求，怎么砍怎么挡，这个在之前的文章介绍过就不多讲，只是在开原型评审会议的时候做好这个准备，很大几率会碰到调整需求情况。
最后，原型确认也是必须要做的，纸质邮件随意，确认之后再开始做，不然等着反复修改需求迟迟上不了线。
当然说上面这句话我自己都不信，我曾经也是按照上面的方式做，但最后还是会冒出来各种各样的需求，加功能推迟上线，这个是真没办法避免，只能说能够在某种程度上避免，不能说完全。 剩下的就靠你本人的魅力与实力去挡住这些需求了，不过这是作为产品的一大核心能力不是吗。
效果图评审
在这个阶段其实已经好了太多，基本与原型评审类似，经过原型确认后在效果图评审上基本不会调整太大，只要记着确认就好了
说到产品的输出就要说到文件交接了，在产品这边设计完成后，需要将文档交接给相关人员，在这种情况下我是建议确认接口人，一方面不会导致文件混乱，由一个人分发下去，第二方面是让研发这边形成一个整体，方便管控；包括在整个开发阶段如果产品需要补充什么内容的时候都是统一发给一个人然后再下发。
三、项目跟进
现在很多公司没有将项目经理和产品经理分开，基本上产品经理也会充当一部分项目经理的角色，在这种情况下项目进度就更需要更好的把控，因为毕竟还有产品方面的内容，精力可能不是很足。所以在这种情况下跟研发碰头的频率会相对来讲高一些，我基本上在这个阶段是每天晚上都会跟研发主管开个会，确认下今天研发的开发内容及有没有什么问题需要协助的，他负责确认研发这边所有的内容，我负责确认产品这边的内容，两个人碰头这样效率会高很多，而不是那种一开会把所有人员全部叫上，你一言我一语这样，全部讲完半个小时一个小时过去了，还没多大结果，完全是无效会议。
在最后我想说的是在这个世界上真的没有最规范的流程，最适合和最有效的流程对你来讲就是最规范的，你需要根据当下你的情况，来制定适合在这个公司开展工作的流程，而不是按照网上生搬硬套，要知道公司环境是怎么样的，对技术这块了不了解，研发环境是怎么样的，氛围、技术、经验好不好等等因素结合起来，才能够制定出适合你自己的工作流，这个工作流也会随时进行变动，比如人员变动、架构调整等等，都会影响，所以要时刻观察和调整，没有什么东西能使用一辈子。
那么另外，我讲的东西更多的是我所经历过的一些实际内容，并不包含太多的大概念内容，如果需要了解概念上的内容，网上有很多可以查询到，我提供的更多是实际工作中遇到的一些问题，如果你有一些想法和问题，欢迎跟我一起交流，大家一起进步，VX：goodnight9527。
网友评论