由项目死锁得到的教训

转载时请注明出处和作者联系方式
作者联系方式：李先静 <xianjimli at hotmail dot com>

该项目有一个PM，但他的主要任务，似乎只是负责与客户交流。硬件部一个主管负责硬件部分，我负责软件部分。软件部分的任务又分散在三个小组里，一个OS/BIOS组，负责OS和驱动部分。一个GUI平台组，负责GUI的窗口管理系统和基本控件。还有我所负责的AP组，主要负责应用程序的开发。

 

这个项目是基于前一个项目的，为了降低成本，要对软/硬件做了一些修改，目前的任务如下：

 

1.       换flash和ram，由8M flash/2M ram，改为4M flash/512K ram。

2.       换LCD，由128x160，改为128x128。

3.       去掉左右键和OK键。

4.       硬件RF部分有修改。

5.       耳机的功放有修改。

6.       由翻盖改为直板。

7.       加防盗功能。

8.       修改硬件引起的软件修改。

 

对底层和硬件一点不懂，这是我最大的硬伤。我自己负责AP组，自然而然的，主要关注点放在AP和GUI这边，这一块的任务除了空间优化外，其它的任务都在按正常计划进行。

 

对于驱动部分，有些头疼。最初，我和负责驱动的组长交流过，请他制定驱动修改的计划。他说，驱动的修改很简单，但要拿到硬件板后修改，这样调试才方便。由于硬件板一直没有出来，以后就没有太关注驱动部分了。

 

按计划，硬件部门今天提供硬件板。而硬件部门现在告诉我说下周三才能提供。不但如些，他们反过来让我们周三前提供一个软件版本，给他们验证硬件功能。

 

做驱动的等硬件去调试，做硬件的又等要驱动去验证。作为驱动方面来讲吧，没有硬件写驱动也是很困难，硬件吧，没有驱动的验证又不能做太多样机。双方都有道理，而我对这一块偏偏不懂。

 

后来，这个问题终于解决了。我也吸取了两点教训：任何一个任务都要亲自跟进，随时关注它们，这些任务越往后拖越麻烦。作为软件部分的负责人，不能因为不懂就不去管它，而应该去学习和研究相关知识，或者寻求帮助。