项目日志在项目管理中的应用
1、前言
软件项目的特殊性使其开发难度越来越大，各企业、团队面临的风险也越来越多，这直接导致目前国内软件项目成功率较低。对于目前项目中存在的问题，影响比较大的主要有以下几方面：
1、计划及过程跟踪不足
在开发活动中，项目计划是项目启动后的头一件重大事件，但是经常被忽略或者得不到应有的重视。
项目计划好比是一份项目的交通图，指导项目准确的达到目标，即使它不是被形成提交客户的正式文件，也应该是项目组内的规范文档。可是项目计划往往只是由项目管理者制定或是在项目管理者的脑子里，只有项目管理者知道。这样的项目计划比较粗糙和模糊，同时由于项目计划是由项目管理者制定的，项目组的其他成员只能被动的执行。而项目管理者既不可能是项目中的全才，也不可能代替其他成员工作，因此这种得不到成员认可的项目计划就等于没有制定项目计划。
为什么每个项目都需要一份项目计划，并且要形成规范的文档呢？这是因为：
第一、通过制定计划，使得小组成员，对项目有关事项，如资源配备、风险化解、人员安排、时间进度、内外接口等形成共识，形成事先约定，避免事后争吵不清；
第二、通过计划，可以使得一些支持性工作以及并行工作及时得到安排，避免因计划不周造成各子流程之间的相互牵掣。比如测试工具的选择，人员的培训都是需要及早计划和安排的。
第三、可以使项目组人员明确自己的职责，便于自我管理和自我激励；
第四、计划可以有效的支持管理，作为项目管理者、业务经理、QA经理、测试经理们对开发工作跟踪和检查的依据；
第五、做好事先计划，就可以使注意力专心于解决问题，而不用再去想下一步做什么。
第六、计划是项目总结的输入之一，项目总结其实就是把实际运行情况与项目计划不断比较以提炼经验教训的过程。通过计划和总结，将项目过程中的经验和教训变成公司及项目组成员的知识积累。
同时，许多公司往往也制定了比较周密的计划，但计划是计划，执行是执行。
计划一旦制定出来，马上束之高阁，或只作为应付用户的工具，对于在实际执行中是否按照计划及时执行，是否延期，是否超支等，采取的是走一步看一步，走到哪里算哪里的管理方法。
实际工作执行项目计划常常遇到各种困难。有的组织文化中有种观念认为计划是一种约束，反正大家努力往前赶就对了，没必要自己捆住手脚；另外一种情况是大家没有按照计划工作的习惯，计划虽然做好了，做的时候还是我行我素，项目管理者也没有维护计划的习惯，项目开始没多久，项目管理者就埋头去解决具体的技术问题，将计划完全撂到了一边。
2、需求变更控制不足
作为软件开发人员或者软件系统客户，相信我们都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，说，当时我是那样要求的，不过现在我们的业务调整了…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要……。
需求包括业务需求、用户需求和功能需求。
业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（FunctionalRequirement ）定义了开发人员必须实现的软件功能。在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因:
第一、对需求的理解分歧，当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的做出来的时候客户当然会跳起来了！这是理解分歧的问题，有客户表述责任、同时也体现了双方的交流不够，项目管理者工作中很重要的一项就是“沟通”。项目管理者应该不断组织协调甚至参与和用户的沟通。
第二、系统实施时间过长，一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候（事实上还会有个Deadline ），开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求；
第三、客户具体情况不同，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变；开发本身要求有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了！
所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以我们不应该梦想客户需求不变，当我们开始一个项目的时候就应该意识到，客户需求变更一定会有的。
那么对于这样的现状，我们该怎么办呢？客户是上帝，难道我们就象以前一样，跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护？
2、项目日志
对于以上的问题，目前，已经有人提出了各种各样的解决方案，这里就不过多的加以描述了，在这里，我只想提出，通过项目日志，可以有效地降低开发风险，提高项目的成功率。
项目经理必须时刻对项目的状态有详细的了解，以至于其他人能够知道项目延迟或者项目超支的原因，以及追加资源的必要性。编辑所有这些数据通常要花费大量时间，因此项目经理常常需要挤出时间来完成这项工作。
创建一个项目日志是一件非常简单的事情。你可以使用日志作为跟踪项目问题、行动条款、变更要求和风险的集中管理。项目团队的所有成员都可以很容易的用一种标准的格式输入信息，生成报表和查看信息。
下面我就把我们在项目中实际用到的项目日志模版做一个简单的介绍。
| 项目日志 |
||||
| 项目名称： |
|
编号： |
|
|
| 项目经理： |
|
日期： |
|
|
| 项目阶段： |
|
|||
| 进展情况： |
□按计划进行 □超前计划 □滞后计划 |
|||
| 工作量： |
工时 |
|||
| 工作内容： |
|
|
||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
| 客户需求 |
回复 |
|||
| 1 |
|
1 |
|
|
| 2 |
|
2 |
|
|
| 3 |
|
3 |
|
|
| 4 |
|
4 |
|
|
| 5 |
|
5 |
|
|
| 问题： |
|
|||
| 备注： |
|
|||
| 相关文档： |
|
|||
在这个表中，在项目阶段一栏中，项目阶段从下面的阶段中选择：
| 项目阶段 |
工作内容 |
| 项目范围规划 |
确定项目范围 |
|
|
确定项目资源 |
|
|
项目范围规划完成 |
| 需求分析 |
明确需求分析范围 |
|
|
需求分析调研 |
|
|
起草初步的需求分析报告 |
|
|
项目组审阅需求分析报告 |
|
|
修改需求分析报告 |
|
|
客户认可需求分析报告 |
|
|
修改项目计划 |
|
|
项目组审阅项目计划 |
|
|
客户认可项目计划 |
|
|
分析工作完成 |
| 设计 |
制定功能规范 |
|
|
根据功能规范开发原型 |
|
|
审阅功能规范 |
|
|
根据反馈修改功能规范 |
|
|
设计工作完成 |
| 开发 |
审阅功能规范 |
|
|
确定模块化/分层设计参数 |
|
|
分派任务给开发人员 |
|
|
编写代码 |
|
|
开发人员测试(初步调试) |
|
|
开发工作完毕 |
| 测试 |
根据功能规范制定单元测试计划 |
|
|
根据功能规范制定整体测试计划 |
|
|
审阅模块化代码 |
|
|
测试组件模块是否符合产品规范 |
|
|
找出不符合产品规范的异常情况 |
|
|
修改代码 |
|
|
重新测试经过修改的代码 |
|
|
单元测试完成 |
|
|
测试模块集成情况 |
|
|
找出不符合规范的异常情况 |
|
|
修改代码 |
|
|
重新测试经过修改的代码 |
|
|
整体测试完成 |
| 培训 |
制定针对最终用户的培训规范 |
|
|
制定针对产品技术支持人员的培训规范 |
|
|
确定培训方法 |
|
|
编写培训材料 |
|
|
研究培训材料的可用性 |
|
|
对培训材料进行最后处理 |
|
|
制定培训机制 |
|
|
培训材料完成 |
| 文档 |
制定“帮助”规范 |
|
|
开发“帮助”系统 |
|
|
审阅“帮助”文档 |
|
|
根据反馈修改“帮助”文档 |
|
|
制定用户手册规范 |
|
|
编写用户手册 |
|
|
审阅所有的用户文档 |
|
|
根据反馈修改用户文档 |
|
|
文档完成 |
| 部署 |
确定最终部署策略 |
|
|
确定部署方法 |
|
|
获得部署所需资源 |
|
|
培训技术支持人员 |
|
|
部署软件 |
|
|
部署工作完成 |
| 总结 |
将经验教训记录存档 |
|
|
编写项目总结报告 |
|
|
建立软件维护小组 |
|
|
总结完成 |
项目结束之后，根据项目日志，可以生成下面的总结表：
| 项目日志分析表 |
|||
| 项目名称： |
|
项目编号： |
|
| 项目经理： |
|
日期： |
|
| 项目开始时间： |
|
项目结束时间： |
|
| 阶段 |
工作量 |
进展情况 |
|
| 项目范围规划 |
|
|
|
| 需求分析 |
|
|
|
| 设计 |
|
|
|
| 开发 |
|
|
|
| 测试 |
|
|
|
| 培训 |
|
|
|
| 文档 |
|
|
|
| 部署 |
|
|
|
| 总结 |
|
|
|
3、案例分析
本项目是要在一家电信运营企业构建远程智能诊断系统。具体的软件体系结构如下图所示：
项目计划
1、项目计划
在80天的时间里，用15人的资源，开发出一种能实现企业产品的远程智能诊断的系统；要求把采集来的产品数据实时可视化和进行诊断，并把数据存于数据库中以进行进一步更新规则库。
2、项目工作包分解
为了分发任务及进行管理，把项目按项目范围进行详细分解是必要的步骤。系统的WBS是信息沟通的共同基础，同时也是系统综合与控制的手段。远程智能诊断系统的WBS如下图所示。
1、项目的进度计划
在制定出系统的WBS之后，就可规划系统的进度安排了。远程智能诊断系统的进度计划如下表。
4、项目进度控制
在建立了项目基准计划之后，管理工作就是进行过程的监控，以确保一切按计划行事。本项目控制过程包括每7天收集一次项目绩效的资料，之后把世纪的绩效与计划绩效相比较，如果实际比计划差，则采取纠正措施，同时要缩短监控的时间间隔。如果实际进度滞后于基准计划，则要更改基准计划以确保计划是切实可行的，是最新的。同时把更新的计划反映到图示中。
5、项目总结
远程智能诊断系统的项目总结包括项目经理主持的评估会议、项目经理与部分项目成员的私人会议和确定技术培训事宜的活动三部分。会议讨论的成果全部备案，以资后用。
在这个项目中，项目开发人员应填写项目日志，项目日志如下：
| 项目日志 |
||||
| 项目名称： |
远程智能诊断系统 |
编号： |
2003-002 |
|
| 项目经理： |
XXX |
日期： |
2003年-7-26 |
|
| 项目阶段： |
开发 |
|||
| 进展情况： |
□按计划进行 □超前计划 □滞后计划 |
|||
| 工作量： |
32工时 |
|||
| 工作内容： |
调整html页面 |
|
||
| 编写后台类模块 |
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
| 客户需求 |
回复 |
|||
| 1 |
要求增加分析模块 |
1 |
需要改动设计，延后工期，不增加 |
|
| 2 |
要求界面修改 |
2 |
可以修改 |
|
| 3 |
|
3 |
|
|
| 4 |
|
4 |
|
|
| 5 |
|
5 |
|
|
| 问题： |
由于XXX离职，导致界面部分无人负责，应尽快增加人员，否则将延误工期。 |
|||
| 备注： |
|
|||
| 相关文档： |
|
|||
4、结论
综上所述，通过项目日志等手段可以有效降低项目风险，提高项目成功率。