从2001年7月从大学毕业，到2005年7月从第一家公司跳槽，整整4年时间了，是该写点东西纪念一下自己4年的历程拉。

昨天说到前一年半的漫长的编码过程，那段也是我上vchelp最疯狂的，在学习，尝试，沟通中不断的提高自己的编程能力，最重要的是，我可以自由的跟vc程序员最好的朋友－－MSDN很好的沟通了。MSDN是如此的聪明，只要我告诉它前面几个字母，他就能猜出我想要了解的是什么，以至于到现在有很多API函数都都是只知道前面几个字母是什么。

写文档，看代码

渐渐的，在我的工作时间里，写代码的时间越来越少，写文档的时间越来越多，项目也逐渐比较正式起来，人员配备也多了起来，用于沟通，管理的时间多于了写代码的时间。当然，公司也正式任命我为项目经理。

在接下来的两年半时间里，我都或多或少的管理着几个项目，除了有一个项目延期的一塌糊涂之外，其他的项目都是按时高质完成的。

作为一个项目经理，如何保证项目的准时和优质完成，最重要的是什么？我认为是对项目进度的把握和对项目风险的控制。至于如何做到，软件工程给我们提供了一条很好的路子。可能有些人会认为软件工程是没有多大用处但增加很大工作量的鸡肋。但其实不然，你做的项目越大，软件工程的重要性就越突出。

需求分析：客户的需求和项目的需求是不同的，需求分析的过程就是把客户模糊的主观需求转化成可度量可测试的客观需求。一个好的系统分析师可以准确的把握住客户的思路，并转换成系统设计师和测试人员所能理解的分条的语言。说穿了需求分析就是要知道做什么。

设计：知道了做什么以后，解下来要考虑的是怎么做了，设计就是来告诉我们这个需要采用什么样的方法来实现。设计一般从大到小，不断的把功能细分，把类似的功能合并。然后再是功能接口设计和数据结构设计。最后是每个小功能的实现的方法或者伪代码，这个已经是详细设计的范畴了。设计是详细也好，是简单也好，有几点是必须要把握的：第一，功能必须覆盖需求；第二，每个功能模块必须有明确输入和输出，并且是可测试的；第三，每个功能模块的开发进度必须是可以估算的；第四，数据结构必须明确。

计划：计划实际上是对资源的安排，应该属于运筹学的范畴。我们一般需要安排的资源有时间资源，人力资源，软硬件资源等。人力资源和时间资源永远是对矛盾体，有本叫《人月神话》的书有很大的篇幅都介绍了关于人力资源和时间资源安排的问题。对于实际做计划来说，我们有很好的帮手，就是project。首先我们经所有的功能模块和其他事件都估算时间，然后确定完成它的前提条件，最后在配置人力资源。通过调配人力资源和功能开发的顺序来尽量减少人员的闲置时间。

风险控制：另外，说到计划还有一个必定要提到的就是变化，有句话说的好，叫做计划没有变化快，那并不意味了我们就不需要计划了，而是需要根据变化来调整计划。同时我们也应该看到一些重大的变化可能会影响到整个项目的成败，所以就有了风险。风险是在项目开始是就存在的，并一直持续到项目结束。风险控制目的就是尽早的发现可能存在的问题，并安排不久方案。说的好听点就是未雨绸缪。风险本身也是在不断变化的，在评估风险时，我们一般会给出两个参数，一个是风险发生的概率，另外一个是风险如果发生的影响，把这两个相乘我们就得到一个风险系数，风险系数越高就越要被关注。项目经理应该每天都关注一下风险系数排名最签名的几个风险，并每隔一段时间重新做风险评估。

执行：执行就是项目按照计划来进行的整个过程，项目经理在这个过程中最主要的事情是与左右的干系人交流，看他们的完成情况是不是与预期的计划吻合，他们的工作产出的质量如何，如果有问题就决策弥补方案或者修改计划。我在执行阶段大不份的时间都是在交流当中，一般每天的例会，每周的总结会，每天完成文档和代码的走读，具体技术细节的沟通等等。个人的经验是，如果你想项目在掌控之中，首先你必须了解这个项目中的每个零件现在的运行情况，所以每天的例会是非常重要的。

测试：测试就是检验我们做的产品是否满足需求。测试人员在需求分析后会写测试计划，并对需求中的每一点准备一个或者多个测试用例。测试人员的目的就是找出尽量多的产品与需求不符的部分，并以测试报告的形式提交成功。对于测试，我要说的是最好的朋友总是会指出你的缺点而不是吹捧你的优点。程序员对待测试提交的bug的态度应该是虚心接受，并坚决改正。同时要做好自我检查。这就是伟大的批评与自我批评。

提交，发布，部署：各种用户手册，安装文档，还有可能现场部署。坚持住，胜利马上就来临了。

昨天本来要把这部分发布的，但是由于时间的关系没有写完，算是一个延期吧，我修改了我的计划，周六和周日休息，下周再来继续我的工作经历。

发表于 @ 2005年09月09日 10:56:00|评论(loading...)|编辑