嵌入式项目烂尾的几点真相

选择了嵌入式行业，就选择了一个充满于挑战的行业。对于软件工程师而言，项目的成功和失败对他们很重要。因为一行行的代码他们不知道熬了多少个通宵，脑细胞死了多少而写出来的。 如果项目失败了，就意味着辛辛苦苦的一切付诸东流。这不得不令人沮丧。本文就给大家介绍一下是什么原因会让一个项目在不知不觉中慢慢地且不声不响地走上失败之路。

成员流动

每家公司都会经历员工或承包商的流动，但关键人物太过于经常变动，可能是一个项目注定失败的领先指标。有很多原因可以说明为什么人员流动对项目会有不利的影响。 第一，它会造成其他团队成员心理上的影响，而降低生产力。其次，失去关键人物可能会导致历史性和重要的信息会永远遗失，这会放缓发展的脚步。 最后，替换队员需要对新的成员进行训练，并跟上团队的脚步。这是一个会使人分心的工作，会让其他成员放下手边的开发工作来教导新的成员，结果会导致开发成本的增加和延长交付时间。

走走停停综合征

孩子被教导说，“不要喊狼来了。”这话是一个警告，不要误发假警报。这种警告有一种“进行!停止!进行!”的周期，在项目中很容易被忽略。 一位经理、客户，或其他一些单位猛烈地催促他的团队，声称该项目要在某一日之前完成。开发人员因此周末加班，投注更多的心力。然后，就像这股来得很快的催促之力，突然之间却又嘎然而止。几个月后，它又再次告急。 “快点，我们必须在X之前出货!” 然后同样的事情又再次发生。 项目这种走走停停一再重复的紧迫性将会对开发团队造成心理层面的影响。开发人员不再相信任何的迫切性。事实上，他们会有一种心态，开始觉得这个项目并不是一个需要认真对待的项目，它很快将再次停止，那么为什么还要投入任何的努力? 所以，不要对项目喊狼来了!

完美主义者的态度

许多工程师都有一种完美主义者的态度，这种态度所带来的问题是，不可能开发出完美的系统，撰写出完美的代码，或者在最适当的时间推出产品。 完美主义是镜花水月，如果完美主义是公司文化的一部分，它将会是产品可能会不断修正，直到公司破产倒闭的标志。 正确的心态不是完美，而是成功。为了可以成功地推出产品，什么是最低的成功标准?设下成功的标准，并在一旦达成后，立即推出产品。之后可以用启动加载器(boot-loader)来添加功能并解决那些小错误。

加速的时间表

要迅速地开发出一个嵌入式系统，事实上，设计团队要放慢脚步，这似乎违反直觉。但依据加速的时间表(accelerated TImetable)工作会产生压力，更重要的是，有比较高的可能性会产生错误，而使得效率降低。错误将直接影响小缺陷的数量，而这些小缺陷随后又会增加测试时间和返工的时间。 另一个问题是，当开发人员都抢着和努力满足加速的时间表时，他们会图省事而走快捷方式。比如，代码没有批注及说明。像是架构图和流程图等设计文件也付之阙如。相反地，设计只留存在程序设计人员的心中。放慢脚步，把事情做正确，会更快地得到最终的解决方案。

不良的结构化软件

嵌入式软件是嵌入式系统的血液；没有了它，产品就无法运作。不良的结构化软件是一个很明确的失败征兆。 嵌入式系统的系统结构需要具有灵活性，以便未来成长之用。它要有用于测试、除错和进行日志记录的空间。一个架构不佳的系统将会使得施作不良，而导致该软件错误百出而难以管理，从而注定要将它的岁月花在除错上，直至项目最终死亡为止。

本末倒置

开发一个新产品是令人兴奋的奋斗过程。其中有很多事情要做，而公司通常是急着想把产品从概念化成可以生产的产品。这种匆促的举动是极其危险的，尤其是当生产决定浮现时。 当产品的机械设计或外观和感觉被拿来推动其电气需求时，这就是一个很好的例子。在工作的电气和软件原型被验证之前，生产工具就准备好要生产了。 在这种情况下，似乎总是有电路板没有检查，需要进行调整的问题。对那些匆匆忙忙、且太快就试着要把所有的事情同时拉在一起的项目，最终结果总是由于修改而落入花更长时间和更多成本的结果。

范围潜变

每个项目都有范围潜变(scope creep)，但范围潜变的程度可以是该项目是否会成功或失败的决定性因素。范围潜变最危险的一个领域是，它是暗中为害的。某天在电路板上增加了一个简单的传感器，几个月后再加一些上去，这些看起来完全无害，但他们可能是致命的。 范围潜变的最大问题是，变化通常是微小的。乍看之下，改变看起来只是短短几天的工作。但是，每次加一点点，系统的复杂性也随之增加了。复杂的系统需要更多的测试，可能也需要更多的除错。随着时间的发展，范围潜变可以将系统改变到使原来的软件体系结构和设计变得过时，或甚至变成是不正确的解决方案!最终的结果是使一个项目变得远远地超出其预算范围，实际进度落在交货日期之后，此一项目很少或几乎没有结束的迹象。

最后

不管是什么样的嵌入式工程师，在开发新的嵌入式系统时，没有人确保这个项目百分之百会成功。影响项目的成功有许多因素，而我们工程师们需要做的就是把失败率降到最低。你可以从以上总结中吸取经验。判断自己的项目是否在走着一条缓慢且迈向失败的路。