产品管理

如何量化用户体验 3510个读者 Leon Zhan... @ yeeyan.com 2008年08月22日双...

2009-07-17T01:13:52.184Z

如何量化用户体验

3510个读者 Leon Zhan... @ yeeyan.com 2008年08月22日双语对照原文字体大小小中大

简介

关于用户体验（User Experience, 缩写为 UX 或 UE）的经典文章，介绍了如何对看似无形的用户体验进行量化，实践性很强。

如何量化 用户体验

译者：Leon Zhang, 数字营销宝典 (DigiMarketing.cn)

原作者：Robert Rubinoff

原文：http://www.sitepoint.com/print/quantify-user-experience

--- 译文内容 ---

很多人都把用户体验看作是网站成功与否的一个总体衡量标准。分析一个网站在提供好的用户体验方面的效果如何，往往会变成一项很主观的事情，仅停留在观点层面，缺乏客观依据。

本文描述了一个量化 用户体验的快餐式的方法，我发现这个方法对于提供给客户一个关于他们的网站和过去开发所作努力的快速、客观、形象的表现很有帮助。

什么是用户体验？

“用户体验”这个术语指的是一个概念：把最终用户作为设计和开发活动的焦点，而不是系统、应用程序或者单纯的审美价值。它是基于一般的以用户为中心（用户至上）的设计理念。

用户体验主要由四个因素组成：

品牌
可用性（注释：用户能够使用一个界面来达到他们的目的的难易程度）
功能
内容

单独作用的话，这些因素中没有一个能带来积极的用户体验；然而，如果综合起来，这些因素就组成了一个网站成功的主要因素。

举例来说，一个设计精美的网站，却频繁地出现服务器错误或超时。或者想象一个很棒的数据库应用程序，由于某种原因而从未被使用过，因为它被深深地掩埋在了网站信息架构的深处。在两种情况中，我们都可以看到，独立的品牌、可用性、功能和内容等要素是无法说明一个网站是成功的。然而，当综合在一起时，这些核心要素就构成了用户体验的基础。

目标分析工具的必要性

比如说你来了一位新领导 – 他们对网站现状不满意，想让你帮忙把握网站的正确航向。如果你像我一样的话，第一件要做的事就是先浏览一下这个网站，然后在脑海中做一些粗略的记录。然后你怎样把这些想法和记录传达回给你的客户，而不是简单地像撕成八瓣一样对现有网站批判一番？

问题在于，我们每个人对一个网站是好还是坏的感知，是受我们个人背景和行业特性的影响而有所偏倚的。如果被叫来评价一个网站的优点和缺点，一个开发人员、可用性专员、设计人员或信息架构人员可能会有完全不同的评判。

一个客观的测量分析工具，会帮你提供给客户有事实依据的建议，而不仅仅是主观臆断和观点。本文中我们将探讨的方法会帮助你：

尽可能消除个人偏见（主观因素）
让不同背景的人（设计人员，开发人员，客户）能够在理解网站上有统一的共识
创建基准规则，以便于网站与其竞争者或过去的开发努力作比较
为你的客户提供一个关于他们网站的优缺点的事实依据和可视化的展示

衡量用户体验

如上所述，用户体验由四个相互关联的要素所组成：

品牌
可用性
功能
内容

但是，我们如何量化和衡量这些看似无形的元素呢？

方法很简单。我们把分析分为四个部分 – 每个用户体验的元素为一个部分。对于每一个元素，我们创建一系列的描述或参数，用于针对性地测量网站。我们为每一个描述创建一个从1到X的尺度范围；并且在这个范围内给每个描述打分。

一旦你完成了这个分析的第一部分，四个栏目中的每一个描述就都有了一个对应的分数。

在本文附上的范例分析中，我们只为每个元素使用了五个描述或参数。因此，我们使用了一个20分的尺度范围，这样网站的最高分值就是100。所以，如果我们为每个元素添加额外的五个描述或参数，我们就会使用10分的尺度范围来打分。

下面就是对范例分析中的每个元素以及描述或参数的概要：

品牌

品牌包括在网站中所有审美的、设计相关的项目。它带给网站想要的组织形象或信息的创意。用于测量品牌的描述包括：

网站提供给访客有吸引力的和难忘的体验
网站的视觉效果与品牌特征保持一致
图像、附加内容和多媒体对于体验的增值
网站传达出品牌的感知预示
网站利用了媒体的能力来增强和扩展品牌

功能

功能包括所有技术方面的和“后台的”进程和应用。它让网站提供给所有最终用户交互式的服务，而且重要的是，注意这有的时候同时意味着前台公众用户和后台管理员。网站功能的描述包括：

用户及时获得对他们查询和提交信息的响应
任务进程的清晰告知（比如，成功页面或邮件更新提示）
网站和应用严格遵守通用的安全和隐私标准
在线功能与离线业务流程结合
网站包含管理员工具来加强管理员的效率

可用性

可用性带来的是所有网站元素和特性的总体易用性。可用性之下的二级主题包括导航和易用性（友好度）（注释：易用性处理的是使在线内容可用于用户的体验，享受和使用的问题）。可用性的描述包括：

网站防止错误发生，并帮用户从错误中恢复
整体网页侧重针对主要受众优化
网站帮助访问者达成一般目标和任务
网站遵循它自己的一致性和标准
网站为残疾用户提供内容

内容

内容指的是网站的实际内容（文本，多媒体，图像）及其结构，或信息架构。我们来看信息和内容是如何按照定义的用户需要和客户的商业需求组织的。测量内容的描述包括：

链接密度有足够的清晰度，且容易导航
内容组织方便用户达到目标
内容及时准确
内容适合客户需要和商业需求
多语言的综合性内容

在多数情况下，我会为这四种元素分别使用10到20个独立的描述。我建议你使用如上描述作为你创建你自己的分析的基础。请记住，如果你添加了更多的描述，你必须也调整20分的尺度，以便每个元素的总分为100。例如，如果你为每个元素使用10个描述，那么你的评分尺度应该是1-20。如果你为每个元素使用20个描述，你的尺度应该是1-5。

作为这一类分析的例子，请你下载这个范例Excel文件。

显示你的结果

一旦你完成了你的分析，并且得到了每个描述或参数的分值，就是时候把数据放入清晰而便于告知的格式中去了。

首先我们要做的是，把每个元素的所有的分值加总。因为我们已经设置了分值尺度，来为每个元素提供满分为100的分数，我们真正得到的是一个百分比的分数。一旦我们有了这些百分数，我发现最有效的是创建一个雷达图来直观地呈现。微软的Excel或者Open Office Calc都很适合，尽管任何带有图表功能的数据表软件都可以。

使用你的数据表软件，你可以创建一个可视化的数据展示。请参见你在上面下载的示例文件来获取更多的范例。

对你的分析发挥创意

关于本文描述的分析和方法最棒的事情是，他们可以用于满足你的特定客户或项目需求。

你当然可以在分析中添加第五个类别来描述易用性（友好度）或者商业指标。例如，你得到了一个政府客户，需要严格遵循508规则（针对美国）。你可以容易地创建一套描述或参数来专门处理易用性（友好度）元素，修改你的图表来相应展示。同样，你也可以很容易地创建一个类别来专门处理你的客户的重要商业指标，比如，ROI，点击率，转化量，或者重复顾客数。

可选地，这个分析平台还可以让你能够为你选择的元素添加更大的权重。比如说你有一个客户，他是奢侈品生产商，并且主要侧重在品牌和视觉效果上。你当然可以创建一个修改过的测量系统，来为品牌要素提供更大的权重，而为，比如说，可用性要素上减少权重。

实际应用

我已经把这个分析用于很多我所从事的项目。我常常在新客户的提案中包含一个“快餐式”分析作为附录，来提供预期的客户一个关于他们网站相对于竞争者的简单印象。

提供这类的评论通常能够给你一个极好的机会来展示你的专业性。机会是其它竞标的公司不会包含这样的免费咨询服务 – 并且你在提案中包含的这个报告可能会是一个对你有利的决定性因素。

在其它事例中，我已经有客户出钱购买关于他们网站的深入的分析和完整的建议。这类报告包括，对于每种描述或参数，完成不同的描述性段落，再配上截屏范例。如果我最终通过跟进我的建议而赢得了客户，我通常会预定网站发布6个月后的再一次评估，作为显示进步的方式，同时加强我的服务的价值。

这种分析也能作为一个入门项目，引出更多的业务。如果你给这种分析定价合理，它可以是一个很棒的工具来让你得到新客户，并展示给他们你的服务的好处。

译者注：

用户体验是一个入门容易精通难的专业领域，而且国内参考资料也相对较少。通过翻译一些这样的国外专业文章，希望能为国内数字营销和用户体验事业尽一份微薄之力；如果能够对您有一些帮助，那更是本人莫大的荣幸。如有翻译不当之处，欢迎您批评指正，非常感谢。

如果想获取更多关于数字营销和用户体验的信息和资源，也欢迎您访问我的网站：数字营销宝典 (http://digimarketing.cn)

产品经理的主要工作内容

2008-10-14T03:46:45.610Z

在战略层面需要考虑的内容
1.产品的定位(理解市场，细分市场，了解用户)
2.品牌的战略(经营品牌就是经营产品，品牌的价值往往反映了产品的价值)
3.产品战略规划(战略即方向，方向错误全盘皆输)
4.产品线规划和产品路标规划(后续研发项目开发的重要指导)
5.项目组合管理(产品组合分析和选择，组合决策，动态管道管理)
6.CI竞争情报和竞争战略(充分了解对手才可能打败对手)

在产品规划和执行层面
1.产品规划和技术平台规划,产品项目的版本规划。
2.管道管理和资源管理(资源需求计划，资源分配和交易，多项目间资源平衡)
3.多项目和项目群管理(产品级项目管理)
4.市场需求分析。
5.产品级风险和问题管理。
6.产品需求全生命周期管理(需求管理，需求收集，$APPEALS，需求验证和跟踪)
7.结构化产品开发方法论(并行工程，产品开发团队，决策机制)

产品开发团队管理
1.产品开发团队的组织结构和角色分工。
2.团队激励机制和绩效管理机制。
3.矩阵管理沟通汇报机制。
4.团队沟通平台建设。
5.产品层面的培训计划和资产库。

产品实施和推广
1.产品推广和实施计划，推广策略。产品营销管理。
2.产品的宣传手册。
3.定制化的产品项目建议书和产品解决方案PPT。
4.产品定价和定位策略。

优秀产品经理的核心技能 - 译言翻译

2008-10-06T01:16:02.698Z

优秀产品经理的核心技能

11103个读者 翻译: Sam 07/30/2007 原文引用双语对照及眉批字体大小小中大

在我以前的工作中，曾经设计过产品经理职位的核心能力模型，今天看到Michael的文章，和我思路非常相像，翻译整理出来和大家共享。

1、沟通能力

优秀的产品经理一定是个成功的沟通者，沟通能力包括口头沟通能力和文字沟通能力。产品经理的一个最主要角色是做为沟通的中心，如下图所示：

产品经理的沟通能力不仅体现在和不同工作岗位的人进行有效沟通，同时还体现在如下方面：

和不同个性的人沟通。例如，大部分工程师的性格偏内向，而大部分销售和市场人员则很外向
和不同工作岗位的人沟通时采用不同的”语言” 。如果要进行高效沟通，很重要的一点是说沟通对象关注和易于理解的”语言”。比如，在和市场人员沟通和与工程师沟通时，要采用不同的沟通方式：对于市场人员说太多诸如”数据库性能”、”内存管理算法”之类的东西，无疑会让他们郁闷不解；而对工程师谈话过于概念化，也无助于他们设计真正的实现细节；类似的，在同老板们沟通时，则应该更多聚焦在较高的层面上，避免过于深入细枝末节的事情。

2、无授权领导能力

成功的产品经理是优秀的领导者，即便是没有明确的授权。

产品经理通常需要在多个领域执行领导工作，包括领导项目团队、领导产品战略和蓝图指定，以及领导跨团队的产品活动等。但是在大多数情况下，产品经理通常没有得到公司正式的授权。此时，是否具有”无授权领导能力”就成为成功与否的关键。

如何在无授权的情况下领导团队，我的建议是–综合运用影响力、协商、人际关系及其他类似技能。

3、学习能力

IT产业是一个快速变化的产业，”不变的也许只有变化”，新技术不断涌现，今日的新产品在几个月后就会变成大路货，甚至更快。优秀的产品经理必须能够快速学习，即便是在比较新的领域。具备此能力才能相对容易地在不断变化的市场和技术趋势下管理好产品。.很多公司在招聘产品经理的时候会犯一个错误–他们过分看中既有经验。比如，一个公司要做安全软件，他们就回在招聘时说明”需具有安全软件领域5年以上工作经验”。这其实是个错误的方法，更好的做法是寻找在软件领域有工作经验的产品经理，同时善于快速学习。

4、商业敏感度

优秀的产品经理对商业有极好的感觉，他们清楚如何发现市场机会，了解竞争差异化的重要性，并能提出制胜的产品战略、定价、推广策略、合作计划以及盈亏分析等。

看到这些，别以为产品经理就该是MBA毕业。实际上，大多数优秀的产品经理并没有上过什么MBA，但是他们对商业有很强的敏感。

5、热爱产品

优秀的产品经理对产品有发自内心的热爱。他们孜孜不倦地尝试各种新产品，注册各种产品的测试版，下载产品的试用版并仔细揣摩，一有时间就去网上看各类新产品的网站。他们对设计优秀的产品喜爱有加，即便这些产品并非自己公司的；他们鄙视那些没品的产品，即便那是自己公司开发的。最重要的是，他们醉心于创造优秀的产品–无论是全新的产品或是既有产品的改进。

6、注重细节，追求完美

优秀的产品经理对细节孜孜以求，注重细节是开发优秀产品的最重要先决条件，正所谓”细节决定成败”。Steve Jobs曾说：

iMac笔记本并非只是透明颜色和外壳外形与众不同，这个产品的核心理念在于成为最精致的消费电脑。

在最新的iMac中，我们坚决去掉了散热扇，因为我们认为使用一台不嗡嗡作响的电脑工作更令人愉悦。当然，并不是我决定就可以取消散热扇，它需要工程师们付出巨大的努力，找到管理电源和散热的更好办法。这是产品设计之初就存在的核心理念。

这也是用户愿意选择我们产品的原因–追求每个细节的完美，从而能让用户更方便愉悦地使用他们的电脑。

优秀的产品经理不但注重产品设计的细节，在其他事情上一样追求完美，比如进行竞争状况分析、制作项目计划，以及所有其他自己负责的工作。

7、日常产品管理能力

优秀的产品经理具备良好的日常产品管理能力，包括：

撰写市场需求文档（MRD）和产品需求文档（PRD）
进行竞争状况分析
规划产品路线图
制作产品演示PPT
设计用户界面
分析产品数据等.

以上这些核心能力不但有助于产品经理的自我提升，同时对于招聘产品经理也有参考价值。

如果你对产品经理的职责有补充，欢迎给我来信，也可在评论中发表高见。

写好MRD的10种技巧-第二部分 - 译言翻译

2008-10-06T01:15:27.809Z

写好MRD的10种技巧-第二部分

2096个读者 翻译: Tigerkin 04/15/2008 原文引用双语对照及眉批字体大小小中大

简介

MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。

在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求。

在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。

在我前面名为“写好MRD的10种技巧-第一部分”Blog文章中，我描述了写好MRD的5种技巧。我知道你一定迫切的想看到其他5种技巧，不用再等了，下面我就描述它们！

在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。如果你还没有阅读前面的5个技巧，请先阅读它们，我会等在这里，好了，你准备好了吗？

以下是写好MRD的10种技巧-第二部分(6-10)

6、说明"是什么"和"为什么"，但不要"如何"

产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发.
有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。

考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。

推荐-描述“是什么”
Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。

不推荐-描述“怎么样”
Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后，用户名和密码将被发送到服务器。下一次Mike来到登陆界面时，Javascript 将读取他的cookie，成功读取后，Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。

我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。

附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。

7、覆盖非功能性需求

      尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：
       a)性能
       b)可伸缩性
       c)可用性
       d)国际化
       e)等等...

我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分，工程师们会非常感激在MRD中定义这些需求。

要点：当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。

8、评审&修正

我有一个朋友-我们叫他Matt（他的真名叫Steve）。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。

他们雇用了一个有三年经验的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。
他是罪犯？他基本上认为他的MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们！

不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD，工程师将喜欢你（或者至少少恨你一些），你的团队也将创造更好的产品。

9、定义市场目标和定位

大部分我看到过MRD在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做的很好。

我还看到过一些没有描述市场目标和定位的MRD，他们通常会这样争辩：“为什么工程师们需要知道这些？拿到定义了什么是需要的还不够吗？”

这些问题（谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的）的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。

这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的（在MRD中）包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。

10、包含一个术语表

如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。

当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时，术语表将确保你的所有读者（有些可能不是技术人员）理解你的意思是什么。

写好MRD的10种技巧-第一部分 - 译言翻译

2008-10-06T01:14:57.714Z

写好MRD的10种技巧-第一部分

3187个读者 翻译: Tigerkin 04/15/2008 原文引用双语对照及眉批字体大小小中大

简介

MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。

在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求。

在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。

写好MRD的10种技巧（第一部分）

1、从用户角度的编写

从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色（User Personas）”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA（sales force automation）软件的“Login”的功能性。

方法A：
用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。

方法B：
Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。

哪个方法更加容易阅读和理解?就我的看法,毫无疑问，"方法B"。还有，它同时减少了令人烦恼的阅读！

2、使用Screen Shots

使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字！

举个例子,看看下面这个screen shot，你需要多少字来描述？我想可能不只一千个字。

3、用简单的语言编写

在我超过11年的行业中，我通常注意到的（更多是令我懊恼）一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。

相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦（有时他们会把MRD撕碎然后再碎片喂给碎纸机）的用做作的语言的陷阱。

        还有：
        a)保持简短的语句，把长的语句分解成多个小的语句。
        b)避免大篇幅的连续文本，把他们分解成多个小的章节。
        c)把大块文本内容分解成，screen shots，表格、重点列表等等。

4、小心的使用模板

        我发现MRD模板非常有用。他们的几个好处包括：
        a) 模板提供了一个标准的格式，使那些不得不阅读大量MRD的读者更加容易阅读。
        b) 模板让新的产品经理快速的写MRD变得容易，因为公司与公司之间的MRD内容是不同的。
        c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分；

        然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用：
        a) 产品经理害怕但又不得不写MRD - 几乎和不得不和Dick Cheney去南德克萨斯打猎一样（译者按：美国副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴）。
        b) 工程师团队害怕但又不得不阅读MRD。
        c) 写MRD和读MRD都需要花大量的时间。

我推荐你使用MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。

5、区分需求的优先级

在这些年里，我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素！

这就是说作为MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。

区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3...这样工作的刚刚好。在这个分类中-P1是最高优先级，P2是第二高优先级等等。

最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。

我推荐你只要包括P1，P2，P3的需求在你的MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。

超级产品经理的噩梦 from 大徐 by 大徐几个月前的一段时间里，我很郁闷，因为我所在的公司已经没有了产品经理。而公司里则出现了一位超级产...

2008-09-04T07:22:09.016Z

超级产品经理的噩梦

from 大徐 by 大徐

几个月前的一段时间里，我很郁闷，因为我所在的公司已经没有了产品经理。而公司里则出现了一位超级产品经理，这个人就是公司的最大领导。出现超级产品经理的结果就是：

1，领导的决定就是获取、整理、升级需求的过程。就是决定产品定位、目标群体定位，产品细节、项目计划的过程。就是决定市场定位、宣传、运营的过程。没有市场分析、没有用户调研，没有数据分析，没有内部评审，就这么干吧。

2，产品经理、项目经理实际上由M来担任，而担任管理职务的人对业务的理解和把握往往是可悲的。通过公司政治斗取得管理职务的人就不用提了，即使对因为业务出众而被提升为管理的前专业人员来说，同样是可悲的。不怕他们在业务上不专业，就怕他们没时间仔细的调查和研究。我认为每日穷于应对各种文山会海、处理人际关系、做人员管理的他们不可能在业务上专业，不可能踏实下来仔细的研究用户需求，不可能静下心来考虑产品的前世今生。

3，所有的项目计划都是先定上线日期，然后从后向前推。砍需求变的很常见，最终的产品是否是用户所需谁去关心？产品的质量谁去关心？产品后续的持续发展谁去关心？压缩再压缩产品需求文档产出的时间很正常，产品经理的人力资源预估谁去关心？压缩再压缩系统设计时间很正常，系统的健壮性、合理性、模块优化程度、可维护性谁去关心？压缩再压缩编码时间很正常，代码的质量谁去关心？所有的人都很疲惫，压力都很大，谁去关系他们的生活是否正常？

4，产品的信息架构、满足的需求、发展的方向都由超级产品经理去定义，然后由工程师去实现。不再以用户需求为导向，不再以用户为中心。取而代之的是自上而下的任务分派，产品经理几乎成为撰写文档、完善细节的工具。产品经理没有了对产品的控制能力，失去了用户基础，失去了创新能力，一切都是那么恶心。

5，很多事情变的难处理，需要向上捅才能解决或是大家喜欢向上捅。最终的结果是很小的事情被捅到了超级产品经理哪里，然后等上几天也得不到处理，所有人都在等待。出现一个链接去哪儿？一个文案怎么写这样的事情也要超级产品经理来决定的事情。也出现了超级产品经理坐设计师边上指手画脚的指导设计首页的事情。

6，超级产品经理会反过来问，用户需求是什么？产品定位是什么？产品规划是什么？

7，超级产品经理只对成功负责，不对失败负责。事情成功了他得名利，事情失败了他也能说出一大套来。没有了团队，没有了信心，也就没有了信任。

是不是你的公司也有类似的事情发生？想想为什么会出现超级产品经理？

缺乏管理？
缺乏团队？
缺乏执行？
缺乏信任？
只关注短期利益？
只满足已有经验？
只强调个人能力？
只迎合领导品位？

从我的角度考虑，那段时间我工作在恶梦中。但每个人的思维和认知都是有局限性的，如果换位思考，这个时间这个情况这个公司，这样处理是不是更好？我是不是想把自己的意志强加给别人？把我认为正确的方式强加给别人？也许，我说的很多话都不对，也许它就没对的。

没有完美的个人，只有完美的团队——贝尔宾团队角色理论：附Belbin Team Roles测试（三）_产品经理加油站-社区研究文摘库

2008-08-27T03:00:21.220Z

没有完美的个人，只有完美的团队——贝尔宾团队角色理论：附Belbin Team Roles测试（三）

2008-07-25 11:34

智多星 PL（Plant）

典型特征: 有个性；思想深刻；不拘一格
积极特性: 才华横溢；富有想象力；智慧；知识面广
能容忍的弱点: 高高在上；不重细节；不拘礼仪
在团队中的作用：

提供建议；

提出批评并有助于引出相反意见。

外交家 RI（Resource Investigator）

典型特征: 性格外向；开朗；热情；好奇心强；联系广泛；消息灵通，是信息的敏感者。
积极特性:有广泛联系人的能力；不断探索新的事物；勇于迎接新的挑战
能容忍的弱点: 事过境迁，见异思迁，兴趣马上转移
在团队中的作用

提出建议，并引入外部信息（一个很好的比喻是：RI 对于团队的作用，就像天线对于电视机，RI 就是团队的天线，就是用来接受外界信号的。注意RI和PL的区别：PL的想法大都是原创自己想的，RI则更可能是他个性喜欢接受新鲜事物，因此 RI 更擅长整合外界新鲜信息。）

接触持有其他观点的个体或群体

参加磋商性质的活动

协调员CO（Coordinator）

典型特征：沉着；自信；有控制局面的能力
积极特性：对各种有价值的意见不带偏见地兼容并蓄，看问题比较客观
能容忍的弱点：在智能以及创造力方面并非超常
在团队中的作用

时刻想着团队的大目标，明确团队的目标和方向

选择需要决策的问题，并明确它们的先后顺序

帮助确定团队中的角色分工、责任和工作界限

总结团队的感受和成就，综合团队的建议

推进者 SH（Shaper）

典型特征：思维敏捷；坦荡；主动探索
积极特性：积极，主动，有干劲，随时准备向传统、低效率、自满自足挑战，有紧迫感，视成功为目标，追求高效率。
能容忍的弱点：好激起争端，爱冲动，易急躁，容易给别人压力；说话太直接，虽然SH总是就事论事，却经常伤人不伤己。
在团队中的作用

寻找和发现团队讨论中可能的方案。SH一旦找到自己认为好的方案或模式，SH会希望团队都follow这一方案或模式，因此SH会强力的向团队成员推销自己认为好的方案或模式。

使团队内的任务和目标成形

推动团队达成一致意见，并朝向决策行动。经常自觉不自觉的，SH在团队中扮演一个二领导的角色，即SH可能不是名义上的领导（CO一般是领导），但SH却给人二老板的感觉。

监督员 ME（Monitor Evaluator）

典型特征: 清醒；理智；谨慎
积极特性: 判断力强；分辨力强；讲求实际
能容忍的弱点: 缺乏鼓动和激发他人的能力；自己也不容易被别人鼓动和激发；缺乏想象力，缺乏热情。
在团队中的作用

分析问题和情景

对繁杂的材料予以简化，并澄清模糊不清的问题

对他人的判断和作用做出评价。

基本上ME就是那种特喜欢给别人泼冷水的人。ME 们靠着其强大的分析判断能力，敢于直言不讳的提出和坚持异议。但 ME 对于一个成功的团队是非常必要的，因为 ME 就是团队的守门员。一个没有守门员的球队没法赢。

凝聚者 TW（Team Worker）

典型特征: 擅长人际交往；温和；敏感，是人际关系的敏感者（注意RI是外界信息的敏感者）
积极特性: 有适应周围环境以及人的能力；能促进团队的合作；倾听能力最强。
能容忍的弱点: 在危急时刻往往优柔寡断，一般很中庸。
在团队中的作用

给予他人支持，并帮助别人

打破讨论中的沉默

采取行动扭转或克服团队中的分歧

实干家 CW（Company Worker，后来在1988年改称为 Implementer ）

典型特征：保守；顺从；务实可靠。
积极特性：有组织能力、实践经验；工作勤奋；有自我约束力。
能容忍的弱点：缺乏灵活性，应变能力弱；对没有把握的主意不感兴趣。
在团队中的作用

把谈话与建议转换为实际步骤。

考虑什么是行得通的，什么是行不通的。

整理建议，使之与已经取得一致意见的计划和已有的系统相配合。

实干家就是好的执行者，能够可靠的执行一个既定的计划，但却未必擅长制定一个新的计划。

完美主义者 FI（Completer Finisher）

典型特征: 勤奋有序；认真；有紧迫感
积极特性: 理想主义者；追求完美；持之以恒
能容忍的弱点: 常常拘泥于细节；焦虑感（注意和SH的不同，SH有紧迫感，但FI是焦虑感）；不洒脱
在团队中的作用

强调任务的目标要求和活动日程表
在方案中寻找并指出错误、遗漏和被忽视的内容
刺激其他人参加活动，并促使团队成员产生时间紧迫的感觉

1．协调者（ CO: Coordinator ）– 成熟、自信、可信赖、好主席、能明确目标、能促进决策。不一定是最聪明的人。
2．培养者（ PL: Plant ）– 有创造力、有想象力、善于打破常规、解决困难问题。可接受的弱点：不善与普通人交往
3．塑造者（ SH: Shaper ）有活力、外向、易激动、爱挑战、爱施压、困难面前寻找各种办法。可接受的弱点：容易发脾气。
4．协力工作者（ TW: Team Worker ）– 爱社交、温和、善解人意、乐于助人、倾听、营造力、避免不合。可接受的弱点：在棘手环境下优柔寡断。
5．完善者（ FI: Completer Finisher ）– 吃苦耐劳、尽职尽责、严肃、善于发现错误、守时。可接受的弱点：有时过度忧虑、不愿授权他人。
6．贯彻者（ CW: Company Worker, or Implementer ）– 守纪律、可信赖、保守、高效、把想法变为行动。可接受的弱点：有些固执。
7．资源调查者（ RI: Resource Investigator ）– 性格外向、热情、健谈、探索机会。可接受的弱点：一时热情后很快失去兴趣。
8．监督评价者（ ME: Monitor evaluator ）– 冷静、有战略眼光、有判断力、看事情全面、善于做出判断。可接受的弱点：缺乏推动和鼓舞他人的能力。
很少有人只有一种特性，大多数人都是同时具有多种特性，但一般在两到三种方面表现突出。

没有完美的个人，只有完美的团队——贝尔宾团队角色理论：附Belbin Team Roles测试（二）_产品经理加油站-社区研究文摘库

2008-08-27T03:00:07.544Z

没有完美的个人，只有完美的团队——贝尔宾团队角色理论：附Belbin Team Roles测试（二）

2008-07-25 11:30

把各部分得分按照以下表格填进去后，加总得到自己的分数分布。

题号

一

二

三

四

五

六

七

总计

没有完美的个人，只有完美的团队——贝尔宾团队角色理论：附Belbin Team Roles测试（一）_产品经理加油站-社区研究文摘库

2008-08-27T02:59:55.403Z

没有完美的个人，只有完美的团队——贝尔宾团队角色理论：附Belbin Team Roles测试（一）

2008-07-25 11:11

团队角色理论叫做贝尔宾团队角色理论（Belbin team roles），贝尔宾（Dr. Raymond Meredith Belbin）是英国的一个教授，他在1981年出版了一本书《团队管理：他们为什么成功或失败》（Management Teams - Why They Succeed or Fail），在这本书中他提出了这套团队角色模型。基本思想是：没有完美的个人，只有完美的团队。人无完人，但团队却可以是完美的团队，只要适当的拥有如下各种角色。

团队角色自测问卷

对下列问题的回答，可能在不同程度上描绘了您的行为。每题有八句话，请将总分十分分配给每题的八个句子。分配的原则是：最体现您行为的句子分最高，以此类推。最极端的情况也可能是十分全部分配给其中的某一句话。请根据您的实际情况把分数填入后面的表中。
一、    我认为我能为团队做出贡献是：
A、我能很快地发现并把握住新的机遇。
B、我能与各种类型的人一起合作共事。
C、我生来就爱出主意。
D、我的能力在于，一旦发现某些对实现集体目标很有价值的人，我就及时把他们推荐出来。
E、我能把事情办成，这主要靠我个人的实力。
F、如果最终能导致有益的结果，我愿面对暂时的冷遇。
G、我通常能意识到什么是现实的，什么是可能的。
H、在选择行动方案时，我能不带倾向性，也不带偏见地提出一个合理的替代方案。
二、    在团队中，我可能有的弱点是：
A、    如果会议没有得到很好的组织、控制和主持，我会感到不痛快。
B、    我容易对那些有高见而又没有适当地发表出来的人表现得过于宽容。
C、    只要集体在讨论新的观点，我总是说的太多。
D、    我的客观算法，使我很难与同事们打成一片。
E、    在一定要把事情办成的情况下，我有时使人感到特别强硬以至专断。
F、    可能由于我过分重视集体的气氛，我发现自己很难与众不同。
G、    我易于陷入突发的想象之中，而忘了正在进行的事情。
H、    我的同事认为我过分注意细节，总有不必要的担心，怕把事情搞糟。
三、    当我与其他人共同进行一项工作时：
A、    我有在不施加任何压力的情况下，去影响其他人的能力。
B、    我随时注意防止粗心和工作中的疏忽。
C、    我愿意施加压力以换取行动，确保会议不是在浪费时间或离题太远。
D、    在提出独到见解方面，我是数一数二的。
E、    对于与大家共同利益有关的积极建议我总是乐于支持的。
F、    我热衷寻求最新的思想和新的发展。
G、    我相信我的判断能力有助于做出正确的决策。
H、    我能使人放心的是，对那些最基本的工作，我都能组织得“井井有条”。
四、    我在工作团队中的特征是：
A、    我有兴趣更多地了解我的同事。
B、    我经常向别人的见解进行挑战或坚持自己的意见。
C、    在辩论中，我通常能找到论据去推翻那些不甚有理的主张。
D、    我认为，只要计划必须开始执行，我有推动工作运转的才能。
E、    我有意避免使自己太突出或出人意料。
F、    对承担的任何工作，我都能做到尽善尽美。
G、    我乐于与工作团队以外的人进行联系。
H、    尽管我对所有的观点都感兴趣，但这并不影响我在必要的时候下决心。
五、    在工作中，我得到满足，因为：
A、    我喜欢分析情况，权衡所有可能的选择。
B、    我对寻找解决问题的可行方案感兴趣。
C、    我感到，我在促进良好的工作关系。
D、    我能对决策有强烈的影响。
E、    我能适应那些有新意的人。
F、    我能使人们在某项必要的行动上达成一致意见。
G、    我感到我的身上有一种能使我全身心地投入到工作中去的气质。
H、    我很高兴能找到一块可以发挥我想象力的天地。
六、    如果突然给我一件困难的工作，而且时间有限，人员不熟：
A、    在有新方案之前，我宁愿先躲进角落，拟定出一个解脱困境的方案。
B、    我比较愿意与那些表现出积极态度的人一道工作。
C、    我会设想通过用人所长的方法来减轻工作负担。
D、    我天生的紧迫感，将有助于我们不会落在计划后面。
E、    我认为我能保持头脑冷静，富有条理地思考问题。
F、    尽管困难重重，我也能保证目标始终如一。
G、    如果集体工作没有进展，我会采取积极措施去加以推动。
H、    我愿意展开广泛的讨论意在激发新思想，推动工作。
七、    对于那些在团队工作中或与周围人共事时所遇到的问题：
A、    我很容易对那些阻碍前进的人表现出不耐烦。
B、    别人可能批评我太重分析而缺少直觉。
C、    我有做好工作的愿望，能确保工作的持续进展。
D、    我常常容易产生厌烦感，需要一、二个有激情的人使我振作起来。
E、    如果目标不明确，让我起步是很困难的。
F、    对于我遇到的复杂问题，我有时不善于加以解释和澄清。
G、    对于那些我不能做的事，我有意识地求助于他人。
H、    当我与真正的对立面发生冲突时，我没有把握使对方理解我的观点。

网站产品需求分析_广告与营销_新浪博客

2008-08-27T02:33:15.225Z

领导：“那个谁，我们要做一个全球最好的人肉搜索引擎。它不但能搜人，还要搜狗搜狐搜百度。你立刻组织人马大干一场！”

　　谁：“我顶——（你个肺）！我搜集具体的需求先。”

　　众所周知，网站的新产品或升级需求，通常是由领导者（CEO、COO、UFO……）提出的。而领导者一般只会给出目标和概念，无法提供细节描述。首先这不是他的职责，其次他没有时间，领导总是忙的（哦…哦…俯卧撑正做到第3个）。当然，最重要的是，他不是真正的用户。

　　作为产品经理、项目经理或需求分析师，需要与最初的构思人、实际操作者、面向用户群以及有类似产品经验的相关人员细致沟通。虽然你不一定在做爱做的事，但一定要交配交的人。这样才能了解到真实需求，设计开发出优秀的产品，打个漂亮仗。

一、地雷总埋在粗糙的需求中

　　为了节省时间不做详细的需求分析，往往会付出更多时间。由于敌情不明，设计开发过程中你会发现不断有新的需求冒出来，而且总是不停地在做修改。因为你不知道前面埋了多少雷，以及有多大，而且不是用鼠标玩扫雷可以解决的。

　　结果：

　　1、你无法准确预估项目时间，老板对你很失望；

　　2、你不能在规定的期限内完成，老板开始对你绝望；

　　3、当你完成以后发现——其实一切才刚刚开始，上帝也绝望了；

　　4、产品终于上线，需求方对你的满意度-100，信任度-150，合计250；

　　5、最后一关，终极Boss（总是比你大很多倍那个）开始考虑该把你降职降薪还是炒个菜——鱿鱼；

　　6、总之，你完了，你的团队也跟着你背黑锅。

　　唯一可以庆幸的就是，你不是炮兵炊事员，不用戴绿帽。不过，如果你经常为这个项目加班……咳咳，可能我没猜中结果。

二、你该侦查什么？

　　知己知彼，百战不殆。你只有知道哪些情报对这次战斗是有用信息，才能打好仗。所以一定要施展你的三寸不烂之舌，把需求相关的问题重复一千遍，直到它变为真理。

　　情报：

　　1、目标任务

　　领导者和构思人对这个产品的目标定义和期望，通常是概念性的需求，比如“为人民币服务”，好一点就是“我们要做一个人际关系社区”；

　　2、用户需求

　　操作者和用户群肯定会用它做什么？可能做什么？和他们好好聊聊，确定他们不会在Twitter里面写Blog，做好任务分解；

　　3、功能需求

　　需要开发人员实现哪些功能？一定要保证用户需求能够通过它们实现，往往操作方式和展现形式也要确定；

　　4、非功能需求

　　除了功能性，产品需要达到什么标准，遵守什么规范？虽然我们不是性工作者，但总是不得不和性打交道，它们通常是——

　　1) 可用性：某些时候可以叫易用性或者用户体验，比如它在不同浏览器能否正常显示？点击108次才能找到结果？等等

　　2) 可靠性：它会经常报错吗？有没有很黄很暴力的页面（比如.net开发的产品）？服务器宕机100遍啊100遍？硬盘挂了，你居然没有备份方案？故障转移方案需要手动还是自动？除此我们还需要考虑——

　　　　A. 安全性：每个用户都可以进行毁灭性操作吗？我们的核不扩散条约有否签订？来自外部的核客是否可以轻易的将我军消灭？

　　　　B. 事务性：是否需要让系统保存工作单元的 ACID 属性？

　　百科一下：ACID，指数据库事务正确执行的四个基本要素的缩写.包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持交易(Transaction)的数据库系统，必需要具有这四种特性，否则在交易过程(Transaction processing)当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

　　3) 有效性：你的任务可能是每天歼敌13亿，而现在只有两个编号8086的战场供你排兵布阵，年底的KPI肯定泡汤——

　　　　A. 性能：是否充分利用服务器资源？响应时间是多少（我们对上菜慢的餐馆深恶痛绝）？程序经过优化吗？有没有必要使用缓存？

　　　　B. 可伸缩性：一个人用就像在跑，十个人用就像在爬，它的设计是否支持高并发量？可以负载均衡或者复制系统线性扩展？是否存在瓶颈？

　　4) 可维护性：是否需要建立维护规则？有升级的可能吗？潜在需求会改变现有架构吗？你确定不会因为一颗螺丝钉导致整台机器返工。

　　5) 可移植性：这个产品是否有特殊的部署要求，我们的山地步兵没法下海作战。

　　三、怎么做好侦察兵

　　沟通能力是优秀的产品经理和项目经理必不可少的一项能力。不过话说回来，力量越大，责任越大。你只有遵守以下军规，才能保证完成你的任务。

　　1、尽量避免专业术语

　　你不是在构建巴比塔，所以在和需求方沟通时，必须使用他能听懂的语言。要假设他什么都不懂，包括你眼中的常识。但是，你必须能够听懂对方的专业术语，因为它们会在你的产品中用到。

　　2、了解用户的专业领域和目标

　　你需要知道实际操作者是怎么工作的，以及为什么需要这个产品？尝试在他的岗位工作一段时间，恶补专业知识。如果有面向的用户群，就不能以单方面的需求为准，必须全面了解。

　　3、合理的采纳需求

　　及时作出决定，对于用户的需求有条件要上，没有条件也要创造条件上。尽量不被客观理由限制，例如找技术上不能实现等借口。不过由于这是你和需求方达成的有效协议，所以对于不恰当的需求，要尊重技术做出的可行性分析和评估。

　　4、实现功能的同时解决易用性

　　找出以前的产品（如果有）有什么优点和缺点，同类产品是怎么满足用户需求的。我们不需要“界面美观、操作方便、提高效率”这样的形容词，不能主观臆断，而是从用户哪儿了解他们对需求的具体定义及其特性。

　　5、提供最好的解决方案

　　由于需求方对技术不了解，可能会提出一些错误的需求解决方法，例如逻辑上自相矛盾。你需要发挥专业优势，帮他找出最佳的产品设计、开发方案（可供选择），而不是一味地迁就。即便是你的领导，你也要敢于说不。

　　6、划分需求的优先级

　　大部分产品最初的规划，都是庞大而复杂的。你需要配合需求方、开发人员对功能需求分级：必须的、重要且紧急的、紧急不重要的、重要不紧急的、不重要不紧急的。在没有足够的时间和人力来完成每个细节时，尊重开发人员的意见作出取舍。

　　7、需求的变更要及时、谨慎评估

　　你应该预设规则避免或减少需求变更。越早发现需求的变更，带来的损失越小。因为夜长梦多……，而且用户在变更需求时，往往不知道会带来什么后果。你有必要跟他讲清楚利弊，包括时间、成本、性能、质量等等，帮助用户进行决策。

　　8、沟通是个漫长的过程

　　要有足够的耐心和用户打交道，你可能随时需要他们的协助。只有保持不间断的沟通，才能减少不必要的修改。反复的修改原型页，就是最好的例子。

　　9、做好需求分析报告

　　你搜集到的情报，要以多样化的文档形式来展现（包括原型页甚至设计稿），例如HTML、Word、PPT、PPG、LiuPP……它在设计、开发、测试等多个环节都会用到。

　　通俗易懂的文字和简洁明了的图表，能保证你的老板、老板的小蜜、设计制作、开发，以及智商低至25-高达250的用户都能看懂。

　　你必须保证图表上的每个元素都能被需求方理解，例如原型页的每块内容怎么调用，每个链接指向哪里，都做好详细说明。只有双方都能完全明白对方的意图，才能确保需求真实。

　　你还得保证报告中没有未知或待定的需求，一定要在第一时间沟通完毕。

　　10、评审需求分析

　　完成需求分析后，我们要请出需求方做出最后的确认。采用越正式的方式，需求方就会越认真的对待。当然最好的方式就是签字画押——拉勾，上吊，一百年不许变！

　　四、侦察完成

　　当对方在需求分析报告上签字时，我们的侦查任务似乎就可以完成了。但不要忘记，军情瞬息万变，战斗才刚刚打响呢。

　　现实生活中，大部分签字者都不把这当回事儿。除非是有法律效应的文书，否则你就当他们在练习签名吧，如果可能的话还会附送唇印。

　　“你们需要我签，我才签的”

　　“不签你们就不干活，我急着要呢”

　　“我根本就没看懂，太信任你们了”

　　当然，你也可能反戈一击：“黑纸白字，再改我们可没门”。如果这是求你办事的兄弟部队，也许可以臭脸挡回去。换成是你的总司令呢？

　　五千年的悠久历史告诉我们，如果你不能反抗，那么就默默的享受吧。签字的实质意义就是告诉你：“我认可当前的文档说明，如果有新的需求和更改，我们再一起商量时间、人力、金钱、美女吧”。

　　没有最好，只有更好。既然我们的目标就是满足用户需求，坚决完成任务。所以在产品上线以前，你仍然需要保持和用户的沟通，时刻通报最新进展。尽可能提供Demo给用户，让他们能够帮助我们完善需求和改进产品。

　　直到产品上线，我们才可以松一口气，高声大呼——

　　改版尚未成功，同志仍需努力！