大概六年前，我在一家名为“抓虾”的在线RSS阅读网站工作（如果你不清楚RSS阅读网站是什么，可以参考Google Reader）。阅读器都需要显示当前用户的未读数，抓虾的做法是给出精确的数字，明确告诉用户“你还有2456篇文章没读过”，Google Reader则显示为10+、100+等形式，告诉用户“我还有十多篇/一千多篇文章没读过”。初看看来，这只是一种普通的差异，但产品人员提出10+、100+的形式更好，原因我如今记不太清楚了，似乎是说这样给用户的心理压力更小，因为如果数字比较大，用户就不需要知道具体的数值，所以阅读体验更好。虽然程序员都并不认同这种理论，但因为分工不同，最终做开发的大伙还是完成了这个功能。“可想而知”的是，这个功能上线之后并没有带来明显的正面反馈。更好玩的是，过了一周，Google Reader的未读数竟然改成了准确数字！
前几周，我在twitter上说起这个故事，本来只是凑兴当个玩笑，收到的反应却出乎我的意料，因为反馈大都是对产品经理一边倒的负面评价。我又想到自己的一个朋友，他在某家以产品经理文化著名的大公司做开发，谈到理想的工作，他的要求是“找个产品经理少的地方就好了”。这样看来，程序员和产品经理的矛盾是普遍而且深刻的。
Continue reading 做个懂产品的程序员
曾经有个流传甚广的问题：前些年程序员都想去做项目经理，现在都想去做产品经理了，这是为什么呢？我看到的一个答案是：因为程序员都被产品经理折磨疯了。
这是一个许多人都赞同的答案，而且从此细想开去，可以发现很多问题：早先的程序员，并不是不会被产品经理折磨，而是几乎根本没有产品经理来折磨。在开发还主要服务于具体问题，以定期发布一版软件为主要形态的阶段，功能的有与无是最大的问题；而在开发深入到生活的细节领域，计算机用来解决各种问题，持续发布成为常态，竞争又日趋激烈的情势下，产品的重要性才日渐凸显出来——我们都习惯了不仔细翻阅说明书，凭直觉使用各种功能，我们也习惯了在系统的各种“提示”下直抵问题的核心。这些便利，很大程度上是赖产品经理所赐。也正因为如此，越来越多的人投身于产品经理，在这种爆发性增长的阶段，鱼龙混杂，难免苦了在一线开发的程序员。与其忍气吞声，不如取而代之，产品经理由是成了许多程序员的选择。
然而就我所见，许多人不是产品经理时苦不堪言，真正坐上了位子却左支右绌，这种例子并不少。究其原因，或许还是经验太过片面，细节计较太多，内心没有棋局。产品经理的工作重点是什么？属于哪个部门？职责边界在哪里？需要着力培养哪些方面的素质？应当与哪些部门沟通，如何沟通？这些关于产品经理本身问题看似有些“虚”，但若回答不好就去做产品经理，却绝难说是称职的。
要回答这些问题，国内已经有不少优秀的产品经理原创作品可以参考，我愿意同时推荐的，是Marty Cagan写的《启示录：打造用户喜爱的产品》。作者是eBay的高级产品经理，在这一领域着力多年，这本书却绝非巨细靡遗的大部头，而是论述产品经理若干核心问题和经验的精当小册子——实际上，我是在火车上花两小时看完的，但深深记住了产品经理职责的三方面：人员，指负责定义和开发产品的团队人员的角色和职责；流程，指探索和开发产品时，反复应用的步骤和成功的实践经验；产品，指富有创意的产品应具有的鲜明特征。
相应的，这本书也分为三个部分，针对每一个方面细致列出若干主题，比如在“人员”部分，就总结了产品经理的职责，与相关职位的差别及边界，产品经理应具备的素质，工作中应当注意的问题等等。这是我非常喜欢的编排方式，看过Effective C++/Java的人都知道，这种编排方式确实是Effective（有效）的；难能可贵的是，作者并没有止步于这些“务虚的探讨”，还根据经验分析了常见各种选择的优劣，比如将产品团队归入技术部门，往往会埋没于细节之间，归入市场部门，又混淆了产品营销和产品管理的职责；再比如产品经理太听信客户或者太过干涉设计细节，往往容易被“怎么做”迷惑，忽略了“做什么”。如果靠自己提炼这些知识，恐怕得有足够多的经理，吃过足够多的亏，经过足够多的反思；不过有了Marty的书，有志从事产品工作的人，肯定可以少走很多弯路。
当然，也正如书名所说，是“启示”而不是“操作手册”，它并没有提供繁复全面的指引。读完第一遍，我收获了很多启示，要完善正确的产品意识，甚至成长为称职的产品经理，还有很长的路要走；不过我想，我会时常翻一翻《启示录》，带着经验来看它，是常看常新的。
