【年终回顾】公司的版本是给别人看的

客户收到邮件后打来电话

客户收到邮件后打来电话，语气很冲，问我们到底还能不能做。我向客户保证会每天同步一次进度，直到项目上线。每天晚上九点给客户发进度报告，我坚持了四十三天。项目延期后，负责人让我做了一份风险评估报告。写风险评估报告时我才看清，有些风险早在立项时就该被注意到。立项时大家都太乐观了，排期压得太紧，没留任何缓冲。救火队员是我在公司的另一个外号，哪里出问题就被调去哪里。被调去救火的项目，往往已经乱成了一锅粥。

失去那个客户，公司损失了将近八十万的年收入

失去那个客户，公司损失了将近八十万的年收入。每两周一次的里程碑检查，让很多问题能更早暴露出来。救火的经验多了，我开始能预判哪些项目会出问题。预判的依据通常是需求变更的频率和团队成员的状态。需求一周变三次的项目，基本上都会延期。我在项目周会上提出了预警，可惜没人当回事。一个月后那个项目果然延期了，负责人才想起我当时的提醒。被事后认可的感觉并不好，我宁愿当时就有人听进去。

为了赶进度，我们组连续三个周末都在公司加班

为了赶进度，我们组连续三个周末都在公司加班。第三个周末加班时，有个同事带着两岁的女儿来了公司。小姑娘在会议室里画画，我们在旁边改代码，画面有点心酸。救火最惨的一次，是上线前一晚发现数据库迁移脚本有问题。上线前那一晚，我们从八点修到凌晨四点，泡面吃了两轮。凌晨四点的写字楼，只有我们这一层还亮着灯。天快亮的时候问题终于解决了，大家累得连说话的力气都没有。我写了一封延期说明邮件，改了十几遍，生怕措辞不当。

有一次需求文档写得模糊，开发理解错了

有一次需求文档写得模糊，开发理解错了，白白做了两周。那两周的工作全部推翻重来，项目又延期了半个月。项目救火时，我学会了用最简单的方式解决问题，不追求完美。先上线一个能用的版本，再慢慢优化，这是我们当时的策略。能用的版本上线后，客户虽然不太满意，但至少没有投诉。后续优化又花了一个月，客户最后还是给了我们好评。项目延期最怕的是一延再延，每次都说下周就好。有个项目连续延期了五次，客户最后直接终止了合作。