在最好的情况下，管理软件项目也非常困难。不幸的是，许多新项目经理本质上没有接受任何就业培训。项目经理有20个成功的管理经验供参考。1. 定义项目成功标准 在项目开始时，确保风险承担者对如何判断项目是否成功有统一的了解。通常，满足预定义的进度安排是唯一明显的成功因素，但必须有其他因素，如增加市场份额、获得指定销售或销售、获得特定用户满意度、淘汰高维护需求的剩余系统、获得特定的交易处理量和确保正确性。2. 识别项目的驱动力、约束力和自由度 每个项目都需要平衡其功能、人员、预算、进度和质量目标。我们要么将上述五个项目的每个方面定义为一个约束，你必须在这个约束中操作，要么定义为与项目成功相对应的驱动程度，要么定义为成功的自由程度，你可以在规定的范围内进行调整。详情请参考我的软件工程文化（Creating a Software Engineering Culture）（Dorset House, 1996)第二章。3. 定义产品发布标准 在项目早期，决定确定产品是否准备好发布。您可以基于发布标准：有多少高优先级缺陷、性能测量、特定功能完全可操作，或其他方面表明项目已经达到了其目的。无论您选择什么标准，它都应该是可实现的、可测量的、文档的，并与您的客户所指的质量一致。4. 沟通承诺 虽然有承诺不可能事件的压力，但你永远不会做出你知道你不能保证的承诺。在与客户和管理者沟通时，你应该有良好的声誉。您以前的任何项目数据都将帮助您提供令人信服的论点，尽管它对不合理的人没有真正的防御效果。5. 写一个计划 有些人认为最好花时间写代码，但我不这么认为。困难的部分不是写计划。困难的部分是制定这个计划--思考、沟通、权衡、沟通、提问和倾听。分析和解决问题需要时间，这将减少项目未来带来的事故。6. 将任务分解成英寸大小的小圆石 英寸大小的小圆石是缩小的里程碑。将大任务分解成多个小任务，帮助您更准确地估计它们，暴露您在其他情况下可能没有想到的工作活动，并确保更准确、更详细的状态跟踪。 7. 如果您的团队经常承担特定的一般任务，如果实现一个新的对象类，您需要为这些任务开发一个活动检查列表和计划工作列表。每个检查列表应包括这个大任务可能需要的所有步骤。这些检查列表和工作列表将帮助团队成员确定和评估与他/她必须处理的每个大任务相关的工作量。8. 在计划中，质量控制活动后应修改 几乎所有的质量控制活动，如测试和技术评估，都会发现缺陷或其他改进的可能性。您的项目进度或工作细分结构应将每个质量控制活动后的修改作为单独的任务包括在内。如果你真的不需要做任何修改，那就太好了，你已经在这个任务的计划之前了。但不要指望它。9. 为过程改进安排时间 你的团队成员已经淹没在他们目前的项目中，但是如果你想把你的团队提升到更高的软件工程能力水平，你必须在过程改进上投入一些时间。从你的项目进度中留出一些时间，因为软件项目活动应该包括一个过程改进，可以帮助你在下一个项目中取得更成功。不要把你的项目成员可以利用的时间花在项目任务上100%，然后惊讶于为什么他们在积极改进上没有进展。 10. 管理项目的风险 如果你不识别和控制风险，他们会控制你。在项目计划中，花一些时间讨论可能的风险因素，评估它们的潜在危害，并决定如何减少或预防它们。想要一个软件 风险管理的简要的指南，参见我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。 11. 根据工作计划而不是日历来作估计 人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划（以人时为单位）的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。 12. 不要为人员安排超过他们80％的时间 跟踪你的组员每周实际花费在项目指定工作的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。 13. 将培训时间放到计划中 确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。 14. 记录你的估算和你是如何达到估算的 当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。 15. 记录估算并且使用估算工具 有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即产品大小，小组大小和进度安排组合起来没有已知项目成功的情况。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一试的好工具。 16. 遵守学习曲线 如果你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。 17. 考虑意外缓冲 事情不会象你项目计划的一样准确的进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为填料，而不是明智的承认事实确实如此。指明一些以前项目不愉快的意外，来说明你的深谋远虑。 18. 记录实际情况与估算情况 如果你不记录花费在每项任务上的实际工作时间，并和你的估算作比较，你将永远不能提高你的估算能力。你的估算将永远是猜测。 19. 只有当任务100%完成时，才认为该任务完成 使用英寸大小的小圆石的一个好处是，你可以区分每个小任务要么完成了，要么没有完成，这比估计一个大任务在某个时候完成了多少百分比要实在的多。不要让人们只入不舍他们任务的完成状态；使用明确的标准来判断一个步骤是否真正的完成了。 20. 公开、公正地跟踪项目状态 创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。 这些提示不能保证你的成功，但是它们将帮助你在你的项目上获得一个坚实的把手，并且保证你做了所有你可以做的事来让项目在这个疯狂的世界上成功。