Angela's profileAngela的交互设计之路PhotosBlogListsMore  |  Tools Help |
|
|
改掉不良的沟通习惯
3是在谈话时考虑过多的“如何说服”时会忽略的 4是暂时不大会处理的 用户体验与产品管理[转](a really good essay)简单翻译了一下郭老师转载的Jeff Lash和Chris Baum关于用户体验跟产品管理关系的文章, 时间紧张还没有做校核, 全文如下: 第一章 用户体验(User Experience, UE)专业人员正逐渐从商业角度对他们的工作感兴趣，在他们的核心观念中，UE的重点是理解用户需求并创建有用和易用的产品来表达这种需求。 UE人员常常在他们的研究、设计和创意没有得到相应的尊重时感到非常失落。差不多每个UE人员都有过与那些尽管缺少交互方面的需求和流程的知识，却根据他们的感觉或毫无道理的看法来驳回一个建立在研究基础上的设计的领导者打交道的糟糕经历。 很多UE人员逐渐意识到他们有经验和洞察力来运用权威性并在帮助构建的产品中发挥更大影响力，产品管理人员也对这些希望扩大影响以保证以用户为中心的产品开发顺利进行的交互设计师、信息架构师和易用性工程师等有了更多的兴趣。 对很多UE实践者而言，成为产品经理(Product Manager, PM)是一个合理的转换，因为两者往往需要类似的技能，特点和能力。此外产品管理是很多组织共有的角色，向这样一个已存在的角色过渡是较为容易的，只是信息架构师或交互设计师如果选择用这种直接方式来影响产品的话，他们还需要学会换位思考。 PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。 PM的职责 PM的基本职责是理解市场并推动适应市场的产品开发，由于UE人员往往已经熟悉了设计的用户需求也具备相应市场知识，因此他们具有成为优秀PM的潜质。 PM还有如下一些较高层次的职责:
产品管理和用户体验的差异 当我向那些不了解"交互设计"的人们描述我是做什么的时候，首先我说:"我观察用户的需要，确定哪类产品最适合他们，然后制定关于这个产品的行为规范，以此推动开发团队的工作。"人们常常回应说: 在我的组织里，我们管这个叫"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后常有的缺陷等，来帮助你作出这种转变。 第二章 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。 作为UE人员不可以做而作为PM必须做的事情 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点，相应地了解这方面的知识并有意识地利用它。从产品的整体上确定用户的焦点，不光是设计。 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。 平衡各方力量确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于:
做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。 推广产品你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)间取得支持。仅仅开发出一款好的产品还不够，你还必须让人们知道它，推广它带来的好处。 向组织中的其他产品提供策略投入 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是"带刺的玫瑰" --- 你同样必须应付挑战和压力。 作为PM，你的权力很有限Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接受命于你。你必须梳理这些分散的资源，指导他们的工作 --- 尽管他们从各自的经理那里获得了不同的工作方向。 你必须做出决定并对此负责，而不仅仅是建议 UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验，因为还需要考虑其他重要的因素(如管理层的需求、商业策略、商业模式等)，让这些人理解作出这种或许有损用户，但最终有益于产品的决定往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往后推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合... ... PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 作为UE人员可以做而作为PM不可以做的事情 PM不必插手过多细节这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都可以委派给其他人来做，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 --- PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于..."。对PM来说，也许它确实取决于某件事情，但这并不要紧的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，作出在用户看来未必完美但在有限的资源下很受用的决定。 PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要制定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。 从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 提出带有远期规划的强烈建议 你所能提供的一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 --- 不管你现在的角色是什么。 帮助PM走出办公室 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。 学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。
想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。 还有其他组织提供类似的训练营活动，包括: 有很多非常好的Blog在讨论产品管理，你也可以从中选择:
还有很多从UE角度来谈产品管理的书籍，这些都应该作为PM的珍藏:
此外，有志成为PM的人还应该阅读一些综合的管理类图书，包括领导力、管理、市场营销、财务、技术、策略学等。 产品管理有两个主流的社团组织: PDMA (产品发展与管理协会)和AIPMM (国际产品营销与产品管理协会)。两者都提供培训、会议、本地讨论小组及其他产品管理资源。 同时，你还可以利用你的一些职业网络，也许能从类似LinkedIn --- 帮你联络能回答有关产品管理问题 --- 这样的服务中获得帮助。在你的公司里项目管理也能指导你，况且来自其他组织的产品经理也能给予你不同的或许更真诚的帮助。 鉴于你想学习产品管理并思考如何迈向这一步，可以找你的经理谈谈。优秀的经理会帮助实现你的职业成长，即使这样也许意味着你将进入公司的其他岗位。 因此，你想成为产品经理吗? 如果读完本文后你发现PM并不适合你，那也很好 --- 在职场中你依然有很多道路可以选择，包括从成为经理到自己开公司，继续实践着你的设计理想。 不管你选择了哪个，都希望你能从我们的经验中有所裨益，祝你好运! 看完了《Scrum敏捷项目管理》看完了那本《Scrum敏捷项目管理》 这本书，在我比较清晰的了解了传统的任务式项目管理的各种弊端，正在为此而苦恼时，他，出现在了我的面前。 虽然它算不上什么经典书籍，但我从中受益匪浅。从看开始几章时兴奋不已，一直看到最后仍然有不少收获。一本书能达到这样的效果，实在不容易。 Scrum方法虽然有他的精妙之处，由其是对于小团队来说。但他实施起来的确有些难度，除了让团队真正理解Scrum有难度外，让整个团队像Scrum理念描述的那样去工作也对Scrum Master的软能力有相当大的要求。 看了好几种项目管理方法之后有种感觉。如果不能做到像微软那样让三种角色互相制约，互相促进来达到共同提高的目的的话，角色分的太清晰常常是以牺牲效率为代价的，我更倾向于无边界职能，这样更容易达到自我管理，从而发挥出团队成员的创造力，最终达到提高效率的目的。 书中多次提到XP，称Scrum跟XP很相近。由于一直没看到过XP的中文书，所以对它没多少了解。以后注意一下，看有没有XP的书，拿来学习一下。 Scrum的角色分配只有三种角色：
product manager代表项目中每个利益相关人的权益，并为项目产出的软件系统负责。频繁检查产品待开发需求的优先次序。 团队的任务是开发软件功能。是自我管理，自我组织和跨职能的。团队成员对每一次迭代和整个项目共同负责。 ScrumMaster需对Scrum过程负责，讲授Scrum方法，负责实施Scrum，督促全体成员遵从Scrum规则和实践。 Scrum严格区分两类人： 承担项目责任的人。对他们赋予权利 无责任的人。无权对项目施加不必要的干涉。 Scrum的科学原理Scrum是经验性过程控制
实践经验性过程控制方法Scrum时，有三大支柱：可见性，检查，适应
Scrum 敏捷项目管理今天到书店去闲逛，猛然间发现，书架上多了好几本项目管理的书，忍不住拿下来翻来翻，突然看到一个名字“Scrum 敏捷项目管理”，于是就把兴趣定格到这本书上。因为那个“Scrum”，并不是因为他生僻（对我来说生僻的单词多了），而是因为老大在最近这个月的的项目中经常用到这个词，并“逼”我们用那个同样有这个词的一个Excel表做项目管理。之所以用“逼”这个字，不是因为他凶，而是因为我不实在不知道那表有什么好的，用起来也不方便，打心眼里不愿意。 直到打开那本书，我才明白。。。 原来有一个叫Scrum的项目管理方法，而且更常规的项目管理方法有相当大的不同。我顿时倍感惭愧，做了一个月的XXXX（为了保持这个称谓的名声，我就不这样自称自己了），居然不知道Scrum 言归正传，现在把我今天学习了一个多小时Scrum的收获记下来，总的来说，收获颇丰。 Scrum方法不同于传统的项目管理方法，由项目经理去计划，安排整个项目，拿着一大堆项目计划，甘特图，工作进度表去告诉每个成员该做什么，该怎么去做 。 上面这句话有点让人费解，下面从非理论的角度来介绍： Scrum主要用来管理复杂的项目，什么叫做复杂呢，就是事情在做之前不能清楚的知道该经过什么步骤去完成，不可能预测每件事物。 常识是经验阅历，培训经历，谦逊品质和才能智慧的综合体，采用Scrum的实践，每当工作偏离正常轨道，无法取得预期效果时，就应充分利用常识解决问题。 使用Scrum进行项目管理，需要团队成员纠正这样一种思维定势，才能使Scrum发挥出他强大的威力，让复杂，难于处理的项目变得可以驾驭。 (...To be continued...) |
|
|
