我的2017产品总结
上周五刚刚结束了一段长期出差，回到上海，猛然间就发现日历已经走到了年尾。这一个礼拜，整理了一下自己负责的产品功能和设计文档，赶紧写下一年的规划，然后也琢磨着得动笔作一个自我的年终总结，于是便有了这一篇文章。
差不多在9月份，也就是转入产品半年多以后，我才终于有了那种脚踩在了地上的感觉——隐约知道如何从得到一个需求进而展开后面的产品设计，也算是给了自己一点继续往前走的信心。而后面2个月的出差，直接去和客户接触，去对接销售，技术支持的经历，也是让自己收获很大。那么接下来就好好谈谈这一年的学习：
一、产品思维
作为产品经理，第一个面对的应该是产品思维，研发，UI手握的都是硬核技能，而产品能靠的说白了就是“一张嘴”，能依仗的是大脑的思维，只是这种东西真的是玄之又玄，旁人一时也无从分辨好坏。但这个缥缈的产品思维却又是能量巨大，假设同等条件下做同一个产品，两个人思维差异导致最终产品的相差之大真的会让认难以想象。而为了更好的理解和掌握，产品思维我自己分了个类，大致是3个：系统性思维、结构化思维、商业化思维。为了比较好的阐述，下面就以我手上的2B数据分析平台为例
首先是系统性思维，有以下两点：
1）业务系统性。接触产品的时候，首先了解的是业务，接着了解业务上下游的产品和情况，知道自身所属的业务链环节，输入与输出是什么，哪些是影响自己的关键因素，哪些是自己会影响别人的关键因素，同时根据查找和调研的资料对于行业整体情况有了解，并进一步判断公司处在这个行业的什么水平，发展到了哪一个阶段。这样做的好处就是，给产品定位和规划的时候，能够比较清晰的知道“客户在哪，麻烦在哪，值不值得，应该朝哪边”，避免挖坑的重要手段。
2）功能系统性。平台的一大特性是功能项多，数据繁杂。针对前者设计的时候都会按照需求或者特性，将功能模块化，尽量在内部相对独立，以便于逻辑处理和开发。但是呢，产品的开发都是持续性的，甚至经常推翻重来，所以，中间不可避免的就是对某个模块加或者改，而这个时候，必须要系统性的考虑功能，改动的地方需要调用哪些数据，对剩下的哪些模块会造成影响，发生冲突能不能解决等。一旦遗漏，就会出现新功能的开发是完成了，原本的却不能用了，甚至新旧功能冲突都不能用了。
所以，面对复杂的业务流程，以及相对应产生的大小功能模块，时刻保持系统性的思维，从“高处”看清整个产品的本质，同时知晓其中的脉络和关系，对于产品经理能不能把一个产品做得符合客户需求，并确保不出错是非常关键的。
然后是结构化思维，每一个产品都会有自己的结构，从上之下，从左至右，进行分层，然后每一层再细分到每个功能。而作为一个数据分析平台，跟着数据走可以最快最明了的梳理出其结构：首先是数据从哪来——输入层（数据来源，数据清洗，数据存放，数据接口），然后是数据怎么用——应用层（数据分析，数据调用，数据查询），最后是数据展示——表现层（数据展示，可视化），基本上一个数据分析平台就是这三大层。接下来按照结构化思维，再针对每一层的模块细化，落实到功能点，按照逻辑结构和设计结构，一 一规划，比如数据来源：对接——用什么方式传输http，ftp，webservice等；格式——以什么形式，文本，excel, zip , xml等；解析——用什么方式解析，python，java等等。等把所有的模块拆解完毕，整个产品的结构图就出来了，这样的好处，不言而喻，如果是对一个新产品，用这种方法能够快速对其进行了解，而且以后无论是对需求做出改动，还是产品出现问题，都能够迅速做出相应的对策。
最后说说商业化思维，商业思维属于产品思维里面比较高级的层面，这个高级在两方面，一是商业思维其实基本上是一个产品从始至终的目标，属于宗旨（不是说所有产品都只为了商业目标，现在以改变世界和创造未来的产品有很多很多，但无论如何绕不开的一件事就是先活下来，所以商业目标是必须的且必要的）；二是一个PM要想尝试和驾驭商业化，基本上是不可能在没有经验的情况下上手的。所以因为这两个原因，现实状况中，商业化绝大多数PM都没有机会了解，只有随着行业深入和工作年限增加成为高级、资深产品之后，才能去实践和规划商业化层面的东西。也就是说，商业化思维，是你从始至终都要考虑，但又只有多年沉淀之后你才能具体接触的东西。而目前作为刚入门不久的产品新人来说，商业化思维自然是没办法结合实际案例介绍了，等以后成长一段时间再补充吧。
二、产品设计
说完产品思维这种概念性的东西，聊点产品设计的实际操作，一年里，跟过的大小功能也有几十个了，然后需求说明，原型设计跑了这么多遍，也算是有了那么一丁点儿心得。
第一阶段：为了画原型而画原型
刚接手产品工作的时候，其实心里比较清楚和觉得实在的就是原型设计，毕竟那些方法论啊，概念啊，没有跟过完整的一个项目实在没底，但原型设计，就像是UI的PS一样，那就是硬核功能，画不画的出来，好看不好看，一见便知。于是，当我接到一个功能的时候，只有一个念头，全身心投入，仔仔细细不放过任何一个点。然后得到的结果就是，1）耗时特别长，产品设计的进度落后，耽误开发进程；2）容错成本高，由于每一个模块都是抠得很细，一旦需求改变，前面费心费力的东西瞬间推倒，然后全新的内容又是一遍；3）被原型设计占据过多的时间，忽视产品本身的思考，本末倒置。所以这一阶段完全是为了画原型而画原型，而不是为了满足需求，实现功能而画原型，估计都是产品新人的通病。
第二阶段：简单用草图，复杂挑重点，能不画就不画
差不多半年后，渐渐懂得在原型和设计之中找平衡，而那个时候，手上需要跟进的功能点和问题越来越多，再按照以前认认真真画原型的话，那估计是天天加班不回家才能完成了，而且这么做肯定不对。于是，为了提高效率，赶时间，再和开发人员沟通的时候，将自己梳理和思考过的设计内容，在白纸上用笔直接画起了草图，一边说一边画，确保开发人员完全理解我的意思和意图之后，就可以让他们动手写代码了，然后，开发当中持续保持沟通和纠正。实在遇到比较复杂的功能，忽略那些用一两句话就能让开发明白的细节，认真把功能重点设计处理来，画出一个完成度80-90%的原型图，给到开发就可以了。这样，大幅缩减了画原型的时间，转而在沟通上做更多的跟进，并且保持必要的产品思考时间。
因为需求说明和产品设计两条线混在一起不大好写，所以在这里单独展开一下没提到的产品设计的两大部分中另一部分：需求说明书PRD。撰写PRD的过程也是一个渐进认知的过程，作为新人最大的问题不在于需求说明书的具体结构和形式，而是在文字表达，无法用简洁而有效的语句让阅读PRD的人快速而清晰的知道产品功能的设计初衷，所以往往表达模糊，句意冗余，细节遗漏。而往后不断的借鉴别人，和自我修改，逐渐形成稳定的表达结构，文字用量大幅下降，自己的撰写效率和他人的阅读效率都会提高很多。而刚才说的原型设计的第二阶段，因为使用草图和挑重点画原型的缘故，在后面配上一份良好的PRD是很必要的，细节落到纸面，可以减少过多的重复沟通，也能弥补原型设计的细节遗漏，最终为产品思考腾出更多的时间（能够用来思考的时间，个人认为，在保证工作正常进行的时候当然是越多越好）。
综上，产品设计中，以充足而准确的产品思考为重，然后将结果和设计想法落地到纸面形成一份好的需求说明PRD，再先重后轻，捡大抛小的完成原型设计，接着拿完成PRD作为基准，做好与上下游部门的充分沟通，准备产品开发。
三、产品教训
毕业一年半以来，不管是工作也好，还是职场人际关系也好，磕磕绊绊踩了很多坑，也得到了一些印象深刻的教训，在这里总结一下列出来，一是让自己再回顾和思考，二是也希望能够给大家提供参考：
1、任何安排的事情，都千万记得要拿到反馈！别人安排自己的，那么在允许时间内主动提供反馈，事情是否能够完成，什么时候完成，能达到什么程度。自己安排别人的，及时跟进，在deadline之前提前把握进度，预留调整时间。
2、重要事情沟通，千万记得落实到纸面！会议纪要，每个人都会，但是，平时更多的事情都是以非正式会议形式对谈而决定的，所以，别忘了，在这过程中一样要用笔记录，或者会谈结束之后，整理出来。既能防止自己遗漏细节供别人参考，又能够作为方案的留底回溯原因和责任，避免无穷无尽的扯皮。（PS：笔记纪要，条理清晰这个点，不是说说或者自以为感觉良好，需要努力修炼，可以多参考参考优秀的人。举个自己的例子，某次和隔壁项目组的大神项目经理去北京开会，整个会议持续了2个多小时，我当时全程做笔记，但是回去的时候整理回忆纪要，发现中间走神或者因为参与讨论，漏了一些东西，还有就是条理和细节不够，只能和那个项目经理沟通，他来发，等第二天邮件收到，打开他整理的笔记，整场会议，什么问题，谁发言，表达主要点是哪几个，结论是什么，依次详详细细，清清楚楚，真是刷新了自己的认知，心想清华的就是牛逼，佩服佩服，盯着这份纪要看了好久，实在惭愧）
3、时刻保持“这件事情我能做什么，我应该做什么”的清醒认知。很多时候遇到团队型解决的问题，往往会因为尖锐突出的东西而过多吸引和分散自己的注意力，导致忽略本身就要做的基础工作，无法跳出事情来客观冷静观察，一旦能够清醒认识到自己要做的事情的时候，会极大提高效率和自我的成长。
关于2017年的产品总结，暂时就写到这里了，前前后后拖了2个月，而最近也是准备离开现在所在的公司了，传统的软件行业还是发展过于缓慢，壁垒高而窄，危机意识告诉我再待下去的话，也许就再也跳不出来，快不起来了。所以2018年一起加油吧，希望大家新的一年越来越好，谢谢！
