学校では教えてくれないこと: テクニカル サポート エンジニアの育成方法

お約束の「違う物語」がここにあります。

課題

4 年前に私に「IT 部門/企業の新人をどのようにトレーニングできますか?」と尋ねていたらどうでしょうか。 - 私は迷わずこう言います。「『猿は見て、猿は真似する』方法を使う、つまり、新人をより経験豊富な従業員に割り当て、典型的なタスクがどのように実行されるかを観察させます。」このアプローチは以前もうまくいきましたし、今でもうまくいきます。少し前、Veeam では、木が大きく、ロゴが緑色で、製品が小さかったころ、これがトレーニング方法でもあり、トレーニングもできました。

徐々に、製品は大きく複雑になり、新しいエンジニアはますます増え、RTFM (Read The Freaking Manual) スタイルのアプローチはますますうまく機能しなくなりました。事実、すでに「知識がある」人はこの方法で学ぶことができます。 、作業の詳細を理解しており、それほど重要ではない詳細を必要としている人。

しかし、関連分野の出身で、成長と発展を望んでいるが、それにどうアプローチすればよいかわからない人はどうでしょうか?たとえば、比較的珍しい言語 (たとえば、平均的な IT スペシャリストにとっては珍しいイタリア語) を話す人はどうすればよいでしょうか?あるいは、そのような制度の下で、社会人経験があまりない有望な大学卒業生をどのように育成するのでしょうか？

ちょっと話を止めて想像してみましょう。あなたはサポート チームのチーム リーダーです。彼は元有能で成功したエンジニアであり、システム管理やさまざまな人々とのコミュニケーションに豊富な経験があります。あなたの任務は、大学を卒業し、頭の回転が速く、頭の回転が速い新しい（「グリーン」とも言える）戦闘機エンジニアにあなたの経験を伝えることです。微妙な違いがあります。これはサポートの経験がなく、平凡なヘルプデスクさえ持たない人であり、あなたの会社で最初のトルコ語を話すエンジニアでもあります。

この問題をどうやって解決しますか?

そして、あなたがこの質問に答えたら（そしてあなたは答えるでしょう、私はあなたを信じています）、タスクを複雑にしてみましょう - そのようなエンジニアが10人いたらどうなるでしょうか？ 20だったらどうしますか？これが部門の継続的な発展であり、常にトレーニングが必要な新人がいる場合はどうなるでしょうか。仕事の品質の最低基準を示し (そしてこの基準は高いです)、その人が望んでいないことを確認する必要があります。できるだけ早く逃げるには？

(続きを読む前に、この質問についてよく考えてください。)

私たちのストーリー

これはまさに私たちが直面した課題/課題です。

この部門は比較的小規模でしたが、「新人に指導者と書類のリストを与え、泳ぐか沈むかで仕事を辞める」という計画はうまく機能しました。この計画は優れており、普遍的であり、何年にもわたって、さらには何世紀にもわたる人類の普遍的な経験によって証明されていますが、ある時点で、私たちは繰り返しにうんざりしていることに気づきました。各新参者には、自分の仕事に役立ついくつかのことを伝える必要があります。 「従来の」スキームでは、メンターがこれを行いますが、誰かのメンターが 1 つずつワードを持っている場合はどうなるでしょうか?同じことを繰り返すとすぐに飽きてしまい、燃え尽き症候群が始まります。これはすでにリスクです。

そしてここで私たちは、新人をグループに集めて講義を行うという、もう 1 つの伝統的な計画を思い出します。これが私たちのトレーニング プログラムが生まれた方法です。

... 当社のエンジニアは、社内外、サードパーティ、および自社主催のカンファレンスに参加することがあります。この出来事から現在のような支援訓練が始まりました。

当社のエンジニアの 1 人が、ラスベガスで開催された VeeamOn で、Veeam Backup & Replication がどのような要素で構成されているかについて素晴らしいプレゼンテーションを行いました。それは、いくつかの調整を加えて「コンポーネント」の講義になりました。この時点までに、機能のさまざまな部分についてすでにいくつかのレクチャーを受けていましたが、その前後のすべての内容の「調子を決めた」のはそのレクチャーでした。それが私たちにとっての基準となったのは、講義の構成方法、使用された教材などでした。

私たちは、仮想化、Microsoft テクノロジ、自社製品について多くのことを話し始め、IT 経験のない初心者向けの基本トレーニングを導入しました。そこでは、ハードウェアから始めて、ディスク API、オペレーションなどの抽象化レベルを上げながら、サポート エンジニアに必要なすべてのことを説明しました。システム、アプリケーション、ネットワーキング、仮想化。

もちろん、私たちが使用するテクノロジーの全範囲をトレーニングでカバーしようとするのは不可能であるか、少なくとも非合理的であることは理解していました。 1 つの製品のすべての機能を教えるにはすでに数か月かかりますが、製品は静止しておらず、常に新しいものが登場します。また、研修講義だけでは、将来のエンジニアに必要なものをすべて提供できるわけではありません。

ほかに何か？

パレートの法則が私たちにとって有効であると言いたいのですが、私たちのトレーニングでは、成功したエンジニアに必要なものの約 20% が提供され、マニュアルを読むこと、研究室で働くこと、テストや戦闘の要求を解決することなど、80% はエンジニアの良心に残ります。 。

20% - トレーニング - 実際、これは理論ベースのほぼ 100% ですが、理論だけですべてを達成することはできません。知識 - 能力 - スキルという古典的なスキームが機能します。知識を与えることはできますが、スキルを開発することと、それをスキルに変えることはまったく別の作業です。

そのため、最初の理論的な講義はすぐに他の内容で補うことができ、全体的なスキームは次のようになります。

• 講義・研修；
• 独立した仕事;
• メンタリング。

最初のポイントではすべてが明確です。初心者のグループを連れて理論を読み、スムーズに2番目のポイントに進み、講義の最後に「宿題」を与えます-初心者が「プレイしなければならないある種の実践的な問題」ラボで「アウト」し、何らかの形式でレポートを提供します (通常、形式は無料ですが、例外もあります)。

私たちは意図的にかなり一般的な形式でタスクを作成し、「あそこに行って、あれをし、見たものを書き留めてください」という正確な指示を避けます。代わりに、単にタスクを提示し (たとえば、このコンポーネントのリストを使用して仮想マシンをデプロイする)、得られた結果を使用して「調査」を行うよう依頼します。その方法や結果の確認方法については触れません。これにより、初心者 (特に IT の世界やエンジニアリング団体の考え方から旅の始まりにある人) に、独立した思考、ドキュメントを読んで新たな問題を分析するスキル、そして非常に重要なこととして、問題を理解することを教えたいと考えています。限界。

問題を解決すると、あたかも前方に突破できない壁があるかのように、行き止まりに陥ることがあることは誰もが知っています。そして、どのような場合に頭を悩ませ続ける価値があるのか​​、いつ助けてくれる人を見つけるのかを理解することも、チームで働くエンジニアにとって非常に重要なスキルです。

私たちの場合、初心者にとってのこの「助け手」はメンターです。

メンターを過大評価することはまったく不可能です。自分で判断してください。彼は、彼に割り当てられた新参者にとっての最初の「連絡窓口」であり、ほとんどの質問に答え、ほとんどの状況を助け、それらの悪いパターン（技術的な部分、ビジネス倫理、ビジネスの分野）を修正できる人です。企業文化）、コーチだけでなくチームのリーダーもこれを見逃す可能性があります。

そしてそれはすべて彼に関するものですか？

講義、トレーニング、指導、独立した仕事 - これらが私たちのトレーニング プログラムを構成する 3 つの主要な構成要素です。しかし、伝えたいことはそれだけでしょうか？もちろん違います！
4 つの完全な訓練プログラム (5 つ目は準備中) という優れた計画があっても、私たちは「略奪の仲間」を集めるのをやめません。教育は私たちの製品と同じように生きているため、新しい情報やそれを伝える新しい方法が常に登場します。

たとえば、私たちにとって重要なマイルストーンは、実際には学校や大学のトレーニングを完全よりも少しだけ繰り返しているが、それが常に機能するとは限らないということを理解したことでした。私たちは、経験豊富で、それぞれの恐怖心や好みを持つ大人たちを指導します。そして、この「学校」システムは人々を少し怖がらせます（スペードをスペードと呼びましょう。95％の場合、学校モデルによるフラストレーションは恐怖から来ています）。私たちは皆、何らかの形で学校や大学を通​​過し、ほとんどの場合、それがすべてでした。今でもトラウマ的な経験なので、二度と繰り返したくないのです。

ここから、私たちはアプローチを練り直すために始めます（はい、まだ始まったばかりですが、「旅は千マイルです...」など）。私たちはアンドラゴジー（本質的には子供たちを教えることを目的とする教育学とは対照的に、大人を教えること）について、経験、目標の理解、情報の同化と生徒の快適さについてのニュアンス、重要性などに焦点を当てて思い出し、学びました。感情的な要素（子供にとってこれはさらに重要です）、実践的な要素の必要性などです。私たちはについて学びました フラスコサイクル そして今、私たちはトレーニングをローテーションしており、経験を積んで完全に「専門分野から外れている」人でもトレーニングに参加させるにはどうしたらよいかを考えています。その経験を更新し、補足し、深め、精査し、何が重要なのかを支援します。 、基礎的な理論だけでなく、メンターの助けを借りて、または独立してスキルに変えることができる実践的な知識も提供します。

私たちはビジネス トレーナーを招待しました。彼らは人前で話す際に講師と協力し、感情について話し、自己主張を訓練し、グループのダイナミクスを管理するためのツールを提供してくれました。そしてもちろん、「トレーニングに何を求めているのか?」という質問に答えるのを手伝ってくれました。そして「私たちの最終目標は何ですか?」結果はすでに出ています。「退屈で何も明確ではない」というスタイルで最も多くのフィードバックを集めたいくつかのトレーニングは、今ではおそらく最も興味深く誠実なものと呼ばれています。しかし、講師は同じです。

そしてつい最近、非常にクールでやる気のある数人が私たちのところにやって来て、ナレッジ中心のサポートとビデオ コースの構築方法について話してくれました。そして、後者をリメイクして「録画」から脱却する方法について、彼らから多くの良いアイデアを学びました。 「ウェビナースタイル」を美しいものとシンプルなコースに分けて、私たちが望むすべてをシンプルかつ明確な方法で伝え、情報を提示するさまざまな方法に溺れないようにします。

また、今では研修の技術的な要素、いわゆるハードスキルだけではなく、講師や管理職だけでなく、エンジニアも含めたソフトスキルにも取り組んでいます。私たちがこれを行うのは、条件付きのイグナットが会社に来たときに、仕事で100%必要なスキルを実践し、自分の感情を管理できるようになり、たとえ最も困難で絶望的な状況であっても、それを認識できるようにするためです。結局のところ、サポートは人々に関するものであり、「私たちは問題が発生したときに自分自身を放棄しません」。最初の電話を受ける前に、新人とロールプレイング ゲームをして、新人がプロセスに参加して自分の応対スタイルを見つけるのを手助けします。最初のケースの前には、どのように協力するのが最善か、何をすべきかを伝えます。私たちはプロセス全体を通して監視し、支援します。
私たちはサポートです。そして、自分自身ではないとしたら、まず誰をサポートすべきでしょうか?

そして結論として、一言…

私の話が賞賛に聞こえることは承知しています。そして同時に、私は自慢しているわけではありません。これは私たちの歴史であり、現在であり、将来の計画のほんの一部です。

私たちのトレーニングは決して完璧ではありません。私たちには多くの欠点があり、たくさんの間違いを犯してきました、親愛なるお母さん！私たちはたくさんのフィードバックを受け取りますが、ほとんどの場合、それは賞賛的なものではなく、問題、欠点、改善が望まれる点について書かれています。私たちは世界中で教えているため、文化的特徴も考慮に入れれば、さまざまなフィードバックをたくさん受け取ります。 ...

私たちには成長の余地があり、神に感謝します。私たちには、仕事をし、批判し、議論し、新しいことを提案する準備ができている人たちがいます。これは素晴らしいリソースであり、素晴らしいサポートです。

そして、サポートとは人に関するものです。トレーニングを行うのは人です。トレーニングは、新入社員がより早く役に立ち始め、優れたエンジニアに早く成長するのに役立ちます。また、優れたエンジニアは世界をより良い場所にします。

...これで私の許可されたスピーチを終了させて​​いただきます。

出所： habr.com