《产品研发过程实践》（17）产品经理

作者:asky 日期:2007-04-29

字体大小: 小中大

做为一个产品经理，首先需要的是你的创意和思路，你必须去规划产品所应该具备的功能，这将使用各种分析方法和手段，比如从竞争对手的产品中进行正向和反向的思维；你需要为自己的产品构造一个好的环境，研发虽然是产品中重要的一环，但是绝对不是唯一的一环，你需要有良好的构思，来形成产品在整个业务环中的定位，需要找到各种合作伙伴来和我们一起推进整个产品在市场上的成熟，你需要根据产品在使用过程中的反馈，来考虑不断的改善（有时候，也是通过一些数据分析手段和数据分析方法，这一点，我一直认为Yahoo做得不错，他们的改进都是有系统监控数据支撑的，而不时拍脑袋出来的），并且分析用户行为，来修整自己的产品；同时，也需要为整个研发部门指明一条前进的方向，说明我们的产品在各个阶段将是什么样子的；并且你还将牵头进行产品的推广的一些工作，比如产品的关键字，产品的宣传语，产品的基本色调等等，这些都是你必须去做的。同时，象对待孩子一样看待这个产品，你必须对这个产品的过程具有一个很清晰的思路，你必须十分明白你的产品目前处于什么阶段，并且清醒地指出下一个阶段的发展方向。

在去年一年中，Yahoo的产品给我留下最深刻的印象是，他们的产品具备了良好的监控能力，我们可以很简单地加入某些代码，来监控用户在站点上的操作访问，并且能够很轻松地定义出各种综合条件的监控，这样，我们才有各种依据来说，某一项工作是否有价值，某一项工作需要改进等等。在产品设计之初，我们就必须考虑这些要素，虽然绝大多数公司未必具有这样一个灵活的监控系统，但是即使是生磕代码，我们也需要加入这些探针，为我们将来的工作来留下一些监控的余地。

以上是产品经理应该做到的一些事情。后面，我仅仅谈一些对我印象最为深刻的产品的思路，当然，这些点不足以构成整个理论体系，但是，只是这些内容在我印象中太深刻了，以至于不吐不快。

首先，如果你的产品是一种直接接第三方开发商的软件（这直接来自于以前开发的工作流引擎产品的感受），即我们常规意义上的中间件产品，那么你在软件设计之初，首先需要考虑的应该是，别人如何使用你的软件完成一部分功能，自己的扩展功能如何能够接入到你的体系中，或者你的系统如何能够嵌入到别人的系统中，这一点是非常重要的。原因是，我们并没有想像中的那么出色，很多看上去很漂亮的中间件产品，在实际的项目使用过程中，开始出现不实用的现象，这在很大程度上，形成了我们后一个阶段研发的重点，也就是说，我们必须预料到我们的产品在前几个项目的实施过程中，可能并不完善，但是，如果还要在项目中得到使用，就必然需要你的系统允许别人用代码来调度，而不仅仅是按照你的思路或者想法来构造。

举一个实际的例子，我想，很多人做过工作流系统吧，规划得比较大的工作流系统一般会包含一下的一些内容，表单生成器，工作流核心引擎，第三方代码注册工具，等等；我们为什么需要第三方代码生成工具呢？原因很简单，我们的工作流虽然定义了各种流转条件，定义了各种运算方法、逻辑判断方法等等，但是我们不能保证用户的工作流流转一定通过这种方法就能构造出来，比如某一个报销的表单，要根据远程数据库的内容，来动态定义流转到什么哪个具体的流程上，那么通过第三方组件的注册，我们可以使得这个代码类似我们工作流引擎自身携带的某些组件，根据这个组件的返回值，来确定流转方向。当然，我们说，如果一个具体的需求暴出来以后，我们对这个具体的需求进行定制化的研发总是容易的，但是做为产品来说，我们在最初的时候，可能还无法预料到如此多的需求，如果没有这些第三方代码的注册工具，我们将被项目牵着走得很累，而且产品会变得越来越象一个项目的附属品。如果我们能够定义出一种模型来构造这些业务，那么这个时候，将是你把这个组件放入自己公用代码库的时候了。这样使得一个产品能够随着项目得到成长，而不是完全象**产品**项目版这种情况出现。在这一点上请做中间件的产品经理务必记得。

其次，产品需要具备良好的设计，但是千万不要自作聪明，设计得极其复杂；这首先是从设计理念上说的，目前有一些做法，是将设计人员和编码人员分离开，独立出来一个设计的角色（其实，我并不十分赞同这种做法，在理论上，这种方案是可行的，但是在实际工作工程中，特别是不断有变化情况下，往往会发生设计思路和理念无法有效传递的情况出现），使得设计人员为了保证自己的设计成果，采用了过分复杂的设计手段进行设计。比如我举一个典型的现实例子来看，在一个业务系统中，需要进行人员通过角色和权限的一个映射关系；如果你要面面俱到地考虑，那么首先，用户、角色、权限层你需要独立分离开，并且和存储方式无关（用LDAP也好，用Oracle也好，用SQLServer2000也好都可以），而且我们为了应付SSO，也需要将服务切分开，使得服务能够远程访问，并且做接口认证和MD5加密，然后我们为了使得用户信息尽量地能够满足要求，所以，需要给角色、权限、用户建立Profile来对应具体的实体；等等，从纯粹设计的思路上来看，这种设计真的很不错，如果将来发生变化，将使得这些变化落在我们的考虑之中，但是，如果从这种理念上，来做产品的话，会使得产品的出现遥遥无期，而且产品很很长的一个时间段中，都无法稳定和投入使用（这一点，我们最好有一个觉悟，我的经验是，如果一个软件开发时间为半年，那么他至少需要额外的1年时间，进行各种改进和稳定，使得他能够让人相对比较放心的运行）。所以，我现在给自己的一个提醒是：我要避免出现两种情况，过于单纯的设计，使得将来的修改变得很困难，和过于复杂的，故意多层的设计，使得产品研发困难重重。我一般的做法是这样，在设计的时候，多考虑可能碰到的问题，但是，在具体落实在设计中的时候，仅仅把可能出现问题的地方，用一层简单隔离开，举一个例子来说，假设，我们可能需要添加一个功能，使得一个用户通过信任关系，或者被信任的关系，把自己的部分权限在某一个时间段中交付给别人，那么在权限系统的设计上就会需要一些变化；但是我绝对不会在这个阶段，就加上各种表的支持，然后需要产品支持这种特征，我只是会注意一点，在用户跨角色到权限的获取过程，必须是一个独立的服务，这样，即使我将来加上这些功能，也仅仅是在一个地方进行修改而已，不会有更多的地方需要改动。千万不要卖弄设计，卖弄设计的一个后果就是系统无意义地庞大而且臃肿，并且使得构造难度加大，部署难度加大，而用户不会为他所不需要的东西付款的。

第三，在可能的情况下，尽量保持概念的简单化，功能简单化。没有人是因为你这个软件能够完成世界上一切事情而购买你的软件的；他们只是因为你解决了他们某一方面的需求而购买的。比如Word，首先能够是个RichEdit工具，然后他会加入各种拼写校对的功能，但是这也是一个一个阶段发布出来的。而不是在一个阶段就全面提供的，因为用户也需要学习，他也需要一点一点地了解系统；你贸然推出一个极其复杂的系统，而且没有良好的概念整合能力，带给客户的将是一场灾难。同时，要记住，代码量越大，概念集越庞大，将使得软件的开发和维护越来越困难，成本的提升不是一种线性的概念，是一种指数的概念。一个包罗万象，而不稳定的产品，还不如一个简简单单的实用的东西。

不要象女孩逛商场一样，或者象我逛书市一样，看见的东西，都想拿下来。这是严重的失误。你在知道你要什么的同时，也需要明确的知道，你不要什么。不要把自己的工作，推卸给研发团队来做。比如某两种逻辑，不知道客户到底需要哪一种，很简单地说一句：“我希望能够通过配置文件，简单地切换整个逻辑流程”。这是典型的不负责任，如果你不明白什么是需要，什么是不需要的，最保险的做法是：不要去做，等你多少明白了一些再说，如果你仅仅想尝试一下，那么请尽量只做一种。配置文档不是麻将中的“百搭”，他最多只能实现你想明白的某种切换（哈哈，在2002年的时候，曾经就这个问题，参与过一次CSDN争论，很激烈，但是现在想来，也有点无聊呢），而不是什么都没有想明白的一种托辞。我碰到了不止一个如此的产品经理，希望以后能够碰到更明白一些的产品经理，而不是什么都要的孩子。

不要把眼光仅仅放在产品本身，要记住还有很多东西会影响你的决定，为你的产品或者产品线构造出来一个良好的业务环和业务圈，将使得他的生命力更顽强。这里我举一个例子，正是由于得实公司的销售和产品的努力，使得在半年多的时间中，我感觉信心百倍（随便提一句，希望得实公司的刘总能够顶住市场上的压力，把这些策略贯彻下去，刘玉璋总经理是一个很令我敬佩的人，他对于工作的执著，他的强烈的事业心，他的严谨的工作态度，他的人性化的管理，给我留下了深刻的印象。正是刘总的个人魅力，是我来到得实的最大动力。虽然我离开了得实，但是还是很珍惜和刘总共事的这段时间，这是我工作得很开心的一段时间，我想我永远不会忘记我来得实之前，和刘总在餐厅的那次面谈，以及我离开得实前夕，略带偏激的，和刘总之间的面谈）。我们提供的产品包括手机端研发的嵌入式软件，包括Syncever的数据同步中间件，以及后台的业务系统；由于这项业务需要手机端的支持（在MOTO、Nokia、Simens、SE等公司的手机上，都提供了这种服务的客户端），而且需要相对比较快速的数据传输（通过GPRS走数据，多少有点慢），需要一个市场的培育期（这是一个新开始的业务，市场从尝试到大规模接受，是需要比较长时间的，这一点是需要我们有一个心理准备的），但是公司不可能为了这个产品，无休止地等待下去。于是得实走了一条我认为很漂亮的路线，抓紧中国移动的大旗，把自己的产品和中国移动绑在一起，来树立自己在同步领域的名声，争取同步业务的单子；同时走国内的终端厂商的单子，力求能够赢得一些短期的现金流，然后，因为有终端的支持，所以，以此向其他服务提供厂商等等进行合作，以期在将来赢得一些长期稳定的现金流。当然，也许有更好的做法，但是，就当时来说，我觉得这个布局实在很不错。

顺便说一句，在2004年，一次到北京近郊去玩的时候，夜晚在院子里烧柴火，我扔了一根很长，很粗的木柴进去（这是一条四四方方的凳子腿），然后坐在边上，期待他能够燃烧起来，但是火越来越小，我很不解。结果旁边的人说：你不会烧火，独木不能烧起来，只有多跟木头支撑起来一个空间，才容易点燃；接着，把木头打断成三截，果然很容易地烧起来了。这件事情让我印象非常深刻，产品也是如此，如果单一的产品，在市场上生存，那么存在比较大的风险，无论如何，需要为你的产品设计出来一条产品线，这条产品线中的产品能够相互依托和相互支持，这样使得你在将来的市场上能够左右逢源一些。至少更容易操作。

各位产品经理啊，你们是产品的构思者，你们决定着产品的走向。如果我的团队仅仅有一个优秀的人才，其他人都比较平庸，我希望他能够担任产品经理的之职。千万不要把产品给忽略了，这将在将来给自己带来极大的麻烦。产品经理的思路如果不够清晰，产品也模糊不清楚；产品经理浮夸，将使得产品充满花里胡哨的东西，一点都不实用；等等。各位产品经理，请重视自己的工作，你的一举一动，都决定着产品叁个月以上的走向。为了整个团队，请至少充分重视自己的决定。