德鲁克说:
“组织的成员作为个体，发展得越好，组织也会取得更多的成就。这一点正是今天所有经理人培训和资深经理人教育课程重点和背后的真谛所在。当组织严谨的作风和道德精神不断发展、组织的目标和处事能力不断提升时，组织内个体成员的发展空间也愈加广阔。”
借着写博客把关于软件开发中新人训练的想法总结一下，也希望抛砖引玉，得到大家的指正。
综合来说，一个软件工程师的培养需要涉及以下四个方面:
1. 产品专业开发领域 指的是产品开发过程涉及的专业技术。如操作系统、数据据等。这里不讨论这一项。
2. 通用软件开发技能 指的是诸如代码撰写、Debug、单元测试、系统分析之类，也包括思维拓展等。
3. 产品应用领域 指的是产品在哪个领域使用，如财务、电力系统、医院管理、企业管理等。
4. 职业素养领域 指的是对待工作的方式和方法，如时间管理、沟通技巧、职涯规划之类的。这里也不讨论这一项。
*关于思维拓展方面，也可以归到第四项目，但我更乐意视其为软件开发中的通用的技能之一。
在学校学习时，常常有老师在考前画画重点，或者被要求抓住思想就可以了，这让不少同学缺少些深入研究的习惯。学校的学习基本是有广度没深度。知识面广，对初入社会应聘也有好处，至少可以说我学过。但工作后，第一步要做的就是夯实基础，养成良好的开发习惯。工作后的技术提升，主要注重工作相关的专业技术的学习，比如关注Windows系统的API、MFC、数据库接口之类的。相比之下基本的软件开发技术能力很容易被忽视，好像总是够用了。公司定义好Coding Rule、单元测试以及文档的规范，员工也未必跟上。大家都知道在代码会使用几个APIs，就像你手上多了几个材料，要想建起大楼，还是要靠运用它们的能力，这就是基本功。我曾经过做过很多尝试，有系统培训的概念也是这两年才形成的。这里做一些总结。
第一阶段，上手期。新人一入职，好奇心强烈，也容易受到打击，很害怕被放在角落里自学。所以让员工熟悉开发环境和工作内容是最好的。先是明确员工的后面工作内容和期预留的学习时间，指好方向。最关键的是指定一个人来介绍现在的工作流程、相关的人员、并且简单过一下现有的代码，指导对开发环境的掌握等等。看似手把手的教没有什么必要，但这是让新入快速进入工作状态的重要一步。只要先了解到工作的流程和一些基本方法，剩下的就是丰富和完善这个过程了。在这个阶段要安排几次练习，以检验学习成果，同时也可以发现一些问题。在这个过程中，只要求知其然就可以了。
这样大概两三个月的时间就过去了。
第二阶段，快速成长期。
这时可以安排一些开发任务了，而系统的学习过程算是正式开始了。这个学习过程有两条主线: 产品专业开发领域和通用技能领域。对于前者，与工作联系密切，各个单位可能不一样，且不讨论。这里关注的是通用技能领域的训练，通过两个方面来展开：开发任务上的训练和读书计划(如果用培训计划来代替当然更好)。开发任务上，主管会Review工作过程和成果，在发现问题的时候加以指导，可以涉及很多方面，总之看到了问题，就要指导一下，说清楚问题在哪？更好的方案在哪？比如提醒一下，这段代码的写法可以参考一下<<代码大全>>第７章，那里有很好的建议。主管提出修改建议最好能有理有据，如果仅是依据以前的经验来判断，难以说服别人。主管也要不断学习才行。
另一方面就是读书了。开发任务上的指导再细，也无法代替读书，因为开发任务上的指导是分散的点，想要构成系统化的描述，书就要端出来了。在这个阶段读读<<程序员修练之道>>和<<代码大全>>(软件构建的部分)。虽然这两本书的中文名让人觉得肤浅，但内容确实非常精彩。我就让我们组人手一本<<代码大全>>。书光读也不行，还要讲出来，要分享，这样能加深理解。如果人多，交叉章节的学习分享就很好办了。也可以读读思维拓展的书，比如<<突破思维障碍>>和其它思维导图的书。不仅强调具体的开发技术，也要不断学习工作上的小方法论。思维训练的工作的价值非常之大，举例来说，经验与创新能力并不成正比，甚至经验与生产力也并不成正比，究其原因就是思维容易被固化。
大概在毕业一年的这段时间里，工程师能力会得到快速提升，需要特别关注。
第三阶段，成熟期。当工程师能够独立承担开发任务，开始表现出强烈的自信心，你对他的指导也越来越少了，这一切都显示他正在走向成熟。那再给他加把劲吧。安排一次面对面的详谈，涉及优势、劣势、职涯规划、兴趣爱好等等。这个时期开始对工作有些不满，比如工作的挑战啊，或者工作内容的转变之类，所以这段时间离职的可能性比较大。主管要认真加以分析，很多时候都有理想主义的影响因素，当然这些不是在这里探讨的内容。我们要关心的是在工作的第二年，我们能带给他什么收获? 所以在面谈过程可以收集到很多信息，在后期的工作安排可以适当安排些机会给工程师。在技术学习上，则依据他们个人的定位来选择:
如果想继续深入技术，可以读读<<重构>>，<<Effective C++>>, 也可以重新读读<<C++ Programming Language>>。
如果除了深入技术，还有兴趣系统设计，就可以读一下<<设计模式>>和一些UML类的书，<<大象>>是本不错的系统设计的书。
如果对软件工程比较有兴趣的，未来想做PM或Leader的，可以读一下<<软件需求>>,<<人件>>,<<日月神话>>,还有测试相关的书。
这里只谈较为通用的技术培养。至于产品相关专业开发领域的学习，可以做出类似的规划。我比较喜欢拉出一个技术架构树，也算是成长的一个愿景。
这个阶段一定要加入另一个训练类别，就是领域知识，不是专业开发领域，而是产品的应用领域。好多年前，我刚开始工作时，涉及到一些数据报表，就在客户的办公室里上了一课。第一次知道了原来数字靠左、文字靠右就是报表的基本要求。相较之下，我使用的Cystal Report有多么强大与之相比一文不值。这一课让我至今受益颇多，以至于后来我甚至准备考一个会计证。工作时，去学习一下产品应用领域的专业知识，一方面与客户沟通会更为 有效，最终把事情做对。如果在第一年就开始学习也不错，只要时间允许，不产生额外负担就行。Eric.Evans写了<<领域驱动设计>>很值得学习，同时“领域驱动开发”也很重要。乔布斯说:"米开朗基罗懂很多关于采石的知识，他不是只知道如何雕塑"。(引自<<乔布斯传>>,
P518)
这样大约两年坚持做下来，工程师的综合能力就会很扎实，你可以视他为正式的工作伙伴了。再往后的规划需要考虑更为广泛的范围，也会受制于公司的组织规划，我还没有能力系统的展开讨论，再学习吧。
作为一个工程师，发现周围没有什么可学的了，或者认为这全在自学了，就会导致人才的流失。为工程师规划好前几年的成长计划，对于培养人才梯队非常重要。比如精心做了三年的成长规划，多数的工程师就会做完三年。这三年就是软件工程师培养系统的价值。当然如果公司制度对于三年以后的职涯发展支持也比较到位，就会留下更多宝贵的人才资源。
我们需要的是开发工程师，不是程序员!
(图片来源:http://www.nirmal.com.np/home/the-difference-between-a-web-programmer-and-a-web-developer-nepal.html)