我的拍拍店铺
没有评论
2011年6月22日
我的拍拍店铺，大S代言日贝迩，请各位多多关照！
感触一下
没有评论
2011年1月12日
看了《开发与研发：领会编程魅力所在》这篇文章之后，感受颇深，特在此啰嗦一下。
做开发也就那么回事，以前总是把自己的工作当作事业来看，现在回过头来看，其实啥也不是，特别是这几年一直在反反复复的做同一款产品，正如文中那句话，“看上去好像工作了五年，其实是工作了一年，然后重复了四年”。而对于我，对此又有什么差别呢？
面对突袭而来的触动，让我感觉到这几年的发展，这几年的积累，实在是太少了，整天沉迷于技术，把之前一些创意一些想法，都让时间给磨灭了。总是觉得，产品的策划、产品的研究、产品的关注是产品经理要做的事，在这种牵强的理由下产生了一种惰性，慢慢的把自己与互联网的产品的诞生划在了各不相干的圈子中。
曾几何时，常常说等技术经验积累够了，就走出去放手一搏，而如今，面对永无止境的技术，越来越不知道什么叫足够？而时间却一天天流逝，是不是该适时的抛弃以前的概念，勇敢的走出去尝试呢？
何以解忧，唯有杜康！
其实，也未必只有杜康，还有知识，能让自己强大起来的知识。
是该重新拾起书本的时候了。
叨两句
没有评论
2010年11月15日
- 产品规则前期一定要调研，调研的结果必须是这一产品符合大多数人的需求，而不是少数人的需求。
- 产品经理的角色不能少，并且不能随便找个人来顶替，并且一定是要专职的人员。
- 开发阶段一定要速度快，并且要请到开发好手。
- 产品运营前期就一定要考虑好将来会遇到的瓶颈，并做好数据优化和服务器优化，一旦运营，要拐弯很难。别拿用户量上来了加服务器来搪塞，很有可能用户量上来，也没挣到钱，但产品还是要运营。
- 市场推广的过程中，遇到阻力不应该反复批评产品，而是想到如何来解决这个困局。
- 任何情况下都不要以抱怨的方式来讨论问题。
Lucene.net 2.9.1版与2.3版的搜索比较
没有评论
2010年10月22日
Lucene.net 2.9.1版与2.3版的搜索比较。
比如：你搜索一个关键词，需要检索并输出一百万条记录，按2.3的版本，它是用
Hits hits = searcher.Search(query);
这种模式下，它会把所有命中的结果都放到hits中存下来，如果有一千万，它就会提出来一千万，而你只取一百万的时候，需手动从hits变量中提取。一千万条数据一次提出来，那将是非常耗内存，再加上并发，系统一下就吃不消了，如果数据量小，倒可以承受。
而2.9.1版本之后，它采用的方式变了，search出来的结果中，只包括命中的Doc ID和Score，代码如下
TopDocs topDocs = searcher.Search(query, null, getTotals);
拿到topDocs之后，你只要按它里面的ID再去索引库中提取内容即可，
ScoreDoc[] scoreDoc = topDocs.scoreDocs;
List<string> cus = new List<string>();
for (int i = 0; i < topDocs.totalHits; i++)
{
int id = scoreDoc[i].doc;
Document doc = searcher.Doc(id);
cus.Add(doc.Get(”email”));
}
这样的好处是，不会把多余的数据提出来，按需提取，是一个很大的改进。
挖一口属于自己的井
13 条评论
2010年8月9日
有两个和尚分别住在相邻的两座山上的庙里。两山之间有一条溪，两个和尚每天都会在同一时间下山去溪边挑水。不知不觉已经过了五年。 突然有一天，左边这座山的和尚没有下山挑水，右边那座山的和尚心想：“他大概睡过头了。”便不以为然。哪知第二天，左边这座山的和尚，还是没有下山挑水，第三天也一样，直到过了一个月，右边那座山的和尚想：“我的朋友可能生病了。”于是他便爬上了左边这座山去探望他的老朋友。当他看到他的老友正在庙前打太极拳时。他十分好奇地问：“你已经一个月没有下山挑水了，难道你可以不喝水吗?”左边这座山的和尚指着一口井说：“这五年来，我每天做完功课后，都会抽空挖这口井。如今，终于让我挖出水，我就不必再下山挑水，我可以有更多时间练我喜欢的太极拳了。”
我们常常会忘记把握下班后的时间，挖一口属于自己的井，培养自己另一方面的实力。这样在未来当我们年纪大了，我们还依然会有水喝，而且还能喝得很悠闲。
驴生法则
没有评论
2010年7月21日
一头驴，掉到了一个很深很深的废弃的陷阱里。主人权衡一下，认为救它上来不划算，走了，只留下它孤零零的自己。每天，还有人往陷阱里面倒垃圾，驴很生气：自己真倒霉，掉到了陷阱里，主人不要他了，就连死也不让他死得舒服点，每天还有那么多垃圾扔在他旁边。
可是有一天，它的思维发生了转变，它决定改变它的人生态度（确切点说应该是驴生态度），它每天都把垃圾踩到自己的脚下，而不是被垃圾所淹没，并从垃圾中找些残羹来维持自己的体能。终于有一天，它重新回到了地面上。
不要抱怨你的不如意，不要抱怨你的男人穷你的女人丑，不要抱怨你没有一个好爸爸，不要抱怨你的工作差，工资少，不要抱怨你空怀一身绝技没人赏识你，现实有太多的不如意，就算生活给你的是垃圾，你同样能把垃圾踩在脚底下，登上世界之巅。这个世界只在乎你是否在到达了一定的高度，而不在乎你是踩在巨人的肩膀上上去的，还是踩在垃圾上上去的。而事实上，踩在垃圾上上去的人更值得尊重。
年轻，没有失败！看驴生豪迈，不过从头再来……人生不过如此，又有什么值得你去伤悲的事，你就当做踩在脚下的垃圾好了，让它成为你人生成功的垫脚石。
本文摘自网络
csharp-cassandra 接口Thrift源码
没有评论
2010年7月12日
有需要的朋友，请点击下载 csharp-cassandra.rar
压缩包中的内容是在ubuntu 10.0的版本下编译产生的项目文件。文件拿到后，一直没有去试用过，有兴趣的朋友可以试用一下，如有什么心得不妨传授一下。
旅行
没有评论
2010年5月31日
人生就像旅行，不能一直低着头走，容易失去方向，看不到终点
人生就像旅行，不能一直抬着头走，容易被脚下的石头所拌，翻了跟头
时而低头，时而抬头，才能更好的掌控好自己的旅行
(转)软件工程的诞生(二)
没有评论
2010年5月23日
5.2.7 从企业应用角度评论软件工程模型
企业在选择或制定软件工程模型时，不要太在乎学术上的“先进”与“落后”，正如有才华的人并不一定要出自名牌大学或拥有高学历那样。关键是看该模型能否有效地帮助企业顺利地开发出软件产品，并且要考虑员工们使用起来是否方便。简而言之，就是考察模型是否“好用”。
最早出现的软件工程模型是瀑布模型。它太理想化、太单纯，看起来已经落后于现代的软件开发模式。瀑布模型几乎被学术界抛弃，偶而被人提起，都属于被贬对象，未被留一丝惋惜。说它如何如何地差，为的是说明新模型是怎样怎样地好。
然而企业界不同于学术界，我认为瀑布模型对企业太有价值了，应当恢复它应有的名誉。几乎所有的开发模型都能够找到瀑布模型的影子，例如增量模型实质就是分段的瀑布模型。
让我们引用爱因斯坦的名言来指导软件开发：任何事物都应该尽可能地简洁。瀑布模型是如此的简洁，所有的软件开发人员天生就能学会（如果学不会，那他就别干软件这一行了）。所以瀑布模型非常适合于企业，请大家别轻易贬低它。
我在这里鼓吹瀑布模型的好处，并不是要让大家呆板地套用它。而是希望大家能深刻领会瀑布模型的思想，在实践中活用它。企业在开发产品时，应当根据产品的特征来确定开发模型。如果没有现成的模型和规范可以套用，那么就自己制定。我本人倡导“以瀑布模型为主线，局部采用并行迭代方式”的软件开发模型。
5.3 软件过程改进的概念
5.3.1 从“软件工程”走向“软件过程改进”
在二十世纪七、八十年代，软件工程的研究重点是需求分析、软件设计、编程、测试、维护等领域的方法、技术和工具，我们称之为传统软件工程。
现代的软件技术、软件工具要比几十年前好不知道多少倍，可是如今绝大多数软件项目依然面临着质量低下、进度延误、成本超支这些老问题。人们逐渐意识到，由于企业管理整个软件过程（包括开发过程、管理过程、支持过程等）的能力比较弱，常常导致项目处于混乱状态。
过程混乱使得新技术、新工具的优势难以体现，传统的软件工程不是不好，而是不够用。
提高软件过程能力的实践通称为软件过程改进（Software Process Improvement）。软件过程改进的最终目的是：提高软件质量、提高生产率并且降低开发成本。从二十世纪九十年代至今，软件过程改进成为软件工程学科的主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。
5.3.2 什么是过程？为什么要重视过程？
一、什么是过程
人们使用合适的方法、技术、工具才能开发出用户需要的产品。过程是指“人，方法，技术和工具”的集合，如图5-8所示。
过程被写成文档后，变成了企业的“流程制度”，人们依据“流程制度”开展工作，这叫“法治”。
图5-8 过程示意图
二、过程与产品有什么关系？
软件产品不能靠人们的意念瞬间完成，它需要比较长的开发过程。一般情况下，好的过程才可能得到好的产品，而差的过程会得到差的产品。
当然也有相反的情况，有些人在混乱的过程中创造了很好的产品，也有些人在严谨的过程中研发出商业上失败的产品。但这类现象不具有指导意义，本书不作讨论。
三、为什么要重视过程？
由于公司销售的是产品而非过程，人们常常只把眼光盯在产品上，而忘了过程的重要性。例如，领导对员工们下达命令时经常强调：“我不管你们怎么做，只要时间一到你们交付产品就行。”其实这是一句因果关系颠倒了的话，却在业界普遍存在。
下面的故事给出了警示：如果领导不关心员工怎么做（即做事的过程），往往会得到失望的结果。
公司领导对项目经理小王说：这个软件项目对公司和客户都很重要，你们要好好干，在6个月之内完成，要让客户满意。6个月后我来看你们的成果，为你们庆功。
每个月末，领导照例打电话问小王：“项目进展怎么样了？”
小王每次答曰：“挺好。”
6个月后，领导兴冲冲地问小王：“项目完成了吧，可以交付给客户了吧？”
小王说：“还有一点东西没有完成，再给我们一个月时间，肯定能够完成。”
7个月后，小王说：“出了一些小意外，我们正在解决之中，我保证下个月完成。”
8个月后，小王说：“我们正在修改某些功能，还需要一个月。”
9个月后，小王说：“我们正在完善某些功能，还需要一个月。”
领导和小王日益焦虑，……
12个月后，项目终于完成了。领导喜气洋洋地请客户来验收软件，大家都做好了庆功地准备。
客户看了软件后，大吃一惊：“这不是我们想要的东西！”
在12月里，公司和客户都不关心该项目的过程，都不知道软件是怎样开发的、不知道软件做成什么模样了，都等着看最后的结果。结果是，进度延误了6个月，终于开发完成了不符合客户需求的软件。项目团队疲惫不堪，公司和客户损失惨重。
所以，人们既要关注结果，又要重视过程。
5.3.3 什么是过程改进？为什么需要过程改进
过程改进（Process Improvement）是指：根据企业的现实情况和发展需求，优化流程制度，努力提升人们在过程中的工作能力，从而“提升产品质量、提升生产率并降低成本”。（注：这是作者对过程改进的定义）
“过程改进”本身就是一件消耗时间、精力和成本的事情，那么企业为什么要做“过程改进”？
答案是：过程改进是企业谋求进步的需要。
企业谋求进步离不开以下两点：（1）企业人士要不断学习新技术，开发新产品，开拓新业务领域。（2）企业人士要不断反省自己，总结经验教训，改正缺点、发挥优点。后者就是“过程改进”的体现。
过程改进体现了“自我反省、自我改进”的精神，不论对人生还是对企业而言，都是极为重要的。
1981年，美国卡内基梅隆大学软件工程研究所（SEI），应美国联邦政府的要求开发了一种用于评价软件承包商能力，并帮助其改善质量的方法。Watts Humphrey将成熟度框架带到了SEI并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，它提供了评估软件开发过程能力的一种标准。
1987年，基于Watts Humphery 等人的工作，SEI的Mark Pauk 等人建立了第一个CMM（Capability Maturity Model，能力成熟度模型），即软件CMM。1993年，SEI推出了CMM 1.1。
之后十几年来CMM的改进工作一直不断地进行着，相继有多个学科领域的CMM模型问世，如SE-CMM, SW-CMM, IPD-CMM等。美国国防采购与技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架，即CMMI（Capability Maturity Model Integration，能力成熟度模型集成）。
CMMI的基础源模型包括：软件CMM 2.0版本，EIA-731系统工程，以及IPD CMM (IPD)。2002年1月CMMI 1.1版本正式发布，立即被广泛采用。
2006年8月，面向开发的CMMI（CMMI-DEV 1.2）版本正式发布，如图5-9所示。为了适应更加广泛的应用，SEI计划今后发布另外二种模型，分别是面向服务的CMMI（CMMI-SVC 1.2）和面向采购的CMMI（CMMI-ACQ 1.2）。注：本书论述的CMMI是CMMI-DEV 1.2。
图5-9 CMMI 1.2的三种模型
5.4.2 CMMI的5个等级和22个过程域
CMMI将能力成熟度分为5个级别：初始级，已管理级，已定义级，量化管理级，优化级。
这5个成熟度等级为评价软件过程能力提供了一个有序的级别，如图5-10所示。同时也为软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。
图5-10 CMMI的5个成熟度等级
除了成熟度等级，CMMI还有一个重要的概念是过程域（Process Area）。过程域指出了达到某个成熟度等级必须要解决的一族问题。除了初始级以外，每个成熟度等级都有若干个过程域，如表5-1所示。由于成熟度等级是循序渐进的，如果想达到某个成熟度等级，例如CMMI 3级，除了满足CMMI 3级本身11过程域之外，还要满足CMMI 2级的7个过程域，依此类推。
|
CMMI等级
|
过程域中文名称
|
过程域英文名称
|
过程类型
|
|
第2级
已管理级
7个过程域 |
需求管理
|
Requirements Management
|
工程
|
|
项目规划
|
Project Planning
|
项目管理
|
|
|
项目监控
|
Project Monitoring and Control
|
项目管理
|
|
|
供应商协议管理
|
Supplier Agreement Management
|
项目管理
|
|
|
度量分析
|
Measurement and Analysis
|
支持
|
|
|
过程和产品质量保证
|
Process and Product Quality Assurance
|
支持
|
|
|
配置管理
|
Configuration Management
|
支持
|
|
|
第3级
已定义级 11个过程域 |
需求开发
|
Requirements Development
|
工程
|
|
技术方案
|
Technical Solution
|
工程
|
|
|
产品集成
|
Product Integration
|
工程
|
|
|
验证
|
Verification
|
工程
|
|
|
确认
|
Validation
|
工程
|
|
|
组织过程焦点
|
Organizational Process Focus
|
过程管理
|
|
|
组织过程定义
|
Organizational Process Definition
|
过程管理
|
|
|
组织培训
|
Organizational Training
|
过程管理
|
|
|
集成化项目管理
|
Integrated Project Management
|
项目管理
|
|
|
风险管理
|
Risk Management
|
项目管理
|
|
|
决策分析与解决方案
|
Decision Analysis and Resolution
|
支持
|
|
|
第4级
量化管理级
2个过程域 |
组织过程绩效
|
Organizational Process Performance
|
过程管理
|
|
定量项目管理
|
Quantitative Project Management
|
项目管理
|
|
|
第5级
优化级
2个过程域 |
组织革新与推广
|
Organizational Innovation and Deployment
|
过程管理
|
|
原因分析与解决方案
|
Causal Analysis and Resolution
|
支持
|
表5-1 CMMI的22个过程域
5.4.3 CMM/CMMI和软件过程改进有什么关系
从二十世纪九十年代至今，软件过程改进成为软件工程学科的主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。
CMM/CMMI是世界范围内用于衡量软件过程能力的标准。
人们往往搞不清楚“软件过程改进”和“CMMI等级评估”之间的关系，经常混为一谈。这里作个比喻来解释：
把“软件过程改进”比喻为“学英语，提高英语能力”，那么“CMMI等级评估”就好比是“英语等级考试”。一般情况下，英语等级考试的成绩反映了英语能力。但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至差到“哑巴英语”的程度。这种“特性”传染到软件领域，不少企业虽然通过了高级别的CMMI等级评估，但是其实际的软件过程能力却非常底下。
软件过程改进的真正目的是提高企业的软件过程能力，而不是为了达到CMMI高等级，切勿本末颠倒。
5.4.4 有了CMMI为什么还要研制软件过程规范
CMMI 1.2厚达560页，既然有了全世界认同的“CMMI宝典”，企业为什么还要研制自己的软件过程规范呢？
解答这个疑问，我们首先要搞清楚“CMMI是什么”以及“CMMI不是什么”。
CMMI是世界范围内用于衡量软件过程能力的标准，但是CMMI不是软件过程改进的执行标准，世上根本不存在适合所有企业的执行标准。
就如“英语四六级考试”是中国所有大学都认同的大学生英语能力的评估标准，但是“英语四六级考试指南”绝对不是“学好英语的执行标准”。
不能把“CMMI宝典”直接作为企业的软件过程规范，主要原因如下：
CMMI的560页文本论述了二十多个过程域和数百条实践，但是这些“过程域和实践”没有与“企业的具体业务和组织结构”衔接起来，所以没法直接使用。
有些企业死搬硬套CMMI，竟然按照CMMI文本逐个遍历CMMI的所有过程域和实践，这种方式非常迂腐可笑：如同给一个病人治病，不考虑病人需要吃什么药，却把药店里面的药逐个儿吃一遍，以为就能治好病。
5.4.5 如何应用CMMI？
既然不能全盘套用CMMI文本，那么究竟该如何应用CMMI？
应当根据企业的实际情况，既要裁剪CMMI过程域和实践，又要补充CMMI没有涉及的过程域和实践。
企业领导和软件过程改进工作者必须明白：企业需要吻合商业目标、容易执行的软件过程规范。
什么是裁剪？
裁剪不是指用剪刀把CMMI厚厚的书剪成薄薄的书，裁剪是要动脑筋的：要分析企业的业务特征，根据自身的人力和财力，选取CMMI文本中一些重要的东西，舍弃其它不重要的东西。至于什么是“重要的东西”，则要根据它对企业的贡献多少来衡量。
CMMI有560页厚了，为什么还要补充过程域和实践？
CMMI对于软件开发过程和项目管理过程的论述非常深入，但是却没有涉及“商务活动”，例如没有谈营销和服务等。
企业开发产品的最终目的是卖出产品，赚取利润。如果软件过程规范中不考虑商务活动的话，会导致开发团队“闭门造车”，很可能开发出“技术上很好的产品，但却是商业上失败的产品”。
5.5 软件过程改进的实施建议
5.5.1 过程改进的目的和基本措施
过程改进的目的是：优化流程制度，努力提升人们在过程中的工作能力，从而“提升产品质量、提升生产率并降低成本”。
基本措施：
（1）如果某个领域还没有流程制度，那么先要制定流程制度，防止流程制度缺失而产生隐患。
（2）对于已经存在的流程制度，要定期审查是否合适企业的实际情况，如果流程有缺陷，则要及时改进，要随着企业的发展而优化流程制度。
（3）有了合适的流程制度之后，要对员工们进行培训，让大家都知道流程制度并且遵循之。
（4）要不断地帮助员工们提升工作能力，如果能力不足，再好的流程也执行不好。
5.5.2 各级领导“亲身参与”而非“口头支持”
我曾多次看到这样的现象：咨询师给企业员工培训流程制度的时候，各级经理总有各种理由不参加培训。当真正在项目中推行新的流程制度的时候，各级经理自己却不懂，仍然按照他原先不合理的方式去管理，让下属不知所措。
各级经理的主要职责是“带领团队完成目标”，他们要“亲身参与”过程改进，才能深刻体会过程的要点，掌握相应的方法技能。“亲身参与”体现在：参与分析问题，商议对策；参与制定和自己工作相关的过程规范；参与评审；参加培训学习等等。
5.5.3 制定“合适”而非“大而全”的过程规范
大凡第一次从事过程改进的人员，他们总是希望制定“大而全”的流程制度，企图覆盖企业中的所有事务。
2000至2001年，我带领6名研究人员在上海贝尔公司一个软件事业部（约150人）从事过程改进工作，一年时间不知不觉写了长达千页的软件过程规范和相关指南。我花了九牛五虎之力去培训推广，最终还是没有用起来。
我们走了很大的弯路，反省后发现，缺乏经验只是一个原因，而“贪大求全”才是最大的失败原因。站在用户角度想想也是，那么厚的过程规范，人都看晕过去了，怎么能够地很好执行呢！
从2002年至今，我一直不断地创作、改进“集成化软件研发流程”（详见第6章），从最初冗长的1000多页精练到100页之内，才能够在IT企业中广泛应用。所以“合适”比“大而全”更重要。
5.5.4 不要迷信所谓的标准
CMM/CMMI、PMBOK、ISO9000等标准都是用来参考的，而不是用来“迷信”的。我发现当人们崇拜CMM/CMMI时，他的思想意识就不知不觉地被CMM/CMMI控制了，这是非常有害的。
2000年之后，国内软件业界兴起CMM/CMMI等级评估热潮。很多软件过程改进人员把CMM/CMMI当圣经看待，完全对照CMM/CMMI文本来操作，都不敢想一想是否合理。
其实软件企业即使不采用CMM/CMMI，也是有可能把软件研发做得很好的，例如Microsoft、Google并不采用CMMI，它们有自己的研发管理方法。互联网公司的软件研发人员最喜欢嘲笑“笨重”的CMMI，有例为证：
某互联网公司的领导夜里经常做恶梦，老梦见竞争对手超过自己。有一天，他梦见一个过了CMMI 5级的公司在做总动员，要和本公司竞争，于是他在梦中笑醒了。
企业采用业界推荐的标准时，要舍弃那些听起来很先进，但是对本企业无益处的东西，只选取对企业有实用价值的东西。
5.5.5 “引导推行”而非“强硬推行”
作者曾经询问某公司领导：“在推广流程制度的时候遇到阻力怎么办？”
该领导回答很干脆：“强制执行，不按流程执行者要处罚。”
这种答复“说得容易，做起来难”。在中国自古就存在“上有政策，下有对策”之说，在推行流程制度时，不仅要预防员工们应付了事，还要引导员工们正确地做事情。
举个例子说，计划生育是一项基本国策，它在实施之初遇到了强大的阻力。有一些人暴力对抗，很多人东躲西藏（形成了超生游击队）。怎么办？惩罚违抗者是一种不得已的措施。更好的方法是对全国人民进行教育宣传，例如农村的墙上到处都是“只生一个好”，这么多年下来，成绩斐然。如今计划生育已经深得民心了，很少发生对抗。
企业制定流程制度是为了帮助员工们把工作做得更好，而不是存心与人们过不去。企业要设法使员工们乐于执行，从而避免流于形式。
以下是作者总结的“引导推行”的建议：
一、解释流程制度
过程改进者不要只是埋头写流程制度，写完了上缴了事。最好在企业内部网上开辟一个专栏，专门解释流程制度。流程制度不是数学定理，可谓“智者见智，笨者见笨”。如果不对流程制度做解释，员工们就不理解“为什么”，如果不理解“为什么”怎么能够很好地执行呢？
不少公司都有名目繁多的规章制度，很多条款用了“必须”的语气。有些内容会损害不少人的利益，但为了顾全大局不得已这样做，如果不解释清楚原因，可能会招致本来可以避免的埋怨或对抗。
解释流程制度还会带来间接的好处：不合理之处会很快被发现（因为解释不通嘛）。
二、培训和考试
要对全员进行培训与考试，使企业中的每个人都熟悉与自己工作相关的过程规范。只有这样才能防止一些人拖后退，使团队发挥最大的力量。
企业里的各级经理往往派下属参加培训，而自己则以工作忙为理由回避培训。我曾经给一个软件事业部做了大力度的培训，几乎所有干活的人都参加培训和考试了（连行政秘书都没放过），但是漏掉了几个经理。结果“当兵的”至少都知道到哪里下载流程制度，知道讲些什么东西。但是那几个“当官的”却浑然不知，依旧我行我素，真是带头起破坏作用啊。所以说，领导亲自参与培训和考试要比口头支持有意义得多。
三、质量保证人员监督实施
人都有惰性，如果没有人来监督员工们按照流程制度办事，那么自觉性不强的员工就会回到“无序”的老路上。
CMMI把质量保证称为“过程与产品质量保证”。质量保证人员的主要职责就是周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的过程规范。
几乎所有的老百姓都明白基本的交通法规，可是明知故犯的人仍然不少，所以社会需要很多交通警察。质量保证人员的工作性质有点像交通警察。
5.5.6 写好必要的文档
企业应用CMM/CMMI之后，通常会要求开发团队写不少文档。据说CMM/CMMI等级和文档有这样的关系：
你们对所做的事情有文档记载吗？如果有，好，达到了CMM 2级。
你们对所做的事情的文档有文档记载吗？如果有，很好，达到了CMM 3级。
你们对所做的事情的文档的文档有文档记载吗？如果有，非常好，达到了CMM 4级。……
很多管理者有这样的感受，在推广流程制度时，员工们抱怨最多的就是“要写的文档太多了”！甚至很多人把进度延误归罪于写文档。
人们抱怨“文档太多了”，有两种原因：
一是过程规范的确很臃肿，规定了太多不必要的文档，如果是这种情况，那么应该精简过程规范，减少文档数量。
二是要求写的文档本身是合适的，但是人们以前写文档太少了，一下子不习惯写文档。现代人早晚各刷一次牙，我们觉得很正常。可是古代人不刷牙，如果你要求古代人早晚各刷一次牙，他们肯定觉得太麻烦了。
企业应该想办法降低写文档的难度，帮助员工们提高写文档的效率：
一要下功夫制定出良好的文档模板，给出充足的提示和示例。这样使用者就可以“依葫芦画瓢”，总比他自己琢磨怎样写要方便得多。
二要督促开发人员经常写文档，才会熟能生巧。