产品经理基本功：想清楚讲清楚

　　开始实习已逾一月，在段时间里我也大大小小的经历了数十个需求。从最初对业务一无所知，只了解哪些书本上抽象的概念到后来能够较为独立的负责一个需求的生老病死。有许多的成长，也有许多的体会。
　　通勤
　　因为租金昂贵等各种原因，实习的公司离家很远，每天单程的通勤时间超过1个小时，并且一种交通工具是不行的，下了地铁还要赶到接驳点坐班车。
　　路上的时间很长，思考的时间也就多了不少。
　　站在上海嘈杂的地铁里，人群拥挤的抬不起来手来。左手拎着饭盒，右手扶着扶杆，偶尔累了还要换换手，玩手机变成了一般人难以完成的高难度动作。于是人群很吵，心却变得很静，有许多的时间可以去思考工作中的那些对与错。
　　在实习之前，我也写过一些关于“产品思维”的一些文章，对于好的产品经理十分敬仰，觉得思维的广度与深度令人着迷。当然，实习之后我也并没有觉得那些是不重要的，但却更多了一层脚踏实地。思维的广度不能只靠资讯的积累，思维的深度也不能只靠天马行空的想象与推测。
　　建立起自己的产品哲学观前，先要能够做好事情，这是产品经理的基本功，也是公司对于任职者的基本要求。相对于技术、设计，产品经理这一职位学校并无专业设置，也无技能训练，好像人人都能走进门，好像人人都能做好事，但其实并非如此。
　　一个合格的产品经理，你至少要做好两件事：第一，想清楚；第二：讲清楚。
　　一、想清楚
　　对于产品er来说，每天打交道最多的不是技术也不是设计，而是“需求”，这些需求可能从别的业务方处来，可能从老板处来，也有可能从产品er里的小脑瓜里冒出来。
　　公司里常常发生的一种情况是别的业务方来了一个需求，产品er觉得“emmm好像还不错，正好两周一更版，加进去吧！”结果做出来的效果可能不尽如人意。
　　对于产品er来说，需求并不完全由自己控制的，无论是实现还是舍弃，到面前的需求就需要产品er认真对待，去思考：
　　这个需求解决了什么问题？
　　它对用户意味着什么？对公司又意味着什么？
　　这个需求是否有可以替代的其他的实现方式？
　　本人在一个以视频为核心产品的公司，前两天直播频道给我们部门提了个需求，希望我们可以在弹幕上给直播频道的主播们进行引流，所以希望他们能够导入弹幕，上面有主播信息以及跳转到相应主播间的button。
　　在接到这个需求之后，我们首先需要去认真的思索这个需求：
　　（1）这个需求一定要做吗？它的目的是什么？
　　这边我们主要考虑的还是主播频道那边的目的：引流，同时希望优化用户体验或至少不对用户体验造成伤害。
　　（2）是否有可以替代的方案？
　　这里我们大概想了三种：
　　主播导入弹幕，点击弹幕引流（与普通弹幕互斥）；
　　主播导入弹幕，点击弹幕引流（与普通弹幕不互斥）；
　　主播导入音轨，侧边栏引流。
　　最后用了哪个方案这里不透露了，在确定做某一个需求之后，还有许多的事需要想清楚：
　　需求是否拆解为了最小粒度？
　　需要撰写多少份prd？（前端？后台？中台？）
　　是否需要UE、UI稿的输出？
　　是否需要数据埋点？
　　是否需要ABtest？
　　想清楚是讲清楚的基础。
　　一个需求的实现需要多方的配合，但人之常情的是，通常前端只想知道前端要做什么，后台通常只想知道后台要做什么，测试也只想知道测试要做什么。但你产品经理er，你需要知道所有人该干什么。
　　通常我拆解需求的方式是先用Xmind进行逻辑的拆分，再用Featurelist进行整理总结。
　　（大致如上图，由于保护公司利益有一些处理）
　　总之，无论是使用什么样的工具辅助，最后的结果一定要是你在脑海里完整、清晰的勾画出了一个需求的方方面面。
　　二、讲清楚
　　在脑海中建立起一个需求的每个细节点之后，你还需要把他事无巨细、毫无歧义的传达给诸位实现者，通常的渠道有四个：PRD、UEUI、需求评审会议以及日常聊天软件。辅助的还包括原型图、用例图、流程图等。
　　其中的起点就是PRD，一般PRD的组成部分是文档信息、修订记录、目录及正文内容，正文内容又包括引言、特性所包含的功能、功能性需求等。
　　由于设计师会按照你所撰写的PRD去输出UE和UI稿，所以PRD里的逻辑必须十分清晰、完整，尽量考虑好所有的边界情况和逻辑漏洞，同时在PRD中用语需要规范，避免由于对于某一词语理解不同而导致效率降低的情况。
　　PRD中的功能入口设置通常需要和UE共同商讨，UE在输出UE稿后需要交给产品经理去统一同步到各位技术手上，为了避免反复修正和需求变更引起矛盾，产品需要仔细的确认UE稿，防止出现UE稿和PRD矛盾或不同步的情况。
　　在输出UE和UI后，会举行一次需求评审会议，主要是产品经理主讲，UE辅助，这是讲清楚中最重要的部分，因为语言总是比文字有更强的说服力，在评审会上要明晰各方疑惑的问题并同步到PRD以及UE上。
　　产品er们也需要去有意识的对文字表达和语言表达能力进行训练，以便更好的讲清楚。
　　需求评审会议后，开发的老大一般会进行排期，这时候开发和测试童鞋可能会来与你核对或者确认一些需求的细节，这时候你就会明白：一份好的prd是提高工作效率的关键，那些prd留下来的坑都是需要产品er后期去填的，千万不要偷懒
　　在沟通时，需要注意当聊天软件无法讲清楚时，一定要积极的去找开发当面交流，以避免矛盾的产生，另外要注意用流程的规范降低交流成本。
　　比如：你确实需要变更或许补充一个需求，一定要和开发以及测试先事先确认，再进行prd和UE、UI稿的修改，修改后一定要通过邮件或其他方式同步到各方。
　　变更时的措辞也需要注意，刚实习的时候我就曾因同步时，措辞有歧义并且错了人而和开发产生了一点小矛盾。开发、测试、产品实在是太容易相互产生怨怼的职位，各尽其职，不拖后腿，才是解决这个问题的根本办法。
　　想清楚讲清楚，我正在努力成为一名合格的产品经理，你呢？