|
我们经常发现完成了体系,却由于一些问题,如体系与实际脱节,体系没有归纳很好的经验总结,体系没有得到高层认可等不能良好的执行,原因有主观的也有客观的,但在执行体系的同时,要尊重公司那些反对意见的人,因为提出反对的人一般都是有自己想法的人,这些人的想法可能促进了体系更加的完善,也更加的人性,也许这些看似无关的举动,却给体系推动带来极大的好处。当然如果你选择了合适的人才,制定了合适的体系,推动一般面临的阻力要小的多,如果你为了通过ISO或者CMMI或者为了达到尽快完善一套文档的目的得到一套过程体系,那这篇文章可能对你的作用会更大。
从点入手
我们也许都知道不要大而全的推动,要从点入手,但对于选取哪一点合适,从哪一点做起合适,每个公司不同,每个公司所拥有的业务和人员不同,可能也略有一些不同,但我在这里说的一些是大同的方法,因为这些方法,对于亟待规范的公司来说或者对于推行体系的来说,应该会起到一定的效果。选取点,不是项目立项,也不是项目验收,对于一个从无到刚有流程的公司来说,
第一点:配置管理
为什么从配置管理入手,因为公司首先要的是成果,是经验总结,经验从哪里来,一定是从已经留下的可以查阅的内容获得,如果一个人用脑子带着走了,那恐怕你想留也留不住,所以对于公司来说,成果是重要的,但是配置管理不仅仅是成果。配置管理还包括过程中成果如何存放,面对众多阶段、众多角色所产生的成果,如何管理才是体系配置管理水平的地方,好的配置管理库可以飞快的构建合适项目的配置管理库,并且让人快速寻找到相应的内容,不好的配置管理库找起来和windows目录没有什么区别,放的乱七八糟,以至于用了搜索。
所以,配置管理应该构建项目配置管理库框架,这个框架建在什么时间合适呢?也许有人在计划完成后才建立,但配置管理库越早越好,在项目前期已经存在了一些资料,而且这些资料通常不被重视(合同除外),没有版本、没有统一归档,经常容易丢失,所以应该在项目立项后立刻建立配置库,分配配置管理权限,让所有人知道应该放置在哪里。
这样看起来很小的工作,实际上节省了很大的沟通和寻找资料的时间,而提高效率往往也在这些微小的做法上。
配置框架建立了,配置权限设定了,那配置中需要产出哪些工作产品、哪些版本,这些都是来源于开发计划了。
第二点:开发计划
开发计划不同于项目计划,项目计划如果说是涵盖了风险、沟通、产品提交等计划的总和,那开发计划只是其中一项关键工作。开发计划制定的如何,体现了管理的水平,就像一个开发人员编制的开发计划也许只编制代码编写的计划,而需求调研人员则编制需求调研及需求评审的计划,测试人员编制测试计划一样,项目经理需要在开发计划中考虑
确定项目生成的工作产品
确定项目发布版本
确定提交给客户的工作产品
确定项目的监控方式
确定项目中采用的工具及版本
确定项目的质量目标(进度、bug等)
确定人员的任务、工期、人员的进入时间
确定是否需要召开外部理想会议
确定是否需要和客户确认哪些内容
确定项目过程中哪些流程可以不实施
确定是否需要进行质量监控
这也就是所谓的项目策划,一场战役决定于站前战术的运用,打响前就决定了成败,所以,项目策划的好坏,也决定了项目的成败。
开发计划是WBS的分解,对于分解到如何程度,如何细度,MSF也同样给出了一些指导,而综合这些指导,我在这里给出一个开发计划编制的一部分要求:
1)
开发计划中应该排定任务的优先级别;
2)
单个任务应该在一天到三天之内;
3)
开发计划中的任务应该采用尽可能清晰且有意义的名称;
4)
开发计划中应该考虑以下因素
有效资源、是否有第三方参与、是否对项目规范熟悉等;
5)
开发计划每个阶段应该尽可能留出缓冲时间;
6)
开发计划中选取了合适的里程碑点;
7)
所有项目范围内的任务均需要纳入开发计划,项目范围外的任务不要纳入开发计划;
8)
开发计划中应该明确体现出项目开发阶段的生命周期;
9)
任务能够被实际的估计;
10)
有成果或交付物;
11)
能够被完成,且不会有较大中断;
12)
可以被分配给一个人完成;
13)
能够把高风险活动分解为低风险活动;
14)
使用动宾短语来描述底层任务,如使用“进行××功能调研”,而不使用“××功能调研”;
包含三到五个层次,尽量不要超过五层;
当然还有更多的一些,在这里就不再多述。
有了计划,有了指导,许多工作也有了参照,开发计划编制的好坏,直接影响了项目的情况,因为我们可以从开发计划中获取大量的数据来数字化项目,这也就是数字化管理。
第三点:数字监控
数字监控,首先要了解project或者其他项目计划编制工具,project是很多开发人员或者项目经理喜欢用的,所以它们也喜欢了解project的用法,因为在很多人眼中这是技术,所以,一定要熟悉project的用法。
project可以提供什么数据呢?
工期
工时
实际工时
完成百分比
成本
实际成本
……
有了这些,挣值法也可以出来了,项目偏差多少人天也可以计算了,领导看到一定是觉得进步了。但是进步归进步,肯定项目还是发生问题存在风险。
第四点:项目风险控制
以前项目经理不喜欢识别风险,也不喜欢记录,现在发现问题了,自然而然要记录风险,控制风险,因为他们一定发现识别风险对于他们要求延期或者项目开发计划不能完成找到了借口或者理由,不管如何,风险总是得到了归纳和控制。
以上仅为部分经验,由于时间关系,本周提供内容截至以上。
上一篇:【40周】SQA或PPQA的职责与级别 下一篇:【42周】配置库结构 |
|