プログラマーが宝くじに当選した場合に、会社が水中に入らないようにする方法
私の下に何人かのプログラマーがいます、彼らは皆非常に素晴らしく、非常に賢いです。どうもありがとうございました。
しかし問題は、彼らの一人一人が1つのコアエリアに責任を負うことであり、チームの他の誰もそれが何であるかについて最も曖昧な考えを持っていません。つまり、誰かが連れ去られたとしても、私の会社は取り替えができないために死んでしまいます。
彼らがバスに襲われたり、辞任したりした場合に備えて、新しいプログラマーを彼らに紹介することを考えています。でも怖い
- 古いプログラマーは、バックアップによって価値が低下するのではないかと恐れて、知識の移転という考えに積極的に抵抗するかもしれません。
- 私は異なる開発者間の技術移転を促進するシステムを持っていないので、私に彼らにそうするように頼んだとしても、彼らがそれを適切に行う保証はありません。
私の質問は、
- 彼らが同意するような古いプログラマーにそれを置く方法
- このような「バックアップ」を容易にするために使用するシステムは何ですか？コードレビューを行えることは理解できますが、これを行う簡単な方法はありますか？チェックインコードレビューによる本格的なチェックインの準備は整っていないと思います。
彼らが同意するような古いプログラマーにそれを置く方法
もちろん、彼らが問題を脅威と見なさないように、問題を率直に提示してください。むしろ、チームとプロジェクトをよりよく機能させる機会です。例えば。 「解雇された場合に備えて、あなたが知っていることを他の人に知ってもらいたい」明らかに間違ったアプローチです:-)「休暇中に病気になったり、病気になったりしても、プロジェクトを円滑に進められるようにしたい」のほうがはるかに優れています。
通常、開発者自身が休暇中に問題が発生するたびに、開発者自身が問題をカバーする必要があります。さらに、優れた開発者は自分が取り組んでいるプロジェクトに責任を感じているので、おそらくこの考えに同意するでしょう。それでも、彼らに議論し、（できれば）アイデアにコミットする時間を与えます。また、チーム内で知識を共有する方法と相手について、発言権を与えることができます。ジョーはジムと一緒に仕事をして（そして彼の知識を共有して）大丈夫だと思うかもしれませんが、ジャックなどとは一緒ではありません.
このような「バックアップ」を容易にするために使用するシステムは何ですか？コードレビューを行えることは理解できますが、これを行う簡単な方法はありますか？チェックインコードレビューによる本格的なチェックインの準備は整っていないようです。
私たちのチームでは、コード/デザインレビュー以外に、
- チームメンバー間のタスクのローテーションと責任領域（私たちにはそれぞれ主な責任領域がありますが、時々、別のチームメンバーがよく知っている領域でタスクを実行します）
- 対面の知識伝達セッション（通常、上記のタスクが必要な場合だけでなく、誰かがチームを去る前にも）
- チーム/プロジェクト wiki
多くの領域では、コードから直接読み取ることができるものよりも開発者が知ることが一般に多くあるため、コードのレビュー自体では十分ではない場合があります。つまり、ドメインモデルもあります。 whatは実際に読み取ることができますが、モデルがないとwhy。
知識を共有するように動機づける1つの方法は、他の人に自分の仕事について短いプレゼンテーションをするよう依頼するです。プログラマーは通常、仕事に大きな誇りを持っています。これは、それを誇示するチャンスです。プレゼンテーションは、部外者にはめったに知られていない癖のいくつかを示す良い機会です。
また、なぜそれについてオープンにするだけでなく、誰かがバスにぶつかった場合に備えて知識を共有する方法を考え出す必要があることを皆に伝えてください。これは無理だとは思いません。それは今私の会社で起こっており、一部はそれについて防御的ですが、彼らはそれが行われる必要があることを知っています。
たぶん、彼らはペアで作業をいくつかできるかもしれませんが、それらが探究的な性質のものであれば、問題はないはずです。
ソフトウェアの内部ドキュメントを最新の状態にすることは、新しい人を雇う前の最初のステップである必要があります。もちろん、それはあなたの貴重なプログラマーがIDEの代わりにOfficeやUMLツールを使って時間を過ごすことを意味しますが、いずれにしてもそれは価値があると思います。
最新のドキュメンテーションを入手したら、プログラマーにそれをクロスチェックさせて、他の人が書いたものを全員が理解できるようにすることができます。まだ新しい人は必要ありません。
次に、新しい人を雇うことを検討できます。会社のワークロードに応じて、そうでない場合もあります。
大企業であれば、人事部に電話してこの問題について話すことができます。私を信じて、主要な担当者がバスにぶつかった場合、経理の人たちは同じ問題を抱えています。主要なセールスマンが重要な交渉の最中にゾンビになった場合、マーケティング担当者も多くの問題を抱えます。
このための正しい人事言語は 後継者育成計画 だと思います。あなたの会社はこれに対処するためのポリシーとフレームワークをすでに持っているかもしれません。
私が働いていたある場所でも同じ問題がありました。彼らがしたことは、各シニア開発者と一緒に働くジュニア開発者を1人雇うことでした。彼らは一緒にプロジェクトに取り組む2人の小さなチームを作りました。数か月ごとまたはプロジェクトごとに、チーム間でジュニア開発者を交代させていました。このようにして、シニア開発者は主題の専門家であり続けましたが、ジュニア開発者はすべてのシステムとそれらがどのように連携するかをよく理解し始めました。さらに、チームサイズが2倍になったプロジェクトは、より速く完了しました。
登場したより大きなプロジェクトの場合、シニア開発者は、他のシステムを学び始めることができるように、プロジェクトの期間中、システムの別の部分でジュニア開発者として行動するように頼まれました。
チームの拡大と成長を続けながら、既存の開発者の知識と年功序列を尊重することが重要でした。それは遅いプロセスでしたが、時間の経過とともにうまくいきました。
オープンソースプロジェクトを成功させる要因の1つは、コードの「所有権」の欠如です。つまり、誰もがアプリケーションの領域の唯一の管理者ではないことを意味します。誰でもアプリケーションの任意の部分に貢献することができ、貢献することが推奨されています。それは私が強く信じていることです。
あなたがしたいことは、物事のあり方が実際にあなたが持っているチームを実際に傷つけていることを説明することです。取得したいポイントを以下に示します。できればこの順序で実行してください。
- これがどのように機能するかを知っているのがあなただけである場合、パイクを降りてくる他のクールなものに自由に取り組むことはできません。
- 私たち欲しいあなたは良い休暇を取ることができますが、他の誰もあなたがすることをすることができないので、余裕がありません。
- 現在の地位に不満があるために人が転職するのは不愉快な事実です。あなたが働いている地域に閉じ込められていると感じているので、私たちはあなたを失いたくありません。
個人的には、亡くなった同僚に対処しなければなりませんでした。情報サイロはありませんでしたが、その損失は依然として大きな打撃となりました。これが発生する可能性は、上記の3番目の箇条書きよりもはるかに低くなります。
ケースを提出したら、問題を修正する方法についてアイデアを求めて支援を求めます。もちろん自分で来てください。彼らのアイデアは、彼らがチームの一員であることを理解するのに役立ち、彼らは自分の専門分野以上のもののために必要です。ジェーンはジョーがやっていることに興味を持っているかもしれませんが、それには少し怖がっています。それを知ることは知識の伝達をより楽しくするのに役立ちます。あなたがしたいことのいくつかは次のとおりです。
- 現在のチームをクロストレーニングします。短期的には少し効率が落ちる可能性がありますが、アプリの1つのコーナーで学んだいくつかの教訓がアプリの他の部分に適用できる場合があります。しばらくの間、ジェーンとジョーがお互いのプロジェクトで一緒に作業するようにします。
- 知識を共有する文化を育む。私が働いていた会社には、「ブラウンバッグテックトーク」プログラムがありました。誰でも、承認されたトピック（通常はテクノロジーまたはソフトウェアプロセスの導入）について発表できます。会社は昼食を提供し、発表者は彼らの努力のために数百ドルを受け取りました。
- メンタリングは生き方であるべきです。他の人をメンタリングする目的は、あなたが自由に新しいことをできるようにすることであり、会社にとってあなたをさらに価値あるものにします。
- ランクを引き上げずに情報サイロの境界を越える方法を見つけます。楽しくするほど、脅威は少なくなります。あなたのチームの人々があなたの言うほど優れているなら、彼らは物事のあり方に完全に満足していないでしょう。あなたはチームがそれを処理できるかどうかの裁判官になる必要がありますが、「まあまあ」の週を選ぶことができます。いつもここから始めましょう。アイデアは、「まあまあ」の責任が何であるか、そして彼らがより良くしている問題を彼らがいかに解決することができるかについて皆に目を向けさせることです。あなたが最初に首をラインから始める限り、彼らは誰も彼らの仕事を取るために外出していないという考えを得るでしょう
一般的に、仕事をもっと楽しくしたい、そしてそれを行うには彼らの助けが必要だと彼らに印象づけるようにしてください。
インターンは良い考えかもしれません、彼らは現在の開発者の直属の部下になるので、彼らは脅威を感じません。
会社が成長するにつれて、古い開発者とインターンシップ後に成功した開発者の両方が必要になります。
これでうまくいくと思います。
新しいプログラマーを持ち込む前に、文書化された独自のレガシーを作成するのを手伝ってくれるように頼みます。
Wikiを使用するか、仕事のあらゆる側面に関するドキュメントの3環式聖書を使用します。
または、本当に詳細で完全なドキュメントが必要な場合は、テクニカルライターを雇って各プログラマーにインタビューし、すべてのドキュメントを作成します。全員が毎日、毎週、毎月、毎年行っています。
次に、そのwikiバージョンを作成し、プログラマーが更新/編集/参加/コメントできるようにします。
その後、時間とともに成長し、新しいプログラマーの学習曲線を改善するシステムがあります。
また、正直なところ、プログラマーが1つのコア領域に留まっているだけでは賢明ではなく、クロストレイン、クロスコアの作業に本当にお金を払う必要があります。
その後、1人が休暇を取るときなどに、既存の担当者を使用できます。
プログラマーの1人が病気になったときはいつでも、質問や問題を繰り返し彼に電話してください。
プログラマーの1人が休暇をとるたびに、質問や問題について彼に繰り返し電話をかけます。
彼らはすぐにthemだけでなく、会社がコア領域に責任を持つ単一の人を持たない方が良いことを理解します。
一般的に、あるマネージャーがドキュメントと後継者育成計画に突然気を使い始めると、プログラマーが解雇または解雇されようとしていることを強く警告します。これは、典型的な管理行動からの逸脱であり、プログラマーにあらゆる種類の警告信号を発することへの懸念です。
すべての人は、すべての手順とプロセスを文書化するように言われます
「 企業破滅の警告サイン 」のレベル3。
別の方法として、あるエッセイは、「 p or Out 」の文化を奨励することを示唆していますが、反論としては、財務的およびパワースペクトルに似た技術的なキャリアの梯子を持っている企業はほとんどありません。 （誤った）管理職のはしごが含まれています。
@ammoQが彼の答えで始まった完全なドキュメントのコンセプトに基づいて...
優れたマネージャーは、直属の部下のスキルを開発して、いずれかの部下がそれらを置き換えることができるように努めています。仕事の完全な透明性を提供する従業員は、すべての仕事を秘密にして隠しておく従業員よりも価値があることを開発者に理解させます。 「秘密の」開発者が今日亡くなった場合、失われた知識を取り戻すことは会社にとって莫大な費用負担となります。 「完全開示」の従業員が今日亡くなったとしても、会社は途方に暮れるでしょうが、それは破壊的ではありません。したがって、「完全開示」の従業員の方が価値があります。
解雇されないようにするために隠された知識を守ろうとする従業員は、昇進にも影響を受けません。開発者が今日負担している平凡なタスクを完了する人がいない場合、開発者をより挑戦的でやりがいのある立場に移動することはできません。日常的なタスクが完全に文書化され、完全に開示されている場合は、新しいジュニア開発者を雇って、前の開発者に記入して、より上級のポジションに昇格させることができます。
つまり、あなたも自分の行動を文書化し、各直属部下にトレーニングを提供する必要があります。そのようにして、あなたが今日死亡した場合、フルタイムの交換が見つかるまで、そのうちの1人があなたのために記入することができます。
誰もバスに襲われることを望んでいませんが、他の誰かのプロジェクトを急遽引き継ぎ、彼らのプロジェクトを維持する必要もありません。次に、誰もが廃業のリスクを負います。
サイロで開発している場合は、プロジェクト間で人を移動させる必要があります。ドキュメント、コードレビュー、または簡単なバグの修正から始めます。これが手に負えなくなる前に、コード保護/領域の小さな行為に対処する必要があります。
コードの一部に1人の専門家がいることは、効率の錯覚です。
休暇に行きたい人はいますか？
経営者の愚かな間違いのために、もっと多くの会社を倒してきました。 1人か2人のエンジニアが去っても、クラッシュして火傷することはありません。しばらくの間、もう少し頑張らなければなりません。シーシュ、私は四半期ごとに誰かを失うオフショアチームを管理しています。タスクの移動を開始します。今日。