工作感悟:初识产品经理

近半年负责一个产品的研发工作，在工作中充分实践产品经理角色，同时也要负责软件开发管理，同时作为前端代码的主编码人员，之前公司中基本上没有出现产品经理的职位，也基本上没有严谨的按照软件开发规范流程进行开发，其中有不少实践总结的经验，还有一些野路子，并非书本中可考证的内容，提前交待好，以免误人子弟。

人人都是产品经理

一个好的产品经理都在做什么，应该具备什么样的能力或者品质？

当然是一个如雷灌耳的书名，这本书不仅介绍产品经理工作方式、方法的，还在宣导一种产品经理的思维方式，甚至认为可以将这种思维方式运用到日常时候中。可我坚定认为，理性工作，感性生活。尽信书不如无书。

我觉得产品经理绝对不是人人能做的，我所说的产品经理绝对不是复述客户需求，做做客户调研，做做调查问卷就能敷衍了事的。我所说的产品经理一种过渡于软件框架设计、软件开发过程、项目成本管理的设计人员。

产品经理是就是做程序员太外向，做销售又太内向，程序员把我们当做业务人员，销售却把我们当做技术人员，这就产品经理游走于商业与技术的角色。

可往往在实践操作中最起码需要原型设计能力；设计出一个高保真的软件原型就可以搞定软件开发人员么？那就把事情想的太容易了，在我参与的团队中，产品经理要做大部分软件交互设计工作、部分架构师、大部分开发经理工作、以及绝大部分用户研究工作，很多时候还会承担前端开发工作。

产品经理在设计之初需要拥有大量的信息量储备，以寻求量变到质变的转化，有时候甚至思考一个行业中如果不浸淫多年，是无法设计出一款好的业务软件产品的，当然软件产品另一个切入点就是使用软件思维、互联网思维重构行业业务逻辑。这就需要高深的设计技巧。

我认为一个好的产品经理应该具备的是洞察力、创造力、预判力；产品经理更多的时候应该是一个通才而不是专才。

常常会听到产品经理你认为**产品的发展前景如何，在这个层面，商业目标、用户痛点的思考是焦点；当然像此类战略目标、商业目标的宏观问题，通常老板们会大量参与，在大方向上给予决策。

产品经理在此时更加倾向于产品设计，这个阶段是我认为最为痛苦的阶段，每天都处于创造力枯竭，脑力消耗极大的状态，这个阶段偏向功能级设计、编写需求文件，产生的产品设计应该是思考的随手笔记。

我在产品设计之初遇到最大的问题就是不知如何动笔，我到底要一个什么样的产品，这个软件产品在我心中应该是何种模样，产品从无到有的过程一定是种“形象化描述”，这种模糊的表述在产品设计之初有很大作用，可以在宏观层面定义出很多大的轮廓与方向还有取舍。

一个产品是无论如何也不可能满足所有的业务场景、满足所有的用户故事，我们必须选择整体的一个切面，把这个切面的业务表述明白即可，选择两三个这样的业务切面即可，也就是我们常说的用户痛点。常常说的用户痛点是需要一整套业务切面与一整套逻辑结构作为支撑才能解决的，浅层的用户痛点设计简单、实现简单，不值一提。在现在的商业环境下，简单的功能大家都可以做，没有丝毫的壁垒，唯有复杂的业务实现、高精尖的功能才会有顽强的生命力。

由技术开发转做产品设计会遇到这样一个问题，简单的功能逻辑思考并不是常规的功能使用逻辑，因为更加趋于易于实现，我在做功能级设计时就需要不断的跳出到用户视角审视我的设计，是不是一个正常的使用逻辑，会不会太过偏于程序员思维。

作为技术人员转产品经理还会遇到一个情况，在业务逻辑还没有明确时就会过细的考虑实现细节与实现难度，错失很多好的功能设计，也错失过良好的业务挖掘时机。

我还是建议由技术人员转做产品经理，必经软件思维、互联网思维，这样的良好感知，圈外人是无法通透的理解的。

用一句话说明白一个功能

一个软件是如何产生的？

做软件更像是做衣服，往往用户只会提出要一件漂亮的衣服，要一件女款外套此类笼统的要求，面对这样的要求，要如何完美应对呢，需求不明确，客户没想法，产品就做不了。。不存在的。

这将是产品设计的第一步，用一句话说明一个产品，然后不断的加入形容词。

用我之前做过的一款产品特性为例：

海洋考察用的软件

辅助海洋考察的软件指导海洋考察的软件

辅助海洋考察的工具性软件辅助海洋考察的管理性软件

我觉得产品经理的第一步并不是分析用户需求，做的第一步应该是将用户没有说完的话都补充出来，把用户没有归纳没有整理的用户故事给提炼出来。对于客户的想法，请用心听，但是不要照着做。

一个个功能的产生必须是要能容易的表述清楚的，在做软件功能设计时，很多功能的定义是暧昧不清的，甚至完全就是用来充版面的，此类功能一定会面临的挑战就是：这个板块是干嘛用的？功能诞生的理由应该是一个明确的文字表述，功能的迭代也应该是明确的文字表述，功能迭代绝对不应是需求的罗列，模块的累加。

用户故事（动作）的交叉、串联才能算是挖掘到了业务深度，做出来的业务功能才有思想有深度。

我们经常有一个逻辑是功能要先从无到有，从有到优；我真的怀疑一个很难被使用的功能，是如何变优的，对于功能的底线是要把握好的。对于“能用”的要求是需要足够高的。

当敏捷遇到产品设计

敏捷开发一直讲我们要快，我们先做出来，然后慢慢改；可是作为产品设计来说，我们更加倾向于精雕细琢，更加完善交互设计，看似矛盾的两种方式，在实际操作中其实没有太多的冲突。因为不论是敏捷开发还是产品设计，都是追求以更小成本交付用户更加满意的产品。适当的结合两个不同视角去运用到实际项目中，是较为普遍的操作场景。

比如在项目之初，在绝大多数情况下，是无法将产品的所有细节都明确下来的，而且对于产品规划人员会更加渴望将产品策略、规划宣导给更多的设计师、架构师，以便丰满产品的最初设计。我们常说的“空对空”交流就出现。

功能与设计对于一个产品业务是有范围边界的，在这样的情况下，我们需要在产品的深度与广度进行确定边界，立足于一个明确的关键业务链路去描述设计，在一个业务切面中将所有要素描述清楚。其中暗合一个道理，设计可以做的不完美，但是扩展接口一定要做好。

如果是敏捷的方法要怎么做呢，敏捷的思路就更加宽阔，我们先做一下嘛，先画一个框框，框框里面先分几块，一块放入板块1，一块放入板块2。我们要的不是完善，首先我们需要的是概念，是感觉对，是可交流、可分解。在此时倡导的是先做。而不是做细做全。

对于开发者来说，基本上开发团队是什么样的风格就会直接反应到产品是什么风格。如果团队是注重文档先行，那么产品就会是一个比较规矩，比较完善的系统，如果团队注重头脑风暴法，那产品比较容易走到“语不惊人死不休”的境地。产品不是一个人的，对于敏捷团队来说，产品是团队的，团队的风格决定了产品的DNA，不可逆势而为。

推广

客户是要引导的
做屋子里最聪明的人

参考书籍
《人人都是产品经理》
《火球 UML大战需求分析》
《硝烟中的Scrum和XP，我们如何实施Scrum》