针对这个问题的见解，写了这么多，但是不知道是否适合这个MAIL LOOP，先发给你看看。
说法很尖锐，但是针对事情，不针对任何人：
问题：
1：部分组员对技术的热衷和敬业度和开发要求不符；
2：OAM Dev知识能力比较薄弱(部分组、人比较浅、知识面狭窄)；
3：当前人员对相关模块的较为深入了解的比较少(1～2个人)，风险～，离职了怎么办？
4：相关模块需要做为知识储备的并不是很了解；
分析：
1：思维的问题
当然，现在我们大部分同事的心态和思维是很积极的，有一少部分同事，失去了对技术的热衷，觉得现在掌握的
东西已经够在这些任务面前绰绰有余了（可持续性）；甚至找点机会可以走管理的或者什么其他的好的路子（科发展的）
或者认为，目前的的状况决定了，干多干少一个样子.....
其实，这些想法都是错误的，这种场合我不适合做太多的裹脚布似的分析，我仅仅说三点：
A:姑且认为，确实已经绰绰有余了（具体后面分析）。学无止境，你关注了我们整个OAM做的东西么？关注了整个NodeB做的东西么？
假如到这个地方你仍然是肯定的答案，恭喜你，你应该是个合格的工程师，但是一个优秀的工程师还应该关注到3G、4G，关注到
通讯行业变化和趋势。假如仅仅关注到了OAM，或者下面的某个Feature,我想，这么多年学可以算是白上了，那应该是一个程序员，
而不是一个工程师。最近发现 OAM 组Aohan同志在结合所做的东西，在学习SBBLINK，OAM其实这个就是很好的一个例子；这种情况
假如持续一年的话，我想他在OAM就应该是TOP几。
退一步说，那天咱南研倒闭了，我相信是那些工程师，那些优秀的工程师生存空间更大一些；
B:某君（我的一个朋友）从业电信行业10年有余，从华为的经理到夏新南研所总监，可谓一切很爽，没想到人家经济危机来了，大家要是
他觉得改怎么办？你觉得他现在的工作很好找？？？
C:当一天和尚要撞一天钟，并且要撞的准时，要撞的声音大，这个就是敬业。我们行业的圈子很小很小，那些当和尚不好好撞钟的人的
职业评价，很容易到你的新雇主那边去的。
为什么要化这么大的篇幅来强调思维为题，因为他是一个抽象的东西，很容易被人忽略的，而却是起到很重要的影响的一个部分，这个思维，在Team/项目中
叫风气，在企业中叫文化，在国家思想建设...., 去年Li chunting发起的职业化的讨论，实际上也是从这个方面开始的。
现代人来说，智商差异度很小，而影响结果的更多的也就是你的态度，你的习惯....
2：部分人知识结构的肤浅；
个人觉得，其实一个人、组最好的知识结构是有一个领域非常深入，而对整个全局有比较好的了解；
这个观点至少应该适合一个组，一个项目，甚至一个领域。针对一个组来说，最好的就是能够深入的掌握一个点，
比如ReProxy,这个掌握不仅仅是你知道他的流程，而是你必须针对该模块具有绝对的发言权，不然你就是不是这个模
块的专家，你就就该模块没有很好的了解和深入。
就该点来说，大家不妨列举一下各个模块的专家了，看看有多少个人，我个人比较武断，我想，包括CPRI Lib,Re Proxy,CoreOAM..，Til有一两个人都是多了，
（当然我也不是），不要说我要求高，起码的做为开发组的一员，每个人都应该对自己所负责的模块了如指掌，法国美国发现一个CR，你一考虑就应该知道问题
在那里，或者说问题有可能在那个地方。
而我们所列举的几个人，可能的只是比别人熟悉该模块，比别人多的是他看了一遍该模块的代码（注意，是看了一遍），我想，这种情况出现在测试组的话可以
理解，但是开发组的话，是我万万不能理解的，这里我就不和其他单位什么的比较了.所以我觉得这个问题应该是排在第二位的紧迫的问题；
3：知识结构的不够广：
我个人理解，这个广，应该是基于前面两个问题的基础上的：
你思维和态度不端正，去做好多的培训，就如同现在的小孩子上学，他不愿意学习，你非得逼他学习，我想效果不会好到哪里去。
你个人知识结构不深入，去做好多其他模块的学习和培训，就如同不误正业，假如不是我们管理层面安排的有问题的话，就要考虑这个努力的想学其他模块的GUY
是不是有跳槽的打算了
关于这些知识领域，在以上的邮件回复中已经列绝了很多很多，单纯就内容来说应该足够了，但是我必须提到的是，ECC，或者说系统BCS部分，常见故障查找等很底层
的相关东西，是能够对我们的CR定位非常有用的东西。
结论：
1：是否有一个职业化的讨论，也可以是一个合格工程师的讨论，优秀工程师的讨论，落实到行动，同时组内可以进行表扬和自我表扬相互结合，批评和自我批评结合；
大家一起找到每个人在工作上的优点，缺点，并且制定补救措施，从而给对技术追求热衷程度造成一种鼓励作用；并且要持续下去；
2：掌握并深化我们对自己OAM模块的理解和掌握，这里面仍然有很多工作要做；可以采用当前OWNER来组织学习，然后其他人，分别讲解的方法.....,BY THE WAY;
现在开发组，每个组内，没有对特定模块的OWNER也是一个很大的问题；
关于这个具体方面的执行方法，我想一定有好多更好的方法，比如TRACK表，交互培训了，学习后考核了....
3: 关于广度的解决方式，确实需要，但是我认为至少3个月内不是紧要问题，或者说还到不了这个层面上，这种广度的培训，和学习，效果是相当重要的，以往的做法是
完了，就完了；唯一作用是，哎，我碰到相关问题，我知道上次是那个谁来培训来着，所以可以找他来解决，晕~~~~