这是一本老书，作者 Steve Maguire 在微软工作期间写了这本书，英文版于 1994 年发布。我们看到的标题是中译版名字，英文版的名字是《Debugging the Development Process》，这本书详细阐述了软件开发过程中的常见问题及其解决方案，强调团队合作、项目管理和开发流程的优化。该书成为软件开发和项目管理领域的经典著作，受到了广泛的认可和赞誉。
不记录，等于没读。
项目可能会以多种微妙的方式偏离轨道，因此负责人绝不能假设项目会在正轨上自行运行。为了使项目顺利进行，负责人必须时刻监控项目，未雨绸缪，解决尚未扩大的问题。为了使项目按计划进行，负责人每天都应该问自己这个问题：“有什么事情是我今天能做，并且可以帮助项目在未来几个月内顺利进行的？”通过每天提出这个问题并认真寻找答案，负责人可以预见到各种可能会使项目措手不及的问题。为了防止浪费精力，负责人应评估每一个请求，以确定真正的问题或目标，并确保每一项任务都能实现项目的目标和优先事项。有些任务，例如满足市场团队的要求以完善功能集，或者实现一个程序员设计中意外出现的“零成本”功能，可能完全不具有战略意义。一个好的负责人懂得说“不”。
注：所谓的“零成本”功能，是指在开发过程中无需额外努力便可以添加的功能。
项目就像是一枚瞄准月球的火箭，只要有一点点不够精确，到时候就无法命中目标。差之毫厘，失之千里。所以，绝对不要让项目有一点点脱轨，不论是多么小的偏差，倘若你没有立即修正错误，它很快就会越跑越远。聪明的主管懂得这个道理，他们会经常注意项目的进度，随时修正方向，保持项目不偏离计划之外。本章介绍帮助项目保持进度的策略。
主动出击
如果没有未雨绸缪，只是坐等问题发生，就是被动式行动：一个月之前没有花30分钟思考这个问题，现在得浪费几个小时或几天的时间去修正。主管不愿意认真地“向前看”，因为不看似乎比较轻松。你得驱逐这种被动式的想法，要积极防范意外才行。 有很多方法和技巧可以训练自己“向前看”但总结起来不过是一句简单的要诀：定期暂停手边的工作，然后往前思考，随时做必要的修正，以避免未来的大障碍。
作者有一个10年以上的习惯：每天花10到15分钟思考下面的问题，并且列出答案：有什么事情是我今天能做，并且可以帮助项目在未来几个月内顺利进行的？
请不要把这个问题的答案想得太复杂，事实上，答案应该简单到能在几分钟之内写完：
- 订购 MIPS 和 Alpha 处理器的技术手册，以便 Hubie 需要时，随时可得。
- 发个 e-mail 给 Word 的工作部门，提醒他们如果有 任何功能要加在这次的新版里，请在下周一前提出需求。
- 发个 e-mail 给负责 Graphics 的各位经理，我们需 要的函数库预计在 3 个星期后用到，确认他们届时可以交货，没有问题
错误的根源
用看程序的方式找错，是既懒惰又效率低的方法，因为很多程序看起来都完美无瑕，但都有微妙的错误。最快又方便的方法是使用在线调试，观察各变量在程序执行过程中的变化。
Word 小组使用了另外一个小组开发的函数库。word 小组在使用中发现函数库执行速度非常慢，不符合他们的质量指标，两个小组甚至闹起了矛盾。作者进行了测试，发现第一次执行，等待时间很长，但第二次执行，速度就非常快。Word 小组长也解释他们也知道第二次速度快，但他们要保证每次都快才行，并且只要停一段时间，那些函数库的执行又会变慢。作者看了原始代码，发现问题是出现在 Word 优化上。原来 Word 为了节省内存，只要某段程序一段时间没有使用，就会把它从内存中删除，再次执行该段程序时，需要从硬盘加载，这是 Word 程序慢的原因。
Word 小组对速度抱怨了几个月，但却没有找到问题的根本原因，也没有仔细测试。开发函数库的小组也没有对自己的程序做测试，因此当 Word 小组提出质疑时，他们没有对自己的程序质量建立信心，而是对自己的函数库做优化。
身为主管，必须随时睁大眼睛，看看是不是有悬而未决的问题，一定要有一个人（或是主管自己）来负责研究到底哪里出错，也许这种研究既花时间又无聊，但总比灾难发生之后再来花几个星期收拾残局要好得多：不要在错误的问题上浪费时间，要先确定真正的问题在哪里，然后再去改正它。
注：这里提到的排错方法并不全面，实际上，排查遵循四个步骤：
- 重现 BUG
- 观察现象
- 提出假设
- 验证假设
本段内容主要强调了以上四个步骤中的“观察现象”，在观察现象时，需要遵守一个基本原则：不要想，而要看。意思是不要猜测错误的原因可能是什么，而是运用一切手段 (示波器、调试器等) 去观察错误的现象，将问题的可能性缩小到几种可能范围内。
关于排错的方法论，如果有兴趣，可以参考我的这篇博文《随想005：调试的思考》。
明确需求
大部分的小组在提出需求时， 都不解释原因。人们开口要求的东西未必是他真正想要的。 处理他的要求之前，请务必确定他究竟想要做什么。如果您能够先明确定义自己的需求，再向别人提出， 这是个避免在沟通上发生误会的好方法。
旅馆餐厅，有人想吃午餐，但走进餐厅看到大家都在早餐，于是问服务员早餐时间几点结束，得到答复后就走了。实际上他是可以点午餐的食物的，虽然他的目的是想吃到午餐，但问出的却是早餐什么时候结束这种问题，他应该问“现在供应午餐吗？”
作者想知道几点可以吃到晚餐，却问自己的太太“什么时候看完足球赛回来？”，什么时候回来跟什么时候吃到晚饭是没有必然关系的，但是人们就是有这种倾向：问错误的问题。
如果有人向你请求某个事情，但是从他的请求中无法看出他的目的，你可以反问他，在还没弄清楚他究竟想要做什么之前，不要贸然答应他，宁可拒绝他的要求也不要浪费这种时间。
人们开口要求的东西未必是他真正想要的。处理他的要求之前，请务必确定他究竟想要做什么。同理，如果你能很清楚告诉别人，想要的究竟是什么，这样别人才能给你真正需要的帮助。
说“不”
程序员有巴甫洛夫反应：向他们提出一个问题，他们就会开始尝试解决它。
——从第二张幻灯片开始演示
勉强接下自己不可能完成的任务，实在是以长痛代替短痛的做法，而且长痛的是整个团队。此外，到时候无法如期完成，还会害得需求小组因此而做了错误的日程安排。所以，最好的方法还是拒绝，或者双方商量一个折中的日程或工作内容。
要协调原本就对立的双方，有一个要诀，就是寻求真正的解决之道。如果你对需求小组说“不”是因为你很确定你的小组人员实在无法在他们的期限之内完成所要求 的，你务必得协助他们寻求真正的解决之道。
绝不要答应别人自己做不到的事情，这样对双方都有益无害。
你无法让每个人都满意。如果你希望每个人都满意，最后你就会焦头烂额，什么事都做不成。
作为主管，在做任何决策的时候应该以项目目标为最大考虑，不要企图讨好别人，尤其不要盲从上级提出的建议。这并不是主张反抗权威，而是考虑到上级可能不了解你的目标、决策优先级以及要面对的技术挑战。如果上级要求你做一件事情，而你认为不妥，那你需要和上级说明为什么你会认为不妥的理由。
作者有次负责摩托罗拉 680x0 处理器的 C/C++ 编译器。作者的顶头上司莫特在询问项目进展时，都会问一下“FORTRAN 进行得怎么样了？”
只要实现了 C/C++ 编译器后端功能，就可以很轻易地做出 680x0 处理器的 FORTRAN 编译器。
但是项目的目标是实现 C/C++ 编译器，而不是 FORTRAN 编译器，莫特之所以关注 FORTRAN 编译器，是以为他自己喜欢 FORTRAN 语言，认为做出来 FORTRAN 编译器会很有销路。
每次莫特提起 FORTRAN 编译器时，作者都会回复：“我们还没开始。主要是因为 FORTRAN 编译器的关键组件—后端处理，尚未完成的缘故。”
莫特忽略了项目的最高优先级是实现 C/C++ 编译器，因为 C/C++ 编译器的市场潜力比 FORTRAN 编译器更好。莫特的个人兴趣已经蒙蔽了他身为主管的职能。
作者没有服从上级的意思，因为他学会了独立判断，不论是谁的建议或要求，都会问自己：这样做对产品有没有帮助？对目标的完成有没有策略上的价值？这样做是否忽略了更重要的事情？成本和风险会不会太高？ 你必须仔细思考这些问题，如果对项目无益，就不该照做。
销售人员提出的需求要仔细甄别，有些需求会对产品有害，要毫不犹豫地拒绝。如果需求可以大幅提高销售额并且不会对产品造成不利，那么就要实施这个需求。比如文件模板，23 个文件模板就比只有 1 个模板更能激发用户的购买欲。销售人员和开发人员一样渴望有最好的产品，这样他们才能更好地推销产品，但是销售人员并不那么清楚怎么做才是对产品最有利，因此需要你进行辨别。
比如销售人员会关注对手的产品特色，会要求开发人员将所有项目都做全。这个时候你应该小心，要从中选出开发策略上有重要性的功能，而不是把媒体的评比项目都做全。记住：不值得开发的功能就不要做。
很酷，但并不重要
- 界面库函数需要增加一个功能，原因是组长觉得这个功能很有挑战、能磨炼写程序的技巧，功能也很酷。
- Excel 剪贴板的实现方式非标准，但对用户而言是无感的。如果将程序修改为标准化，则用户需要更改一些宏。这时 Excel 项目经理不应该更改剪贴板的实现方式，因为并非非改不可。
- 让组员停下手头工作，去修改函数的风格和命名原则并不好。应该在用到这个函数时顺手修改，而不是停下手头工作，这些改变对改善产品质量并不是立竿见影的。
- 用 C++ 重写 C 程序，因为 C++ 是更新的技术，这是不正确的。可以在新项目中使用 C++。
这带给我们的教训是：
- 软件产品的开发，不能只为了有趣、挑战性，或是够有个性够令人眩目。
- 不要把时间浪费在无法改善产品的工作上，即使这么做在将来会有潜在的利益，也要与现在投入的时间成本做个衡量。
你应该专注于什么样的工作：与项目目标一致的策略性工作。尽量撇开“免费”的附送软件（如果某个功能不能产生效益，就无需费时费力做），克制大家追求“酷”的欲望，尽量减少对产品没有改善效果的工作。如果你无法学会说“不”，或无法了解别人真正需要的是什么，就会发现自己深陷泥沼，净做不该做的事情。
要点
不要让意外出现的问题打乱项目的脚步，如果你要项目顺利进行，你就得花点时间思考未来。今天做些小的改变，在未来可以防范许多意想不到的问题，即使真发生了无法避免的灾难，你也能在风雨中稳稳掌舵。如果你随时自问：“有什么事情是我今天能做，而且可以帮助项目在未来几个月内顺利进行？”你就会知道该采取什么行动。
在准备解决一个问题之前，你要先确定找到了问题的症结。还记得 Word 小组抱怨函数库速度慢的问题吗？Word 小组自己的问题，误导了函数库小组努力设法优化，最后却徒劳无功。因此，在你企图解决任何问题之前，请务必确定已经对问题有了彻底的了解。
在投入大量时间于任何一件工作之前，请想一想这件工作是否能满足真正的需求。还记得那怪异的下拉列表框需求吗，其实是分层菜单。当你收到任何一项需求时，最好了解一下背后的原因，提出这项需求的人究竟想要做什么。这样可以节省很多宝贵的时间。
基于非常多的原因，有些主管很难对不合理的需求说“不”。有些严重情况下，主管会答应对方自己根本做不到的承诺。如果你发现自己常常不好意思说不，请站在对方的角度想一想，如果不能按期交付，是不是会造成更严重的后果？如果你是需求小组，该到货的东西迟迟不见，你是不是又急又怒？你必须对其它小组负责，就像你希望他们也对你的需求负责一样。
每当你收到一个需求，要你在产品中加入某一项特色功能时，请先想一想这项工作在策略上重不重要。如果不重要，就不要开发它。至于这个功能是否免费、是否很酷、竞争对手有没有，都不是重点。尤其要警惕那些用来完善一整套功能的需求，它们看起来很重要，因为它能给你一种没有它就不够完整的感觉。你必须牢记，产品的策略性比完整性重要。如果你不敢确定这项功能是否具有策略上的重要性，只要想一想这个需求的动机，就可明白大半了。
每一份打赏，都是对创作者劳动的肯定与回报。！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
