近期项目失利反思

半年前参加了一个项目组，这个项目的成败将会深刻影响公司的发展方向，因此备受关注。然而，该项目却一再的延期，超时至今已有4个月左右，中间加班无数，1月中旬到3月中旬，平均每天工作14小时，有数个夜晚直接住宿到单位，有数天是次日凌晨才下班。如此的加班最终换来的却是产品在展会上表现不良，功能不稳定，市场部对该项目彻底失去信心。

发这个文章目的不是抱怨，而是反思原因，以避免下一次重蹈覆辙。那么问题出在哪里？

从人员结构分析，此项目虽然是公司在一个新领域的尝试，但为保万无一失，项目负责人则是公司找来的在此领域有多年实际项目经验的工程师，其负责新项目的管理、设计以及部分相关功能的实现。负责硬件的工程师本身也从事工作多年，积累了一定的经验。而我，主要负责整个项目所有arm的设计和实现，而我前一个项目设计的arm程序是兼容此项目的应用场景的，所以也没有问题。

既然出现了大量的加班现象，就从项目安排上分析原因。首先，此项目是在7月初启动的，预计12月底完成。事实上，项目组真正开始运转，则是在10月份才开始的。7月到10月间，仅开展了一些驱动文档的编写和未经测试的驱动程序编写。按照正常的流程，一旦项目开始启动，就应该马上进行原理验证，这期间包括打样原理验证板等工作，为后面项目推进打下基础。实际上，此项目并未安排原理验证的步骤，而是直接进行了第一版电路板的打样，期待一版成。结果第一版电路板暴露出了大量的硬件设计缺陷，这对驱动的开发带来极大的阻碍。由于项目进度安排的不合理，导致很多原理验证的工作甚至拖延到项目延期。

既然提到了电路板，就不得不说说电路设计。由于我是嵌入式软件出身，因此，我更倾向以软件设计的思路，去分析硬件结构，至于正确与否，也许只能在日后尚可得以明确。

这次设计的硬件出现了以下几个问题，这些问题都或多或少的阻碍了项目的推进。首先，项目在开发上主要分为两大块，一块是以ARM为主的负责通讯、管理和相关设备的驱动。另一块是以FPGA为主的程序设计和相关设备驱动。

我的观点是硬件设计应该根据功能/职责,事先划分好不同的功能模块，并定义明确相互之间的通讯接口，这样做的好处是，各个功能模块之间相互独立，有利于进行独立的开发和测试。而目前的设计，使各个功能全部耦合到一起，开发一个功能时必须等待别的模块提供特定的服务才行，开发效率低下。另一方面，独立的功能模块有利于对系统故障的排查。目前的设计，系统发生故障时，难以追踪故障的根源，如果采用独立模块设计，通过测量各个模块的接口，即可缩小故障原因范围，然后通过进一步调试，断定问题所在。

抛开具体项目，无论从公司还是个人，都不希望看到付出得不到回报。所以真正付出之前，是不是更应该着眼一些更切实际的事情。比如说抛开一些不切实际的幻想，所有的计划都应更科学，经得起推敲。或者说，应该步步为营，分阶段，分步骤的实现一个伟大的目标。

如前所述，公司在这个项目中倾注了大量的心血，我又何尝不是如此，所谓希望越大，失望越大。不过失败是成功之母，于是我将我的实际经历和想法，都总结于此。如果是有经验的人，必定还可以从此项目中总结出更多的经验，不过对于现阶段的我来说，这些经验与我而言仍受益匪浅。