本文是基于美国项目管理协会《项目管理知识体系指南》(PMI PMPBOK),针对软件开发而进行的经验交流,预期的读者群是:
各软件公司对软件生命周期的阶段划分粗细不一,但大体上可分为:启动、需求、设计、开发、变更、测试、发布、维护阶段。当人们停止使用软件,该软件的生命周期宣告结束;前7个阶段属于项目周期,项目周期的结束是以软件正式发布被人们使用为标志的。
除了启动阶段和维护阶段外,其他阶段即是输入也是输出,前一阶段的输出是后一阶段的输入。为了让项目可控,要求输入输出是可见的、可量化审核的、可定义的,也称为可交付物(deliverable);可交付物大多是互相依存而衍生的,例如根据需求说明文档而构建原型而编写设计文档,所以可交付物的信息载体一定要有效、精确、完整。如果哪个阶段的可交付物缺失或不完整,必定会影响到后续阶段,例如没有设计文档直接开发,开发的返工率和返工次数相当高,这种现实案例太多了。
各阶段的交付物是项目组和客户一起完成的,不管是谁负责的,都要经项目经理审核,项目经理转呈组织管理层批阅后发送给相关信息接收者。项目经理是项目所有信息的必经通道也是传递可交付物的唯一通道,严禁项目组出现多渠道跟客户沟通的现象,这会导致信息混乱、信息阻滞、信息传递给错误的接收者、错误的接收者错误地处理信息而延误项目进程等,这些将对项目产生或大或小的害处。
下面着重说明每个阶段需要哪些可交付物。
在项目的初始时期,信息是最少的,随着项目的逐步开展,信息量越来越多逐步趋于稳定最后定型。这个阶段常见的过程是项目立项(项目发起书)、项目背景研究(可行性报告)、甲乙双方人员会晤(开工大会)、制定后续阶段的工作方式和流程(沟通计划)、制定项目总体计划等。
项目类型主要有外部项目、内部项目和长工期维护演变的项目。外部项目的购买者是公司外的客户;内部项目一般是因为技术升级、公司某部门需要新软件支持业务、业内同类软件压力等原因由公司发起的,客户方由公司某部门扮演;长工期维护演变的项目从字面上很好理解,为何要把修复时间长的维护转成项目做?原因是这类项目相对而言范围不大金额不高,适合交给组织中的准项目经理负责,这对他们是很好的实战锻炼;罗马非一日建成,好的项目经理需要经验积累和失败总结才能成长,带项目宜由小到大;小项目可控性可操作性高,项目经理容易由此得到信心和项目经验;同时组织承担的失败率低并由此评估该项目经理是否适合带项目。
项目发起书非常简洁,一般是一张纸。主要内容有优先级别、状态、项目编号、项目名称、背景、目标、范围、项目主要相关人员等,见下:
项目发起书另一作用是组织据此进行人力资源计划和统筹,通过分析状态为队列中的项目及其优先级,组织能估算当前人力资源是剩余的还是不足的,如果是剩余,可以安排人员做其他任务;如果是小不足,要优化和调配;如果是大不足,要招聘和培训新人。另外,组织能获知未来项目的技术趋势,如果是新技术,组织要进行有效指导和安排培训。
可行性报告比项目发起书更详细地说明项目起因、背景历史、范围目标、采用怎样的技术架构和预期效果等等,最主要的是分析项目在既定的范围、成本、质量和进度下,是否能实现。对于外部项目,该文档多用于打单,要求格式正规内容尽可能地详尽;对于内部项目或维护演变的项目,着重是采用怎样的技术架构、收益分析等。
在开工大会前,组织已经任命项目经理和分配人力资源。项目经理编写《开工大会章程》,发送给组织高层、项目组所有成员、客户主要人员等,通知他们开会。
《开工大会章程》的主要内容有项目名称、会议时间、会议室(地点和电话)、主持人(客户方负责人或组织高层)、与会人员(姓名和职务)、议题等;其中议题的先后次序是主持人介绍团队成员、客户领导介绍项目的商业需求和期望效果、项目经理说明项目总体范围和项目关键可交付物、双方商定粗轮廓的项目计划和主要里程碑等,剩下的时间是问和答(F&Q)。
有些项目经理觉得开工大会不重要,这是误区,开工大会是人员到场最齐全的会议之一,项目经理有责任让所有人员清楚各自职责,并在会上对客户精简介绍项目常识,例如说明时间成本范围质量是项目的铁三角;说明项目的几大阶段;说明一个变更需要经历怎样的审核过程等等。