诸天哪，要因此惊奇，极其恐慌……
—— 《耶利米书》2:12
某公司宣布利润创记录，其股价却下跌了20%。当晚的金融新闻解释说，该公司没有实现分析家预期的业绩。一个小孩打开昂贵的圣诞礼物，却大哭起来，这不是他想要的廉价洋娃娃。某个项目团队奇迹般地实现了一个极其复杂的应用，但却遭到用户的抵制，因为该应用没有帮助系统。
在抽象的意义上，应用如果能正确实现其规范，就是成功的。遗憾的是，这只能付抽象的账。
在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。不符合用户预期的项目注定是失败的，不管交付的产品在绝对的意义上有多好。但是，像希望得到廉价洋娃娃的小孩的父母一样，你走的太远也会失败。
Gently Exceed Your Users' Expectations
温和地超出用户的期望
但是，执行这条提示需要做一些工作。
交流期望
用户在一开始就会带着他们对所需要的东西的想象来到你面前。那可能不完整、不一致或是在技术上不可能做到，但那是他们的，而且，就像过圣诞节的小孩一样，他们也在其中投入了一些感情。你不能简单地忽视它。
随着你对他们的需要的理解的发展，你会发现在他们的有些d期望无法满足，或是他们的有些期望过于保守。你的部分角色就是要就此进行交流。决不要忘了你的应用要理解你将要交付的产品。并且要在整个开发过程中进行这样的交流。决不要忘了你的应用要解决的商业问题。
有些顾问称这一过程“管理期望”——主动控制用户对他们能从系统中得到什么应该抱有希望。我们认为这是一个有点高人一等的想法。我们的角色不是控制用户的希望，而是要与他们一同工作，达成对开发过程和最终产品，以及他们尚未描述出来的期望共同理解。如果团队能与外界通畅地交流，这个过程就几乎是自动的；每个人都应该理解所期望的是什么以及它被怎么样构建出来。
有一些重要技术可以用于促进这一过程。其中，“曳光弹”和“原形与便笺”是最为重要的技术。两者都让团队构造用户能看见的东西。两者都是与用户交流你对谈他们的需求的理解的理想途径。并且两者都让用户习惯与相互交流。
额外的一英里
如果你和用户紧密协作，分享他们的期望，并同他们交流你正在做的事情，那么当项目交付时，就不会发生多少让人吃惊的事情了。
这是一件糟糕的事情。要设法让你的用户惊讶。请注意，不是惊吓他们，而是让他们高兴。
给他们的东西要比他们期望的多一点。给系统增加某种向用户的特性所需的一点额外努力将一次又一次在商誉上带来回报。
随着项目的进展，听取你的用户的意见，了解什么特性使他们真的高兴。你可以相对容易地增加，并让一般用户觉得很好的特性包括：
- 气球式帮助或工具提示帮助
- 快捷键
- 作为用户手册的补充材料的快速参考指南
- 日志文件分析器
- 自动化安装
- 用于检查系统完整性的工具
- 运行系统的多个版本，以进行培训的能力
- 为他们的机构定制的splash屏幕（交互式软件显示的初始画面——译注）
所以这些特性都是相对表面的，而且实际上不会因为特性肿胀而给系统带来过度的负担。但是，每一项特性都告诉你的用户，开发团队想要开发出了不起的系统，要用于实际的系统。只是要记住，不要因为增加这些新特性而破坏系统。
网友评论