伟大的期望
伟大的期望
――《实用程序员：从学徒到大师》
一家公司刚宣布其创记录的利润额，其股票市值就降落了20%。当晚的财经新闻则解释说该公司的利润未能迎合分析家们的预期。一个孩子打开一件昂贵的圣诞节礼物却突然大哭起来：这不是他一直要的那个廉价娃娃。一个项目团队奇迹般地完成了一个明显是复杂的系统，却因为缺乏帮助系统而被用户束之高阁。
在抽象的意义上，如果一个应用程序正确地实现了其规格说明，那么它就是成功的。不幸的是，这只是抽象的兑现。
在现实里，一个项目的成功是由它在多大程度上迎合了用户的期望来衡量的。一个项目低于用户的期望值就被认为是失败的，不管在绝对意义上该交付系统有多好。但是，正如那个期望廉价娃娃的孩子的父母，你如果走得太远了也过犹不及。
窍门69：稍微超出你的用户的期望。
然而，实践这一窍门还需要一些工作。
交流期望
一开始用户是带着对他们需求的想象而来的。可能这些想象是不完整的，前后不一致的，或者技术上是不可能的，但是这毕竟是属于“他们的”。而且，正如那个圣诞节的孩子，他们已经在上面投入了感情。所以，你不可以简单地置之不理。
随着你对他们需求的理解进一步深入，你会发现他们的需求无法满足的地方，或者他们的需求大概过于保守之处。你的部分任务就是对此进行沟通。和你的用户一起工作，使得他们对你行将交付之系统的理解不偏不倚。贯穿整个开发周期都要这样做。永远不要忘记你
的应用程序意图解决的商业问题。
一些顾问把这个过程称为“管理期望”——主动地控制用户应该从系统中期望得到的东西。我们认为这种说法多少有点居高临下。我们的角色不是试图去控制用户的希望。相反，我们要和他们一起工作，以达成对于开发过程和最终交付的共识，还包括那些他们没有描述出来的期望。如果开发团队总是能够通畅地和外部世界交流，这个过程就几乎是自动的。所有的人都了解期待什么以及如何构建。
有一些重要的技巧可以用来推动这一过程。“曳光弹”和“原型及记事贴”是其中最重要的。两者都使得团队建立一些立杆见影的系统；两者都是交流你对项目需求之理解的理想方式；而且两者都让你和你的用户实践相互沟通。
额外一英里
如果你紧密与用户合作，分享他们的预期，通报你当前的工作，那么在项目交付使用之时就不会有什么意外发生。
这是一件“坏事”。试着给你的用户惊喜。别惊吓他们，要记住，而是取悦他们！
给他们的要比他们一直期望的多一点点。那一点需要为增加一些面向用户的特性而付出的额外努力，将会因其善意而不时得到回报。
在项目进展中倾听你的用户。推测什么样的特性会真正取悦他们。有些东西你可以相当容易地添加，而且对一般用户来说也看着不错。它们包括：
· 浮动式或者工具提示帮助
· 快捷键定义
· 作为用户手册补充的快速参考指南
· 彩色化
· 记录文件分析
· 自动安装
· 可用于检测系统完整性的工具
· 为了培训而运行系统多个版本的能力
· 一个专门为他们的组织订做的启动画面
所有这些东西都是相对肤浅的，且不会真的用膨胀的特性使系统不堪重负。然而，每一件这样的事情都告诉你的用户，你的开发团队致力于生产一个出色的系统，一个意欲付之实用的系统。但是要记住，别因为加入的新特性而破坏了系统。
相关章节包括
· “够好的”软件
· 曳光弹
· 原型和记事贴
· 需求陷阱
挑战问题
· 有时一个项目最苛刻的评估者就是在其中工作的人。你是否曾经经历过由于你生产的某些东西未能满足你的预期而失望？这是如何造成的呢？可能不仅仅是其中的工作逻辑。
· 你的用户对你交付的软件的评价是什么？他们对于软件不同方面的注意力是否正比于你为之投入的努力？是什么令他们满意？