世界上最远的距离，肯定是标准规范与实际执行1

之前吐槽到哪了？记不清了，算了，从这里开始，参加了CMMI 3的复审后，组织了一个小队伍，吭哧吭哧干了几件事：

1. CMMI3规范的落地推进 

2. 公司内部用的项目管理系统

3. 定义组织级产品化规范

听起来高大上，辛辛苦苦干了半年，还没有一件事上了正轨，路漫漫其修远兮，天天挨叼。一个一个顺着说吧：

CMMI3规范的推进，真是千难万险，背景是公司小作坊形式的系统开发已经干了很多年，所幸技术口的高层领导始终坚持着同一开发平台，但问题在于真正干活的人都是野路子出身，要写代码，行，要浪费时间去搞什么需求调研，写什么概要设计，还不如先把系统做出来，等局方的指导意见，改起来更起劲。最后验收的时候，文档一气呵成，啧啧，效率多么高！

说点题外话，电子政务行业的规范性以及IT化整体水平确实比较低，因此在需求调研阶段，有的时候还真是啥都调研不出来，为毛？因为局方自己也不知道要干嘛！！！就此打住。

客户肯定是对的，但广大奋战在一线的项目经理也确实有不得已而为之的苦处，强行推规范，制度，时间长了，肯定还是要打回原形。因此思想教育的重要性就出来了，以德服人什么的最好了。抓紧时间读了一本叫《质量免费》的书，结合实际，总结了一下：

1. 搞IT项目，文档是非写不可的，区别在于是在推进过程中写还是验收前去赶，这是事实，无可辩驳。

2. 拿数据说话，不做计划，不做需求推一个项目的质量成本和按规范去做的质量成本去比较一下，谁的优势更明显。

3. 说服领导，设立一个颁发给项目组的年度品质奖，提升过程管理在劳苦大众中的美誉度。

很明显，这个思路是有阻碍的，拿数据说话，数据从哪来？当前项目管理过程的控制几乎只能从客户骂娘的投诉那里知道一些，其他的真的是两眼一抹黑。于是在这个背景下，还要同步的推一套项目管理工具，对上，提供一副老花镜，让各级领导能稍微清楚的看到项目的实际过程；对下，能够切实的提供项目推进的指导思路和实用工具，提升项目效能。

有个问题补充说明一下，为毛我这么肯定野路子的质量成本更高，因为我自己被坑过，就是前文提到的项目（需求狂变，人员狂变），当时用的redmine做任务跟踪，结项之后，我把工时登记按类型和里程碑做了一下统计，发现返工+测试+debug的时间竟然超过了60%，到后期快交付的时候，简直是惨绝人寰，没日没夜的改，完全没时间思考。而在原本应该做需求调研和系统设计的时间，我们卓（傻）有（不）成（拉）效（G）的出了一套后面几乎被推翻重构的所谓的系统原型。呵呵，呵呵。。。

哎，吐槽成瘾，下篇再说正事，差不多要去酒店开年会了，再聊。