定义有麻烦的项目
首先，我们来定义一下什么叫有麻烦的项目，它们一般具有以下特征：
1、项目表面上已经进入后期，但是没有人能说出项目结束时间。
2、产品漏洞百出。
3、管理层已经无法控制进度，制定的进度计划没有半点准确性。
4、开发人员日夜加班，效率低下。
5、项目小组的 士气极度低落，失去了工作的激情。
像这样有麻烦的项目在行业内普遍存在，如果不采取一些措施来修复的话，项目注定会失败，什么是失败？失败项目的成本、工期远远超过估算，甚至项目被取消。作为项目经理，项目的负责人，我们有什么方法可以把这些有麻烦的项目拉向正轨呢？本人前一段时间亲身经历过一个像这样的有麻烦的项目，读过《快速软件开发》一书后，其中的“项目修复”一节使我受益非浅，运用上面讲的一些方法后成功的把项目拉向了正轨，本文在参考《快速软件开发》一书的基础上介绍一些实用的项目修复方案。
修复项目
修复项目有三个最基本指导思想：
1、筛选需求，缩减项目规模。
2、注重短期的过程改善。
3、面对现实，放弃原计划，着手制定新的计划。
对于一个有麻烦 项目，很多人都还把注意力放在如何赶上原计划上，这样的项目，最重要的是怎么完成，完成！不要再幻想出现什么转机，项目已经有了麻烦，和原计划已经有了出入，所以，我们应该面对现实，把当前的事情做好。
如果你想改变项目的现状的话，动作一定要大一点，小打小闹的改变不足以改变现状，小打小闹在公司高层眼里意味着什么？意味着你并没有什么办法来修复项目。
下面详细说明修复项目的措施：
第一步要做的
1、分析自已的处境
评估一下项目的最后期限到底有多重要，或许项目本身就不存在硬性的完成期限，这样的话，你就不必担心项目修复是否成功了。还有，有这个时候，公司上层或者是客户为了避免项目严重延期，会和你商讨一些功能上的取舍。
2、客观分析
为了在现有的基础上成功，项目组需要做什么？公司上层需要做什么？客户需要做什么？过去的都已经过去了，关键要着眼于现在。
3、自已要做好项目修复的准备
如果你的项目处于修复状态下，而且落后的不是一点半点。那么你要意识到你的项目已经支离破碎了，必须有一些大的举动来挽救，让所有人都知道要对项目采取一些措施来修复。
4、争取多方意见
询问一下你的开发组、你的其它同事、你的领导等所有了解项目的人，有什么方法可以使项目走向正轨。
5、面对现实
有麻烦的项目组需要一个客观的、现实的项目经理。项目修复刚开始，你不要再向任何人承诺项目的完成日期，不要再陷入：“迫于压力的承诺－>更大的进度压力->更多的错误->更加偏离计划”这样的死循环。你应该用几天的时间去认真分析一下项目，再给出一个客观、准确的计划。
影响项目成本、进度的四大因素：人员、过程、产品（功能集）、技术。在项目后期，在技术这一因素上已经没有多大的改进余地。我们在此讨论针对其它三个因素的改进措施。
人员
人员是影响项目进度最重要的因素，我们应该在这个因素上下最大的功夫。
1、采取一切措施来恢复开发人员的士气
兵战者，求胜于势，恢复开发人员士气对于项目修复的成败起着决定性的作用。恢复开发人员士气的最佳方式是做一件很明显的事情让他们知道公司已经把他们放在了首位，比如说，完成任务可以提前回家，在不影响进度的前提下允许他们请假等等，当开发人员意识到自已受到了重视，项目组士气自然会得到提升，提升士气的方法很多，可以根据实际情况来选择恢复士气的方法，其实有时候领导的一句话就足以恢复整个项目组的士气。
2、消除重大的人员问题
如果你觉得项目有一位有问题（不合作，难以沟通等）的员工，那么就请勇敢的面对这个现实。即使他现在起着关键性的作用，也要毫不犹豫的撤掉他，这些的员工对项目组士气的影响要大于他在技术上的贡献。
3、增加新成员要谨慎
虽然有一句话叫作：“向一个已经延误工期的项目上增加新成员无异于火上浇油”。但是如果能把项目组的任务分解到新成员并不影响原有开发人员的话，就不存在“浇油”的问题。不过你要考虑到新成员很可能用8小时的时间去完成原有开发人员用1小时所能完成的任务，这样的情况出现后，你是否能维持与管理层的关系，因为管理层极可能不会容忍一个人用8小时的时间去完成1小时的工作。如果你无法妥善处理这样的后果的话，那么就不要增加新的人员。
4、充分利用开发人员的时间
在项目修复模式下，你要尽可能的充分利用现在开发人员的时间，因为他们已经对这个项目非常熟悉。打算增加新开员的成本，还不如用在提高现有开发人员的效率上。
5、观察开发人员的节奏
千万不要让开发人员陷入“进度压力—更多的缺陷－更多的工作量－更大的进度压力”这样的循环里面，给他们足够的时间，让他们能考虑一下质量问题，这样的话进度就自然而然的加快。
过程
虽然是人员是影响项目进度的最为重要的因素，但是如果想成功修复项目的话，用心整理一下过程也是必需的。
1、修复支离破碎的过程
项目一遇到麻烦，大家通常都知道是开发过程哪一个环节出现了问题，其实，出问题的环节一定是忽略了软件开发最基本的东西。
如果缺陷管理困难，就搭建一个缺陷管理系统；如果开发人员得不到及时的任务分配，那么就放更多的精力于各开发人员的任务完成状态上，可能你做更多的工作以保证任务的及时分配；如果开发人员的代码质量总是难以保证，那么就加入代码审核过程。
2、创建详细的小型里程碑
在项目修复模式下，一定要建立一个项目跟踪机制，以便于实时了解项目的状态。
小型里程碑可以让你每天都能看到项目进度是否在按着计划进行。小型里程碑有三个特点：1)小型性2)二元性3)彻底性。小型性指每个里程碑必须在一两天之内可以完成；二元性是指里程碑要么就完成，要么就没有完成，不存在“差不多完成”、“完成了90%”之类的情况；彻底性是指当你完成了最后一个里程碑时，项目也就完成了，不存在你所建立的进度表之外任务，如果还有其它任务，那么就把它加进来。
创建一些没有太大意义的小型里程碑有助于提高项目组的士气，人都是这样，快速完成一个任务心里总会感到愉快，即使这个任务不是那么重要。
在项目初期是不适使创建小型里程碑的，因为那个时候你对所要做的工作了解的详细程序还不够。但是项目修复模式下，每个人都清楚的知道项目还剩下些什么。
3、依据里程碑的完成来安排进度
为每一个里程碑设立完成日期。不要再打加班的主意，完成日期必须是在没有考虑加班的情况下设立的。每一天任务的完成保证了，才有每一个月的保证，最后也会保证项目的成功。
4、细致的跟踪项目进展情况
创建了小型里程碑，但如果不跟踪实际进度的话，就没有一点儿实际意义。每天都要检查里程碑的完成情况，一定要确保标记为“已完成”的里程碑是百分百完成了，如果把“99%完成”的里程碑标记为已完成，就会打乱你的计划，你所能对项目控制的程度也会越来越弱。
绝对不能让开发人员在小型里程碑进度上偏离正轨，如果误了里程碑，并不加以改正，项目很容易偏离正轨。晚了1天的任务有可能会晚2天，晚2天就会晚3天，接下来项目实际进度就和计划完成脱节了。如果一个开发人员在里程碑上落后了，就让他当天加一下班，以赶上进度。如果是计划制定的有问题，那就要及时的修正它。
5、记录延误里程碑的原因
如果一个里程碑延误了，一定要延误原因记下来，这样可以帮你发现潜在的问题。
6、短期后修正
每1、2周都要对计划的里程碑进行修正，如果完成开发人员用5天的时间完成了3天的任务，而且没有可以改进方法的话，那么就把剩下的工作量乘以5/3，千万不要幻想着你能在以后的时间里把以前落下的任务补回来。
7、在得出有意义的进度前不要固守着某一个
在计划/进度表没有达到非常准确的情况下，不要急着把它交给领导过目，一个良好的进度/计划肯定是在从制定到跟踪，从跟踪到修正，再跟踪、再修正这样的循环中得出的。
8、勤快的进行风险管理
产品（功能集）
产品的功能没有管理好，那么项目修复就是不可能的
1、稳定需求
在项目修复模式下，首先稳定需求是最为重要的任务，如果在这个时候需求还是频繁化的话，那么你就不用考虑其它修复手段了，花时间去稳定它。很多项目都是在后期还不确定究竟要完成哪些功能，这样的项目注定是要失败的。
2、修正功能集
毫不犹豫的把那些优先级较低的功能、特性剔除掉，一定要根据优先级来完成任务。
3、去除没有用的垃圾
如果一个模块质量极其低下，改了又改，bug还是不断涌现，那么就从把这个模块的代码去除掉，重新设计它，不要让一堆无法控制的缺陷把项目拖死。
4、持续降低缺陷数目
功能、特性可以权衡，质量是不可以权衡的，项目管理三角形：成本、进度、功能。三角形里并没有质量这一角，不要为了追赶进度而在质量上做手脚。
参考书目：
《快速软件开发－有效控制与完成进度计划》 电子工业出版社