プログラマーが宝くじに当たった場合、会社が水中に進まないようにする方法[非公開]

私の下には数人のプログラマーがいますが、彼らはすべて非常に優れており、明らかに賢明です。どうもありがとうございました。

しかし、問題は、それらの各自が1つのコア領域を担当していることです。チームの他の誰も、それが何であるかについて最も曖昧な考えを持っていません。これは、それらのいずれかが取り出された場合、それらは交換できないため、ビジネスとしての私の会社は死んでいることを意味します。

彼らがバスに遭ったり、辞任したりする場合に備えて、新しいプログラマを招いて彼らをカバーすることを考えています。しかし、私はそれを恐れています

1. 古いプログラマーは、バックアップによって価値が低下するのではないかと恐れて、知識移転の考えに積極的に抵抗するかもしれません。
2. 異なる開発者間の技術移転を促進するシステムがないので、たとえ彼らにそれを行うように頼んだとしても、彼らがそれを適切に行うという保証はありません。

私の質問は、

1. 彼らが同意するような古いプログラマーにそれを置く方法
2. この種の「バックアップ」を容易にするために使用するシステムは何ですか？コードレビューができることは理解できますが、これを行う簡単な方法はありますか？チェックインコードレビューによる本格的なチェックインの準備ができていないと思います。

彼らが同意するような古いプログラマーにそれを置く方法

もちろん、問題を脅威としてではなく、チームとプロジェクトを改善する機会と見なすような方法で、問題をオープンに提示してください。例えば「私は他の人はあなたが解雇の場合に知っているものを知っていたい」は、明らかに間違ったアプローチです:-) 「私はあなたのいくつかは、休日に行くか、病気になっても、プロジェクトの円滑な動作を確保したいと思います「はるかに優れています。

通常、開発者自身が休暇中に問題を経験するたびに、開発者自身が問題を経験します。さらに、優れた開発者は作業中のプロジェクトに責任を感じているため、おそらくこの考えに同意するでしょう。それでも、彼らに話し合い、（できれば）アイデアにコミットする時間を与えてください。また、チーム内で知識をどのように、誰と共有するかについて彼らが発言できるようにします。ジョーはジムと仕事をする（そして彼の知識を共有する）ことは大丈夫だと感じるかもしれませんが、ジャックなどとはできないかもしれません。

この種の「バックアップ」を容易にするために使用するシステムは何ですか？コードレビューができることは理解できますが、これを行う簡単な方法はありますか？チェックインコードレビューによる本格的なチェックインの準備ができていないと思います。

チームでは、コード/デザインレビューとは別に、

• チームメンバー間のタスクと責任領域のローテーション（各自が主な責任領域を持っていますが、時々、他のチームメンバーがよく知っている領域でタスクを実行します）
• 対面ナレッジトランスファーセッション（通常、上記のタスクが必要なときだけでなく、誰かがチームを離れる前）
• チーム/プロジェクトwiki

多くの場合、開発者はコードから直接読み取れるものよりも多くのことを知る必要があるため、コードのレビュー自体では不十分な場合があります。つまり、ドメインモデルもあります。コードが実際に何をしているのかを読むことはできますが、モデルがなければ理由はわかりません。

彼らに知識を共有するように動機付ける1つの方法は、彼らの仕事について他の人に短いプレゼンテーションをするように頼むことです。プログラマは通常、自分の仕事に大きな誇りを持っています。これはそれを誇示するためのチャンスです。プレゼンテーションは、部外者にはめったに知られない癖のいくつかを見せるための良い機会です。

また、なぜそれについてオープンになって、誰もがバスに襲われた場合に備えて知識共有のスキームを考え出す必要があることを全員に伝えてはどうでしょうか。これは不合理だとは思わない。私の会社では今まさにそれが起こっており、一部の人はそれについては防御的ですが、彼らはそれを行う必要があることを知っています。

たぶん彼らはいくつかのことでペアで仕事をするかもしれません、彼らが好奇心nature盛な性質のものであれば、問題はないはずです。

新しい人員を雇用する前に、ソフトウェアの内部ドキュメントを最新のものにすることが最初のステップです。確かに、それはあなたの貴重なプログラマーがIDEの代わりにOfficeとUMLツールでいくらか時間を費やすことを意味しますが、私はそれがどんな場合でも価値があると思います。

最新のドキュメントを入手したら、プログラマーにクロスチェックして、他の人が書いた内容を全員が理解していることを確認できます。まだ新しい人はいりません。

その後、新しい人を雇うことを検討できます。または、会社のワークロードに応じて。

大企業にいる場合は、人事部に電話してこの問題について話すことができます。私を信じて、主要な人員がバスに襲われた場合、会計の人は同じ問題を抱えています。重要な交渉の最中に主要なセールスマンがゾンビになった場合、マーケティング担当者も多くの問題を抱えることになります。

このための正しいHR言語は後継者計画だと思います。あなたの会社はこれに対処するためのポリシーとフレームワークをすでに持っているかもしれません。

私が働いていた場所には同じ問題がありました。彼らがしたことは、各シニア開発者と一緒に働くために、1人のジュニア開発者を雇うことでした。彼らは一緒にプロジェクトに取り組む2人の小さなチームを作りました。数か月ごとまたはプロジェクトごとに、チーム間でジュニア開発者を交代させます。このように、シニア開発者は主題の専門家のままでしたが、ジュニア開発者はすべてのシステムとそれらがどのように連携しているかをよく把握し始めました。さらに、チーム規模の倍増プロジェクトにより、プロジェクトが迅速に完了しました。

大規模なプロジェクトについては、シニア開発者は、プロジェクトの他の部分でシステムの別の部分でジュニア開発者として行動し、他のシステムの学習を開始できるように求められることがありました。

そこで重要だったのは、チームの拡大と成長を続けながら、既存の開発者の知識と年功を尊重することでした。それは遅いプロセスでしたが、時間が経ってもうまくいきました。

成功したオープンソースプロジェクトを成功に導くものの1つは、コードの「所有権」の欠如です。つまり、誰もアプリケーションの領域の唯一のメンテナーではありません。誰でもアプリケーションのどの部分にも貢献することができ、また奨励されています。それは私が強く信じていることです。

あなたがしたいことは、物事が実際にあなたが現在持っているチームを傷つけていることを説明することです。ここにあなたが行きたいポイントがあり、この順序でできれば：

• あなたがこれがどのように機能するかを知っている唯一の人であるなら、私はあなたがパイクを降りてくる他のクールなものに取り組むことを自由にすることはできません。
• 私たちはあなたが良い休暇をとれるようにしたいが、他の誰もあなたがすることをすることができないので、余裕がない。
• 人々が現在の位置に満足していないために転職するのは不愉快な事実ですが、あなたが働いている地域に閉じ込められていると感じるので、あなたを失いたくありません。

個人的な注意として、私は亡くなった同僚に対処しなければなりませんでした。情報のサイロ化はありませんでしたが、損失は依然として大きな打撃を受けました。これが起こる可能性は、上記の3番目の箇条書きよりもはるかに低いです。

ケースを公開したら、問題を修正する方法についてのアイデアを求めて彼らの助けを求めてください。もちろん、あなた自身で来てください。彼らのアイデアは、彼らがチームの一員であり、彼らの専門分野以上のものに必要であることを理解するのに役立ちます。ジェーンはジョーがやっていることに興味を持っているかもしれませんが、それによって少し怖がっていると感じます。それを知っていると、知識の伝達がより楽しくなります。あなたがしたいことのいくつかは次のとおりです。

• 現在のチームをクロストレーニングします。短期的には少し効率が落ちるかもしれませんが、アプリの他の部分に適用できるアプリの1つのコーナーで学んだ教訓があるかもしれません。しばらくの間、ジェーンとジョーにお互いのプロジェクトで協力してもらいます。
• 知識共有の文化を育みます。私が働いていた会社は、「ブラウンバッグテックトーク」プログラムを持っていました。誰でも承認されたトピック（通常は技術またはソフトウェアプロセスを紹介する）について発表できます。会社は昼食を提供し、発表者は努力のために数百ドルを得ました。
• メンタリングは生き方でなければなりません。他の人を指導する目的は、あなたが新しいことをするのを自由にすることであり、会社にとってあなたをさらに価値のあるものにします。
• ランクを引き上げずに情報サイロの境界を越える方法を見つけます。楽しくすればするほど、脅威は少なくなります。あなたのチームの人たちがあなたの言うほど上手なら、彼らはおそらく物事のやり方に完全に満足していないでしょう。チームがそれを処理できるかどうかの判断者である必要がありますが、「まあまあピック」週間を持つことができます。常にここから始めましょう。そのアイデアは、「まあまあ」の責任とは何か、そして彼らが抱えている問題をどのように解決できるかについて、みんなの目を引くことです。首から先に行けば、誰も仕事に出てこないという考えを得るでしょう。

一般的に、あなたが仕事をもっと楽しくしたいので、彼らに印象づけようとしてください、そして、あなたはそれをするために彼らの助けが必要です。

インターンは良い考えかもしれません。彼らは現在の開発者の直属の部下になるので、彼らは脅迫されることはありません。

会社が成長するにつれて、古い開発者とインターンシップ後に成功した開発者の両方が必要になります。

これはうまくいくと思う。

一般的に、あるマネージャーが突然ドキュメンテーションと後継者の計画を気にし始めると、プログラマーが解雇または解雇されようとしているという強い警告サインです。これは、典型的な管理上の振る舞いとはかけ離れたものであり、プログラマーのあらゆる種類の警告信号を引き起こします。

誰もがすべての手順とプロセスを文書化するように言われています

「企業の破滅の警告サイン」のレベル3。

代替案として、あるエッセイは、「アップまたはアウト」の文化を奨励することを提案していますが、反論は、（誤った）経営者のキャリアラダー含まれています。

@ammoQが彼の答えで始めた完全なドキュメントのコンセプトに基づいて...

優れたマネージャーは、直属の部下のレポートのスキルを開発して、いずれかのレポートでそれらを置き換えることができるようにします。開発者に、仕事の完全な透明性を提供する従業員は、すべての仕事を秘密にして非公開にする従業員よりも価値があることを理解させます。「秘密の」開発者が今日亡くなった場合、その失われた知識を取り戻すことは企業にとって大きな費用負担となります。「完全な情報開示」の従業員が今日死亡した場合、会社は依然として損失を被っていますが、それほど破壊的ではありません。したがって、「完全開示」従業員にはより多くの価値があります。

解雇されることを免れるために隠された知識を保とうとする従業員は、昇進を免れます。開発者を、今日の負担となるありふれたタスクを完了する人がいない場合、より挑戦的でやりがいのあるポジションに移動することはできません。ありふれたタスクが完全に文書化され、完全に開示されている場合は、新しいジュニア開発者を雇って、以前の開発者を記入し、より上級の地位に昇進させることができます。

これは、あなたもあなたがしたことを文書化し、各直属の部下にトレーニングを提供する必要があることを意味します。そうすれば、あなたが今日亡くなった場合、フルタイムの交換が見つかるまで、そのうちの1人があなたのために埋めることができます。

新しいプログラマーを導入する前に、文書化された独自の遺産を作成するのを手伝ってくれるように、各プログラマーにお願いします。

ウィキ、または仕事のあらゆる側面に関する文書の3リングバイブルを使用します。

または、本当に詳細で徹底的なドキュメントが必要な場合は、テクニカルライターを雇って、各プログラマーにインタビューし、すべてのドキュメントを毎日、毎週、毎月、毎年作成します。

それから、あなたのプログラマーが更新/編集/参加/コメントできるウィキ版を作成します。

その後、時間とともに成長し、新しいプログラマーの学習曲線を改善するシステムができます。

また、正直なところ、プログラマーを1つのコア領域にとどめることは賢明ではありません。

そうすれば、1人が休暇などをするときに、既存の人員を使用できます。

プログラマーの1人が病気になったときはいつでも、質問や問題を繰り返し電話してください。

プログラマーが休暇をとるたびに、質問や問題を繰り返し電話してください。

彼らはすぐに、彼らだけでなく会社にとっても、コア領域に責任を持つ独身の人がいないほうがよいことに気付くでしょう。

誰もバスに襲われたくはありませんが、彼らはまた、誰かのプロジェクトを急に引き継いで、プロジェクトを維持する必要もありません。その後、誰もが廃業するリスクを負います。

サイロで開発している場合、あるプロジェクトから別のプロジェクトに人を移動させる必要があります。ドキュメント、コードレビュー、または単純なバグの修正から始めます。これが手に負えなくなる前に、コード保護/縄張りの小さな行為に対処する必要があります。

コードの一部に専任のスペシャリストがいることは効率の錯覚です。

休暇に行きたい人はいますか？

経営陣による愚かなミスのために、私はさらに多くの企業を倒した。1人か2人のエンジニアが辞めたとしても、クラッシュして火傷することはありません。しばらくは少し努力する必要があります。Sheesh、私は四半期ごとに誰かを失うオフショアチームを管理しています。タスクの移動を開始します。今日。