火坑项目救火方案总结
最近一个月，我一直在一个项目上“救火”。这个项目已经做了一年多了，一直没有交付，最近几个月更是不断地出现问题，导致客户经常给老板打电话……无奈之下，老板安排我放下部门的其它工作，亲自奔赴一线，带领研发团队完成交付。
到现场已经一个月了，这段时间整个团队基本上都是 200% 的工作强度，没有周六日，每晚最早 12 点下班，经常搞到两三点，早上则必须 9 点按时上班。虽然目前并没有真正地交付，不过经常这段时间的努力和团队的不断调整，能够感觉到这个项目正在逐步地好转。上周五，给客户演示的核心开发内容，也第一次没有被客户“批”回来。团队也逐渐地有了信心，但是真正的第一次完整交付，还需要等到 11 月 15 日，到时候才能知道我们的努力会不会有成果。
今天，趁着飞机上有一些时间，我决定整理一下对于“火坑项目”的救火方案。这样，形成经验与模式，方便后续的重用。
救火步骤
经过本项目，我整理出救火大概分为以下几个步骤：
- 救火准备与计划
- 紧急问题处理
- 系统问题处理
- 救火总结
救火准备与计划
真正抵达火坑项目一线之前，应该做一些简要的规划。我建议使用一个脑图，简要整理出这个项目的以下内容：
项目背景、救火任务目标、现场调研方向与实际问题、结果物梳理、具体工作任务安排。
这样，有的放矢，比到了项目上一头乱麻很太多了。
紧急问题处理
到了救火现场，其实第一要务应当是解决当下最紧急的问题。这些问题往往是客户想要“骂娘”的紧急问题。
这一点是我在这个项目上遗漏的地方。我到了现场之后，重心放在处理整体、全局问题上，而忽略了客户当下紧要却不重要的问题。导致客户又打了几次电话给老板……
系统问题处理
紧急问题处理完善之后。我们更需要系统性地解决整个项目组的问题。这才是问题的关键。
这个环节分几步：
- 系统、全面、客观地了解项目问题
- 有针对性地制定解决方案
- 全员宣贯
- 执行与监控
要真正的系统解决问题，往往需要全面、客观、细微地了解整个项目的所有问题。我认为这需要至少持续一周以上的沟通、一线工作。只是通过一天两天，和几个人简单地快速沟通，是不能看到很多真实的问题的。
其次，可以使用脑图的方式，制定出有优先级、有重要度、可落地的执行方案。并向全体团队成员宣贯、执行。
下面是我在这个项目上的问题梳理与方案建设，由于涉及到具体项目及具体人员，一些信息不便展开，大概看一下结构就可以了。
救火总结
对于出了比较多问题的火坑项目，救火完成后，我们应该对这个项目的问题、方案、后续计划进行总结。并需要总结出后续项目需要注意的关键关注点。
先总结到这里，希望这个项目能如期按质按量上线。
