人々がチームを去るとき、どのような行動をとりますか？
最近、当社の主要エンジニアの1人が辞任しました。このエンジニアは、アプリケーションの主要コンポーネントを共同執筆しています。 トラック番号 にはまだ到達していませんが、近づいています:)
男がワルツを脱ぐ前に、この損失からできるだけスムーズに回復するために必要なアクションを実行して、最終的に残りのチームを「成長」させたい彼が作成したパーツを適切にカバーします。
コンテキストの詳細：コンポーネントがカバーするドメインとコードはロケットサイエンスではありませんが、それでも多くの重要なものがあります。一部のチームメンバーはすでにこれの多くをカバーできますが、それらは自分の皿にたくさんあります。
これらは私の頭に浮かぶアクションです：
- テストとテストカバレッジを改善する-特に重要なものについては、
- 高レベルのドキュメントを更新し、
- コードが実行する「おかしいもの」を文書化します（いくつかの重いダクトテーピングを行う必要がありました）。
- コードドキュメントの追加/更新-「公開」可視性を備えたすべてのものをドキュメント化します。
最後に質問：
この状況でとるべき行動は何だと思いますか？そのような状況で何をしましたか？あなたにとって何が上手くいかなかったか？
私は彼にコーディングを完全に停止するを求め、彼の時間を費やします：
- 他人を指導する
- コードで彼のコメントを確認する（状況に合わせるため）
- そして、もし彼が彼が一週間で去るだろうと知っていたら彼が書いたであろう文書を書く。
私は彼が所有しているモジュールに優先順位を付けて、他の開発者がそれらを使用できるようにします。
彼が去った後、コーチングをしたり、彼に質問したりするのは遅すぎます（良い状態で）。
彼が去ったら、その機会を利用して、あなたがあなたの組織を改善できると彼がどう思うかを彼に尋ねてください。元従業員は失うものは何もなく、フィードバックは正直であり、常に貴重です。
あなたはキーポイントをカバーしたように見えました：
- 更新/作成重要なドキュメント延期してきたコンポーネント/システム。
- メモよくある落とし穴、落とし穴などがわかるかもしれませんが、チームにはわかりません
- それらが欠落している難しい/複雑なセクションのテストを改善します。
彼らが役立つかもしれない他のもの：
- 最後に"brain dump"を行うために誰かpartnerを用意してください。これははるかに高速ですが、正確性は劣りますが、時間がないときにドキュメントを作成します。
- 退職する従業員と良好な関係を保つようにしてください。時間外にコンサルティングロールで数時間雇用する必要がある場合があります（本当に行き詰まった場合）。
少なくとも、これは、元の雇用主が最初の2年間で4人の主要な技術スタッフのうち3人を失うことを見てから学んだことです...
30年間の請負業者として、私はチームを何十回も離れてきました。
たまに電話がかかることがあります。時々そうではない。
私にかけ直さなければならなかった人々は、どういうわけか、私が請負業者であり、去っていることを理解しませんでした。ちなみに、これはプロジェクトの初期の段階で明らかになりました。一部の組織では離職率が低い-人々は何年も一緒に働いており、キュービクルに重要なシステム情報が記載された黄色の付箋紙があり、正しい文書はありません。
私に電話をかけなかった人たちは、おそらく不幸で、私のコードをすべて削除しました。知るか？
しかし、以下の習慣をつけた組織は幸せでした。
バグ追跡。これは重要です。コードに「TODO：」コメントを含めないでください。これらは、正式に追跡する必要がある機能のリクエストまたは潜在的なバグです。ダクトテープとバンドエイドはすべて、バグ修正または将来の機能強化として正式かつ完全に文書化する必要があります。
テスト。また重要です。ビルドが壊れていると、誰も家に帰りません。
要件、設計、および展開のドキュメントを最新に保つ。これには、積極的で継続的なレビューとウォークスルーが必要です。それには、離職を期待し、管理する組織が必要です。数年以上同じ仕事をする人はいません。ドキュメントでこれが簡単になるまで、シャッフル、再シャッフル、および再シャッフルします。
目標と成果物の追跡。作成中のコードを積極的に管理していない場合、他の人が取り組んでいることや、何が完成していないか、何が壊れているかがわかりません。 （ "FOB"フラットオンバック。つまり、手術台で "OOT"。また、手術中。以前は "おっぱい"と言っていましたが、一部のエンジニアがこれに反対したときはやめなければなりませんでした。カラフルすぎる。そして、彼らは正しく、それは不適切です。）
これにより、彼らが去る直前に彼らが新しいコードを書くのを止めることができます。
要点は、チームが何を行っているか（要件）、何をチームが出しているか（テストされ、文書化されたコード）、およびチームが進行中のもの（新しいコード、修正）の360度のビューが必要であることです。
その見解があれば、チームの個々の人を置き換えることができます。
すでに述べられていることに加えて、さらにいくつかのヒント：
- 彼が取り組んでいるすべてについてのステータスの要約を書いてみましょう。確実に行われること、「うまくいく」べきこと、半分完了したこと、手つかずのもの。
- 彼が（非公式に）担当する可能性があるすべての副次的なタスクを文書化します。顧客のサーバーのログファイルを月に1回確認するようなものです。完璧な世界では、これらのタスクはすべてすでに文書化されていますが、実際には、何かが忍び込んでいた可能性があります。
- これが大量脱出の始まりかどうかを知ることは重要です。プロジェクトで問題が発生している可能性があり、他のメンバーもすぐにフォローする可能性があります。もしそうなら、可能な限り打ち消したい。
- エンジニアがクライアントに直接連絡している場合は、彼の連絡担当者が誰であるか、および彼らの立場は何かを文書化してもらいます。あなたの既存の記録はその点で正確ではないかもしれません、そしてそれらの人々を知らないことは恥ずかしい状況につながるかもしれません。
- エンジニアが顧客のサーバーにVPNアクセスできる場合は、それらが誰であるかを確認してください。彼のアカウントが一時停止され、代わりの新しいアカウントが間に合うように作成されていることを確認してください。
最初に働いた会社で最初にポジションを変更したとき、行と列で行ったすべての作業のリストを含むスプレッドシートを作成しました。
- それがあったプロジェクト/製品
- プロジェクトの特定の領域
- ビジネス/プロジェクトマネージャー
- 仕事の複雑さ
- 誰に渡されたか
- 引き渡されたか、引き渡されたか、または必要でなかったか
- 引き渡された日付
- そのためのドキュメントの名前（付随するArticles.Zipに格納されていた）
- それに関するコメント
これは、引き渡しの過程で更新され（優先度に応じてフィルターおよびソートされ）、最終的にすべての私の仕事の凡例とアーカイブ、および必要なドキュメント/ディスカッションのTODOリストとなり、人々は引き継ぎに満足していることを確認しました。
私は古いマネージャーに譲ったので、彼ら（または他の誰でも）は私に尋ねなくても私の仕事/ドキュメントを入手できました。
私はそれの白紙のコピーをたくさん求められました、そしてそれはどんな引き渡しのための非公式の事実上の引き渡し文書にもなりました。
開発者として去ったとき、私は最後の1時間までコーディングの予定がありました（そして、それのために去るのに遅れました）ので、ハンドオーバーがうまくいくことを確認するために新しい作業を停止することについてピエールに間違いなく同意してください。
将来の主要なプロジェクトでこれらすべてを行うことを検討してください。それは私の会社が彼らのレッスンを難しい方法で学んだ後にやっていることです。
コードプロジェクトには常に少なくとも2組の目があります。そうすれば、誰かが去った場合の影響は常に限られています。
また、テスト/ドキュメントを常に最新の状態に保つことも、長い道のりです。