微软研发致胜策略 02：系统化的方法

这是一本老书，作者 Steve Maguire 在微软工作期间写了这本书，英文版于 1994 年发布。我们看到的标题是中译版名字，英文版的名字是《Debugging the Development Process》，这本书详细阐述了软件开发过程中的常见问题及其解决方案，强调团队合作、项目管理和开发流程的优化。该书成为软件开发和项目管理领域的经典著作，受到了广泛的认可和赞誉。

不记录，等于没读。

令人惊讶的是，一个相对微不足道的工作习惯或流程竟能对结果产生重大影响。理想情况下，这个习惯或流程实施起来几乎不需要努力，其有效性也不取决于使用它的程序员的技能水平。为了引出最有效的工作策略，负责人应将他们试图解决的问题以越来越精细的形式提出。例如，负责人不应该问“我们如何能持续按期交付？”因为这可能会导致许多不理想的解决方案。相反，负责人应该提出一个更具体、更有益的问题：“我们如何能在不增加人手和不强迫开发人员加班的情况下持续按期交付？”负责人应尝试将负反馈回路纳入他们制定的策略中。而当他们向团队介绍工作策略时，应该提醒团队，即使是一个好的策略或指导方针也不一定在每种情况下都有效。

作者使用纸和笔写技术文件或文章的初稿，然后再输入计算机编辑。原因是作者发现自己用 word 软件时，常常把时间浪费在编辑修改上，从而拖延了工作效率。作者意识到这个问题后，就开始用纸笔，这一点小改变，却大大提高了作者的写作效率。

用不同颜色的杯子区分咖啡的浓度，这样客户在续杯时，服务员就不会弄错。作为反例，有的咖啡店要求服务员记住每位客户点的咖啡浓度，很显然，这容易出错。

好喝咖啡的简单秘诀

作者家附近有两家咖啡店，它们的硬件设施和人员都很相似，但咖啡的质量却差异很大。咖啡质量稳定的那家咖啡店，他们有一个简单又关键的质量体系秘诀，每当新的服务员到职，经理就指着咖啡壶上的横条给他上课：

“你倒咖啡时，只要发现水位在这条线以下，就要立刻煮新的一壶，不要被任何事耽搁。”
“万一那时候店里很忙怎么办？”
“即使一整队的芝加哥公牛刚刚打完球，全挤到这儿来也不管，还是先煮新咖啡要紧，那怕你已经倒好一杯咖啡要端给美国总统，只要看到水位在这条线以下，就要停下所有的事，先去煮咖啡。”

从一个空壶放进磨好的咖啡豆，到开始煮，总共要花15秒钟，但煮咖啡的时间要7分钟。造成这两家咖啡店质量不同的原因竟然是一家等到壶内的咖啡全空了才再煮新的，一家却是壶内的咖啡到了低水位时就再煮新的一壶。两家的作业方式几乎完全一样，就只有这点小小的差异，结果竟然如此天差地远，而且这和人员的技术毫无关系。咖啡壶全空之后再煮咖啡，就需要客人再等 7 分钟，如果仅仅只是等 7 分钟，并不会造成咖啡质量不稳定。问题在于，在等待煮咖啡的过程中，店员会受到客户的催促，在压力之下，店员会为了快而做出伤害咖啡质量的事情，比如为了快点煮好咖啡，咖啡机内只放一杯量的咖啡和水，由于水太少，加热器不容易调到适当的火力等等。所有求快的操作，都违反了煮咖啡的基本标准。

从这些例子可以看出，在程序上的一点小小改变，可以造成非常不同的结果。

应用到软件开发上，软件开发过程中，正确的修复 BUG 时机是什么？等到所有的功能开发完毕后再一起测试、修复 BUG，或是一发现有 BUG 就立刻除掉它，或是无所谓，反正花的时间都是一样的。如果你认为何时除错都一样的话，那可就错了。这就像咖啡店经理误以为什么时候煮新的咖啡都无所谓，是一样的错误观念。对于项目经理而言，最坏的情况莫过于被 BUG 整得团团转，根本无法追求项目目标。如果你想要控制好项目的发展，最好是不要有任何 BUG，忽略了这个目标就等于是注定失败。

程序设计师应该把无错误编程当成一件重大的事情看待，一旦发现 BUG，就要立即处理：

• 培训程序设计师建立一个理念：BUG 是一件严重的事情，不可忽略也无法逃避，要尽早解决它。
• 谁的 BUG 谁负责。不要让其他人帮着散漫随便的人收拾残局。
• 修复 BUG 要趁早
• 最重要的一点，如果要求程序出现 BUG 时立刻修复，那么程序设计师的功力高下便可立见分晓。如果有人的进度一直落后，这等于是警告你——他需要加强训练了。

注：本书出版时间较早 (1994年)，在现在 (2024年) 看来，大家已经公认尽早修复 BUG 。

学习前人的经验

对于每一项系统化的方法都详细解释它的用意，你为什么这么规定，你期望组员做到什么。适当的时候，组员自然会明白并感激你的巧妙安排。不要把系统化的方法当作教条，应该向组员解释这些工作方式的内涵与用意。

提出详尽的问题

策略是非常重要的，因为它是许多经验和思维浓缩而成的。身为主管，你应该鼓励组员提出改进工作效能的建议。作者对于软件的第一优先考虑点是没有 BUG，为了鼓励程序设计师学到避免 BUG 的策略，每当设计师在追查错误原因时，作者都会问设计师以下两个问题：

1. 如何避免这个错误？
2. 更简单或自动地发现这个错误的方法是什么？

设计师经常思考这两个问题的答案，就能逐渐学会更高明的程序设计技巧。

提出详尽的问题，可以引导出真正有效的策略性工作方式，帮助项目目标顺利完成。比如提出一个问题：

如何持续按期交付？

有些主管问这个问题的后果是逼迫组员加班，或者贿赂组员加班。我们可以把问题问的更精确：

如何在不加班的前提下，持续按期交付？

于是主管不得不想法子加强效率，去寻找更有效的解决方案。为了不加班，也许得雇用更多的人手，这是解决方案之一，但公司绝对不会喜欢，干脆再把问题说得更精确些：

如何在不加班、也不增加人手的前提下，持续按期交付？

这可就真的迫使主管来点真正有创意的思考和认真检讨工作本身值得改进的地方了：

• 运用公司内别的小组已完成的程序代码
• 买一套完整的函数库
• 雇用一位短期的顾问
• 把产品中较无价值的功能特色从目标中删除

不要死守规则

当你提出并推动策略时，同时也要提醒开发团队，不见得要 100% 地遵循策略，最重要的是灵活运用。比如大部分情况下，使用 goto 都是不好的，但是在函数内部跳出错误处理时，使用 goto 可以让代码更清晰。我虽然反对 goto ，但更反对的是对规则盲从，产品才是最重要的。

策略性工作方式的主要缺点是规则太明确了，我们要明白这些规则是可以打破的，遵守策略，但不是死守策略，僵化地死守策略无异于做傻事。

反馈

项目经理总是要求他的组员写进度报告、开进度检讨会、再做后续报告，没完没了。这位主管是希望藉此获得项目进度的信息，很不幸，他的负反馈回路却阻碍了他真正需要的产出，他想了解组员对于如何解决问题的见解，可惜方法不对，他要求组员写报告，结果让组员心生反感，根本不想发表意见，他的制度使人噤声——讲得愈多，你必须写的报告就愈长，没有人想写报告，所以只好闭上嘴。这正所谓适得其反。

在微软曾经有几位主管， 每次一遇到项目进行不顺利，就把组员叫出来骂，说他们是最差劲的程序设计师，不配自称是微软的程序设计师，以及等等之类的无聊话。我不能确定这几位主管究竟用意何在，但是如果他们的目的是让组员工作更努力的话，那他们的方法可就大错特错了。我相信您完全可以想像，这种责骂只会激起组员心中的愤恨、羞恼和沮丧。更糟的是，就我所知这些项目的问题事实上都出在管理方面，目标不够明确或是野心太大，这些项目的程序设计师只是倒霉遇上了差劲的主管，其实他们的能力并不比公司内其他的程序设计师差，因此责骂他们只会让项目更糟，绝对没有改善的效果。

你必须小心注意，别设置了不当的负回路系统，例如以程序新增的行数、或新加入程序的数目来决定组员的奖金，把程序改好则不记入功劳，那么，程序员肯定只爱写拼拼凑凑的初稿，程序不求精巧，而且不愿认真改善现有的程序。您原本希望奖励的是生产效率，结果却造成公司里大而无当的拼凑程序到处泛滥。 我希望您能从以上的讨论中，体会到两点原则：

1. 当您设计一个新系统时，利用负反馈的观念来帮助项目进行顺利；
2. 要考虑这种反馈对员工的长期影响，确定不会造成不良的副作用。

越简单越好

策略应该简单明了，让人容易了解和遵循。

人都希望用简单的方式解决复杂又耗时的问题，因为人们常常被工作之外的程序性事情绊住。若是要求所有程序设计师针对他遇到的每一个 BUG 写一份报告，说明如何避免这个 BUG，事情立刻变成了大麻烦。如何避免错误的报告应该由主管汇总编写，组员只要口述检讨就好。我们的目的是整体生产力的提升，而不是去填满繁杂行政程序的各步骤。所以策略实施越简单越好。

要点

小小的改变可能产生惊人的效果，所以，请仔细观察您现有的工作方式，会很容易发生问题吗？耗费很多时间吗？矫枉过正或防弊重于兴利吗？会不会让人员心生挫败，而造成生产力低下？如果是的话，请找出一种简单又有效的方式改善这些情况。

当您决定采用任何一种策略性工作方式，请解释您的用意，让组员充分了解是什么方面应该改善。这种开放的做法会在无形中教育组员，让组员学会思考，也许，时间久了之后，他也能想出很不错的点子。

当您针对问题寻求解决方案时，一遍又一遍地修正您问自己的问题，培养自己能够提出精确的问题，想出更好的答案。但光是精确还不够，精确的问题也可能是错的问题，让您得到没有帮助的答案。您必须注意，问题是否切中要害，是否是您真正想达到的目的，是否是您的理想状况。不要自问： “如何让程序设计师加班？”要问： “如何增强工作效率？”

策略愈是吸引人，愈会有多人认同它，甚至把它当成牢不可破的定律。请提醒您的组员， 再好的策略也不能应付每一种情况，“避免用 goto”是公认的好的程序设计策略，它让程序可读性提高，但是当不用goto 的结果是可读性反而更低时，您得教程序设计师如何权衡取舍。

每当您建立一个反馈回路时，请务必考虑它的副作用和长期使用的效果。最好的反馈回路不但可以随着时间增强效益，也能同时减少负面的作用。

每一份打赏，都是对创作者劳动的肯定与回报。！