在近期的工作中，我的经验、认知和能力一次次受到挑战，感受到很大的压力。不过在这不断暴露问题的同时，对产品工作流程的各个节点也有了一些新的认识和感触。本文算是对这一年产品工作的全面复盘。希望对同道中的你有所帮助。
一、工作开展之了解研发流程
亲自走过的路总比看别人走的路来的更加真实。熟悉产品研发的整个流程是我近期阶段最大的收获，项目的每一个环节，leader都放手让我自己去摸索最后汇报，不足之处给出建议，让我快速成长。如：独立向业务展开调研，独自直接跟开发对接，自己写测试案例。
这段时间下来，我认识到对任何知识的学习，系统化很重要。对一件事情系统化的认知就可以明确目标知道怎样实现，就可以完善系统的细节，形成自己的方法论，就可以有宏观的架构思维，知道哪个时间做哪件事，从而高效地实现。
那熟悉产品的整个研发流程，其实是做产品的第一步，想做产品还没开始的朋友最喜欢问，产品要做哪些工作。产品的日常其实是渗透到整个流程的各个环节之中。下图中的黄色部分就是目前我所在公司PM的工作内容（Bug复现、接受用户需求、需求分析、功能设计、功能测试、编写更新日志、 编写使用说明、通知用户...），红色部分是程序员工作内容（模块看似少实际内容很多，特别是当各种bug发生时）。
产品研发流程
二、需求分析之评估价值辨别真伪
挖掘需求本身，评估需求价值，辨别需求真伪是产品工作的重中之重。需求是产品输出的源头，我们会接到来自各方的需求：业务方反馈、老板或leader的个人想法、业务发展或产品本身的迭代功能……之前项目，从需求收集到需求输出，考虑多是需求价值，即这个需求到底有没有必要做，做了之后可以为我们带来什么？现在考虑更多的是需求真正是为了解决了什么问题，是否有可替代的更好的方案？而不是用户反馈说，简单的添加一个什么样的功能？或把这个功能改成什么样式？用户想要什么不等于真实需求；可以怎么做不等于应该怎么做。需求分析理论我们都知道，如何把理论在实际工作中真正应用起来，需要不断实践分析总结（这是现阶段我感悟最深的一点）。
产品经理如果想不清楚就开始做需求，一定是带一大批人跟着你踩坑，需求变来变去，实际都是没想清楚。所以我们大部分的时间一定是在思考需求本身和完善逻辑，画原型和写文档只是产品经理的“副业”（也可以说是产品经理的基本功，关于这个基本功，我也仍在修炼中，尽量各种能力并行前进吧，只不过分清主次去强化能力）。
辨别需求真伪(重中之重)
三、需求评审之背景讲解
之前我所在的项目组开需求评审时，我是一上来就跟开发讲功能点：我需要一个什么功能，这个功能应该做成什么样子。如果开发不了解需求背景或需求目的，他们就真的只会按照PM的口头意思或者原型原封不动的去“实现”出来。现在我所在的新项目组，对接的程序员是产品出身，当然这边对业务的分析要求相对高一点，合作下来让我知道如果开发了解需求背景，也会有自己的思考，去看这个功能合不合理，或以一种可拓展性更强的方式来实现。
但不管是前项目组的程序员还是现项目组的程序员，都很感恩，没有他们，就没有所谓的功能实现和bug修复。产品经理也就干不下去了😂。
自制的感恩图（在网上找了一大圈，没找到产品经理和程序员相亲相爱图，全是“相杀”图🤣）
四、产品分析之竞品分析
做产品设计时竞品分析是必须要做的一件事儿。大到项目立项时的竞品行业分析、产品战略，小到产品设计时具体的某个功能，你都要去借鉴，去对比，去分析。如果竞品没有直接显现的功能，需要触发某个条件才能发生，那么你就要把自己当作一个用户，去体验它的完整流程。
五、产品设计之情况分析
- 具体分哪几种情况？
设计前通过脑图列举出所有情况，再思考有的情况是否可以合并，等各类情况都整合确认之后，再去做设计，效率和质量都提高很多。 - 是否考虑了异常情况，边界情况？
- 流程是否形成了闭环？
在新增一个功能时特别要注意对其他模块的影响，最好的做法就是把自己当作用户，反复体验整个流程，关注点不能只在新增的功能点上。
其实还有更多的注意点在产品设计过程中应该考虑的。（目前经验较浅，暂时总结这几点）
六、文档撰写之条理清晰
目前我工作的主要内容多数是在已有的功能上做重构或优化，PRD文档在开发的过程中一次又一次被挑出描述不清楚，尤其是写类似“和XXX功能效果一致”这样的话。所以，这里我要特别说明的是在已有的功能上做重构或优化，需要在文档中讲述新的需求是新增、删除还是更新之类的；同时文案也要易懂，不存在歧义。我几次表述存在歧义，导致程序员截图来询问，这是什么意思，或者说这里是不是矛盾。
原型上，需要标明当前页是从哪个页面或哪个按钮跳转来的？当前页返回，又是回到了哪个页面？同样得，弹窗上的按钮，“取消”也好，“确认”也罢，必须要写清楚点击后的效果。是又发生了页面跳转还是停留当前页？如果这些不表述清楚，程序员会在实际开发过程中根据自己的理解“自定义”跳转或者截图来询问，这样给大家的工作都造成了困扰。
文档说明（目前做的一个issue）
七、 产品测试之场景罗列逻辑清晰
关于修复的bug（添加的新功能应该在写PRD时就罗列好场景和逻辑，这有利于程序员理解并正确的进行开发工作，也是在为测试做铺垫），测试之前用脑图把场景案例罗列好，理清其中的逻辑结构，然后按场景顺序一项项进行，才能有条不紊的开展测试工作。一上来就开始测试，思绪多半是混乱的，逻辑也是不严谨的（但自己会误认为自己是清楚各种情况的，觉得画脑图是多余的），这就容易造成测试返工，即走到某一步选择重测（因为漏了其中某一模块的数据或功能检测），也容易造成漏测某一情况，而导致上线后出bug。
测试场景罗列
八、项目跟进之快速解决问题
在实际开发过程中，具体的细节问题往往比自己想像的多很多。也经常发生：用A方案好还是B方案好？这个时候需要产品的判断力和决策力，在最快的时间内拍板采用哪种方案，从而快速解决问题。项目上线后，线上产品出现异常，要能最快找到问题并协调开发将问题解决。这个过程需要我们不断摸索，慢慢学会分析问题原因的能力。
最后，写几条最近几个月关于产品工作的一些感悟，和大家一起共勉。
1.多关注业务，先弄明白业务是什么、业务遇到了什么问题、业务怎么做，基于此并结合自己的产品设计能力提供产品解决方案。切记不要用“我觉得”、“我认为”、“我想”去看待产品，拍脑袋做的需求往往增加开发返工的成本。
2.画原型和写文档是产品经理的基本工作，真正核心是做需求。
3.做需求前一定要想清楚需求价值。提升体验 、提高效率、降低成本 、增加收入中的一个或多个。想清楚了再开始做，一个点都没找到的需求要驳回。
4.每做一个模块需求，都需要复盘和总结，走过之后再去看当初为什么没有考虑到位。
5.永远保持好奇心、自己去尝试，如果自己可以做到的，就不要让开发去处理。
细细想来，其实产品是一个很有意思的岗位，他需要各种软实力，比如你的快速决策能力，你的高执行力，你的语言表达和沟通能力，你的创造力，你思考问题的方式等等，这些都需要去锻炼。
产品经理的必备素质
人生本就是一个不断升级打怪的过程哈，不断打破自己的边界，挑战不同的事情，走出因习惯而形成的舒适圈，这样的人生才有意思啊。（好励志的感觉，当为自己为大家打打气，革命尚未成功，同志仍需努力哈）
往期文章：
职场反省|一年工作小结
B端产品的交互思维与设计说明
好啦，本次文章就到这里啦~ 让我们一起成长！O(∩_∩)O~
网友评论