今天上班，武汉这两天可真尼玛冷啊，对了，大家新年好哇！
接着上次的聊，搞来搞去，主要就是搞了几个流程，先这么放着吧，有必要再细化说明一下。看起来比较简单，其实也实际走了十来个项目，被领导同事多次关怀，改过两版之后的成果，绑在这个流程上面的，有项目输出文档的关联（供QA审查），里程碑与评审记录（作为绩效数据），项目成员清单等等。
随手截的一张图，红线可以忽略。
好吧，项目的生命周期过程大概是有了，具体项目的推进还得是WBS的分解与执行，于是又有了一个任务执行的流程：
仔细想想，还差点什么东西？对了，是部门间的战役，总结起来，出战方有：品质部、测试部、研发部、交付部、市场部等等，简直是一个多国军旗啊，回头想想，一个不大的公司，有的时候扯皮拉筋的群发邮件真心能产生风暴。咋办呢？把各类问题梳理后按流程来走吧，实在不行的可以无限向上反映，直到老板板子打下来，大家就踏实了。
我说的玩笑话，其实真正需要流转的记录的就两大类：需求和缺陷（缺陷主要指的是测试缺陷），需求通常由客户经理、技术支持工程师、交付项目经理发起，由研发部门（含基础平台、产品）牵头搞定；测试缺陷通常是个内部的流程，为了满足CMMI3要求的啥单元测试、集成测试、系统测试、验收测试等等。这类流转信息，借用了当前比较流行的系统Jira/bug zilla等通用的几个状态（打开，关闭，重新打开，驳回等），再加上扯皮专用的状态（转发），凑在一起，就有了一个需求、缺陷的状态图，懒得贴图了，和UML的状态图大同小异。
好了，背景交代完毕，开始吐槽：
1. 过度管理的无奈
为了迎合管理层的需要，在任务流程中包括了工时登记的要求，于是一条一条的任务，谁谁干了多少个小时，哇，豁然开朗，领导打开部门工作饱和度统计，打开部门周报汇总，哎哟，不错噢。整体来看，大部分的任务发布和工时登记就是为了凑够每周40个小时的工作量，以至于下周领导看到报表的时候，各部门的饱和度大于等于1，实际呢？你懂的。
刚开始推行的时候，我甚至写过关于怎么写任务名称和工时汇报的培训文档，告诉大家怎么清晰的描述一个任务，还尼玛举例说明，什么是好的，什么是不好的，青春啊。。。在我看来，确实有点过度管理，事必躬亲，累死还不讨好。但，高大上的管理理论一时半会用不上，大家都是游击部队，若不能用一些固化甚至呆板的流程来规范大家的行为，公司也很难做大。就现在看来，两难。
期望在2014年，能够开始做流程优化的工作（前提：现有的流程能推行起来），所谓的进度规划，敏捷过程，里程碑评审都能逐步导入到公司的体系中（后面会专门说一下我自己瞎琢磨的CMMI3框架下的敏捷过程怎么搞）。
2. 组织的执行力为毛这么差？
从开始搞CMMI3复审开始，我就开始准备了一个公司级的SVN，里面专门用来共享OSSP相关的规程，指南，标准，以及培训材料。其间高层领导多次强调，深圳培训做了好几次，武汉这边培训做了好几次，群发邮件若干次，到现在竟然还有人跑来问我这个SVN的地址是多少，里面各种含辛茹苦写成的文档，总结那估计更是没人看过。。。已经一年了好吧。。。这里我真的有点灰心了，到底能不能行啊。。。我还指望今年能把整体项目管理理论水平都尼玛提升一下呢。。。
也许是我太着急了，就像我的女儿一样，才半岁，我天天围着她又是说话又是看卡片，她也没能开口骂我两句，让我滚犊子。。。咱公司目前大概也是这个情况，要走太空步，先能够站起来走两步再说。
最近老是在想，我该怎么把这摊事也用项目管理的方法管起来。。。就目前来看，尽管有领导撑腰，失败的可能性仍旧是大大的。
原文：http://blog.csdn.net/u011450909/article/details/18961411
