项目研发管理实施经验谈(1)

本文为iihero@CSDN原创，如若转载，请注明原始出处，谢谢。

提起项目管理，可能各人都有自己的一套实施经验和原则，适合自己的才是最好的。小中型团队和大型团队的管理方法肯定有很大的不同，就如同软件本身，当规模比较小时，就相对容易控制，可是达到一定规模以后，如果没有有效的方法，就很难管理和控制。先从小型团队开始吧。

小型团队，一般不超过8人。在这个范围以内，人员之间的沟通代价相对还是比较正常的。作为PM而言，要明确如下几点：

1. 整个项目的最终目标是什么

没有明确和精确的目标，往往做到最后，都比较失败。作为项目主管，在目标定下来之前，往往有义务去修正和引导，以确定最终的目标。比如针对所有功能需求，这一次迭代，实现哪些功能，哪些可以不用实现，哪些需要加强，等等，既要满足产品部门的需求，同时也要充分考虑到团队成员的技能条件。

2. 更注重结果而不是过程

这可能是管理人员和技术人员的一个很大的不同。如果你是一个公司的顶级老板，你肯定不太会关注研发过程中的各种复杂的迭代过程，而只关注最终一次迭代以后产品的效果以及用户的体验，因为那才是真正跟产品市场相关的东西。作为PM，更多的精力要关注研发的阶段性结果，根据结果做进一步的进度安排。对于中间的过程，不宜投入太多的精力。一个很具体的任务，下达以后，要求一周以内完成，无论组员用什么方法，只要最终完成，达到效果，则是有效的。如果不能完成，则证明之前的安排有误。

3. 更能适应需求变化

对于合理的需求变化，PM必须能向组员有效的解释，并做出相应调整。一般情况下，很多组员是很排斥需求变化的，可是事实上，需求变化在项目研发过程当中是非常常见的。要想这种事情发生的少，在项目前期，就必须做非常明确的具体的需求分析，那个工作做得越细致，后期就会越轻松。相信很多人都有类似的体验。

4. 有效的源码管理工具

无论你是使用VSS, cvs, svn, git还是clearcase，必须得选择一个行之有效的源码管理工具来管理项目的源码，对于小型团队而言，svn或cvs,git都是够用的，如果习惯了VSS，也是可以的。最终的目的，是能把大家提交的代码，管理起来，按照项目或产品的各个阶段，形成多个版本分支。　如果没有源码管理，很难想像，如何维护一个产品1.0, 1.1, ....2.0等多个版本。同样，针对项目文档，也有相应的版本，它们与源码版本应该是一致的。根据实际需要，可以放到源码库一同管理，所要做的，只是分配不同的权限。只有相关人员才有签入签出的权限。

5. bug跟踪管理

随着项目的推进，必须有一个bug跟踪管理来追踪系统的各种bug、功能完成情况。它与实际的进度任务安排是密切相关的。愿意花钱的，可以使用JIRA系统。也可以使用开源免费的的bugfree等系统。

6. 持续集成原则

必须做到每天至少一次全系统编译，得到安装包，然后基于安装包，有一次自动化测试，通过全部的基本功能测试集。只有这样，才能保证提交给客户的才是真正可用的。试想一下，如果没有这样的自动测试，只是简单的编译通过，然后提交给测试人员去做基本功能测试，整个周期必将大大延长。
在实际实施过程当中，有些组员，可能会比较容易主观的先check in代码，然拍屁股走人，不管后果，这种情况必须制止，那就是，当天，谁最后一个check in代码，他必须完成一次全系统编译，通过全部自动化测试，没有完成，不能走人。只有这样，才能保证项目研发的正常运转。　
　记得多年前，曾经看到过一篇介绍微软的产品研发，基本与此类似，谁当天最后一次check in代码，必须在顺利通过所有的编译之后才能离开。

7. 代码的有效review 和 check in

针对所有组员，在签入代码时，必须提供有效的注释，不要一个文件一个文件的提交，而是作为一个子任务整体提交。提交之前，必须得到至少1到2个人的review，才能正式提交。

8. 少开会，多面对面沟通

实践证明，频繁开会，并不能有效提高工作效率。日报，周报之类的，并不提倡。

9. 任务及任务时间表确定

通常，任务不应该是下达式的，而是商量式的，即把任务分配到最适合或比较适合的人的手上，关于完成的时间，要针求各个人自己的估算值。为什么这里用到“比较适合”，有时候，为了平衡组员的技能发展，比如在A离开时，需要B去“替代”，这时就可能要考虑替代性的任务安排。时间估计，是比较头疼的事，有的人估算任务时间比较保守，3天能完成的工作，他可能说成4天；而有些人比较激进，3天才能完成的，他说成1天或2天；这就需要因人而异的进行综合界定，最终提交的进度安排，通常，都要*1.5，要留有缓冲时间。

10. 注重性能测试

性能测试，最好在项目实施初期就要拟定好目标和要求，它的结果有时候会决定整个项目的生死。