新規採用者をトレーニングするためのより良い方法[終了]

私が現在所属しているチームはかなりの離職率を経験しており、メンバーは通常、同じ会社内の異なるプロジェクトに移動しています。現在、新しいメンバーの「トレーニング」は、彼らを実際の経験を提供し、より新しい採用者がメンターに何か尋ねるかどうかより多くの上級開発者に尋ねる主要な連絡先（通常はトレーニングを完了する最も最近の人）とペアにすることです知りません。これは、新規採用者が迅速に関与する機会を提供し、メンターにシステムへの理解を向上させることも要求します。

しかし、ご想像のとおり、このスタイルのトレーニングは非常に時間がかかり、十分な知識の伝達にはなりません（誤解が広まり、ギャップが拡大します）。

私は、将来の新入社員向けのドキュメントとトレーニング資料の生成を任されています。私はすでにテクニカルライティングを時々行っていますが、それはエンドユーザー向けであり、非常に具体的であり、多くのスクリーンショットがあり、完了するまでに長い時間がかかります。

新入社員向けの新しいドキュメントを作成することは優先度が低いと考えられており、私は現在、約40時間しか作業できません。私が技術文書を書いている現在の方法でシステムを文書化しても、40時間でかろうじて表面を傷つけるだけです。特に、コードベースだけでなく、展開とサポートについても文書化する必要があることを考慮します。

ドキュメントの作成に多大な時間を費やすことなく、ドキュメントをすばやく作成して、新入社員をできるだけ早く最新の状態にするにはどうすればよいですか？

追加情報：
現在、Wikiといくつかのトレーニングドキュメントがありますが、どちらもまばらです。

良い質問。プログラマのOJトレーニングが真剣に受け取られることはほとんどなく、頻繁に話題になることもありません。

私が見たいくつかのアイデアはうまくいきます：

• Wikiに、新規採用のランプアップドキュメント（作成中のドキュメント）があります。その文書で、新入社員が最初の1〜2週間に実行するタスクについて説明します。私が働いている場所では、最初から、内部のソフトウェア/ツールからプロセス、特定のタイプの情報の場所まで、知っておくべき負荷がたくさんあります。編集>「x、y、zを順番にインストールする」のような手順と構成のスクリーンショットを用意しています。WinServer、SQL Server、SharePoint、BizTalkでシステムまたはファーム（VM）を構成すると、ソフトウェアはそれほど単純ではありません。音。これは、サポート対象の他のバージョンのアプリケーションにも当てはまります。
• 練習問題。私がいるところには、大規模なAPIを公開する製品があります。したがって、クライアント/顧客が行うのと同じように、（事前に定義された）拡張機能を作成するための独自の製品ドキュメントに目を通すことは常に有益です。したがって、製品のAPIの一部として数学ライブラリがある場合、「APIを使用して計算機を作成する」などの練習問題があります。
• メンターは良いです。持っておく。私たちもここでそうしています。人々に会ったり友人を作るのに良い方法であるだけでなく、彼らは学習の源として非常に貴重です。彼らが他の誰かがそうであるかもしれない企業知識の歴史を持っていないので、私は訓練を終えるためにそれが最も最近の人であってはいけないことを勧めます。ローテーションでみんなにやってもらいます。
• 私たちは（大体）毎週のプレゼンテーション/技術トークを行います。新入社員に製品から何かを選んで（または割り当てて）もらい、3週後にプレゼンテーションを行います。彼らが間違っている可能性があることを彼らが知っていることを確認してください、そして彼らがプレゼンテーションで何かを誤解した場合、チームはそれらを修正することができます。
• 新しい採用担当者は、開始時にドキュメントを作成します。それは彼らにそれを読むことを強制します。

Dan McGrathが指摘しているように、彼らのためにwikiを改善するためにも、新入社員を奨励することは良い考えです。

まず、私はあなたがあなたがあなたのクライアントのために書くものほど完全にあなたの新しい雇用トレーニングドキュメントを作る必要がないことを提案します。それは、新しい開発者がガイドとして使用できるように十分に技術的である必要がありますが、すべての小さなことを概説するほど詳細ではありません。結局質問があれば、チームと話すことができます。

チームに役立つために、新入社員が知っておくべき10のことは何ですか？これらのことに集中してください。それらをあなたのアイテムのヒットリストにして、新しい開発者が十分な情報を手に入れ、十分な情報を得られるようにします。リストに載っているものが多すぎる場合は、最初の2週間または3週間で行うかどうかを自問してください。もし彼らがこの時間に何かをしないなら、おそらくそれは搭乗ガイドに含まれるべきではありません。

ガイドのセクションごとに、適切な担当者が右上に強調表示されていることを確認してください。このように、新入社員が質問をした場合、彼らは誰に助けを求めればよいかを知っています。また、1人のチームメンバーがあまりにも多くのセクションの主役にならないようにしてください。彼らがメンターでない場合、あなたは一人の人が新しい雇用の質問で時間をかけたくないでしょう。

このドキュメントを丸1週間費やさないでください。少なくとも1人の新規採用者にそれを通過させたら、少し時間を置いて調整してください。何がうまく機能し、何が機能しないかを確認して修正します。

私は最近、職場で同様の文書を書き始めましたが、同様の時間的制約があります。私も最初と同じように、非常に詳細なレベルで記述したいのは簡単ですが、実際には逆効果かもしれません。

新しい人が役割を開始する場合、最初の数週間は情報が殺到している可能性があります。最初のトレーニングを、何年も会社にいる開発者の頭の体裁にすることは、私の頭の中で、誰かが最初の数か月、さらには1年間、そのポジションで知る必要があることをはるかに複雑にします。それを高水準に保ち、標準的な専門用語と概念を使用してみてから、会社のプロセス内の詳細でそれらを拡張します。

私にとって、このドキュメントの最初の反復は、私の職場で使用するSDLCの概要であり、各ステップ内で関連付けられている役割のリスト、それらの役割を実行する人々のいくつかの例、および関連する特定のチェックリストですライフサイクルの各ステップも同様です。個人的には、チェックリストはトレーニングの目的に欠かせないものだと思いますが、私が仕事でする他のことについても同様です。例えば：

• プロジェクトマネージャー（ジョー）がJiraでタスクを割り当てます。
• 式xに基づいて、タスクの推定完了時間を設定します。
• 作業を開始するときに、チケットを「進行中」に設定します。
• gitからブランチを作成し、リンクをクリックして、この進行状況に関する30秒のビデオを表示します。
• 設計ドキュメントの制約に基づいてユニットテストを記述します。ユニットテストの命名規則については、yページを参照してください。
• レビュー用のチケットを設定し、コードをレビューシステムに送信します。

新入社員は、概念の大部分に精通しているはずです。そして、会社でプロセスがどのように適用されるかを段階的に説明したガイドを用意してください。また、プロジェクトの実際のドキュメントがうまく実行されたと感じて、最初から最後まで実際のドキュメントを使用してプロセスの簡単なデモを行います。

すでに述べたように、これもまた生きたドキュメントなので、より多くの情報が必要であると識別されたときにセクションを拡張できます。チーム全体で最新の状態に保つ必要があります。それはwiki、OneNoteドキュメントなど、何でもかまいませんが、すべての人が編集およびレビューできるもので、あちこちで暇な時間があったら、他の人たちがそれを改善に参加するように始めます。そうすることで、一人の人がそれをせずに、自分たちのプロセスをすべての新入社員に広めています。

プロセスを確認したら、ミッションクリティカルではないプロジェクトの小さな機能/バグ修正をフォローしてもらい、ドキュメントがカバーしていない質問をしてもらいます。これらの質問が何であるかを記録します。これは、次に作業するときに、おそらくドキュメントに最初に追加するものであるためです。

時間を費やすことなく、このような良いことを組み合わせることはできません。少なくとも、自分でやりたい場合は。あなたが試みているのと同じくらい正確にそれを文書化することが本当に必要かどうかあなた自身に尋ねるべきですか？

唯一の選択肢は、新入社員に主な仕事を任せることです。彼らにいくつかの部分を書かせてください。これらを修正するために費やす時間（フィードバックの形式）は、現在の状況よりも短くなります。いくつかの優れたテンプレートを提供すれば、レイアウトについて心配する必要はありません。

私はあなたがすでに彼らがミッションを不可能にするように命じたことを知っていると信じています。ライターとして、あなたはおそらくすでにマークトウェインの言葉に精通しているでしょう。

もっと時間があったら、もっと少なく書いたでしょう。

リソースがほとんどない場合は、おそらくファイルキャビネットを入手し、すべての人に、すでに持っているもののコピーを作成して、そのコピーをファイルキャビネットに入れるよう依頼するのが最善でしょう。そうすれば、少なくとも新入社員に「システムについて何かを調べたい場合、開始する場所はファイルキャビネットにある」と言うことができます。

上手に書くには時間がかかります。さらに、対象者に合わせて調整する必要があります。エンドユーザーのために機能するものは、プログラマーが必要とするものではありません。

言うまでもなく、優れたトレーニングは書面の資料に限定されず、オンライン、教室、マルチメディアなどの教育リソースの完全な一式が含まれます。

彼らが言うように、「あなたが教育が高価だと思うなら、無知の代価を試してください。」

さらに、ドキュメントを最初からプロセスの不可欠な部分にするのではなく、事実の後に行われるものとしてドキュメントを表示することは、体系的な組織の問題を示していることは言うまでもありません。