培训新员工的更好方法[关闭]


10

我目前所在的团队拥有相当高的营业额,成员通常移至同一公司的不同项目。当前,我们对新成员的“培训”是将他们与主要联系人(通常是完成培训的最新人员)配对,后者将为他们提供动手实践经验,并将询问更多的高级开发人员,如果新聘的员工向导师咨询不知道 它为新员工提供了快速参与的机会,并向指导者提出挑战,以提高他/她对系统的理解。

但是,正如您可以想象的那样,这种培训方式非常耗时,并且不能提供很好的知识传递(误解不断扩大,差距不断扩大)。

我的任务是为未来的新员工生成文档和培训材料。我已经偶尔进行过技术写作,但这是针对最终用户的,它具有很多截屏,非常具体,并且花费大量时间来完成。

为新员工创建新文档被认为是低优先级的,我目前只有大约40个小时的工作时间。以我目前编写技术文档的方式来记录系统,几乎不会在40小时内刮擦表面。特别是考虑到我不仅必须记录有关代码库的内容,还要记录有关部署和支持的内容。

如何快速编写文档以使新员工尽快更新,而又不花费大量时间编写文档?

附加信息:
目前,我们既有Wiki,也有一些培训文档,但是两者都很少。


2
关于软件开发如何?听起来您需要教学顾问,而不是程序员。
独眼巨人

4
如果文档不是软件开发的一部分,注释是否不是源代码的一部分?
Malfist 2012年

编写解释代码工作原理的文本无疑是软件开发的一部分。“为新员工生成文档和培训材料” 不是软件开发的一部分,程序员的技能不太适合。培训特定于编程的新员工也不是问题-您的问题完全是通用的。
独眼巨人

Answers:


17

好问题。很少对程序员进行在职培训,也很少经常谈论它。

我见过的一些想法很有效:

  • 在您的Wiki中,有一个新员工的升级文档(您正在编写的文档)。在该文档中,描述新员工将在前1-2周内执行的任务。在我工作的地方,从一开始就需要了解很多负载,从内部软件/工具到流程,再到特定类型信息的位置,都需要了解。编辑>我们有“按顺序安装x,y,z”等说明,并带有用于配置等的屏幕快照。因此,使用Win Server,SQL Server,SharePoint,BizTalk配置系统或服务器场(VM),我们的软件并不像它那么简单声音。这适用于我们支持的那些应用程序的其他版本。
  • 实践问题。我在哪里,我们有一款产品公开了很大的API。因此,像我们的客户/客户一样,仔细阅读自己的产品文档以编写(预定)扩展对我们总是有益的。因此,如果您将数学库作为产品API的一部分,则存在一个实践问题,即“使用我们的API编写计算器”或类似的东西。
  • 导师很好。留着它们。我们也在这里做到这一点,不仅是结识新朋友/结交朋友的好方法,而且作为学习的来源,它们是无价的。我建议不要让它成为最新的完成培训的人员,因为他们没有别人可能拥有的公司知识历史。让每个人轮流做。
  • 我们每周(大约)进行演讲/技术讲座。让新员工从您的产品中挑选(或分配)某些东西,并在第3周后做一个介绍。确保他们知道有错误的余地,如果他们在演示文稿中有任何错误,团队可以纠正它们。
  • 新员工在开始工作时就进行文档编制工作。它迫使他们阅读它。

正如Dan McGrath所指出的那样,鼓励新员工也为他们改进Wiki是一个好主意。


2
+1。(imho)最好补充一下,新员工还应该改善Wiki /文档,因为他们遇到了缺少或不足的东西。这可以帮助您改善入职资源,同时最大程度地减少经验最丰富的员工所花费的时间。我发现它也有助于巩固新员工的理解。
丹·麦克格拉斯

除了最后一个关于使新员工从事文档工作外,我们在工作中的所有优点和事情。与此相关的几个问题:a)有点过于琐碎。b)可能包含产品行话。c)如果他们是新手,他们将如何知道这是否正确?
Burhan Ali

2

首先,我建议您不必使新员工培训文档变得像为客户编写的文档那样详尽。它需要足够的技术来使新开发人员能够用作指南,但又不能太详尽以至于它概述了所有小事情。毕竟,如果他们有问题,他们将能够与团队交谈。

新员工对您的团队有用的十件事是什么?专心做这些事情。使它们成为您的命中清单,以便新开发人员有足够的工作要做,并有足够的信息来保持他们的发展。如果清单上有太多东西,问问自己是否会在头两三个星期内这样做。如果他们这次不会做某事,那么也许不应该在登机指南中。

对于指南的每个部分,请确保在顶部突出显示一个go-to人员。这样,如果新员工有任何疑问,他们就会知道该向谁寻求帮助。另外,请确保一个团队成员不是太多部门的首选人。如果他们不是导师,那么您不想花一个人的时间解决新员工的问题。

不要花整整一周的时间在这份文件上。在让至少一名新员工经历之后,请给自己一些时间进行调整。看看什么有效,什么无效,然后修复。


〜40来自我尽早完成其他项目,所以一旦我用尽了最初的40个小时,这并不意味着以后没有更多的时间。
Malfist 2012年

1
@Malfist-足够公平。但是,如果您没有时间,并且优先级较低,那么在进行项目工作时最好出一份初稿进行测试运行。采取迭代的方法进行处理,以确保获得更多反馈。如果您选择了10样东西,而新员工说“实际上,我确实没有使用过第4节,但是关于____的部分就很好了”,您就会知道如何改进和更新该文档,从而对下一个文档更加有用人。
Tyanna 2012年

2

最近,我在工作地点开始编写类似的文档,但时间紧迫。我很同情,就像我一开始所做的那样,很想在非常详细的级别上编写它很容易,但是实际上可能适得其反。

如果新人开始担任某个角色,那么他们可能会在头几周内被大量信息淹没。对他们的最初培训是对已经在公司工作了多年的开发人员的不满,在我看来,这将使某人在担任该职位的头几个月甚至一年中需要了解的东西变得非常复杂。保持较高的水平,尝试使用标准的术语和概念,然后使用公司流程中的详细信息对其进行扩展。

对我来说,本文档的第一版只是我们在我的工作地点使用的SDLC的概述,其中列出了每个步骤中相关的角色列表,履行这些角色的人员的一些示例以及与之相关的特定清单生命周期的每个步骤。我个人认为清单对于培训目的是必不可少的,但对于我在工作中所做的任何其他事情,也是如此。例如:

  • 项目经理(Joe)在Jira中为您分配任务。
  • 根据公式x设置任务的估计完成时间。
  • 开始工作时,将其设置为“进行中”。
  • 从git创建分支,单击链接以观看此进度的30秒视频。
  • 根据设计文档中的约束条件编写单元测试,有关单元测试的命名约定,请参见第y页。
  • 设置票证进行审核,并将代码提交到审核系统..'等

希望您的新员工应该熟悉其中的大多数概念,并且现在拥有有关如何在公司中应用流程的逐步指南。我还从头到尾使用我认为执行得很好的项目中的真实文档对过程进行了快速演示。

如前所述,它也是一个活动文档,因此可以在确定需要更多信息时对其进行扩展。整个团队都应该参与其中以保持最新状态。它可以是Wiki,OneNote文档等,也可以是所有人都可以编辑和查看的内容,然后在闲暇时分开始让其他人参与改进它。这样一来,一个人就不会这样做,而是将自己的想法传播给所有新员工。

一旦他们检查了过程,请他们对非关键任务项目进行小功能/错误修复,并让他们提出文档未涵盖的问题。记录这些问题是什么,因为它们可能应该是您下次处理文档时首先添加的内容。


1

如果不花费时间,您无法将做这样的事情结合在一起。至少,如果您想自己做。您应该问自己,是否真的有必要像尝试的那样精确地记录下来?

唯一的选择是让新员工担任主要职务。让他们写一些部分。您花费在纠正这些问题上的时间(以反馈的形式)将少于您当前的情况。提供一些好的模板,您不必担心布局。


1

我相信您已经知道他们已经给您分配了不可能完成的任务。作为作家,您可能已经很熟悉马克·吐温的名言:

如果我有更多的时间,我会写的更少。

在几乎没有资源的情况下,可能最好的办法是得到一个文件柜,并要求每个人复制他们已经拥有的文件并将其放入文件柜中。这样,您至少可以对新员工说:“如果要查找有关系统的信息,那么开始的位置是在文件柜中。”

好的写作需要时间和时间。此外,还需要针对目标受众量身定制。对于最终用户有效的并不是程序员所需要的。

更不用说良好的培训不仅限于书面材料,还包括在线,教室,多媒体等完整的教育资源。

正如他们所说:“如果您认为教育很昂贵,请尝试无知的代价。”

此外,不用说,将文档视为事实之后要做的事情,而不是将文档从第一天开始就作为流程的组成部分,就表明存在系统性组织问题。


我们的团队遍布全球...因此,最好不要使用文件柜;)
Malfist 2012年

好吧,给它屏蔽一个虚拟文件柜,如DropBox.com
JonnyBoats 2012年

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.