LifeBoxing

我的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年一起加油吧,希望大家新的一年越来越好,谢谢!


评论(2)
热度(1)
©LifeBoxing | Powered by LOFTER