2005年4月1日：“客户不满”
你总是在伤害你爱的人。我们必须真心诚意地爱我们的客户。我们把满是Bug的代码发布出去，尽管这不是什么大问题；我们延期交货，这不是什么大问题；我们对客户需求没有一个深入清晰的了解，并做到客户至上，这不是什么大问题；我们没有跟客户进行很好的沟通并达成一致意见，这不是什么大问题；我们没有很好地聆听客户的声音，然后把信息传递给该得到这些信息的人，同样，这仍然不是什么大问题。注意，真正的大问题是，当我们在折磨客户的时候我们常常浑然不知，也不知道我们做得有多恶劣，而到察觉的时候已经太晚了。
作者注：以上陈述我有些夸大其词，不过是为了增加些戏剧性而已。实际上，我们能够认真聆听客户的声音，并且把这种客户的意见集成到了我们的产品中，这方面我们做得很好。这甚至是多年来微软的一个巨大的竞争优势。尽管这样，随着软件市场的日益成熟，我们客户的期望也在不断提高。因此为了保持我们的竞争优势，我们必须继续改进。本栏目将讨论应客户需求的变动而变动代码的好处。
如果我们发布了没有Bug、高质量的代码，但它跟客户想要的东西不一致，那么客户会不满意。按时发布客户不想要的代码同样会使他们不满意。即使我们对客户需求有了一个深入清晰的了解，分清其需求的轻重缓急，我们发布的代码仍然必须符合这些需求，否则客户就会不满意。做好沟通与聆听并不够，如果我们最终无法交给客户他们真正想要的东西，一切都没有意义。
不知者无罪
实际上，良好的沟通和聆听反而会有害于我们。假设我们跟客户交谈了，了解了他们真正想要的东西。客户看到我们这么真诚会很高兴，以为我们真正了解了他们所要的东西。两年之后，我们交给客户一个解决方案，但它达不到他们的期望。结果是：
客户很失望，因为产品并没有像他们期望的那样发挥功能。
客户觉得受到了侮辱，因为我们浪费了他们的时间，我们燃起了他们的希望，最后又亲手把这希望之火扑灭。
客户被激怒了，因为我们没有恪守承诺为他们服务，他们可能再也不会相信我们了。
如果我们一开始就不理会客户，至少我们还可以为这个错误找到借口。我们可以声称“我们不知情”。遗憾的是，我们确实知情，我们的确承认了，我们确实也承诺了。即使承诺没有以合同的形式确定下来、不具备法律效力，但承诺是实事，而我们没有守诺。
欲速则不达
你觉得这不会发生吗？错了！我们总是不恪守诺言。令人惊讶的是，我们居然还有客户。我们的销售人员与客户交谈，告诉他们我们的计划。我们的顾问拜访客户，信誓旦旦地说他们会与产品团队一起提供特定的解决方案。我们的市场和产品计划人员成立专门的工作组并告诉客户我们正在开展工作。
作者注：我说的“我们总是不恪守诺言”是指我们达不到理想目标。我们交给客户当初要求的东西，但并不完全符合他们所需要的。客户在看到产品之前并不知道他们想要什么，这也是为何敏捷方法强调迭代客户反馈的原因。我使用“承诺”这个词，是因为它对微软的员工来说有着重要的意义。我们很容易在我们的产品中犯些小毛病，但就是这些小毛病使客户头痛不已。我想让工程师知道这一点。
我们确实是在开展工作。市场机遇决定了我们产品的计划和远景。但我们与客户之间还没有形成一个良好的沟通渠道，除非已经太迟了，我们无法应客户要求再做改变。当客户在运行着的产品上点击某个按钮时，我们才意识到需要花时间去重新思考我们已经做过的事情，此时的天国之门已经关闭。遗憾的是，大部分情况下，在客户接触到我们的产品之前，我们已经完成了所有的编码。
作者注：这里让我来推介一下产品测试版和技术预览版，因为我在原来的栏目中没有提及它们（这是个严重的疏忽）。大部分微软的产品都发布测试版，但只有一两个，并且通常只在开发周期的后期才发布。然而，一些产品已经开始在早期阶段就频繁使用技术预览和测试版——这种做法我很喜欢。
实际上，当我们的产品出货之后，我们跟客户的沟通渠道做得相当好。Watson和SQM会向我们汇报信息，反映我们的客户在我们交付的产品上正在经历的所有糟糕体验。这已经向前迈进了一大步。我们修复这些Bug，然后在3个月或者3年之后再次发布产品，接着Watson可以向我们证明这些讨厌的问题是否已经消失。
作者注：当你的应用程序在微软的Windows操作系统上崩溃的时候，你会看到一个“发送错误信息”的对话框，Watson就是支持这个功能的一个内部称谓。（常常会有这种对话框弹出，并确实引起了我们的注意。）SQM也是一个内部技术名称，它通过匿名收集用户对产品的使用模式和体验，来支持MSN、Office、Windows Vista和其他产品的用户体验改进计划。（请你在安装我们的软件的时候加入这个计划，它会让我们知道什么工作得很好，而什么不尽如人意。）
但有些问题会导致我们不能守诺，扼杀我们的商业机会，摧毁我们的客户对我们仅有的一点点信任，这会是些什么问题呢？我们怎样才能在产品出货之前就发现这些问题？我们怎么能避免这些问题的发生呢？
敏捷错觉
说到这里，那些敏捷方法的信徒们可能已经在尖叫了：“使用敏捷方法！”好啊，你试试每周或者每月跟1亿个客户开个会看。这并没有看起来那么简单。我不是说敏捷方法没用，而是说你可能有点太想当然了。
当然，你可以让项目经理或者产品的计划人员替代这1亿个客户，但他们能代表所有这些客户的准确性，跟你买彩票中大奖的概率差不多。也许你真的会中头奖，很多人都玩彩票，但你可不能把你的生意或者你的退休保障当赌注压在这种偶然的东西上呀！
你需要与客户间建立一条直达的通道，就像Watson所做的一样。你写的任何代码都应该对应于一个特定的客户需求、市场机遇、商业需要（比如TwC）或者用户问题（比如一个Watson桶）。这样的话，如果一个特定的问题出现了，或者你需要对你的工作进展得到定期反馈的话，你就知道应该找1亿客户中的哪个人了。
作者注：实际上，Watson并没有帮我们跟客户之间建立起一条直达的通道——我们收到的信息是匿名的，并且进行了汇总处理。我们真正建立的，是一条获取用户问题的渠道。每个“Watson桶”代表了一个用户问题，这个问题上千，有时甚至上万的用户都经历过了。因此对于一个Watson问题，我们不知道该找谁去确认，但我们能够了解到他们的问题到底是怎么回事。可信计算（Trustworthy Computing，TwC）——微软在安全、隐私、可靠性、健全的商业实践方面发起的研究课题，已经从Watson数据上为我们的用户带来了巨大的收益。
回头想想
你如何才能把一个特定的客户需求跟一行代码关联起来呢？对于Bug，这种关联我们已经做得差不多了，但对于功能开发呢？为了解决这个问题，你必须回头再想想：
为什么你要写那行代码？它的功能需求是什么？
那个功能需求因何而来？客户的应用流程是什么？
那个应用流程从何而来？市场机遇或者客户协议是什么？
谁定义了那个市场机遇或者签了那个客户协议？他的Email是什么？
如果你回顾一下你所做的工作发现它并不是客户所需要的，那么你所谓的客户需求，很可能是凭空猜测出来的。可追溯性（traceability）是能使我们的客户满意的关键。
一石多鸟
不过这只是个开始。像所有伟大的东西一样，可追溯性解决的不仅仅是与客户相关的需求问题：
可追溯性使我们的客户可以检查他们面临的问题的状态及相关解决方案。现今，不管是服务开发还是产品开发，因为我们具备后向追溯的能力，当客户检查一个错误或程序崩溃的状态时，他们基本上可以做到这一点了。至于从产品定义到产品开发的前向可追溯性，则不管是我们还是我们的客户都已获益匪浅。
可追溯性有助于我们权衡业务轻重缓急并促进交易达成，就如功能开发时安排优先顺序一样。因为可追溯性将我们与我们的变动对业务产生的冲击联系了起来，我们可以对一项功能或变动所需的资源量做一个明智的选择。
可追溯性帮助我们架构解决方案，确定依赖关系，并且安排组织项目。这是最出乎我意料的一个优点。有了可追溯性，你就可以知道什么样的用户应用流程决定了什么样的功能开发。因此你就能知道为什么会有这功能模块。这有助于建立正确的软件架构及依赖关系，从而采取适当的方法来组织项目。太棒了！
当然，如果没有可追溯性，客户就不知道他们的需求是否能够被满足，以及何时能够被满足；产品部门也不知道真正的业务危机将会是什么，因此只能靠猜测去做决定；各个部门都不知道他们为什么要这个或者那个功能，也不知道它们之间是怎样的依赖关系。我们的生活从此变得混乱不堪，危机重重。
作者注：为了引起注意，我又一次夸大其词，但我并没有夸大可追溯性的好处。对此我欣然接受，我非常喜欢可追溯性。
工欲善其事，必先利其器
那么，如何实现可追溯性呢？理想情况下，我们应该有一个工具，我们能用它来跟踪用户应用过程和需求，就像我们现在跟踪Bug和程序崩溃一样：
销售人员和顾问能够使用这个工具来记录客户需求、应用过程和承诺。
市场和产品计划人员能够使用这个工具来抓住市场机遇，并由此与客户达成协议，并且定义关键性的跨产品的应用。
产品计划人员和项目经理能够使用这个工具来整合需求，记录重复性，把多个产品之间相关的应用关联起来，并且在产品的层面草拟一项应用的操作过程、需求和功能规范书。
产品部门能够使用这个工具来对功能需求进行分诊，在设计和实现的全过程跟踪各个功能的进展情况。
测试团队能够运行测试用例并发现Bug，于是他们很容易就能明白各个潜在问题的破坏性。
客户需求的发掘人能够对客户提出的需求实现进度跟踪。产品团队也会联系他们，要求他们说明相关问题或者提供反馈。当情况有变时，客户需求的发掘人也能主动联系产品团队来更新需求。
查缺补漏
有些部门其实正在使用Product Studio来实现可追溯性，但这个工具还不算是个完美的解决方案。在我们得到正确的工具之前，若想做到在整个设计过程中跟踪客户需求和应用过程，我们还有以下几个方法：
作者注：Product Studio是微软内部的一个工作条目跟踪数据库。如今我们已经将它产品化了，并把它集成在Visual Studio Team System中。自从本专栏设立以来的5年里，大多数微软的工作部门已经采用Team Foundation Server（TFS）来跟踪项目进展。我们已经近乎实现可追溯性了，就像我之前所述的那样。
当你撰写市场分析报告的时候，对相关的客户协议书做个链接，并确认这些协议书具有相应的客户联系信息。同时也在这份市场分析报告中留下你自己的联系信息。
当你在创建高级应用范例的时候，对市场分析报告及客户协议书也做个链接，同时也要留下你的联系信息。
当你撰写功能规范书、需求列表或者产品应用案例的时候，将相关的高级应用范例、需求分析、市场分析报告和客户协议书都做个链接。哪个功能与哪篇文档相关一定要明确，不要只建一个冗长的链接清单了事。
当你创建设计文档的时候，做个到规范书和其他支持文档的链接。再次强调一下，不要创建一个长长的参考列表——事无巨细地将所有信息都罗列出来，甚至你可能将每个联系人的联系方式都列出来。
当你面临抉择或复审工作的时候，通过这些链接追踪到相关人员那里，也就找到了问题的根源。
令客户满意
当下，我们的业务运转方式像小孩子的“打电话”游戏一样。每个人把他认为客户想要的东西告诉下一个人。一路传下去，信息在每一步都会被扭曲和丢失。等到我们产品出货的时候，客户甚至不认得这就是他当初要求的东西。（此时你可能想起了那幅经典的卡通图：客户真正想要的是在一棵树上挂起一个轮胎秋千；但他们最后得到的却是树干被挖出一个洞。）
当产品不断演变，开发不断推进，你必须回过头去跟客户谈谈，以确保你做的决定是正确的。同样重要的是，客户在他们的需求或者应用流程改变的时候，也要有办法跟你取得联系。如果没有一个沟通渠道，这是不可能做到的。
可追溯性把这种渠道建立起来了，但你必须谨记你要做什么并努力去做。期间出现的任何差错，都会使你承受毁约的风险。但如果你做对了，也就意味着你每次都能给客户带去他们真正想要的东西。那就是你辛勤努力的价值所在！
