我们公司为每一个新进来的员工指派了一个导师。这让我想起了原来听过的微软培训，现简单的归纳了几条，放上来供大家讨论。

１、首先微软的导师选择不是领导行政上指定的，而是学生选择导师。
    在这里微软强调的是：牛人才能成为导师。公司的人力资源系统有一模块会把导师的特长列出来，以及原来被选择为导师的次数，还有历界学生对其的评价。

    如果是新员工的话，基础的流程常识之类的有培训，具体到某一方面的技术的话，可以由你的上级指导你选择。

２、不是新人才能选择导师，当你换岗，换项目，反正对某个领域是新的时候，都可以选择导师

３、导师不会天天指导你，帮助你制定培训计划。因为导师的时间比你的时间宝贵的多

方法是：

　　　１）学习、提高等等的计划由你自己来完成。

　　　２）导师可以在邮件上花几分钟给你指导一下。

　　　３）导师可以在某个有空地时间找你谈谈（或你约导师），但多是你请导师吃饭的时候。这样饭也吃了，导师也当了。

４、（注意是大点）导师指导你，对他是有好处的......

　　　１）提高影响力（微软最注意的一点）　

　　　２）有了影响为，才有绩效吧。

　　　３）有了影响力，以后的新人才会选择你吧，以后的新人选择你的越多，多到你的档期安排不过来，这才更牛吧！

 

５、这对企业文化也有好处。

　　１）文化影响共享，比强制，指派更有效些。　

　　２）对新人、旧人都好，不会出现你有难，十方都会，但都不支援你的情况

　　３）不会出现研究成果，只保存在某个人的头脑里的情况。节省资源

    特别说明：这种考核对导师不考核。因为是他导的作用，不是师的作用。师的考核是看他被选择的次数，学生对他的评价。这更客观，真实。

　　一个非常出色的Issue跟踪系统，这里的Issue不单单是指BUG， 很多时候也可以是TASK， IMPROVEMENT， NEW FEATURE， 甚至是一个QUESTION。

　　在多年前， 我曾经尝试使用过那个经典的的Bugzilla，但是一个项目作下来，大家都反映那个东西的界面实在是太粗糙，简直无法忍受而且报表功能也是在太弱。最后大家就讨论自己作一个BUG的跟踪系统，就在大家已经完成了设计文档准备编码的时候， 我们发现JIRA原来就是我们要找的东西，而且比我们要的更多。它内置一个可以配置的工作流引擎(osworkflow)，一个快捷的全文检索功能(基予Apache Lucene).和一个可以配置的Dashboard(portlet)，以及一个和CVS连接的引擎，通过这个连接，在一个Issue中直接可以看到修改的文件名称，如果配置了viewcvs的话，还直接直接定位到行，根据一个问题可以跟踪到代码的行，这正式我们梦寐一求的功能。 也正是这种特性，才使我们能够把一个个Issue当作发布和版本管理的一个单元。

CVS

　　这个应该大家都知道。在系统开发过程中，一切的源代码和设计文档都应该进入版本管理系统来进行管理， 有的时候可能资源库可能会膨胀的很大， 但这个代价是值得的。

XPlanner

　　在整个管理体系中，进度管理一直是一个?比较薄弱的环节，我也曾试过dotproject这样的管理软件，但由于dotproject管理的太过详细，填报起来太复杂，大家渐渐都失去了填报的热情。这个 XPlanner软件可就简单多了。指定了迭代，story，然后就可以填写进度了。由于这个软件也是OpenSource的，所以如果觉得不满意，修改起来也很方便，现在老林就对这个系统作了些改进，可以直接和JIRA系统连接起来，JIRA中建立issue后，可以在XPlaner中反映出来，连填写 story的时间都省去了， 然后在下班之前可以生成一个详细的报告，列出每个人在这一天内在自己负责的Issue在上的处理时间和进度。

WIKI

　　在项目管理中，我们一直把它当作文档管理和Portlet系统来使用，它现在已经变成我们的小组的工作台，在WIKI中我们制定了包括系统开发设计规范在内的一切设计文档，以及数十个经常的HOWTO项目，例如如何配额一个标准的开发环境，如何使用CVS客户端，如何使用JIRA，以及自己的 JavaDoc， JSDoc等。 我们也可以通过Wiki来简单的整合系统，在Wiki中我们列出了所有开发环境和开发工具的入口，例如上面就放了进入JIRA，XPlanner以及我们各个Project的连接，甚至到 Apache中常用的Project的JavaDoc的连接，现在再也没有人去记录这些URL了，只要打开Wiki所有的资源都在面前了，并且由于wiki本身的开放性，所以每个团队的成员都是一个维护者，同时也是这个系统的受益者。在很多的团队中经常出现的情况是一个小子对某个技术特别在行，大家遇到这方面的问题都问他，在小的团队中， 面对面的交流通常是最快的交流方式，但是放到大的团队中，这个就不大可行了，那个小子迟早有一天会被问的烦到吐血为至，特别是他自己的工作也无法按时完工的时候。还是抽一个小时写出来，放到 wiki里面吧， 别问我， 自己去查Wiki。

基于ISSUE的发布管理

　　从版本管理的角度来考虑，最理想的发布方法就是把CVS中的代码拿下来， 打上一个tag， 编译并且测试一直到发布。 这样的管理方式的确是很简单的，但事实上用户可不买帐的， 用户觉得在新的版本中某个新的功能他还不想要，这可能是他还没有整理好业务初始数据或者在实际的业务流程上或人员上没有做好准备， 上帝说了不要咱就不能把这个新功能发布。在这个情况下，基于Issue的发布管理是一个好的方案。

　　这里讲的Issue就是前面JIRA系统中的一个issue。 通常每个Issue的完成都会伴随这一些代码的修改。 基于Issue的发布简单的来说就是把一组Issue变更的文件用patch的形式发布到正式的系统中。

　　基于Issue发布的前提就是要在Issue和Source之间建立连接， 使发布人员清楚的知道每个Issue修改的源代码是什么。我们实践下来最简单的办法就是在提交source的时候必须加上JIRA编号， 没有JIRA编号代码是不能提交的。 这样有以下好处：

1）防止一些没有经验的程序员无意义的提交， 比如一个小子今天提交了一个java文件，明天发现这个变量命名有点不爽， 修改后就要提交，在这种情况下， 这个提交是没有意义的，如果测试组已经测试这个Issue， 是否测试组要重新测试？ 为一个变量名称化这样的时间和冒险是可嫩的。小伙子还是在第一次提交的时候就把变量名想好了再提交。

2）程序员偷偷的修改代码，一个小伙子发现自己的已经Closed的Issue中有一个Bug， 便偷偷的修改代码。 这个当然也是不可能的，凡是提交到CVS中的代码就不是自己的了，那是大家的， 没有足够的理由想改当然没有那么容易。 先自己建立建立个Issue， 向Team leader报告， 然后再去修改代码.。

观目前使用的知识库，首先 仅仅按照服务地点来组合，就不是很科学的方法。文档的建立，并不是为了记录，而是为了查阅的方便。keso说过，GoogleNotebook目前失败在 于既不方便于存储也不方便提取。目前查询系统和分类界面都不是很令人满意。所以服务文档看似很多，但却很少有人去查询。
    较为科学的分类方式，借鉴当今比较火的web2.0的概念叫做tag（标签）,我们通过tag文档，作为日后搜索文档和查询文档的关键字。这个关键词可以 是服务地，也可以是问题类型等。这样，一个文档被贴上多个tag后存档。比如：A单位，网络，cisco。日后a单位网络出现问题 在查询的时候，输入a单位，网络 即可搜索到相关文档。或许就是相同的问题。比如我想了解关于cisco的问题，那么同样通过cisco tag，我们也可以了解到相关信息。当然，如何组织tag的定义分类 对于快速搜索是很有帮助的。

另一个就是版本控制。当一篇文档以标准的 格式完成的时候，我们把它加入到存档中。随着时间的增长，必然会产生新的问题或者对原有问题有了新的看法。还有新的工程师发现了问题。那么就要去修改。共 享文档自由修改虽然方便，但是版本控制就成问题。如何确保不被错改，误改？所以引入了“权威版本”的概念。比如一篇关于某系统的详细文档，经过管理人员审 订的初稿可以定为“权威版本”。日后如果发现问题或者有了新的解决需要更新，那么工程师可以立即去修改。但是这个修改并不影响到权威版本，当修改稿被广泛 接受或者经测试无误，则并入“权威版本”并相应的版本号进步。
    版本控制其实在office中已经实现，但是很少有人关注，并且其应用也受到一定的限制。并且由word组成文档组并不利于迅速的搜索，对于常见问题来说，建立长篇的大型word文档不是一个很棒的选择。

wiki系统自出生以来，就实现了协作、共享和查阅。所以基于这种特性，很是看好wiki在日后企业中的应用。不仅仅是实现项目和文档的管理，如果实现相应的权限控制，甚至可以实现组织和运作的管理。

通过网络的传播，不仅仅是在局域网中，在任何地方，工程师们都可以访问到OA中的文档，有效快捷的针对性查询。在家里，可以系统地看到其他项目组的有条理文档。

EA（Electronic Arts） 公司就在其内部实现了类wiki系统的组织管理和项目管理。