在瑞典的一段时间，和E公司专家一起工作交流，与我司在各个方面都非常重视流程有较大区别，E公司非常重视人的作用。人的问题为什么在E公司这里可以比较好的解决？我们是否可以学习到什么？
本文对照E公司的一些做事方法和经验中，总结了如下三点人员培养经验：
手把手面对面地进行知识性经验传递，解决从他人经验成长的问题
采用小循环快速反馈和减少不必要的工作要求，解决让每个人从自己经历中成长的问题
通过自动闭环机制和技术性解决问题，解决人的差异的问题
1， 手把手面对面地进行知识性经验传递，解决从他人经验成长的问题
我司特别喜欢总结经验，然后要求推广。LLM上有数以千计的案例，CMM的经验总结可以堆积如山。经验总结还有一种常见的喜好是固化。固化到模板，固化成CheckList。举一个例子：在TR2阶段，光TR2的CheckList检查项有180项左右，包括基本项、架构、性能、可靠性、可服务性等，每一个检查项可谓凝集了写作者的精华。每一次写作TR2文档前，都会对写的好的TR2文档范例进行宣讲。
照此道理，现在的TR2系统设计应该做的非常完美才对。事实上，恰恰相反，大部分文档的设计质量差强人意。大部分人都承认，我司的经验和CheckList并没有起到应有作用。
为什么固化的CheckList不能够起作用呢？在这些模板和CheckList中，大部分的条目，如果不是和有经验的人一起做事是无法理解为什么要这么做的。比如，CheckList项“新加功能要考虑是否可能将来也适用于各软交换产品，设计时要兼顾各个产品需求”，怎么样才叫实现了这个CheckList项？Marco要从Macro角度设计才符合这样的要求，消息流程要从消息流程的角度设计才能够满足这样的要求，具体情况仍需要具体分析。这条CheckList项出发点是好的，但是不知道如何实际应用，在设计的时候，绝大部分设计人员就只能按自己的理解进行设计了，不理睬CheckList。
还有个比较有名的问题单修改说明模板，一个问题单也许修改验证只需要20分钟，但是这个模板填写可以多达1～2个小时。这个问题单修改说明模板，到底有多大的效果呢。我曾经有连续两个月左右，每天检查5～6张问题单，每次都发现有人部分CheckList项没有填写，或者单元测试略过不做，或者模板要求的测试用例不填写。至于CheckList打上YES的，有的直接从上一个文档中继承的，很明显的CheckList问题应该检查到的，也没有检查出来。这个模板的效果很难说有多好。
不知道从什么时候开始，在研发的各个阶段，我们开始把希望寄托在CheckList和模板上，以为CheckList和模板制订了，经验也就固化了，经验传递也就能够大功告成了。但令人沮丧的是，实际观察，经验的有效传递并不明显。
在E公司，如何扩散经验呢。E公司的经验扩散一般不是通过写总结文档、写成CheckList，而是直接把会做这种工作的人分散到没有经验的小组中去，由这个有经验的人带着其他人直接一起做事情来传递经验和知识。所以E公司系统设计人员，不会在TR2之后把文档交给开发人员，由开发人员去做，而是直接加入到实现小组，作为实现小组一员全程参与，来确保设计的准确理解。
反过头来，仔细思考，我们用CheckList可能用错了地方。对于事务性的过程可以用CheckList来做，但是对于知识性的范畴，用CheckList是没有办法解决的。为什么这么说呢，因为事务性的事情，比如到机要处借便携，要做哪几件事情，是一清二楚的，做了就打勾，CheckList在检查完备性上是没有问题的。但是对于知识性领域，检查完备性的作用就很难达到，比如说设计，今天设计设备管理，明天设计升级，设计内容是不断变化的，针对知识性领域的CheckList要不因为要求普遍适用变成了抽象的概念而无所判断，要不就没有办法定义完整的CheckList项，因为内容是不断变化的。模板针对知识性也是和CheckList有这方面的不足。
所以模板和CheckList针对易变的知识性领域，我们需要传递的是制订模板和CheckList背后的经验，而不是模板和CheckList本身，模板和CheckList本身很难担负起经验传递的功能。知识性的经验存在人的头脑中，总结成普适性抽象概念原则后，每个人的理解又很难达到一致。这也就是为什么我们一个项目做的很好经验总结成CheckList、规则、模板之后，到了另外一个项目无法实施的很好的原因。最好的办法，其实就是把做个这些事情的人，分散到需要扩散经验的团队中去。在CGP迭代实践中，虽然团队的成员技能情况Dangerous，Jack希望有经验的人和他们一起工作，但是还是相信我们通过这种Team Working方式能够做好事情，事实上也的确有用（见下文）。
其实理解起来也很简单，我们成长最快的时候是什么时候，是新员工的时候，老员工带着新员工，面对面手把手一起工作，新员工很快就学会了老员工的该怎么样做事的技能。但是一个员工度过新员工阶段之后，往往就要求独立工作，这样设计等等一系列的技能成长起来反而很慢了。
另外特别要提的一点是，从错误中手把手帮助没有经验的人学习，也是一个非常好的途径。自己没有发现错误，别人帮你发现错误，如果能够学会别人的这个能力，这就是一个非常好的经验传递途径。
我在瑞典曾经发了一个纪要给Jack，让Jack审核是否有问题。Jack看了以后，知道有些地方写错了。Jack不是直接反馈检视意见，而是直接跟我说，我们明天一起讨论一下这个纪要。然后第二天，大家一起讨论，顺便又交流了新的东西，原来纪要中理解错误的东西，通过讨论也搞清楚了。这么一个小小的事情，令我相当感慨，原来他们这么重视经验和知识的传递，重视手把手/面对面的交流沟通来达到问题的彻底解决，人员的成长。
我司目前开发测试一线的习惯大都是发出检视，每个人用模板化的工具反馈检视意见，然后作者修改。偶尔作者会对自己认为需要讨论的问题进行讨论，一般情况下，缺陷数达到目标了（因为我们的过程非常重视数字化的质量目标），几乎没有人再想起这些缺陷为什么会形成，能从这些缺陷中怎样辅助人员的成长。
比如DRB评审，DRB评审提了很多的问题，我所知道的是，我们这些经验丰富的专家要求我们经验少的设计人员解决DRB提出的问题，但是并没有和设计经验少的人员一起面对面手把手地一起分析原因、改进设计、一起解决问题，提高一线设计人员的经验。
这样，多少人经过了多少设计、多少编码、犯过了多少错误，即使是同一个人，再做同样的工作，犯的错误还是很多，我们的经验没有得到有效的传递。我们老以为安排一个人做了一种类型的工作，他（她）的能力就会得到提升，但是我们很少把工作中犯过的错误看作是帮助没有经验的人提升的机会。
这个现象，归结到我们的现实就是，我们现在有大量有经历的人，但是缺乏有经验的人，只能老是感慨组织能力在下降，一代不如一代。一个人做过3次系统设计，不帮助他成长，系统设计的能力还和第一次做系统设计一样，这个就是有经历没有经验。
对于象我们这样的知识型工作领域，传递经验最好的途径是有经验的人和没有经验的人一起工作（Team Working），面对面手把手传递经验。
2， 采用小循环快速反馈和减少不必要的工作要求，解决让每个人从自己经历中成长的问题
相当多的时候，可以听到一种抱怨，恨铁不成钢的一种抱怨，就是做不到位，而且在很多场合都听到过这样的抱怨。我们之所以制订出很多非常非常详尽的规定/要求，有的时候就是因为做不到位，然后不断增加要求，不断把规定要求拔高的一种解决方法。
典型的例子，因为开发质量做的不好，TR4发布给测试的版本质量老是做不到位，所以我们采取的办法，就是在转测试前要制订了各种各样的要求和活动，然后要求开发必须在TR4前达到这些要求做了这些活动才接受版本。每次TR4反复审视，反复强调，并更加严格要求，但是每次出TR4版本感觉质量没有非常明显的改善。
平台版本以前一直是和产品同步开发的，但是产品发现，平台的版本质量好像不够好，经常会导致产品联调开始几乎都是加载配置问题，于是制订了相当严格的要求，要求平台必须通过TR5的版本来配套产品TR4版本，再次一点也要达到TR4A，如果和产品同时提供TR4版本，产品几乎会以不可退却的姿态表明这种要求的偏爱：绝不接受。在这种要求下，平台必须在产品TR1和TR2甚至TR2之后仍然接受产品分配过来的需求，但是却要提前交付。我们人没有质和量的变化，却要在更短时间达到更多更高要求，大家每次都拼一把，博一把，多年来版本质量还是没有明显的稳步上升规律。
去年实施过程框架，开始对过程框架每一步不断改进做到位的想法非常认可，也认为我们做的不好，其实就是没有找准每个阶段的问题，没有不断改进，达到要求所致。也就是：如果我们做不好，一定是某一个阶段没有做到位的原因。在R002C01和R002C02的设计阶段，我们都按照过程框架要求，对TR1和TR2的设计务必达到内部接口和外部接口都准确定义到BIT级的要求。但是，坦白的说，我们TR2阶段能够做到内外接口BIT位的准确定义，那是相当的难，几乎就没有人能做到了。按道理，从R002C01到R002C02，做了一次再做第二次设计的人，应该会好一些，实际上这个做到位的情况还是没有多大改观。
还有一个做不到位的情况，相当的普遍，是量化考评。我这里说的量化考评指的是开发人员和测试人员，不是PL/PM及之上的一类人。做过量化考评的人，都发现对于一线基层开发人员，要不是量化的结果分不出真正干的好干的坏的，要不就是大家这个季度什么量化就做什么，没有量化的工作就慢慢被人忽略掉了，要不最后评价结果还是主观来评价。这是相当头痛的一个问题，看过很多量化考评说取得好的效果的，但是很少看到有人说他的团队坚持多少年量化考评，也没有看到团队能力因为做了量化考评变得更强了。我们现在仍然看到不断有团队宣称采用量化考评如何如何，可能纬度正在变得越来越庞大，一个开发人员的PBC可以多达20条，甚至更多，形形色色的加分减分项可以长长的排下去。
现在，这些方方面面的做不到位的情况怎么解决？是不是继续强化，坚持不断提高要求来解决？
想想这些问题，有的时候觉得我们真是处于相当矛盾之中：你的人没有任何改变，还是那样的一些人，做事的方式还是那样的做事方式，为什么通过仅仅提高要求，我们的工作就可以做的更好了呢？
我们为什么不检查一下我们的工作要求，评价一下，有多少其实没有太多价值的，做与不做都差不多，能不能砍掉这些工作要求，留出更多的时间让每个人能够做好事情？能不能想一想如果做了一直都没有更好的效果，是不是做不到位的问题，还是我们这种解决方法就不对了？ 更进一步，什么样的工作有没有用，什么样的工作有没有效果，能否通过更快的小循环闭环来检验结果，促使自己下一次做的更好？
比如：我们对于开发人员测试人员的量化考评，是否有效？我们是知识性的工作者，知识性的东西怎么可以通过数量来衡量？我们都知道，开发了1000行代码未必比开发100行的人厉害，工作12个小时一人天的人未必输出结果比工作8个小时的人好。对于一个20人，100人组成的团队管理者，他的统计数据反映组织能力，对于个体，数据能反映什么呢。在E公司，倾向于依靠各级管理者直接从项目过程任务完成的质量来给出对下属员工的评价，没有量化的PBC作为评价的参考依据。所以，对于开发人员测试人员的量化考评，有没有想过做和不做是否都一样的效果，是否可以停止这种工作方式来节省大量的统计表格、计算分数的工作量？
为什么转测试的标准这么难达到，是否不断的强力执行标准就可以做的更好？未必，从CGP的迭代1来看，实施Jack推荐的方法，系统设计人员和测试人员、开发人员在开发时候始终在一个团队，大家一起讨论如何设计如何测试，每天都尽可能完成一部分功能，合入一部分功能，测试一部分功能。通过快速反馈，可以提前发现问题。结果迭代1能够81％的问题在迭代测试中发现，到SDV的时候，两周的迭代，只要3天就完成了，缺陷只有整体缺陷的19％。迭代1的开发人员技能状况也并不比别的开发要好（配置Team中系统设计人员熟悉配置管理、但是对模板和LMT Server不熟悉。2个开发人员对这些模块都不熟悉，代码以前没有看过，要开发的时候才开始学习。相应测试人员在配置部分的测试工作了半年，经验很少。5个Team，3个差不多的情况），每天的小循环活动，使得发现问题的周期变短了，同样的人能产生不同的结果，做不到位的问题通过小循环迭代却可以解决。
我们很担心这样的团队，Jack也觉得dangerous，但是还是相信我们，通过Team Working和自己能够在快速小循环中通过发现问题和解决问题中成长起来，做得更好。人员最好成长的过程是经过失败后马上能改进并加以应用，获得成功，学得才最快，而CMM项目即使在项目末进行总结，经验不能马上被利用，人员从自己和他人的经验中成长的过程就慢。
Jack本身就是一个非常重视小循环反馈的人，每次和我们交流完毕，总要当天就问我们有什么Feedback，他好做的更好。Jack介绍的1/3检视（工作进行到1/3时间就进行一次检视）也是快速反馈自己的工作是否做的很好的一种小循环。
再比如说，系统设计，我们是一下很难达到定义到BIT级别非常准确，但是如果我们立即进入迭代循环，快速通过2周的开发测试验证设计接口的好坏，不好也可以得到解决，而不是在TR2勉强定义了个接口或者不定义接口，要等到2～3个月以后才发现问题了。在快速迭代中，如果设计人员不定义接口，开发过程马上就要用到，这样不需要苦口婆心强制不停检查BIT级别的要求，马上就会有下游去找设计人员讨论解决这个问题。
为什么产品担心平台提供接口不对，平台质量不好，就是因为，长长的几个月IPD-SE CMM过程，不知道你平台的到底是好还是不好，等到最后一刻才能揭晓结果。如果每一周都能够产品和平台一起联编出版本验证，即使有一点做不到位，影响也可以减小到一周半周来解决，而不是数个月才发现有问题。短期内的做不到位，使用小循环迭代快速反馈，至少不会导致长期的做不到位。
小循环的快速反馈，就是承认我们可能不能一下子做到位，但是我可以在尽可能短的时间发现自己工作上的不足，而通过改进来使得自己做到位了，因而进步更加频繁。
有些做不到位的工作要求，做了和不做效果都是一样的，我们为什么不能减少这种不必要的工作要求。有些做不到位的工作要求，通过划分工作为一系列的小循环工作，在自己的小循环中看到结果，即使能力有限，也可以尽可能早地发现自己的做不到位，并立即在下一个小循环中改进，解决做不到位的问题就好办多了。
我们要承认一个比较普偏的现象，大部分人是从自己的错误中学习成长的，而减少不必要的工作就是让人有更多时间从自己的工作中改进，把工作做的更好。小循环快速反馈和减少不必要的工作要求是一个比较好的方式。
3， 通过自动闭环机制和技术性解决问题，解决人的差异的问题
在瑞研所有一个节能措施，让我非常印象深刻。说起来这还真是一个非常简单的事情。在瑞研所办公室加班到晚上10:00以后，照明的灯会自动关闭，这个时候必须再按一下开关，灯才会亮起来。过1个小时（记得不准），灯又自动关闭了。如果继续加班，必须再次按一下。
有一个环保措施，也让我印象非常深刻。去超市买水，如果标价是10块的水，要收11块钱，其中1块钱明确告诉你是买瓶子的钱。在超市，同时有一个自动回收瓶子的机器，把1个空瓶子塞回去，就会退回1块钱给你。我在超市看到一个大胖子，把上百个空罐头空瓶子塞到自动回收的机器，塞的不亦乐乎。后面还有三四个人等着排队。环保能够做到这样自动自发，真是相当令人感慨！
以上两个小小的事情，想一想，每次都让人回味无穷。在我司，随手关灯的标语到处贴着，甚至警告关显示器的标语比比皆是，有时甚至把随手关灯上升到视为美德的程度，但是晚上我们还是可以看到空荡荡的办公室灯火通明。对于环保节能，我们国家口号和标语比任何地方都多，但是我们也知道，我们的天空是灰蒙蒙的，我们山河大地都变了颜色。
这种反差更加让人思考：自动闭环机制和技术性解决问题比口号/要求/规定要实际的多，这些方法能够实实在在地一劳永逸的解决问题，而不必要埋怨人的差异性，特别是上升到素质的高度。
我记得以前有一个存储过程CheckList，是一个接进上百项的CheckList。到后来，它的用处有的是时候也沦落到装点门面的象征了：大部分写存储过程还是按自己的经验写。后来化4个小时做了个简单的检查是否会引起前后台CRC校验不一致的检查工具，存储过程引起的问题，就可以通过技术解决问题，比起苦口婆心要求不同的人使用CheckList检查解决彻底的多。
我们现在有这么多的规定和要求、口号，能不能把它都变成不需要考虑人的差异的问题解决方法：比如工具化、自动化？
比如说需求跟踪，为什么不能够从OR-DR-AR等都通过Word模板中的宏，自动化按规则生成，自动进行关系跟踪。我们现在经常要化大量时间在这个上面，而且老是遗漏、编号错误等等，设计人员怕麻烦、版本经理也麻烦。
又比如我们现在这么多的测试环境，可是我们到现在还没有一个很好的自动化环境管理工具，最大化地利用环境、节省安装环境调测时间。在E公司，一个人修改合入代码后，可以登录网页，选择自己修改的部分，然后让自动化环境管理系统自动下载代码、自动化编译、链接、打包、选择空闲环境自动安装、自动化测试，最后还能够以邮件通知结果。这些都通过技术来屏蔽不同人的技能差异。
我们现在有很多事情如果能够设计回收瓶子这样一个自动化的闭环机制（加上技术支撑），每个人都乐于做好这个事情就好了。
我们很多的规定和要求/口号，包括固化经验，要尽可能地落到实处，比较好的解决办法是：要么设计自动化的闭环机制，使得每个人自己乐于作为自己的事情解决；要么用简单实用的技术性来解决，比如工具化自动化：这两种措施都能够比较好地屏蔽掉人的差异性。
4， 三点感想的总结
人的成长来自于自我学习和从他人经验学习。总结起来，对照友商的一些经验，人的培养可以从如下几方面着手：
ü 手把手面对面地进行知识性经验传递，解决从他人经验成长的问题
ü 采用小循环快速反馈和减少不必要的工作要求，解决让每个人从自己经历中成长的问题
ü 通过自动闭环机制和技术性解决问题，解决人的差异的问题
