 admin | |  |
发帖数： 4 篇
注册时间： 2000-01-01 00:00
|
|  消息  查看  好友  引用 | | |
经过多少次成功的经验和失败的教训，如今软件项目的管理越来越受到软件公司的重视。目前在国内较为流行的软件项目管理体系有CMM、RUP，还有XP(极限编程)等。这些软件工程管理方法在很多公司得到应用并取得了良好的效果。
本文并非系统介绍某个软件开发管理体系，而是从作者在软件产品项目管理中的实际经验出发，针对国内中小型软件企业，谈谈自己在软件产品项目管理中的几点体会。
一. 关于员工的招募与培训
资源的分配与管理，是软件项目管理的重要内容。在人工成本已上升为软件公司的最大成本支出的今天，有效的人力资源管理，是控制项目成本、提高资源利用效率的有效途径。同时，员工的质量也在很大程度上决定了一个公司的整体素质。
员工试用前的考核，比试用本身更重要
项目组成员可能来源于组织内部，也可能直接到人才市场中招募。在项目进行过程中，由于项目组成员的流动、项目组扩展等原因，补充项目成员的可能性在项目生命周期的各个时期都存在。
软件项目中员工的聘用受公司聘用机制的约束，但是项目经理一般在所负责项目的员工聘用方面有较大的决定权。有很多的项目经理在对应聘员工作了初步的考察后，会对自己说，“行，这个人我看还可以，别再在这方面浪费时间了，先试用吧，不行还有试用期呢”。设立试用期当然是降低用人风险的有效手段，但过分倚重试用期却不是一种好的想法。如果发现用人不当，损失的不只是试用期的工资成本，更重要的是项目的时间成本。
相比较而言，加大员工试用前的考核力度，是一种更好的控制用人风险的模式。有的项目经理会说，“这个道理我当然明白，我是作了详细考核才决定试用的。”但是实际上，很多项目完全可以在这方面做得更好。如事前在人员素质、能力、经验等方面制定更明确的用人要求，更有针对性的准备(如问题的准备)，根据具体情况安排相应的领域专家进行面试等。当然从公司角度讲，高级管理者能以某种形式参与到试用前的考核中来也是很有必要的，例如要求参加面试的考官每次都能给出可供备查的书面评估等。
将规矩公之于众
你的项目也许是采用标准的CMM方式进行管理，也许是采用RUP的某个裁剪版本。也有可能象采用设计模式那样，在实践中将一些管理模式整合起来，形成了一套在本项目组行之有效的管理模式。为了将新员工纳入到本组的管理模式中，要对新来的员工进行必要的培训。这项工作可以由项目经理亲自做，也可以由项目经理在组内指定某个“师傅”来做。Bug是怎么管理的？测试计划怎么做？工作产品如何提交？配置库在哪里？如果能将组内已有的这些管理规程以某种方便的方式公之于众(如在内部网上做一个“员工指南”栏目)，可以充分发挥新组员的自我学习能力，迅速提高新成员融入项目组的速度，从而大大提高新员工的培训效率。
这种做法，不仅对新员工大有裨益，对需要变换项目角色的老员工来说，同样有帮助。这种做法的另一个优点是有助于带动全项目组人员主动参与到项目管理过程的改进中来。
二. 关于信息的沟通
对于项目管理来说明，信息的交流有组内信息交流和组间信息交流之分，又有水平信息交流和垂直信息交流之分。
充分的组内信息交流，是项目顺利开展的基础
无论采用哪种管理模型，充分的组内信息交流都是必不可少的。在一个项目组中，会存在多种角色，不同的角色意味不同的权责。从某种意义上讲，角色意味着决策权的细化和在组内的分配，而软件项目正是由一系列持续化的微观决策推动的。充分的信息交流是正确决策的基础，是软件项目沿着正确的道路前进的必要条件。以CMM为例，其周例会规程、定期和不定期的评审、风险跟踪等无不强调了信息交流的重要性。
掌握这个原则，我们就可以抛弃一些软件个人英雄时代的想法，如“最近项目很紧，这段时期大家每人在家里加班做吧。”
基于这个原则，作为项目经理，要坚决剔除那些视技能为“玄学”的人。如果项目经理不幸也是一个这样的人，这个项目就玄了。
项目组与外界的信息沟通：做好项目公关
项目管理本质上是一种水平的管理。对于软件产品项目来说，与其它部门信息的沟通，能促进项目的良好运作。如果销售部门能对本项目有比较准确的把握，就会在商务方面和对潜在用户的承诺方面做得更好，同样的情况也适用于产品支持部门、市场宣传部门。如果因信息沟通不够，导致相关部门对用户作出了过于离谱的承诺，感到为难的就不只是项目经理了。对于那些要对项目预算负责的项目经理来说，做好项目在公司内部的公关就尤为重要了。如果公司有很多同事见到你就问“Hi, 你们的项目怎么样了”，作为项目经理，你要马上坐下来反思了。
项目组与外界的信息沟通是多渠道的，以下是一些值得鼓励的做法：
l 定期或不定期地向相关部门通报项目进展情况
l 通过内部系统网页公布项目相关信息
l 邀请相关部门的人员参与内部评审
l 在饭桌上或休息室里讨论你的项目
三. 关于角色与责任分派
人员可以省，角色却不能省
前面讲到，角色是项目开发中的责权在项目组内的分配。对于国内软件企业来说，资源不足是普遍现象。也许你的项目足够小，小到可以没有专职的测试人员，但你不能把不同层次的测试也给省了。你可以让同一个人同时担任多种角色，或在不同的项目阶段担任不同的角色。例如，配置管理员兼做测试，开发人员间互相做测试，或者开发人员兼做配置管理，等等。极端的情况是，由于资源不足，项目组不再有专职的QA人员了，少了一个人整天拿着Check List在项目经理旁边唠叨：“你这个还没做，那个做得不规范，配置项也不完备…”，对项目经理是很大的解脱。但是该做的事情还得做呀，要么高级管理者兼做QA，要么项目经理再自觉一些，“日三省吾身”。哈哈，这个例子确实有些极端，从管理学的角度，自我监督总是靠不住的。
要尊重项目组内角色的判断和权利
项目的成功是项目组内每个人的功劳，软件产品项目的开发过程中，每个角色都有其职责范围内的权利。举个例子，在微软，没有测试经理的签字，产品是不能发布的。对国内的软件企业来说，项目经理在项目组内的事务中几乎有所有的最终决定权，但决定不等于武断。如果对测试人员报告的Bug经常不加说明的取消，对其积极性的打击是可想而知的。
项目经理在安排具体任务的开发计划时，比较可行的模式是自下而上地产生计划。对于某项具体的任务，由承担人员提供估计计划，与项目经理讨论产生最终的执行计划。对于组员给出的估计，首先是尊重，然后再分析其任务分解的合理性。对于项目经理来说，如果发现自己几乎总在说：“这个小模块，怎么要那么长时间，一周就够了”这样的话，那么在督促员工提高工作效率的同时，也要检讨自己的分析方式。要知道，在统计一个模块真正完成的时间时，是要把针对此模块的Bug修订时间计算在内的。
四. 关于风险控制
五. 关于管理工具的使用
六. 关于测试与质量保证
七. 关于管理规程的建立
八. 关于软件开发计划与跟踪
九. 关于团队文化
| |
|
2008-05-23 15:48
保 密
