一个失败的案例

曾经有这样一个经典的案例。某咨询公司在系统的部署和运行方面有很好的声誉，它曾经实施过许多成功的案例，并且有庞大的客户群。在其事业的顶峰期，实施了一个接一个的成功项目。其技术实施团队成功的把客户服务、充满智慧的系统部署、稳定的系统运行（这一点带来了长期的业务关系）结合到了一起。

就在公司随着成功飞速前进时，管理层开始安排具有业务流程、写作和客户服务各方面经验的员工总结一套方法论。因为他们知道公司不可能永远的照此发展下去，不能永远都依靠运气和员工的盲目努力来获得成功。

接受任务的员工开始认真的投身于自己的任务。他们花了几个月时间研究项目管理、反复软件开发、流程设计、沟通交流以及管理学方面的理论。他们与客户、内部员工、共事的CXO们进行了广泛的沟通交流。他们把收集到的所有好方法和好点子通通揉合到一个庞大的模板和设计图里面。这个模板包含了从业务前咨询到项目运作的结束程序的所有内容，甚至包括了一些项目陈述和图片的样板，因为开发人员认为这可能对公司的销售队伍有帮助。

结果是，没有人使用这套东西。无论同事们说他们有多么喜欢这东西，事实证明这样的包罗万象的文档对于项目的日常运作来说太麻烦了。客户也不喜欢这套东西，他们几乎不看它。他们要么被这个文档所淹没，要么就找不到他们想要的东西。

我们现在还能看到许多的系统集成商和咨询机构吹嘘他们的方法论。这些所谓的方法论的大部分比上述案例中的文档好不到哪里去。有些粉饰成复杂理论的方法在实质上还是同样的东西——一套模板和一堆没有什么应用价值的文档。在许多IT用户那里，我们还可以看到很多的项目档案和技术设计材料，盖着一层灰尘，从它们被送给用户的第一天起就再也没动过。

应该建立方法论，而不是方法

问题并非是这些文档里的那些思想和点子有问题，也并不是因为这些文档的内容太多了。相反，是这些文档内在的理论和运用之间的不恰当结合让我们接受起来有困难。

当我们谈到方法论时，我们往往想到的是那些可以直接体现出来的东西（deliverables）：比如可以列出的一系列风险、循序渐进的规划步骤、以迅捷的方式进行关键信息交流的方法。有些时候我们谈论的层次可能比这要高一点点，我们可能会涉及到开发人员开发系统的过程，但这仍然是不够的。只有极少的情况下我们才有可能会谈到，为了适应特定的客户需要我们应该任何修改那些现成的模板。

然而不幸的是，上述的那些我们关注的，可以直接体现出来的内容、以及那些系统开发过程的相关内容，都还算不上是方法论。它们只能算作是方法论的产物，是我们把理论转化来更适应实际操作的产物。关于开发过程的内容离总结出方法论只有一步之遥了，它是特定的工作团队或组织的特定习惯和能力与普遍化的方法论相结合的结果。那些可以直接体现的内容离总结出方法论就更远了，它是那些开发过程的知识和实际应用、完成项目所作的工作相互作用的结果。

举一个简单的例子。理论指出，项目存在的原因是某项任务不是日常重复的，所以要成立项目组来专门解决这项任务。网络设计方法论则进一步指出，要完成一个项目，必须准备好下一步移交给实际的操作。所以，你就必须对执行操作的团队解释清楚，各种网络构件（比如访问点、身份验证系统、服务、服务器）之间是怎样相互作用的。开发过程的知识则更进一步，大致勾画了项目中的人员该如何围绕解释清楚这些内容而出力。这类解释采用的是文档的形式（书面的或者电子化的），让用户能够以最方便的形式读取。

那些模板之类的东西最恰当的作用是向参加到操作流程中的开发人员提供一个可参照的范例。最好的模板都是从以使用文档为主的方法中产生出来的，而文档方法论则与以设计、部署、运行为中心的、更贴近实践的方法论有所不同，它主要的作用是向项目团队提供技术应用所需要的各种信息。所以，搜集一堆模板并不能算作是总结出来方法论，这些模板也不是放之四海而皆准的真理，它们是需要作适当调整才能适应不同客户和团队的需要的。

一个成功的案例

在另一个发生在一家系统集成公司的案例里，开发人员负责开发一个“技术方法论”来向那些初级的员工提供帮助。开发人员的想法是要利用自己广博的专业知识和技能开发出一套包罗万象而又和谐的方法论。开发团队的人员们总的加起来，共拥有100多年的研发经验，其中80多年是和基础设备的开发有关。

该团队开始了这个方法论开发的项目，其间编辑了大量的文稿、无数的负责流程图。他们几乎综合了每一个细节可能用到的模板。在最初的混乱与繁杂处理好了之后，有成员建议再往回看看，搞清楚团队到底要完成什么样的目标。他们的目标和对方法论的描述写了满满一张纸。然后，他们又对这些原则进行了进一步的解释，花了四页纸的篇幅。借助于这些较详尽的解释，其它的使用者可以自己创造出一个操作流程。而他们最初写出的那些大量的文档就是从这类流程中总结出来的，也就是说者四页纸的内容实际上已经提炼了那些大量的文档的基本内容。这样的一套方法论就自然的更容易理解了，咨询机构的销售人员自然也更容易向客户介绍这套东西。它同样还涉及到了业务运作的内容，在那些原本很难沟通的部门之间创造了一种共同语音。

在第一个案例里，开发人员非常关注于最后开发出来的文档，并没有真正的设计方法论的核心；在第二个案例里，开发人员始终关注于开发出清晰简洁的指导原则。这就是为什么两个案例的结果截然不同的原因。