这是一本老书，作者 Steve Maguire 在微软工作期间写了这本书，英文版于 1994 年发布。我们看到的标题是中译版名字，英文版的名字是《Debugging the Development Process》，这本书详细阐述了软件开发过程中的常见问题及其解决方案，强调团队合作、项目管理和开发流程的优化。该书成为软件开发和项目管理领域的经典著作，受到了广泛的认可和赞誉。
不记录，等于没读。
在大多数公司中，开发团队需要保持一个进度表，以便公司其他部门能够协调他们的工作。至少营销团队需要了解他们应该在什么时候开始推广产品。尽管进度表对于协调各产品团队的工作非常重要，但如果制定和使用进度表缺乏合理性，它们可能对开发产生毁灭性的影响。一个不切实际的进度表可能会打击团队士气，并最终导致生产力下降。一个仅仅过于激进的进度表可能会导致“进度狂”，即程序员为了短期内满足进度而采取捷径，从而危及产品的长期质量。进度计划应该设定在既具挑战性又切实可行的范围内，以保持项目的快速推进，但如果过于激进，程序员可能会做出愚蠢的决策，比如牺牲充分测试时间以迎合进度要求。通过使用“里程碑进度计划”，领导者不仅可以更好地与其他团队协调，还可以使项目更加激动人心，并促进创造性的工作，使团队以惊人的速度产出高质量的代码。
微软在开发 Excel 时以进度为最高优先级，每个人都在疯狂地赶进度。他们被迫忽略 BUG，直到所有功能都实现后再集中处理 BUG。 开发人员承受了很大的进度压力，为了进度不得不放弃产品质量。在当时并没有发现明显的问题，直到几年后，微软才尝到过度重视进度的可怕后果。
- 伤害士气：每时每刻都在收到进度落后的信息和压力，进度实在是太被过分强调了，以至于我们做了多少了不起的事情，都没有半点成就感。我们被那种落后的威胁淹没了，再怎么努力，也看不到工作有任何进展。这不是工作本身的问题，实在是那种绝望的无力感所致。我们用尽全力，我们仍然不断地落后，而且从来没办法把进度补回来。事实上，进度表定的太不实际了。
- 牺牲质量：进度表太不实际，不太可能完成，组员为了赶进度就开始牺牲质量。时间实在太少，程序就只好不测了，只要编译通过，第一次执行没有错误，就算完成了，然后继续赶下一个功能。
没有人相信日程表可以把所有的事情都算到、算准，但是就有人（尤其是高层管理者）要把“预估的完成日期”当成“一定要完成的日期”。
日程表必须有点激进，让程序设计师有一种紧迫感，迫使他们把注意力集中在最重要的事情上。但如果日程是如登天般不可能完成的任务，那就只会打击组员的士气。
在项目刚开始的时候有一些基础工作不能忽略：设定明确的目标和优先级，预先思考设计上和开发上的问题并设法预防，建立测试计划，设定质量指标，这些工作在日后可以节省很多时间。
将大的计划划分为具有阶段性产出的小项目，每次完成一个阶段，都会鼓舞组内成员。开发 Excel 时，进度表规划了 2 年的功能，成功也是在 2 年后检验。对于完成日期在两年之后的项目，你会有时间紧迫的感觉吗？老实说，没有，直到期限将至的几个月前， 你才开始觉得火烧眉毛。
注：在作者写这本书的时候(1994年)，软件开发流程“瀑布模式”，会事先规划好所有一切。从 2000 年开始，人们就意识到在这种方法不合理，因此提出了迭代、增量、敏捷模式，推崇先实现最有价值的功能，每次实现一个功能并立即将它们集成到系统。
人们常常忘记一点：日程表上的完成期限是推估出来的，这个期限未必最符合成本效益，事实上也未必合理， 因为工作项目都是估计出来的，不能代表实质的工作项目。因此日程表上的完成期限并不是真正的完成日期。大部分的上级主管都不会乐意听到这些，但这却是千真万确的事实。使用阶段性的小项目可以让事实更接近理想，但也不是完美的做法。
身为主管，你一定要时常提醒组员：产品的质量远比遵守期限重要。请牢记本章所提供的经验教训：
最会误导项目发展、伤害产品质量的事情就是过分重视进度，这不仅打击人员士气，还会迫使组员做愚蠢的决策。
要点
如果项目进度表不切实际，并导致团队成员牺牲质量以便赶上无理的截止日期，则该进度表可能对项目产生破坏性影响。如果你创建了一个难以实现的进度表，只是为了从团队成员身上获得尽可能多的加班时间，那么这将打击团队的士气。一旦团队成员感到自己处于绝境，他们永远无法进入最佳状态。等到项目结束（可能会快些），他们就会另谋高就。
将项目分割成数个小项目，有各自的阶段性目标，这种做法可以让团队成员更加投入，并营造出“赢”的气氛，让团队成员感受到项目进展的鼓舞。理想的小项目期限大约是两个月，给组员适当的急迫感，促使他们积极地工作，特别是当小项目有个明显又令人振奋的主题时。试着把小项目设计的令人兴奋又期待，使小组在完成后有种自豪的成就感。随着一个又一个的小项目完成，小组会有越来越强的信念，相信自己的工作是非常重要的。
注：现代的项目管理推荐更短的进度安排，团队只安排最初1~2 周的工作。因为无法预测到几周之后的状况，因此只能安排这么多。这没关系，可以使用波浪式的规划方式，以迭代方式产生日程安排。项目经理无需人们提供太多没有事实依据、凭空想象的细节。
每一份打赏，都是对创作者劳动的肯定与回报。！
