代码之道——2006年7月1日:“停止写规范书,跟功能小组呆在一起”

    我不是项目经理(PM,Program Manager)。我也从来没有担任过项目经理。我将来也不可能成为一名项目经理。这并不是我个人对项目经理的抵触。因为我的朋友之中不乏有出色的项目经理。很显然,我没有权利去教导项目经理怎么去做他们的工作。     尽管如此,项目经理应该停止写规范书。就这么简单!他们在浪费我的时间,浪费组织的时间,浪费整个公司的时间。你几乎可以听到残留着的、细微的、嘎扎嘎扎的声音,因为规范书像白蚁一样在一口一口咬掉公司和客户的价值。我对此深恶痛绝!     其实不仅仅是项目经理。开发者也必须停止写开发规范书。测试者则必须停止写测试规范书。疯狂必须停止!浪费必须停止!我们必须重新找到我们的感觉,找回我们的生产力,还有我们的智慧。     作者注:如果用回应数来考量,本栏目肯定是我发表过的最有争议的栏目之一。你也可以从接下去的那段文字看出,我当初就猜到了这一点。关于我的观点,大家最大的误解是在“正式文档”和“非正式文档”的区别上面。我认为,多工种呆在一起工作的团队只需要非正式的文档,比如把白板上的内容拍了照片放到维基网站上,并加上少许的注释。而被距离隔开或按照工种划开的团队则需要正式的文档,比如具体的规范书。     你失去理智了吗?     “你肯定不是认真的?”我听到忠实的读者这么说,“你多年来一直鼓吹质量(参见第5章的“牛肉在哪里”栏目)和设计(参见第6章的“通过设计解决”栏目)。你告诫开发人员在他们拿到规范书之前不要采取行动,在没有彻底理解设计之前不要开始编码。莫非现在你承认以前是被误导了,或者甚至可能你本身的认识就是错误的?”不,当然不是。     功能团队在开发用户体验之前必须首先理解它,开发人员在实现一个内部设计之前也必须首先充分理解它,这样才能面对面地解释给同伴听。但是,这些步骤中没有哪个需要正式书写的文档。     为什么我们需要正式书写的规范书呢?客户不需要它们。市场和产品规划部门也不需要它们。即便是内容发布者和产品支持人员,他们对规范书的使用也是有限的。因此,谁需要这些荒唐无用的“杰作”呢?为了找到答案,我们不妨把规范书扔掉,看看谁会叫起来。