第1章项目失控的早期信号

1、项目失控的早期信号：进度偏差、需求蔓延、技术瓶颈、团队士气低落

做嵌入式项目这么多年，我见过太多项目从「还行」到「完蛋」的转变。说实话，没有哪个项目是突然崩掉的。它一定会有信号，只是我们没看见，或者看见了没当回事。

今天咱们就聊聊这四个最典型的早期信号。你如果能提前识别它们，至少能救回一半的项目。

进度偏差，说白了就是「计划赶不上变化」。但很多项目经理喜欢用百分比糊弄自己——「我们完成了80%」，结果最后20%花了双倍时间。

我个人习惯是：每周五下午花15分钟，把实际进度和计划进度摆在一起看。偏差超过10%，就得拉警报了。

进度偏差的典型表现：

我在一个车载项目里遇到过这种情况。当时Bootloader开发预估4周，结果第3周时发现Flash驱动有bug，需要重写。团队没人吭声，直到第5周才说「搞不定」。嗯，那一次我们整整延期了2个月。

我的建议：别只看「完成百分比」，要看「剩余工作量」。用燃尽图（Burndown Chart）替代百分比汇报，数据不会骗人。

需求蔓延，你想想看，是不是每个项目都逃不过？客户说「加个小功能」，产品经理说「这个很简单」，然后开发人员默默加班。

嵌入式项目尤其危险。因为硬件已经定死了，加功能可能意味着Flash不够、RAM溢出、中断优先级冲突。我曾经接手过一个智能家居项目，原本只需要控制3路灯光，结果客户一路加到12路，最后MCU引脚不够用，只能换芯片——整个硬件方案重来。

警惕这些信号：

怎么防？我的做法是：任何新增需求，必须附带「影响评估」——包括开发工时、测试工时、硬件资源消耗。没有评估的需求，一律不接。

技术瓶颈是嵌入式项目最头疼的问题。因为它不像进度偏差那样可以追回来，也不像需求蔓延那样可以砍掉。它就在那里，你绕不过去。

常见的信号有：

我记得有个工业控制项目，需要在1ms内完成PID计算和通信。我们用了DMA、用了中断优先级优化，还是差那么一点。团队连续加班两周，人都快崩溃了。最后我发现——是编译器优化等级没开。开了-O2之后，问题直接解决。

技术瓶颈的应对思路：

这个信号，说实话，比前面三个都致命。因为进度可以追，需求可以砍，技术可以学，但人心散了，项目就真没救了。

士气低落的早期表现：

我曾经带过一个团队，项目延期3个月，大家每天加班到10点。有一天我发现，最积极的那个工程师开始准时下班了。我找他聊，他说：「反正也做不完，何必呢？」那一刻我才意识到，士气已经崩了。

我的经验：士气问题不能靠「画饼」解决。我后来做了三件事：第一，砍掉30%的非核心需求，让大家看到进度在往前推；第二，每周五下午不加班，大家一起复盘+吃下午茶；第三，公开表扬每一个小进展。一个月后，团队状态明显回来了。

这四个信号，其实是一个连锁反应：

记住一句话：项目失控不是一天发生的，但如果你能识别早期信号，就还有救。下一章咱们聊聊，发现信号之后，具体怎么「救」。