第二章 过程改进,没有灵丹妙药
第三节 2005年4月1日:“客户不满”
敏捷错觉
说到这里,那些敏捷方法的信徒们可能已经在尖叫了:“使用敏捷方法!”好啊,你试试每周或者每月跟1亿个客户开个会看。这并没有看起来那么简单。我不是说敏捷方法没用,而是说你可能有点太想当然了。
当然,你可以让项目经理或者产品的计划人员替代这1亿个客户,但他们能代表所有这些客户的准确性,跟你买彩票中大奖的概率差不多。也许你真的会中头奖,很多人都玩彩票,但你可不能把你的生意或者你的退休保障当赌注压在这种偶然的东西上呀!
你需要与客户间建立一条直达的通道,就像Watson所做的一样。你写的任何代码都应该对应于一个特定的客户需求、市场机遇、商业需要(比如TwC)或者用户问题(比如一个Watson桶)。这样的话,如果一个特定的问题出现了,或者你需要对你的工作进展得到定期反馈的话,你就知道应该找1亿客户中的哪个人了。
作者注:实际上,Watson并没有帮我们跟客户之间建立起一条直达的通道——我们收到的信息是匿名的,并且进行了汇总处理。我们真正建立的,是一条获取用户问题的渠道。每个“Watson桶”代表了一个用户问题,这个问题上千,有时甚至上万的用户都经历过了。因此对于一个Watson问题,我们不知道该找谁去确认,但我们能够了解到他们的问题到底是怎么回事。可信计算(Trustworthy Computing,TwC)——微软在安全、隐私、可靠性、健全的商业实践方面发起的研究课题,已经从Watson数据上为我们的用户带来了巨大的收益。
回头想想
你如何才能把一个特定的客户需求跟一行代码关联起来呢?对于Bug,这种关联我们已经做得差不多了,但对于功能开发呢?为了解决这个问题,你必须回头再想想:
·为什么你要写那行代码?它的功能需求是什么?
·那个功能需求因何而来?客户的应用流程是什么?
·那个应用流程从何而来?市场机遇或者客户协议是什么?
·谁定义了那个市场机遇或者签了那个客户协议?他的Email是什么?
如果你回顾一下你所做的工作发现它并不是客户所需要的,那么你所谓的客户需求,很可能是凭空猜测出来的。可追溯性(traceability)是能使我们的客户满意的关键。
一石多鸟
不过这只是个开始。像所有伟大的东西一样,可追溯性解决的不仅仅是与客户相关的需求问题:
·可追溯性使我们的客户可以检查他们面临的问题的状态及相关解决方案。现今,不管是服务开发还是产品开发,因为我们具备后向追溯的能力,当客户检查一个错误或程序崩溃的状态时,他们基本上可以做到这一点了。至于从产品定义到产品开发的前向可追溯性,则不管是我们还是我们的客户都已获益匪浅。
·可追溯性有助于我们权衡业务轻重缓急并促进交易达成,就如功能开发时安排优先顺序一样。因为可追溯性将我们与我们的变动对业务产生的冲击联系了起来,我们可以对一项功能或变动所需的资源量做一个明智的选择。
·可追溯性帮助我们架构解决方案,确定依赖关系,并且安排组织项目。这是最出乎我意料的一个优点。有了可追溯性,你就可以知道什么样的用户应用流程决定了什么样的功能开发。因此你就能知道为什么会有这功能模块。这有助于建立正确的软件架构及依赖关系,从而采取适当的方法来组织项目。太棒了!
当然,如果没有可追溯性,客户就不知道他们的需求是否能够被满足,以及何时能够被满足;产品部门也不知道真正的业务危机将会是什么,因此只能靠猜测去做决定;各个部门都不知道他们为什么要这个或者那个功能,也不知道它们之间是怎样的依赖关系。我们的生活从此变得混乱不堪,危机重重。
作者注:为了引起注意,我又一次夸大其词,但我并没有夸大可追溯性的好处。对此我欣然接受,我非常喜欢可追溯性。
工欲善其事,必先利其器
那么,如何实现可追溯性呢?理想情况下,我们应该有一个工具,我们能用它来跟踪用户应用过程和需求,就像我们现在跟踪Bug和程序崩溃一样:
·销售人员和顾问能够使用这个工具来记录客户需求、应用过程和承诺。
·市场和产品计划人员能够使用这个工具来抓住市场机遇,并由此与客户达成协议,并且定义关键性的跨产品的应用。
·产品计划人员和项目经理能够使用这个工具来整合需求,记录重复性,把多个产品之间相关的应用关联起来,并且在产品的层面草拟一项应用的操作过程、需求和功能规范书。
·产品部门能够使用这个工具来对功能需求进行分诊,在设计和实现的全过程跟踪各个功能的进展情况。
·测试团队能够运行测试用例并发现Bug,于是他们很容易就能明白各个潜在问题的破坏性。
·客户需求的发掘人能够对客户提出的需求实现进度跟踪。产品团队也会联系他们,要求他们说明相关问题或者提供反馈。当情况有变时,客户需求的发掘人也能主动联系产品团队来更新需求。