写在最前面
Apple是PMO背景的PM。本文是TA在唯品金融互金风控团队担任PM期间对产品经理工作的心得体会的一小部分。分享出来和大家交流探讨。
在步入猪年之际，结合过往的经历，总结一点心得体会。以期在激励自己的同时，为后续不断进行总结与回顾起个头。万事开头难，希望自己能坚持下去，在不断的总结迭代中，稳步提高自己的认知。
一个产品从需求的提出到上线落地，直至后续业务反馈，产品的整个生命周期，每个环节都和产品经理息息相关。产品经理的Owner意识尤为重要（PO=Product Owner）。做为Owner就需要关注方方面面，在这里对三个方面做下小结。
#1：需求的沟通
个人初转做产品经理时缺乏方（tao）法（lu），不敢一个人找业务方。一方面性格比较慢热，不能很快的和业务方熟悉起来；另一方面胆子小，也不知道问什么，问出来的东西比较Low。碰到“讲道理”的业务方还好，如果碰到强势或不讲理的业务方会越来越不敢去面对，挫败感很强。
随着经历的丰富，经验的逐渐积累，稍微总结了一些谈需求的技巧，在我的工作中经常用到，实际效果还不错。
首先，做好准备工作。在和业务方聊之前，先准备一些自己需要的问题，可以先从了解当前的现状是什么开始。比如：当前的工作流程是什么、谁在什么情况下干什么事情、他们使用什么系统，想要吐槽什么，这些问题可以了解“过去”，以便和“未来”进行对比，即做这个需求的价值是什么。举个例子，在贷后风险产品的一个环节中，需要收集通过快递发出的确认函的配送情况的反馈。当前的现状是快递员配送后，手工填写一张表格带回站点；站点人员手工逐个汇总成excel表格，根据站点、省市、大区的行政划分逐层汇总，最终交由业务线的负责人进行追踪分析，关注确认函发出后的业务反馈效果。这个整体流程的梳理和理解对于理解产品大的场景非常有帮助。
第二，痛点驱动
了解当前的做法（流程、方式、做法等）有什么问题或待改进的地方（痛点）：大部分业务方能清楚想要解决问题，有时会给出解决方案，此时，需要自己从整体流程、数据流、合理性、甚至合规、安全等等方面综合考虑。毕竟直接说“我要吃肯德基”的业务方较多，而不是告诉你“我饿了”这个真实需求（这里借用壹叔《产品之旅》一书中的小故事）。基本上，业务方没说出来的很有可能才是痛点。接着上述确认函的配送情况收集当前现状继续说，从业务方的描述中，会发现如下几个方面的问题：
人工介入环节多，易出错，过程不可控（有可能是任意填写、整理时也易出错）
时效性差，需要等到整理之后才能知道结果，早已过了线上线下配合的最佳作业开展时机
耗费人力，不能更好的关注业务。
了解了这些业务现状的特点，现状与业务方的期望之间的距离就是痛点。当前最紧急的需要迭代的内容，结合资源忙先程度，第一个迭代的范围自然就出来了，优先级也就有了。还有一些业务方会直接告诉你“我要在这里加个按钮点击后可以...”。如果听到这样的需求，基本上描述的是一个伪需求。遇到这种情况，有2种方式可以解决：
抛开系统层面，聊聊业务方当前的工作内容、工作流程，以及为什么这样做。尝试理解背后的动机和原因。如果业务方不肯透露更多原因和细节，需求属于伪需求的结论可以得出了。
和真正使用系统的伙伴聊，最能深刻体会他们的痛点，获取一手需求。这样就会有更好的解决方案，提高业务人员的工作效率及准确度等。简单的比如，公司内部系统之间带参数的简单跳转，能减少复制粘贴动作，浏览器切换动作。复杂的，比如个案分析，可以系统的将与人相关的各类信息，基本信息、各类地址信息、行为轨迹等通过一定的逻辑分析以结论性的内容呈现在案调人员的屏幕前，这样提高效率和准确度的同时，对个案的标准是一样的。
#2：需求到PRD
最初开始做产品经理时，认为PRD是产品经理的产出物，完成PRD就是首要目标，所以当时的状态是拿到需求就开始PRD。特别勤奋，经常加班，反反复复的修改。这样的后果就是时间耽误了，成果寥寥无几，自己很累；天天加班，进步特别慢。当我逐渐意识到，不能为了写PRD而写PRD。这也是初入PM行当时常犯的一个错误。PRD只是和其他团队成员同步信息的一种文档工具；是后续查阅回溯问题时参考的依据。我调整了把需求转成PRD的步骤，不同环节关注不同的内容。
先梳理出大致流程，包括系统之间的数据流、业务流程（包括正/逆向流程、异常情况处理方案）、系统由哪些团队使用、每个团队干什么事情，带着流程和各相关方进行方案初步沟通，得到反馈后进行调整。确定方案无误后，拆分模块，细化各个模块流程，出第一版原型（页面原型即可，具体逻辑不需要写出来，能口述贯穿即可）。完成这些后，再次和各方沟通确定，此时确定的内容涉及整体流程、各模块内部的详细流程、页面交互等，采用场景带入的方式去讲解。
确定了主流程、主场景后，就可以补充细节了。比如模块之间传递的字段、界面交互、数据格式、保存逻辑等等。整个过程中需要考虑异常场景兼容方案、灰度方案、简单的监控（以防系统异常无法及时获知及解决，特别是量大的业务，比如交易业务；自动化的详细监控可以滞后进行）、合规、安全等方面。
另外，总结设计原型过程中的几个小技巧：
平常积累一些组件，我个人积累了一些简单的组件，比如：时间段查询、下拉框（Axure自带的不太美观）等
Axure官网经常会有免费且常用的原型部件库，下载下来导入本地安装目录，即可随时取用，详见https://www.axure.com.cn/
最近尝试使用了下墨刀（https://modao.cc/），虽然很早之前就听过，个人感觉比Axure好的地方在于 1) 在线原型设计工具，无需安装（当然也有功能稍微强大点儿的安装版的）2) 天然集成了常用的组件，无需自己去摸索查找。3) 预览不限浏览器，Axure在Chrome浏览器预览时需要安装插件。当然，Axure也是一款强大的原型设计工具，根据个人习惯选择即可，二者的快捷键不同，刚开始切换会有些微不适应。
对通用的常态化组件，进行统一说明。在项目经历中都能信手拈来复用，达到事半功倍的效果。
界面布局，比如对齐、居中、水平等间距等等这些苦力活放到最后做
时刻紧绷一根弦：画原型不是最重要的，重要的是原型背后的产品方案
对于界面交互遵循的一些基本原则（其实是我的血泪史）：
能够让用户选择的不让其输入。比如系统预设的各种编码。
一次操作能够完成的不让进行两次操作。比如排序采用拖动的方式，而非手动排序。
虽然是中后台的系统但也要考虑易用性，交互符合人的常规意识。比如重要的字段排在前面。
#3：让AHA留下
无论什么岗位，针对工作中遇到的问题、突然闪现、被击中的AHA Moment（沟通过程中激发的思考要点），一定要及时记录“防蒸发”。否则，事后再提起或需要用到的时候，将要消耗成倍的时间来解决，并且还打断了现有工作节奏，实属“划不来的买卖”。及时记录的方式有很多种：
1) 有道云笔记
2) 手机备忘录：随身携带的手机，随时随地都能记录
3) 周围也有小伙伴使用录音笔记录
及时记录后，可以在每天下班前或早上其他伙伴还没来上班的时候，进行下归纳整理记录在纸质笔记本上，加深印象的同时，会重新再思考一遍，或许会发现一些新内容。
最后送给自己一句话（与各位共勉）：既然选择了“人人都是产品经理”这条路；不管怎样，跪着也要走完。对产品有敬畏心，不断地打磨和丰富自己的技能域，在高质量交付工作的同时，提高自己的能力。
写在最后面
产品经理需要在业务、运营、开发、测试、安全、合规监管、数据、模型等各方之间（通过产品）建立连接。对硬技能和软技能的综合要求比较高。在工作过程中以一定的方法论作为指导，在具体的工作中不断的总结归纳，形成自己的方法论才能走的远、走的稳。
