不知什么时候起，生活的节奏就快超过我的想象，我们在这一秒的欲望，恨不能下一秒就满足。人们都彼此你追我赶，不知道要去何方。
Life is full of surprise
Sometimes we excited
Sometimes we sad
But in the end
Every color fading in the wind...
又是一股陌生的海浪向我拍来，想到了《敦刻尔克》里那些落水的士兵，好在，我们都知道应该往哪个方向游去……
逃生的路上，遇到的同伴各色各样，有的喜欢独来独往、有的乐于互助帮忙。至于我，也就按自己的节奏走着，没啥好慌张。
迎着这股海浪，回望自己浸淫在互联网的这些时光，试着讲述自己的过往，分享自己存储的能量。
产品，尤其是互联网的产品，人们喜欢说痛点、刚需、高频……但是实力派们，往往是站在上亿的用户基础上，再回想自己还能做些什么。需求？问题？都是从用户的每一次打开、每一个点击、每一下滑动开始的，本来就没有尽头，只是看能提供更好的服务。而不仅仅是听用户说自己的需要，那些只是海面上的冰山，水下那90%才是用户心里真正的诉求所在。
当今世界，每个人身边的机会太多，但是很多人最自己的了解太少，以至于并不知道真正属于自己的机会是哪个，以及自己真正的机会是什么……趁着酒后的三分清醒（喝了点比利时的浅粉象，酒精度8.5度，已经算是啤酒中的烈酒了），聊聊我对于产品的浅薄理解，希望对各位看客有所帮助吧。
1. 缘起。
大概也就是从2014、2015年起，开始对团队不断灌输一个概念：做产品的核心，就是要明确一切“从哪里来、到哪里去”。
怎么解释呢？
比如说需求，我们常听说“用户有这样的需求”，这个需求从哪里来的呢？从用户么？我不这样认为。
虽然是由用户提出的需求，但是真正的需求，是用户提出这个需求时候的动机。“我需要一个统计报表，能展示ABCD四个数据的变化趋势”。那么这个报表是用来做什么的呢？是用来解读某个产品的健康状况？销售情况？活动进展？推广结果？……我所知的报表的目的，往往是用来做某个方面的决策依据的，所以真正的需求是建立一个清晰的数据模型来表达当前的业务健康情况和趋势。
这就是从一个表面的需求，去挖掘真正需求的一个简单例子。这个过程中，需要用同理心去理解对方的诉求，如果不理解也没关系，多问几个“为什么”会很有帮助，当然，需要用请教的语气和态度，不然只会是一拍两散……
2. 际会。
于是，当需求确认了，接下来要做的就是设计业务模型了。
业务模型的设计根据实际情况的不同，会遇到不同的局面。有的比较简单，比如只是收集报表统计的所有数据类型，然后设计成一张直观的图表（一般excel就能满足了）；有的十分复杂，比如要统计某一次运营活动的效果，区分不同渠道、不同推广方式带来的用户情况，然后还要分析新用户和老用户的活跃情况……这种时候，一张报表是无法满足的，就需要考虑在一个界面中用尽可能少的图表来完整的表现出来。这就要先整理分析的维度，比如按渠道、按推广方式、按新老用户、按活跃度，其中新老用户的活跃度是需要做对比的，所以要在同一个报表中展示；
于是最后我就整理2个表：各渠道新老用户活跃度对比、各推广方式下新老用户活跃度对比。
（你完全可以不按照这个去整理，因为如果需求是要一个3，你可以用1+2、也可以用1*3、还可以用6/2，方法从来就不止一种）
3. 風起。
设计好业务模型之后，就要把模型用所有人能看懂的方式展示出来了，比如PPT、线框、手绘……根据团队熟悉程度和个人习惯酌情选择，没有统一标注，只求所有相关人员能够达成共识，明白最终要产出的东西——原型图。也就是成品最终呈现出来的样子，尺寸、颜色、动态效果、跳转流程……原型图不只是一张张静态的图片，而必须是重现出用户真实使用时的场景。
比如手机app或微信H5的效果图，就应该是在手机中打开查看，才能感受使用者在手机中看到时的心情。这种时候才能确认每一个点击后的动态效果是否能让用户感到安心，不会让用户觉得困惑和迷茫。
做原型图的时候也很简单，只需要把效果图放在合适的屏幕里，按照预期的顺序一张张展示，就能够基本完成最小可用性测试了。只有确认了原型图的可用性，负责实现的技术团队才敢放心地进行开发测试，而不用担心“需求又TMD要变”了。
4. 存在
确定了需求和原型，个人认为一个产品50%命运基本确定了。然后进入到了实现界面和功能的研发阶段，也是老板们最迫不及待的阶段。作者认为，这个阶段决定了近30%的产品命运，因为这个阶段的结果与预期的匹配程度，直接影响到用户对产品的真正体验。
在这个过程中，从业务设计者、交互设计师、开发工程师、测试人员，到运营客服，几乎都在忙于一件事——沟通确认。
确认用户使用的流程是否正确，每一个输入位置、字符长度、数据类型、格式要求是否正确；确认每一次点击按钮之后，给用户的反馈是否恰当；确认用户看到的是当初设计的样子、用户的每一步操作都会得到正确的反馈和引导；
除此之外，更要确认界面上的展示内容、用户录入的内容、用户访问和操作的记录都被恰当的加载和收集。毕竟对于计算机系统，本质上就是一套“输入-处理-输出”流程。每一个输入、处理、输出（反馈/显示）就是信息化产品的价值体现。三者缺一不可，否非就没有存在的必要性。（回想几年前的智能手环，究竟什么人才需要随身带一个计步器，告诉自己每天走了多少路呢？在我看来这简直就是主动让别人来奸视自己，算是自虐么……）
所以在这个环节，不是说把需求和原型、效果图、说明文档……一股脑儿扔给研发的同事就可以不管不问了，反而是需要保持高频的互动和沟通，过程中才能不断打磨和完善对需求的理解和支持，及时纠正产品设计的一些错误和YY，回归到用户需求的本质上。
5. 打磨
每一块精美的玉佩，都是从不起眼的石头中被发掘出来的。古人制作玉佩，先从其貌不扬的原石（基本就跟被江水冲刷过的石头差不多）中挑选中合适的原料，经过切、磋、琢、磨等工序，才终于能做出一个精致光滑的玉佩。
套用到互联网产品的套路中，切就像是需求分析，一层层剔除不需要的、干扰的表面现象，触达真正的需求本质；
接着是磋，也就是产品设计，将打算做的需求制作成低保真原型、高保真原型、交互原型、需求说明文档……，某个版本的最终样子逐渐清晰起来；
然后是琢，研发人员开始按照设计图纸一点点精雕细琢，刻画出业务设计人员脑海中的产品形态，并最终可以交付使用；
但最后的磨，是最枯燥、却也是最重要的一个环节，直接决定了用户的最终体验。(作者想不出谁会买一个能磨破皮肤的玉镯子，除非是送给得罪了自己的人……）
磨，是最后的打磨和抛光，是让用户体验到产品用心程度的关键环节。所谓“匠人”，也就是在作品完成后还要不断的改善、优化，直至自己已经觉得尽了全力。这样的作品，用户从接触的那一刻开始，就能够感受到该产品的与众不同，如果符合自己的品位，自然是爱不释手。
对于互联网产品，“磨”从产品测试验收开始，“磨”完一个版本，就会有一批新的需求和bug可以进入下一个排期了。作者产品生涯的总结之一就是“需求是做不完的”，所以没有什么是来不及的，所有的“来不及”都是项目管理能力不足的提现（可不是给项目经理甩锅，毕竟项目管理包括“需求管理”这个环节）
6. 后话
作者身边有不少非互联网行业的朋友，觉得互联网产品需要具备深厚的知识储备、或很强的专业技能储备。我只想说：你们想太多……互联网行业的产品经理至今还没有形成一套完整的知识体系，却反而形成了很多不同的分支和流派（BAT这些你懂的），每年都有新的词汇被造出来，但是公司业务的本质却很少有改变（比如作者认为，共享经济和传统行业的渠道分销没有本质上的区别，只是用当下的技术、在当下的环境里大大提高了效率）。
但是产品经理之所以会成为一个独立岗位（虽然目前很多公司的产品经理只是替老板画画原型、写写文档，但趋势上，产品经理必然会成为需要背负业务KPI的销售类职能，毕竟，如果不能创造价值，算什么产品？），也必然会有其相应的任职要求和岗位职责，下面我就以自己认为产品经理需要的基本技能作为本篇的结尾吧。（实在说了太多了）
a. 了解互联网产品的基本使用环境（有多少种类型的终端、有多少种不同源生内核的浏览器、有多少种操作系统、不同网络的优势和缺陷、互联网产品的软硬件交互流程……）；
b. 了解业务流程和核心指标（公司是做什么业务的，有什么优势资源，有哪些收费业务，用户是谁……）
c. 了解互联网产品的数据监测（什么样的产品/终端适用哪个统计工具、不同统计工具的优点和缺陷，统计数据的定义和对于产品优化的意义）
d. 能够将需求转化为量化数据指标，根据数据证明需求设计和执行效果
e. 良好的沟通与表达能力，可以用语言、绘画、肢体、心灵感应（开玩笑哈，U Can U Up）……，让同事、用户能够理解产品设计的目的和目标。
觉得还没过瘾？当然，区区几千字怎么能把我十年的产品经验表述完呢？不过与其这样酒后乱语，不如等某天醒来，静心凝神，从头梳理，给各位看官更完整的内容，我希望，那是一套带着爽爷烙印的产品设计框架/语言。
古来圣贤皆寂寞，惟有饮者留其名。仰天大笑出门去，午夜之前回家来。后会有期！
