引言：
在论坛上经常看到很多人有关项目管理的经验，而且都是长篇大论，侃侃而谈；总是看得我晕头转向，总感觉，都是停留在人的作用上，总是强调管理中的人为因素，几乎很多条目都是带有很强的人为色彩，看完后，总是觉得这些经验很不错，但是自己往往却很难在自己的项目中具体实施。 想法：
本人是一个实践主义者:)，自己在项目管理中，总是尝试抛开人为因素的困扰，利用一些简单通用的工具来协助项目管理，通过这些工具的运用，让它们自动来推动项目管理的进程，减少人为因素的问题，形成一条无形的推动项目进程的生产链条。 核心链条：
源代码管理工具 => Bug追踪工具 => 每日编译工具
WinCVS/CVSNT => Bugzilla => BAT和Perl脚本 下面是这些核心工具的运用经验： 1. 必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则：
1) 程序员尽量每天只在下班前提交一次;
2) 提交的代码必须是在自己的机器上是正常运行的；
3) 每次提交都必须用简短的话说明自己提交代码的功能描述。 2. 建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。 3. 用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考） 4. 测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况，或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。 5. 开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。 6. 管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。 这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本，随时掌握产品的走向。。。等等。 另：有关项目管理中与客户、与公司上层、成本、进度等等，这里没有具体谈，但如果切实运用以上经验，会在一定程度上简化这些关系的复杂度，使得各个环节变得相对简单。
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
