《技术出身，如何做好项目经理》系列之《一个项目经理的工作日志》

《技术出身，如何做好项目经理》 系列之 《一个项目经理的工作日志》

这一天，我们的部门研发经理把我叫了过去，告诉我我们小组要接手一个新的项目，这个项目已经经过客户和公司两方高层的确认了，最后要求完成的时间是2个月，也就是在6月5日之前必须完成，合同都签署了。然后，研发经理把客户fax过来的需求交给了我。我拿过需求来一看，上面写着：

【XXX机顶盒系统需求】

1. 需要支持HTML4.0的浏览器，支持JavaScript和Flash

2. 支持Email

3. 支持MP3音乐格式文件的播放

4. 支持记事本、时间安排表、待办、计算器、英汉字典、地址簿等PIM应用

5. 视频点播系统

6. 运行系统最终要求16M DOC和32M RAM上。

…

 

因为大部分的PIM（Personal Information Manager）程序都已经写过一遍了，VOD系统又是采用合作伙伴的产品，因此我把视线集中到了如何构建一个更好的桌面系统，把应用集成到一个框架中来。

 

我们首先询问了客户对界面的需求，他们回复我们，需要类似Windows的桌面风格，并且Email给我们一张图片。值得庆幸的是，我们原有的界面就是这种风格的，并不需要太大的修改。我觉得这个项目问题不大，有望在2个月内完成。

 

我大概做了一下近期的计划，首先我们要对桌面系统和用户交互方面进行一次深入的讨论，拿出一个让我们自豪，让客户满意的方案；然后考虑采用哪些技术，并进行软件设计；最终进行编码实现。

 

尽管时间紧迫，我还是准备在3～4周之内，拿出用户交互设计的方案。这段时间中，我们不停的在开讨论会，大家提出了很多好的见解和近乎疯狂的想法，期间我们还参考了一些资料，包括计算机杂志上一篇介绍SUI（Social User Interface）的文章，还有《冲破技术牢笼》（一本专门讲述交互设计的书籍）。期间，我们还讨论了要进行集成的应用程序，以及构建UI系统的方案。最终，我们决定：

1. 采用XML作为桌面系统的配置方案，提供极强的可定制、可扩充性。

2. 采用Netscape4.76作为我们的Browser。

3. 利用Browser实现WebMail。

4. 采用SUI的一些思想，加入一个桌面精灵程序。

5. 为支持更好的桌面特性、以及精灵程序的需求，支持Always On Top属性。

6. MP3和VOD程序作为Netscape的Plugin。

 

然后，我大概预计了一下工作量和人力资源的安排：

1．XML解析器（基于SAX的XML解析）： 1人月

2．窗口管理器（包括基于XML可配置、和支持总在最前）： 2人月

3．桌面精灵程序： 1人月

4．MP3程序： 2人周

5．系统集成： 1人周

6．系统测试：1人周

（注：在我进行估计的潜意识中，每周是工作七天的）。

 

但是现在我只有5个人周了，而且我现在的人手已经分配到各个项目中了。我在项目讨论会上，向事业部经理提出了我的资源和时间问题。我得到的回复是，时间不能改变了，五一加班，这样就有六周时间了；然后，把我的一个小组成员Lee从另外一个项目（周期较长）调到我这个项目中来，负责窗口管理器。

 

最终，我的项目小组由4人组成，一个兼职的学生John（水平不错，在我们讨论交互设计的时候，就开始准备XML解析器的前期工作了），Lee负责桌面系统的窗口管理部分，Huang负责协同合作伙伴的开发工作并进行集成VOD系统的工作，我负责桌面精灵程序以及总体系统的设计工作。然后，我们开始工作了。（这时，John已经完成了他的XML解析器。）

 

首先我们考查了这些功能的实现技术，大体做了设计的工作：桌面系统的构架、模块划分以及模块之间的关系（包括桌面配置和窗口管理两部分，分别由John和Lee负责）；考虑了Netscape的运行方式；如何使Mp3、VOD与Netscape相结合等问题。这时，又有1周过去了，我们还有整整5周时间。Rush！

 

John和Lee和我在五一加班一周，期间我们在公司吃住，每天都是通宵工作，然后白天睡觉，下午还一起去打一小时台球。我们还各自换了公司里最好的显示器，这种感觉很棒。很快的，在五一假期结束后，John和Lee各自的模块编写基本完成了，我的桌面精灵程序的功能也基本实现了。

 

这时突然，用户由于在国外参加了一次展会，对他们原先提出的界面设计有了新的想法，并发回给我们展会上的一些图片。应该承认，国外的设计的确是优秀的。我们负责这个项目的销售人员在没有和我协商的情况下对客户做出了承诺，OK，按照这个做，只是换换图片嘛。其实，这并不是换换图片的问题，需要在桌面配置管理部分进行不小的代码改动。我想提出异议，但是已经为时已晚了。好吧，重新进行设计和编码，好在由于原来的设计灵活度比较大，没有伤筋动骨。但是，返工还是花了几天时间。

 

这时，意料之外的情况发生了，John由于导师布置的课题进行了调整，现在必须要花加倍的时间在他的毕业设计上了，只有晚上有几个小时可以过来、周六日可以工作。

 

同时，桌面系统进入整合阶段了。首先，是在整合中发现Lee和John没有充分考虑到他们两个人的模块是工作在一个进程中的，他们原本设计的基础是两个模块是并行的，这不得不花了3天的时间，把两个人的接口重新进行了组织，程序终于可以运行了。但是，桌面系统显得非常不稳定，经常发生core dump，Bug是随机出现的而且还无法确定其发生的地点，gdb报告说错误发生在glibc的内存管理部分中。这个Bug极大的困扰了我们，我们整整花了一天一夜24小时连续调试和检查代码终于发现了错误（我在后面的代码评审中会谈到这个错误）。不幸的是，在John准备备份（tar gz）的时候，由于连续作战精神恍惚，错误的删除了新修改的代码，这不得不又花费了3个小时以上的时间，在最近一次备份的基础上重新修改并验证。

 

在这个Bug解 决之后，我们希望把桌面系统提交系统测试部门进行测试。但是，测试部门拒绝了我们单一应用测试的请求，理由是他们只接受产品的测试，这个单一应用无法进行 系统测试，而且这个测试应该由我们自己完成。这使我大为光火，坚持认为系统测试部门应该进行单一程序的测试，这样及时发现Bug（而不要使Bug激增出现在一起）有助于我们节省开发的时间。最终，大家不欢而散。

 

我们把Netscape和桌面、精灵程序集成在了一起，发现了一个非常严重的问题。由于我们之前的设计（为了节约内存，同时也为了多个应用能并行执行），并不启动多个Netscape，而是采用外部控制的方式通知运行中的Netscape新建一个窗口。然而，Netscape程序本身经常由于不确切原因僵住（经常是在网络访问过程中，怀疑是Netscape程序内部关键代码区域互斥的结果，而且所有的Netscape窗口都Block），导致应用僵死、切换失效。而且，这种外部控制的方式已经硬编码在模块中了，改变这种方式将会带来大量的代码修改。我们略微修改了一下调用的逻辑关系，情况有了好转。

 

这期间，合作伙伴的VOD程序也早应该就位了。但是，不幸的是由于合作伙伴所在的公司发生了并购，交付的时间大大的被推迟了。Huang发现VOD程序在测试板上经常死机，Huang每天保持和合作公司的联络，终于解决了问题。

 

接下来是整个系统的整合，突然我们发现原来的由另一个由多媒体小组提供的Mp3播放程序使用的是Widget－XXX1.0，而我们使用的是其2.0版本，而且由于两个版本有很大的体系结构差异，加之这个Mp3程序使用了很多1.0版本中未公开的功能，移植起来非常困难。这个程序的作者也是一个兼职人员，而且已经离开了公司，我一直联系不到他，他的代码没有任何注释，而且没有留下任何有关的设计文档。不得已我们决定重写，我自己花了4天3夜终于完成了Mp3程序。

 

这时已经6月5日了，我们告诉事业部经理，工作已经完成了99％，只差整合了。整合的时候，也发生了一些意外情况：小系统的Shell同大系统中的B Shell是不同的，有的脚本需要调整；精灵程序运行太慢了，这跟系统资源紧张有很大的关系，最后不得不取消了这个精灵程序；Netscape在资源紧张、CPU较慢的情况下，僵死的情况又频繁发生了… …

 

已经6月12日了，整合仍然没有最终完成，我们大量的设想权益之计设法让系统基本运行正常。最终，在6月19日，我们把一个伤痕累累的系统提交给了系统测试部门。

 

系统测试部门进行了为期4天的测试，然后用了两天时间对所发现的Bug我们做了必要的修正，其余全部的作为限制型Bug，在6月26日把产品提交给用户了。我们惊奇的发现，原来客户对于不能在6月5日交付的反应并不强烈，这让我们开始怀疑6月5日的Dead Line是如何得来的？

 

客户在收到产品之后不久，就放弃了这个产品… …