2006年7月1日:“停止写规范书,跟功能小组呆在一起”
我不是项目经理(Program Manager,PM),我也从来没有担任过项目经理,我将来也不可能成为一名项目经理。这并不是因为我个人对项目经理的抵触,其实,我的朋友之中不乏出色的项目经理。很显然,我没有权利去教导项目经理应该怎么去做他们的工作。
尽管如此,项目经理应该停止写规范书。就这么简单!他们在浪费我的时间,浪费组织的时间,浪费整个公司的时间。你几乎可以听到残留着的、细微的、嘎吱嘎吱的声音,因为规范书像白蚁一样在一口一口咬掉公司和客户的价值。我对此深恶痛绝!
其实不仅仅是项目经理,开发者也必须停止写开发规范书,测试者则必须停止写测试规范书。疯狂必须停止!浪费必须停止!我们必须反省,保持头脑清醒,重新焕发我们的生产力。
作者注:本栏目肯定是我发表过的最有争议的栏目之一。你也可以从接下去的那段文字看出,我当初就猜到了这一点。关于我的观点,大家最大的误解是在“正式文档”和“非正式文档”的区别上面。我认为,跨工种的团队只需要非正式的文档,比如把白板上的内容拍了照片放到维基网站上,并加上少许的注释。而不同地点不同部门的团队则需要正式的文档,比如具体的规范书。
你失去理智了吗
“你肯定不是认真的?”我听到忠实的读者这么说,“你多年来一直鼓吹质量(参见第5章的‘牛肉在哪里’栏目)和设计(参见第6章的‘通过设计解决’栏目)。你告诫开发人员在他们拿到规范书之前不要采取行动,在没有彻底理解设计之前不要开始编码。莫非现在你承认以前是被误导了,或者甚至可能你本身的认识就是错误的?”不,当然不是。
功能团队在开发用户体验之前必须首先理解它,开发人员在实现一个内部设计之前也必须首先充分理解它,这样才能面对面地解释给同伴听。但是,这些步骤中都不需要正式书写的文档。
为什么我们需要正式书写的规范书呢?客户不需要它们。市场和产品规划部门也不需要它们。即便是内容发布者和产品支持人员,他们对规范书的使用也是有限的。因此,谁需要这些荒唐无用的“杰作”呢?为了找到答案,我们不妨把规范书扔掉,看看谁会叫起来。
进退两难
如果我们不再有规范书,开发和测试人员会大叫,“我怎么知道代码应该实现什么功能呀?”告诉他们找项目经理讨论去。然后他们接着抱怨,“项目经理又不会整天在我的办公室里转悠。我需要记录下来的规范书。我必须对它们进行复审、修改和更新。”
是的,这里的确有问题。不是开发和测试人员必须有规范书以便复审、修改和更新,而是项目经理没有整天留在附近,一起来讨论用户体验、实现和测试策略。好吧,那如果项目经理这么做了又怎样呢?
如果项目经理跟开发和测试人员整天呆在同一个开放区域里,并且周围摆满了白板,一起为同一个功能集合努力工作,又会怎么样呢?我们还需要正式书写的规范书吗?等等,我听到了更多的尖叫声。
特殊要求
如果没有正式书写的规范书,依赖这些功能的其他团队将会抗议,“如果我们不知道你的代码是怎么工作的,我们怎么知道如何去使用它呀?”这问题问得很好。如果项目经理整天跟功能团队呆在一起,他们也就不可能有时间去应对所有的下游团队,而我们也不可能把所有人都塞到同一间房间里去。然而,下游团队其实不需要规范书——他们需要的是一个小型的软件开发包。不管怎么样,组件团队都得提供软件开发包的,这么做非常有价值。
如果没有正式书写的规范书,“合规警察”(Compliance Police)将会咆哮,“<在这里插入你最喜欢的官僚栓剂>的文档在哪里?”这问题问得也不错。合规警察让我们远离伤害。尽管他们的工作不怎么讨好,但却非常重要。他们常常需要正式书写的文档来完成他们的工作。然而,合规警察同样也不需要规范书。他们需要的是完整的合规文档,跟规范书相比,它常常以不同的形式包含不同的信息。
作者注:这些“合规警察”是谁?他们其实是普通的工程师,只不过他们的工作重点是,确保微软的产品在关键领域的正确性,比如安全、隐私、全球可用(没有不合适的委婉语或引用)和遵从所有适用的法律和法规,等等。举例来说,他们要求的典型文档包括:威胁模型(安全方面的)、隐私声明、专利权使用条款等。
在上述两种情况下,你都不需要正式书写的规范书。你需要的是其他类型的特定文档,而这种文档会比较容易写,因为它不会没完没了。
我不记得了
那么我们还需要正式书写的规范书吗?我“不记得”所有的状况了,因此让我们来理一下:
项目经理在团队的房间里度过他们所有的时间,跟功能团队一起讨论用户体验、实现和测试策略。
功能团队为下游团队写一个小型的软件开发包。
功能团队填写必要的合规文档。
我把它们都写下来了,看起来很不错。不过,等一下,这里有个问题。
人们常常健忘。你不得不把想法写下来,尤其当你经常在不同的项目之间切换的时候。很自然,如果一个功能从开始到结束要花费几个月的时间,在这期间可能会有人离开团队,那么信息岂不是都丢失了!
坚持做一件事情
但如果你一次只做一个功能会怎么样呢?那花费的时间就不会那么长,你也不会在项目之间来回转换。团队中有人离开的几率会小一点,而把想法记在脑子里也会容易得多。你只是需要用数码相机把白板上的任何内容拍下来,然后放到一个维基网站上或Word文档中或OneNote记事本中。
这看起来像是规范书,只是没有了让人头脑发麻的长篇大论。它给你留出了更多的时间去思考,以及在白板前合作,而减少了你在座位上摆弄像素和文字的时间。
很好,你把功能团队聚集在了相互靠近的区域,并配备了大量的白板。你一次只做一个功能,直到这个功能做完。你用相机把所做的决定存档。你撰写了对下游团队有价值的专门文档。这听起来像是精益软件开发(你可以在第2章的“精益:比五香熏牛肉还好”这篇文章中了解到更多的内容)。妙极了!这就是你停止浪费之后所得到的。
你准备好了吗
可能极少有团队马上停止写正式的规范书。他们还没有接受“功能小组”(Feature Crew)的概念,即一次只做一个功能,并且从头到尾把这个功能做完。他们不能呆在同一个团队房间里面,主要靠白板来相互沟通。
然而,变化已经开始了。各个部门正在调整位置以相互靠近,因为这样做起事情来更快、更容易。各部门也正在组织功能小组,因为这样做可以更快地得到更高质量的功能,并且留下较少的未完成的工作。顺着这个趋势,把它们不断整合,那你可以把规范书永远抛弃了。这不是梦想,而是简单时代的回归,是久经鏖战的智慧结晶。
作者注:我作为Xboxcom项目开发经理时接手的第一个棘手事情是协调6个Scrum团队,包括将立体墙搬到每个团队的房间中。在这次办公室调换之前及之后数个月,这6个团队一直一起奋斗在Kinect及Windows Phone两个项目上。这次Scrum团队得出的时间及速率数据是度量协同合作效力的最佳良机。其中5个团队的四周平均速率提升20%~63%(第6个团队发布了beta版,因新项目的开发而暂停),提升20%就像每星期另增了一天的生产能力,并多出了两天的周末时间。提升63%(那就是每星期多了3天!),同时缩减了工程长度。不要预先分配其他工程项目,让第一个空闲的人自由选择,这样就有助于跟其他人进行跨部门的工程合作。团队唯一要做的文档工作就是后期维护记录。用OneNote记下来,并做好基本的“合规事宜”。