互联网之'我的阅读'

在娱乐资源匮乏的二线城市，这是他们唯一消费得起的文化娱乐活动。任何Web 2.0 网站只要占住这个广大的下层社会就发了。尽管工资水平不高，这些人对网络服务的付费冲动以及付钱的速度奇快无比。

RSS ，Tag ，Trackback ，Wiki，Widget，这些上层社会中的菁英阶级创造出来的玩意，真是他妈的见鬼了。笔者四年前接触Web 2.0 技术文件，就觉得这些东西应该送进坟墓里去，一般人实在太难理解了。

「关系」！B2C 购物网站的购物者之间存在什么关系？有必要建立关系吗？会因为什么而开始第一次搭讪？建立起来的是甚么关系？能够长久维持吗？ 「关系」，是Web 2.0 唯一需要思考的关键

并不是所有的Web 2.0 服务都会走向交友服务。但是关系的建立与维持却是Web 2.0 赖以生存的基础。而其实，多想想人与人之间的关系是如何产生的，以及背后的人性心理是甚么，是很有帮助的。

树图 树图（Treemaps）可以将多列数据以方块组的形式展现出来，这些方块还可以加以不同颜色、以不同大小组织起来，从而以图形的方式来揭示数据内在的模式。这种用户界面可以用来表现复杂的数据关系（比如层次关系等）。 在网站Smartmoney website上，便有一个这样的例子。通过这种用户界面，浏览者可以一目了然的看到数百种库存的信息。下面的图例中，库存货物信息根据不同行业被分组，进而按照其市场资本的大小以不同大小的矩形 表示出来。而颜色则用来表示价格的升（绿色）降（红色）。 要了解一个公司的详细情况，则可将鼠标移至该公司所在矩形的上面（下图展现的是通用电气公司的情况）。

拖放 拖放（Drag-and-drop）这种用户界面设计采用了使用者所熟知的移动元素的操控方法（使用者可能有过使用微软视窗应用的经验）。在恐怖小屋的在线商店（Panic Room’s online store）的网页上，要将物品放入购物车中，浏览者可以点击带有加号图标按钮，亦可通过拖放动作来完成。 拖放动作比较简单，先点击你要加入购物车的物品：

首先，我想到的应用是RSS ＋ 百度知道（新浪爱问） ＋ Wiki。RSS阅读器与Wiki可以说是同病相怜的难兄难弟，因为它们都相当有价值，却难以被普罗大众接受。而百度知道（新浪爱问）则是网民们喜闻乐见的应用，更重要的是它们使用起来十分简单，几乎每个人都知道这是干什么用的。虽然百度知道这类应用吸引了众多的网民，但是它仍然存在众多的问题，例如只能进行简单地对问题进行分类、相同问题会被反复提问等等。我觉得，问题通常都会基于某个背景，问题本身也有它的内涵和外延，这些与问题相关的要素得以呈现的时候，这个问题才真正有了价值。通常，我们在阅读的时候总会想到这样那样的问题，在这种情况下，问题所在的上下文就是背景，就是内涵和外延。于是，我想到了RSS阅读器。我希望阅读器不是简单地将feed聚合起来，更重要的可以让我们通过简单的语法在文中把问题标注出来，在这里，Wiki链接就可以派上用场了。一个个Wiki链接就是阅读者提出的问题。接下来的事情，各位可以继续发挥想象力了；

接着，我想到的应用是电子地图 ＋ Wiki。这个想法其实很简单，因为国外有了类似的实现例子——www.platial.com。这是一个典型的用地图说故事的网站，通过在地图上标注地点，然后写上标注的原因即可。通过这种形式，我们可以描绘出一幅漂亮的旅行地图，把沿途的风光和心情故事记录下来，这可比在Blog上写游记爽多了。不过，爽归爽，Wiki的踪影哪去了呢？别急，用户在创建地图的时候可以设定是否协作完成，如果采取了协作的方式，那么集合众人之力，我们就可以轻松得到广州市特色小吃地图，广州市高校地图等等了，这不就是Wiki协作性的一个体现吗？   

最后，我想到的是Website ＋ Wiki，就是使用Wiki来建立站点。这个想法在国外也已经有人做了——www.wetpaint.com。由于Wiki的导向性以及自内聚性，Wiki系统成为了建站的不二之选：导向性确定了站点的主题，例如我们可以从wetpaint.com中看到的有关《达芬奇密码》以及XBox的站点；自内聚性体现于Wiki链接，Wiki链接使得站点中的各个页面之间能够相互引用，这无疑解决了建站中时常会遇到的老大难问题——孤立页面，更重要的，它保证了相同的Wiki链接指向的内容是唯一的。如果您渴望个性，同时也渴望找到志同道合的朋友，那么使用Wiki来为你喜欢的主题建立一个站点吧！你必定会感受到其中个性与共性相碰撞带来的快乐。

Avatar服务的成功关键，在于其展示机会要多。用户花钱买头像，就是为了展示自己。如果曝光度不足，购买的意愿就会降低。这就是「有钱，要让大家知道」的心理，经营者首先必须制造曝光机会。

你写的Blog与上传的相片都是有形财产，无形财产则可带入「信用」的概念，亦即在一个社会中被认可的程度。例如，社区网站实行多年的积分及等级制度，就是一种被社区成员公认的个人信用。 一个用户在Web 2.0 网站中的活动必须要累积成财产，最后，除了在此地形成的关系链以外，用户还会因为这些虚拟财产的累积而再也无法离开。简单来说，「搬家」变得困难。 然而，这些制度大部分没有被好好运用，积分与等级仅是无关重要的数字罢了。经营者其实没有注意到，适当制造「穷人」以及「阶级不平等」才是一个社区网站进步的关键；而实体社会其实也是如此。

而经营者该做的事情是，定义出你的社区中，哪些是用户的虚拟财产，包含了有形与无形的。是所谓的活跃程度？关系链的多寡？还是被其他人推荐的次数？积分如何累积，如何变成等级？ 其次，等级与积分该如何被展示，被消耗，以创造真正的被拥有的价值，让用户自然的感觉阶级不平等的存在，适当的呈现这种不平等以促进整个社会（社区）向上的动力，进入正面循环？

产品管理和用户体验的差异 尽管PM的职责很广也很有战略性，他们还需要负责在战术层面具化他们的战略。在一些细节上，PM可能存在与UE人员重叠的问题。正如Johathan Korman写道: 当我向那些不了解"交互设计"的人们描述我是做什么的时候，首先我说:"我观察用户的需要，确定哪类产品最适合他们，然后制定关于这个产品的行为规范，以此推动开发团队的工作。"人们常常回应说: 在我的组织里，我们管这个叫"PM"。 乍一看，用户体验的角色和产品管理惊人的相似。然而你仔细观察就会发现产品管理和用户体验在职责、重点和依赖度上是有区别的。 职责: PM负责整体成功，而UE人员负责界面设计使之满足用户需求并易于使用。UE人员同样应该像销售、营销、工程人员那样关注整体的成功，尽管并不负责这些方面。 重点: 当UE人员聚焦在界面与产品体验之时，PM会从市场整体反馈、特定市场规划、竞争力、技术、收益与损耗以及可调用的资源等方面来审视这些界面与产品体验。 依赖: 信息架构师(IA)、图形设计师、易用性专员等主要精力集中在界面上，他们需要依赖自身或类似角色的其他人一起来完成工作。PM则坚定地要求他人能执行其产品策略，他们更多地需要融合一些微妙的产品目标、策略、影响力、坚定和公平的决策等因素，这些要求多甚于UE人员。 或许Johathan Korman最好地诠释了PM与其他角色如UE之间的差异: PM负责产品应该做什么(What the product should do)，而其他角色负责产品怎么做(How the product does that)。

产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方常常争论谁应该负责定义产品的特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为是他们在花时间直接与客户和用户打交道，研究用户需求。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。 好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 好的PM能深知用户体验这个角色并理解其重要性，重视他们的投入并利用他们的研究和建议来创造优秀的产品。正如总统需要从自己的内阁成员那里获得建议一样，PM也应该利用自己的"内阁成员" --- 用户体验、市场营销、技术等 --- 去做出决策。 从UE人员向PM角色的转换远不止去操作所有的界面设计，PM一项很重要也很有挑战的任务是负责确定产品的目标与策略，树立内在和外在的产品领导能力，创造商业模式及获得资本，从小事出发又能着眼大局，并协调市场、工程技术、财务、销售当然还有UE一起向成功迈进。 在第二章，我们将向你介绍迈向产品管理的方方面面，包括你在UE岗位上不可以做而在PM角色上需要做的事情、成为PM你必须做哪些准备、UE背景的人成为PM后常有的缺陷等，来帮助你作出这种转变。

第二章 在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。

作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，只是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点，相应地了解这方面的知识并有意识地利用它。从产品的整体上确定用户的焦点，不光是设计。 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。 平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。 推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)间取得支持。仅仅开发出一款好的产品还不够，你还必须让人们知道它，推广它带来的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，在这个位置上你还需要影响其他产品。你也会与其他公司内的其他PM交流，思考公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是"带刺的玫瑰" --- 你同样必须应付挑战和压力。 作为PM，你的权力很有限 Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接受命于你。你必须梳理这些分散的资源，指导他们的工作 --- 尽管他们从各自的经理那里获得了不同的工作方向。

你必须做出决定并对此负责，而不仅仅是建议 事实上你必须做出很多的决定并为此负责，不是所有人都会认同(你的这些决定)。当然如果你的工作干的好，你可以向他们证明你的决定是正确的，明确解释你的原则，其他人也就不会显得焦急或轻视 --- 但这并不容易! UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验，因为还需要考虑其他重要的因素(如管理层的需求、商业策略、商业模式等)，让这些人理解作出这种或许有损用户，但最终有益于产品的决定往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往后推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合... ... PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 PM不只是产品开发团队的一员，你是整个产品的象征。无论你把事情做好了或搞砸了，也无论你是否真的能驾御局面，你都必须为此负责。 作为UE人员可以做而作为PM不可以做的事情 从UE岗位转换到PM岗位的人会对新职责感到兴奋和有挑战性，与此同时，他们也会失去一些UE工作的一些方面: PM不必插手过多细节 这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都可以委派给其他人来做，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 --- PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美 有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于…"。对PM来说，也许它确实取决于某件事情，但这并不要紧的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，作出在用户看来未必完美但在有限的资源下很受用的决定。

PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要制定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。

从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力 不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 问清目标非常重要，体现在两个方面：第一，PM自己有可能之前没有仔细想过产品目标，你这一问后，有可能让你成为最受信赖的顾问之一并帮助他们建立目标。 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 不要只是提出设计方案然后让PM做决定，要让自己准备好参与讨论特定设计选择的影响，向他人展现你的设计背后的原因已经他们在更广范围内与产品远景和目标的联系，聆听PM怎么说并搞清楚他们拒绝或认可的理由。 提出带有远期规划的强烈建议 你所能提供的一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 --- 不管你现在的角色是什么。 帮助PM走出办公室 PM不应该对客户和用户视而不见，尽管有人是这么干的。你应该通过询问他们最后一次见用户是什么时候来帮助他们，把他们带入到正式或非正式的用户研究中，或者给他们讲在用户访谈中的一些有意义的故事，邀请他们下次同去。如果被拒绝了，下次继续邀请。 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。

学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。