Group items tagged

PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。

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

平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。

推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)取得支持。仅仅只是开发出一款好的产品还不够，你还必须让人们知道它，推广它的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，你在这个位置上同样需要影响其他产品。你也会同其他公司内的其他PM交流，你需要考虑公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是”带刺的玫瑰” — 你同样必须应付挑战和压力。

在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。 作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，但是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点。相应地了解这方面的知识并有意识地利用它。 从产品的整体性上协助确定用户的焦点，不只是设计 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。

学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。 还有其他组织提供类似的训练营活动，包括: • 实务营销 • 280小组 • Blackbot • ZigZag营销 • 硅谷产品小组 有大量非常好的Blog在讨论产品管理，你也可以从中选择: • Roger Cauvin的博客 • 实务营销的博客 • SVPG博客 • 产品管理观察 • Tyner Blain • Michael的产品管理与营销 • 如何成为优秀的PM (它的联合作者之一便是 Jeff Lash) 还有很多从UE角度来谈产品管理的书籍，这些都应该作为PM的珍藏: • 赢在新产品: 产品从创意到启动的加速实现, 作者Robert Cooper • 软件产品管理精华, 作者Alissa Dver • 产品经理手册, 作者Linda Gorchels 此外，有志成为PM的人还应该阅读一些综合的管理类图书，包括领导力、管理、市场营销、财务、技术、策略学等。 产品管理有两个主流的社团组织: PDMA (产品发展与管理协会)和AIPMM (国际产品营销与产品管理协会)。两者都提供培训、会议、本地讨论小组及其他产品管理资源。 同时，你还可以利用你的一些职业网络，也许能从类似LinkedIn — 帮你寻找能建立联系并回答有关产品管理问题 — 这样的服务中获得帮助。在你的公司里项目管理也能指导你，况且来自其他组织的产品经理也能给予你不同的或许更真诚的帮助。 正因为你学习产品管理并思考如何迈向这一步，可以找你的经理谈谈。优秀的经理会帮助你的职业化成长，即使这也许意味着你将进入公司的其他岗位。

作为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(包括其他开发成员)能找借口拒绝和用户沟通。

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

产品管理和用户体验的差异 尽管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)。

PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要制定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，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的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向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的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。

设计过程中的副产品1. 角色，角色设计为系统的设计提供了典型的用户目标，它能够把用户研究的开销缩减的最小。2. 原形，这是最终作品的模型，原形可以很简单，简单到用几张图片来表示未来复杂的网站（低拟真度原形），也可以比较复杂，拥有最终产品的一样的交互能力（高 拟真度原型），纸面原形的测试效果其实已经很不错了。通常原型设计会让整个信息架构活起来，所以，请尽量在设计定稿前多做原型的测试！3. 剧情，剧情设计时另一种可以让信息架构设计活起来的技术，它模拟了一个用户执行具体任务时如何体验整个信息架构的过程，也能够让团队的其他成员很好理解设计的意图。

2. 富UI 现代 Web 中的 UI 变得越来越漂亮，越来越好用。过去的一年，Web 中的 UI 有了显著提高，有了一种接近桌面的感觉。Ajax 和 Flash 被广泛使用。 特别是我们比去年看到了更多留白区域，还看到很多现代的 UI 技术会显示用户同系统之间交流的视觉状态，比如，按钮在正常和被按下时显示不同的样子，用户同系统交互时能及时得到反馈，另外，越来越多的服务可以被用户定制。

1. 凸版印刷风格 这种风格有些出人意料，可能因为之前很少有人使用。该风格在在各种主题的网站中都有，但主要用于产品设计或在线服务类网站。

3. 透明 PNG 使用 PNG 实现透明虽然不被 IE6 支持，却在过去的一年大行其道。设计师们似乎正在尝试将背景图片和内容融合并实现一些印刷媒体的风格。比如，将 PNG 半透明图片放到整体背景的某个区域上，用来加亮显示这个区域，如标题或声明。一些 PNG 同名技术还用来实现灯箱框效果。 Smashing Magazine 去年曾有篇使用透明效果实现创意设计的文章，很多设计师在他们的作品中开始尝试这些技巧。有趣的是，透明效果常被用于页首和页尾部分，不过也有些例外。

4. 巨大字体 以前的文章中我们曾介绍过巨型字体设计，2009年，巨型字体设计还会风行，尤其是那些设计社，以及展示型，产品介绍型，或在线服务型网站，他们会使用巨型字体显示重要信息。 巨型字体设计中使用的字号往往超过36px，设计师们对字体编排注入了更多关注，以实现更漂亮，更连贯，更值得信赖的站点。

6. 灯箱效果 灯箱框是第二代弹窗，它们比第一代基于 JavaScript 的弹窗更友好，可以让用户将注意力集中到最重要的部分。这些窗口一般由用户的某个行为激发，并显示在其它内容的上层，他们有时候是半透明的，并包含一个关闭按钮。

5. 代用字体 设计师们还把更多注意力放到字体上，虽然经典的 Web 字体，Helvetica, Arial, Georgia 以及 Verdana 等仍占主流，一些代用字体正浮出水面（如 sIFR）。 有趣的是，这些字体会和设计无缝地衔接，设计师们似乎并非为字体而字体，而是要将字体同他们的设计结合在一起实现更漂亮的效果。

7. 媒体块 随着宽带接入的普及，用户现在可以承担更丰富的内容，设计师们也借机提出更有吸引力的内容。越来越多产品网站使用媒体块显示视频，让用户更容易理解这些内容。用户只需靠在椅子上看视频，不需要一步一步往下点，这些食品通常比较短，直奔主题，虽然很正规，但也包含一些娱乐性。 不过请注意，视频应当是你内容展示方式的次要选项，并不是所有人都有宽带接入，也不是所有人都喜欢有视频播放（他们可能正在后台听网络收音机或播放音乐），另外，也不是所有人都启用了 Flash 和 Javascript。

8. 杂志外观 传统印刷媒体设计中使用的编排技术也出现在 Blog 设计中，文章的编排，文字排版，图片甚至对其方式。基于网格的设计也很流行，但主要用于展示与产品页以及大型博客，极少用于公司网站或网店。

9. 滚动幻灯导航 幻灯片水平和垂直滚动，可以向不同方向滚动，当前项加大加亮。这种导航技术可以让用户快速直观地浏览站点中的内容。一般常用语娱乐性网站，另外，设计者还可以使用该技术展示他们的作品。

10. 在重点位置做形象展示 网站的左上方一般是一个站点最重要的区域，因为那是用户注意力最集中的地方。因此，在那个部位放上网站中最重要的信息是明智之举。 事实上很多设计师正是这样做的，不管是 Web 程序，公司网站，在线服务还是作品展示，设计师们将口号或简介性内容放在那里，并使用醒目的排版给用户以良好的第一印象。这些内容长短不一，不管哪种方式，但它们都占据可观的空间，一般横跨整个幅面，高度在250到400之间。不过这些形象展示性区域一般并不用于博客或在线商店。

50. 你们的程序员能看到测试用例么？MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 51. 你们是否随便抓一些人来做易用性测试？MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 52. 你对自动测试的期望正确么？MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 53. 你们的性能测试是等所有功能都开发完才做的么？MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 54. 你注意到测试中的杀虫剂效应了么？MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 55. 你们项目组中有人能说出产品的当前整体质量情况么？MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 56. 你们有单元测试么？MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 57. 你们的程序员是写完代码就扔过墙的么 ？MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 58. 你们的程序中所有的函数都有输入检查么？MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 59. 产品有统一的错误处理机制和报错界面么？MVM： 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 60. 你们有统一的代码书写规范么？MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 61. 你们的每个人都了解项目的商业意义么？MVM： 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 62. 产品各部分的界面和操作习惯一致么？MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。 63. 有可以作为宣传亮点的Cool Feature么？MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 64. 尽可能缩短产品的启动时间MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 66. 你们根据详细产品功能说明书做开发么？MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 68. 所有人都始终想着The Whole Image么？MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 69. Dev工作的划分是单纯纵向或横向的么？MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 70. 你们的程序员写程序设计说明文档么？MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71. 你在招人面试时让他写一段程序么？MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 72. 你们有没有技术交流讲座？MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 73. 你们的程序员都能专注于一件事情么？MVM： 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5 个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的 资源了。

74. 你们的程序员会夸大完成某项工作所需要的时间么？MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 75. 尽量不要用Virtual HeadsMVM： 最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。

你应该计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。… 在我们知道基本形状之前，不能为房屋加上屋顶。… 要求每个层面的工作在下一个层面可以开始之前完成，会导致你和你的用户都不满意的结果。… 一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成”。 拿到这里会有一点小变动，应该这么说：不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作。

不要把需求整理的非常详细以后再去内容设计，只要在内容设计该结束的时候完成需求整理；不要在开始信息架构设计的时候完全确定内容设计，只要在信息架构该确定的时候完成内容设计。也就是说“需求整理在信息架构开始的时候完成即可”。

用户调研应该贯穿于设计的任何一个环节，在整个设计过程中既起到“引导”的作用，又起到“校验”的功效。加入了对用户的研究以后，整个“迭代的设计过程”才会变得完整和丰满。

与产品定位有关，没有任何一款产品适合所有用户，不同的人群，有不同的需求，甚至可能不需要这种产品。

普遍期望：指某一类群体的用户的期望值，这类用户因为有着相似的工作经历、生活环境等一些条件，所以对该产品的期望值有其相同的地方，其共同的期望就属于普遍期望。个体期望值：是指用户个体与个体之间有其各自不同的差异化，所以对同一产品会产生细微不同的期望值。比如说手机产品，对于学生群体来说他们都期望手机价格适中，外形时尚。但是男同学和女同学对于手机的色彩的期望值却大不相同。所以说任何产品的设计、推出都要分析研究用户期望值的这两个层次，对于我们更好的锁定目标群体、研究用户都是很重要的方面。

用户期望值和用户体验的关系 他们之间的区别在于两者所处的阶段不同，前者属于产品的预期阶段，后者属于产品的使用阶段。当用户体验高于用户的期望值，那么对于用户在精神上会得到极大的满足感，会对该品牌的产品产生更强的忠诚度；反之者用户会有极大的失落、不满，进而对该品牌的产品产生不信任感。所以在产品推广中，不要使产品让用户有过高的期望值，不然一旦你的产品达不到用户过高的期望值，将对产品和品牌产生极大的破坏。