我最喜欢的方法是“规范书变更请求”(SCR,Spec Change Request),它还有一个扭曲的名字叫“设计变更请求”(DCR,Design Change Request)。这种方法是委员会议和走廊会议的组合,同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容,你的这个想法可能是你自己想出来的,也可能源于一次走廊对话,也可能受到了一次主管会议的启发。
不管你是项目经理、开发、测试或实施人员,你都可以把你的想法写到e-mai中去,并且e-mai的标题定为“SCR: <受影响的规范书> - <变更的简短描述>”。在e-mai结尾的地方,你用粗体字写下这么一句话,“除非有人强烈反对,否则这就是最新采纳的规范书。”然后,你把这封e-mai发给最直接受这个变更影响的项目经理、开发、测试和实施人员。几天之后,当你根据他们的建议做完了必要的修改,你就可以把你的SCR发给团队中剩下的所有人,并且把它放到RAID中或者一个公共目录中,跟其他SCR一起跟踪。
译者注:关于RAID,参见本书最后的“术语表”。
这里的关键是,规范书的变更现在文档化了,并且得到了相关人员的复审,而且不会阻碍工作的进展。反对几乎总是例外,不会有很多。开发人员在任何时候都可以继续工作,这里只是一个权衡问题——动手做之前花更多的时间等待是否有反对,或者冒着后来被反对的风险马上就动手做。典型情况下,开发人员会一直等待,直到SCR经过了初始的几次修改后发给团队全体成员的时候才动手做。
预防是最好的治疗
当然,最理想的是规范书从一开始就不会迟到,至少你不能被它蒙蔽。这里就用得着T-I-M-E图表了。在T-I-M-E图表中,第一份规范书展示了对整个项目的设计。它不是简单的需求文档,也不是数个小型规范书的集合,而是项目的一个高级规范书,很像是开发主管写的那种高级架构文档。这个规范书应该展示项目将具有的功能和用户界面,以及它们怎样在一起协作,而把细节留给以后的规范书。所有后来的规范书和功能都必须参考这个高级规范书。
这样的话,开发、测试和实施人员就可以制定计划去说明未来所有的功能了。他们能够生产出集成得更好的产品,使用户体验更加流畅。项目经理也可以使用第一份规范书去安排剩下的其他规范书,先做优先级高的,而不必担心遗漏什么东西或者做出让别人吃惊的事情来。这种理想终究使T-I-M-E产生了(难以抗拒)。
作者注:T-I-M-E(Totay Incusive Mutuay Excusive)图表是由Donad Wood首先提出的,但它从未像我的同事Rick Andrews最初预期的那样流行过。然而,微软现在的价值主张、远景文档、跨产品案例和仔细设计的原型都能达到同样的目的。