コミュニケーション能力が低い開発者を管理する方法

私は、大企業内でライフサイクルの中間点にあるアプリケーションの小さな開発者チームを管理しています。残念ながら、これは通常、プログラミングタスクが「その他の技術的作業」に30/70分割されていることを意味します。この作業には以下が含まれます。

• DBA / Unix / Network / Loadbalancerチームとのさまざまなタスクでの作業
• 異なる地域でのハードウェアまたはインフラストラクチャの注文と配置の管理
• まだCIに移行されていないテストの実行
• 分析
• サポート/調査

開発者はすべて、これらのより日常的なタスクを行うよりもコーディングを好むと言うのは当然です。そのため、楽しいプログラミングジョブをチーム間で均等に配布するようにします。

ほとんどのチームは、独自のコンパイラ/ゲームエンジン/高頻度取引システムなどを作成するためのエリートプログラミングスキルを持たないかもしれませんが、「物事を成し遂げる」ことができ、他のチームと協力する優れたコミュニケーターであるため、採用されました、そしてここで複雑な官僚機構をいくぶんナビゲートします。彼らは優れた開発者ですが、優れた総合的な技術スタッフでもあります。

ただし、チームの1人のメンバーはおそらく平均以上のコーディングスキルを持っていますが、平均以下のコミュニケーションスキルを持っています。従来、以前の開発マネージャーは、上記のより日常的なタスクではなく、プログラミングタスクを提供する傾向がありました。ただし、大企業のIT部門で一般的に必要とされるバランスのとれたスキルセットを開発する適性を示している他のチームにとって、これが公平だとは思いません。

この状況ではどうすればよいですか？彼にもっとプログラミングの仕事を与え続けると、それがより速く行われることを知っています（そして逆に、彼は他の仕事をより遅く完了すると期待しています）。しかし、それは私の原則に反しており、単にあなたが好きではないタスクに悪いことによって、あなた自身のために「快適なニッチ」を切り開くことができるという考えを促進します。

clarifyみが原因でこの問題に対処しようとしていないこと、または言及したように「肩に欠けている」ことを明確にしたいと思います。バランスの取れたチームを維持する方法についてのアドバイスを探しています。チームは幸せでやる気があります。この質問に対するさまざまな答えを観察することにより、これを達成する方法について多くの異なる意見があるようです。

丸みを帯びた個人を持つことにあまりにも多くの努力をしており、丸みを帯びたチームを持つことに十分な努力をしていないようです。

何かが得意であることは何も悪いことではありません。実際、それが彼が雇われた理由でしょう。最初からプログラミングが得意な人がいることに感謝すべきです。

あなたは述べました：

...それは私の原則に反するものであり、あなたが好きではないタスクに悪いことをするだけで、自分にとって「快適なニッチ」を切り開くことができるという考えを促進します。

彼が平凡なプログラマーだったら、私は同意するでしょう。しかし、あなたはそれを言わなかった。あなたは彼が良いプログラマーだと言った。彼は他のタスクから抜け出すのが苦手ではありません。彼は単により良いプログラマーになることに努力を集中しているだけです。それには何の問題もありません。

マネージャーとして、誰もが「丸みを帯びた」ことを確認するのはあなたの仕事ではありません。s ***を確実に完了させるのはあなたの仕事です。そして、あなたはそれをしていません。実際、あなたは物事を成し遂げることを妨げる決定を下しています。

問題が何であれ、それを乗り越える必要があります。チームの生産性を低下させています。

あなたは、この男について「何かをする」というあなたの決定に対する他の答えで、ここでいくつかの熱をキャッチしていますが、私はあなたが言っていることを完全に理解しています。他のチームメンバーが「これらのよりありふれたタスクを行うよりもコーディングを好む」場合、彼らはあなたが貧しいコミュニケーターの悪いパフォーマンスに誰もが望むタスクだけを与えることで報酬を与えていることに腹を立てます。

あなたがチームの「良いコミュニケーター」の1人であり、そのスキルが問題の開発者に匹敵していると想像してください。あなたは電話を処理したり、キーボードのマウスをほとんど知らない他のITスタッフと仕事をしたり、ユーザーのサインオフの計画などを作成したりします。その間、不機嫌な開発者は、「コミュニケーションスキルが低い」ため、「楽しい」ものだけで作業しているユーザーを無視して、一日中キューブに座ってしまいます。

今、あなたは不機嫌な開発者は「平均以上」のスキルを持っていると言いましたが、彼が最高だとは言いませんでした。つまり、チームの3分の1、不機嫌な開発者のスキルレベル以上の優れたコミュニケーター開発者は、すべて腹を立てています。

彼らは不機嫌な開発者に悩まされているので、あなたの最高のパフォーマンスのスタッフから生産性を失う価値はありますか？あなたが決める必要があります。

あなたが男を解雇したくない場合は、これらのアプローチのいずれかを取ることをお勧めします：

1）より良いコミュニケーターになるように彼を指導する。これが実現可能かどうかは、あなただけが知ることができます。もう少し手を握るだけで助けになるかもしれません。一部の人々は、正式なビジネスインタラクションを恐れており、それを求められたときに腹を立てて表現しています。

2）お金または他の利益のいずれかで、「良いコミュニケーション」を奨励します。あなたが実際に優れたコミュニケーターを大切にしていることを明確にしてください。そうすれば、開発者はそれほど悩まされませんが、報酬は本物で意味のあるものでなければなりません。「地区マネージャーとの昼食」は削減されません。また、単なる一枚の「スタープレーヤー/クドス/アタボーイ」賞も授与されません。その余分なお金、余分な休暇、いくつかのフレックスタイム、昇給を制御するより高いアップといくつかの深刻な認識などがあります。

まず第一に、チームメンバーに非難をかけることは、経営スキルが低いことを意味します。

もし彼が本当にコミュニケーション能力に乏しいなら、彼の社会生活を非常に残念に思うが、実際、職場ではこれは彼の問題ほどあなたの問題ではない。それに直面してみましょう、彼は実際にあなたの退屈な作業環境、彼のパフォーマンスに影響する個人的な問題、またはあなたを殺すために密かに陰謀をしていることに飽き飽きしているかもしれません。

コミュニケーションには少なくとも2つかかります。結局のところ、貧しい人々のスキルを持つ人はあなたかもしれません。残りのチームメンバーがかなりうまくやっているということを決して気にしないでください。彼らはすべて、あなたが持っているコミュニケーションの不備を（知らないうちに）補い、幸いにも無視することができます。

とにかく、あなたから3枚の机に座っている人についてインターネットに尋ねるのはやめましょう。チャップに行って、実際に何か問題があり、解決できるかどうか尋ねてください。（または最適化または改善できる鈍いもの）

たぶん彼は自分の机の位置を嫌っているだけで（トイレに面しているのでしょうか？）、これは彼を機嫌が悪いのです。

ヒント：答えに耳を傾けてください。彼は人間ではなく、感覚的な人間です。

（例：特定の慣行の必要性と特定の決定の意味を詳細に説明してみてください。一部の人々は、船を崖に追い込まないような船長がいるという感覚を与えて、詳細を掘ります）

人は違います。マネージャーとして、あなたはチームを最大限に活用するために、人々を異なる方法で（しかし公正に！）扱う必要があります。

そうは言っても、おそらくソフトスキルの低い開発者にとっては良いでしょう。開発者が楽しんでいる（またはやりたい）コーディング以外のことは、これらのソフトスキルの多くを含んでいると考えます。彼らにその仕事に従事させ、理想的には副作用としてソフトスキルを向上させます。

多くの場合、人々は仕事から抜け出すために何かを悪くはありません。彼らはそれを楽しんでいないか、それに対する適性を持っていないので、彼らはそれで悪いです。あなたは後者を助けることができないので、前者に取り組んでください。

30/70分割は、すべての問題の始まりです。開発者がそのような分割に満足しているのを見たことがない。

開発者は10、15％の他の作業に満足している（そして、線量が適切なときは楽しいので自分自身も満足している）が、30％は多すぎると見ている。「他の30％の仕事」が嫌いな人は1人しかいないので、他のチームメンバーは自分の心を話すのを好まないと思います。

また、「生産性の計算」をより現実的な数値に調整することも重要だと思います。「コンテキストスイッチ」での損失は避けられないため、100％になることはありません。

• ^{30 + 70、つまりプログラミングと他の作業を切り替えるときに最大100％の生産性を合計することは、実際には決して起こりません。おそらく20 + 50または20 + 40程度です。コンテキストスイッチは、特にソフトウェア開発者にとって苦痛です。興味がある場合は、この記事を読んで、なぜそれが良いのかを説明してください：プログラマーを起こさないでください！
  生産性を重視するプログラマーは、当然そのような損失に不満を感じるでしょう。}

ジョブの一部としてテストを実行する場合、テスターに​​渡すことを検討しましたか？プログラマーができるという事実（経験豊富なプログラマーなら誰でもできるはずだ）は、そうすべきだという意味ではありません。テスターもそれを行うことができ、それをより良く行い、「コンテキストスイッチ」で生産性の損失を被ることはありません。

QAリソースをどのように活用するのか不思議に思うもう1つのポイントは、サポート/調査についての言及です。私が一緒に働いていたプロのテスターは、そのようなことで「先発」をする傾向があります。

• ^{元テスターとして、私はそれらを非常によく理解しています-実稼働の問題は、テスターとして（テスターとして）テストカバレッジ（「この問題はテストによって適切にカバーされていますか？」欠陥の優先順位付け（「テストでカバーされ、リリース前に報告されていたが、当時適切な優先度/重大度を設定していませんか？」）}

優れたテスターに​​とっては、サポートの問題の調査をいつデベロッパーに渡すかを見つけるのは非常に簡単であり、これはあまり頻繁には起こりません。これで開発者を過負荷にする理由は、単に私の心を逃れます。私がすでに書いたように、彼らは確かにそれを行うことができます（私は一般的に上級開発者がQAが行うことを行う方法を知っていることを期待します）が、それは彼らがすべきであることを意味しません。

私はこれについて2つのことを言っています

1. コーダーまたはソフトウェア開発者を募集しましたか？
   あなたがソフトウェア開発者を検討しているとき、あなたが言及したすべてのことはソフトウェア開発の一部であり、特定のタスクだけを募集していない限り、これらを無視することはできません。IMO全体のソフトウェア開発の50％がコーディングの残りであるのは、すべて設計、分析、テスト、文書化などです。

2. 誰も完璧に生まれません。
   それはあなたがすべてに優れている人を見つけることができるということだけではありません。あなたは彼らに苦労させ、彼らに物事を学ばせる必要があります。

マネージャーとして、あなたはそれらを最大限に活用する必要がありますが、長期的には問題に直面する可能性があります。私はこれが得意ではないという気持ちを彼らに伝えてください/私はこれを行う余裕はありません。ほとんどすべての人が平等に扱われ、チームから最も効率的な出力が得られます。

スタッフの全員が同じ役職/職務記述書を持ち、職務記述書にあなたがリストしたものがすべて含まれている場合、このプログラマはこれらのプログラマ以外のタスクをさらに割り当てて、これらの他のスキルを磨く必要があります。同様に、他のスタッフがプログラミング以外のタスクに継続的に取り組む必要がある場合（使用するか失うか）は、プログラミングスキルが向上しません。

しかし、私はまだあなたの主な優先事項はおそらくあなたの締め切りを守るべきだと思います（あなたはまだ仕事を均等に分配している間にそれを行うことができるかもしれません）。

編集： あなたが小さなチームを持っている場合、おそらくすべてのメンバーが複数の帽子を着用できるようにすることは理にかなっています。十分な大きさのチームがある場合は、おそらく、さまざまな分野に特化したグループを持つことが理にかなっています。あなたの投稿からは、専門家のグループを持つのに十分な規模のチームがないようです。

元の投稿から、この開発者のコ​​ミュニケーションスキルについて正確に何が欠けているのかは明確ではありません。会議に出席したり、計画/調整型の作業をしたりすることに興味がない（たとえば）ことは、必ずしもコミュニケーション能力が低いことを示しているわけではありません。たぶん、開発者はこの種の作業がマネージャーの仕事であると感じ、開発者としての生産性を低下させるのでしょうか？それとも、彼は組織のオーバーヘッドが多すぎると感じ、これは彼が全体的な時間の無駄だと感じているものに対する抗議の一形態ですか？結局のところ、人々が一日中話し合い、何も成し遂げられないという逆の問題もオフィスではかなり一般的です。

この開発者と対立しない方法で話し、なぜ彼が非プログラミングタスクを避けるのかを理解しようとすることが重要です。それはおそらく単一の理由ではなく、さまざまなタイプのタスクと同じくらい多くのさまざまな理由があるかもしれません。会話の目的が、チームのすべてのメンバーのチームの生産性と仕事の満足度を効果的に向上させる方法を学ぶことができるようにすることであることを彼が理解していることを確認してください。今こそ、あなたが耳を傾ける時間であり、反抗的な反応についての彼の懸念を主張したり、それに対処しようとするのではありません。おそらく、他のチームメンバーとも会う必要があります。おそらく、彼らはこの男に仕事のチャットティア側に集中しながら重い開発作業を任せることにまったく問題がないでしょう。

この会議の後、あなたが行った会話について少し時間をかけて過ごし、この従業員の視点をオープンマインドで考えてみてください。たぶん、あなたの最初の気持ちは正しかったので、彼はあなたが彼に開発を促すべき重要なスキルを欠いているのかもしれません。または、彼はあなたの仮定にいくつかの有効な挑戦をしたかもしれません。他のチームと協力して、いくつかのプロセスを正式化し、冗長なコミュニケーションの必要性を減らすことができます。たぶん、他のチームは体重を減らしていないので、経営陣と友好的なチャットをする必要があります。あなたが考慮していないかもしれない多くの可能性があります。

最後に、そして最も重要なこととして、個人とのフォローアップの会話、または適切な場合はチーム会議を行います。影響を与える力の範囲内にある実際の組織上の問題を特定した場合は、従業員に仕事の状況を改善するために取ろうとしている行動を伝えてください。個々の従業員が間違っているとまだ信じている場合は、その従業員と一緒に座って、彼から必要な変更とその理由を説明してください。開発者は、論理的/実践的な説明によく反応する傾向があります。「すべての楽しい仕事をするのは仲間にとって公平ではありません。すべての人が純粋な開発者であることを望みますが、それは状況の現実ではないため、くだらない仕事の負担を分かち合う必要があります。」

もちろん、この男が不機嫌そうなだけで、なぜ彼が不幸なのか、理由に反応せず、同僚から尊敬されない理由をあなたに伝えることを拒否します...まあ...パフォーマンス改善計画の時間です。

チームを管理しようとして、全員の意欲を高めたいと思いますが（公平感があると助かります）、最高のプログラマープログラミングができずにプロジェクトを犠牲にしていますか？つまり、これがポイントではありません。

あなたはあなたの最高の開発者を十分に活用していない、または失うリスクを恐れていませんか？あなたの仕事は、これらのタイプの義務を全員から試して緩和することです。

平等に扱われても、全員を同じように扱っているわけではありません。他の人が、より多くのプログラミングタスクを割り当てるために、プログラミング以外の義務を緩めたい場合、どちらも得意ではないというリスクを冒していませんか？

編集： あなたの個人的な感情以外は、問題を特定していません。ある時点で、コミュニケーションの欠如がプログラマーの妨げになります。他の人はresみを示し、彼らの仕事は苦しむかもしれません。これまでのところ、あなただけが問題を抱えているようです。他に共有していないものがない限り？

編集2 最終的には、誰もが特別なお願いをするつもりです。この人は、より少ないコミュニケーションとより多くのコーディングを行います（すべてのアカウントでそうするべきです）。他の誰かが少し後で来たいと思っています。別の人は、期限を守るために会議をスキップする必要があります。グラフィック担当者は、より大きなモニターを取得します。スコアを維持することに重点を置きすぎると、何が重要かを忘れてしまいます。

私は多くのスクリプティングを行う不機嫌なLinux管理者であり、コミュニケーション能力が低いことに気づきました。私はあなたの男によく似ています。実際、パフォーマンスのレビューで私が熱中するのはそれだけです。一方、私はチームを継続的に革新と問題解決に導き、展開している新しいプラットフォームへの道を作成して導きました。そして、チームを多くの時間と会社に救いました。自分になることを許されることでたくさんのお金。

私の上司は彼の家族/妻と私たちの会社の上級管理職に彼の職を辞めるように頼まれた....同時に。彼は、責任を公平にバランスさせるためにたゆまぬ努力をし、自分で多くの負荷をかけました。部門外の人とのやり取りの中で、彼に戻ったコミュニケーションの誤解があった場合、彼はそれを素早く修正しました。彼は「上向きの管理」が苦手だったため、緊急事態になるまで私たちのチームが最後にリソースを獲得し、その後、同社はそれらのツールを使用するチームに相談することなく、テストされていないハードウェアの売り上げの高いベンダーに過剰な支払いをしました。「バランスのとれた」チームを作成するために、彼はタスクリストをミクロ管理し、タスクのバランスをとってチームメンバーが得意でない分野のスキルセットを改善できるようにしました。その結果、コードが破損したり、実装の設計が不十分になったりしました。作者以外の人々は、その壊れたコードのサポートタスクを「学習」できるように特別に割り当てられましたが、実装、コード、およびテストが不十分なため、チームメンバーと実際のチームメンバーの間には多くの貧弱な善意が生まれました。有毒チーム状態への迅速なルートである「非難ゲーム」の発生の増加。

私の上司は、ジュニア管理者の役割から来て、彼の方法を改善した穏やかな、収集された個人です。彼は良い決断を下し、チームメンバーに独自の優先順位を設定することに大きく依存しています。彼は優れたコミュニケーターであり、私のチームによって表明されたコミュニケーションの問題、アイデア、ニーズに冷静に対応し、上司と協力して対応します。彼はたゆみなく「上向きに働く」。彼は大規模なアーキテクチャの変更を行うのが遅く、環境を変更する前にチーム全体と徹底的に相談し、チームメンバーの専門分野に頼ることに満足しています。

新しいマネージャーの下では、ダウンタイムがほぼゼロになり（サポートタスクに費やす時間の割合が約40％から約10％に低下しました）、チームの満足度が上がりました。 「3年から5年ごとに新しいハードウェアで銀行を破る」から、5年間で年間約100万ドルを節約する継続的な買収計画に移行する予定です。その計画は、以前のマネージャーでは決して起こらなかった草の根プログラムでしたが、新しいマネージャーによって積極的に上級管理職にプッシュされ、チームのスキルセットで多くの相乗効果を見つけることに依存していました。CIOから非公式に言われたのは、私たちは今では会社で唯一「本当に一緒になっている」チームであり、作業環境への干渉をできるだけ少なくし、できる限り多くのリソースを問題領域に向けてシャッフルします。これは事実であり、他のチームのワークロードを混乱させましたが、サポートの「コスト」をさらに低くしていますが、それらのチームのサポートの「コスト」も低くしています。

開発者がスキルセットを向上させる場所は、学校内または自分の時間です。彼らが物を作る場所はあなたの会社の時間です。物を生産する最良の方法は、彼らが最もよく知っているものを生産することです。1人の開発者が快適ではない分野で作業する場合、専門のチームとして働く2人目の開発者を引き込むか、専門の開発者がコードを記述してドキュメントと図を作成する必要があります。サポートタスクをコードを書いた人にルーティングします。はい、これにより「バス要因」と呼ばれるものが増加します。スペシャリストがバスにぶつかった場合、部門がスピードバンプにぶつかる可能性が高くなります。（または解雇、または仕事の切り替え、または...）それの真実は、その恐怖による生産性の損失は、「バスイベント」が発生したときの実際の損失よりも桁違いに大きいということです。起こる。「バスイベント」で一般的に起こるのは、スペシャリストの仕事の継承者が自分のイメージでそれをリメイクし、それが最も効果的にサポートできるようにすることです。オン。

最善を尽くせる人に物事を割り当てます。彼らを支援させ、彼らの仕事を文書化してください。彼らの創造性を育み、気を散らしたり、細かな管理をせずに集中できるようにします。それ以外はすべて管理学校のBSであり、残念ながらあなたの会社が泳いでいるように聞こえます。それはあなたのチームも泳ぐ必要があるという意味ではありません。

企業の観点から見ると、優れたマネージャーは企業の価値を促進すると同時に、それらの価値に従ってタスクを実行します。IT従業員の観点から見ると、優れたマネージャーはチームにできる限り迅速かつクリーンに行う権利を与え、週末のMBAクラスで学んだ価値を下層部の喉に押し付ける上級管理職に対する糞便の障壁として機能します。あなたは会社員であり、それはあなたのチームにとって最高ではないかもしれません。「良い」コミュニケーションスキルを持つ人は、それを言うには丁寧すぎます。

• 従業員が自分の職務記述書でコミュニケーションスキルがどれほど重要かを知っていることを確認してください。彼/彼女と協力して改善してください。
• そのようなタスクでは、他のチームメンバーと同じくらい良いと主張しないでください。
• 考えている原則に従ってタスクを割り当てます。タスクをスキルに効率的に割り当てることと、公平性/楽しみのバランスを見つけます。

これらは単なる要約のアイデアであり、誰かがこれらのポイントを盗み、他の答えの1つに折りたたむことを願っています。;-)

パフォーマンスがすべてです。彼にプログラミングタスクを与えます。これを部門の他のメンバーと話し合ってください。必要に応じて、誰かをcomタスクに参加させるか、comタスクのみでタスクを実行します。楽しむというプログラミングを考えないでください。すべてがあなたのPOVから「楽しい」です。

そうしないと、管理が非常に難しく、本来よりも効果の低い状況が生じます。

なんて素晴らしい質問でしょうか。それは、すべてのチームリーダー、スーパーバイザー、技術者のマネージャーが考えるべきものです。私はあなたのアプローチが好きです、誰もが「楽しい」タスクを取得する必要があります。さまざまなタスクを拾い上げることができ、クロストレーニングを受けたチームを持つことで、ピータービルト原則が「不可欠なチームメンバーがチームを離れたり、息を gasんだりする」ことを防ぐことができます。

今、多くの投稿で指摘されているように、仕事は公平ではなく、そうすべきではありません。マネージャーは、どれだけ価値のある作業が行われたかを測定します。

• マネージャーは、スキルに基づいてタスクを個人に一致させます。
• 優秀なマネージャーは、チームのスキル、成長、関心、生産性に基づいてタスクをマッチングします。
• 優秀なマネージャーは、少しの助けとガイダンスでチームにこれをさせます。すなわち、マネージャーがそれに一日中費やしていない。

優秀なプログラマーに相談して、学びたいことがあるかどうか尋ねてください。彼が他にどんな仕事を受け入れますか？彼は他のチームメンバーのプログラミングを支援できますか？はい、私はコミュニケーションが問題であることを知っているので、おそらく彼はそれに取り組むべきです。

これをパッケージ化する別の方法は、タスクのリストを用意して、各スタッフが何かを選択できるようにすることです。優秀なプログラマーに最初に選んでもらいましょう。前もって彼に警告し、タスクのリストをさらに良く見せれば。

あなたが抵抗を得るなら、あなたはほとんど常に変化でそれをします、セールスポイント、彼にとって価値のある何かを見つけてください、なぜ彼は利益を得るでしょうか。最後に、あなたは彼にチームのためにそれをするように言うことができます。

また、ミスや生産性の低下が始まることを期待します。これは人々が学んでいる兆候です。このプロジェクトは苦労するかもしれませんが、次はより良いでしょう。

最後に、作業を確実に行うことはあなたの仕事ですが、スタッフを成長させ、プロセスに参加できるようになればさらに良いでしょう。物事を確実に成し遂げるための最善の方法は、何を成し遂げる必要があるかを知り、結果を所有するチームであると言う人もいるかもしれません。

編集：ああ、試してみてください、上記のアドバイスは長年のミスから来ていますが、チームの成長を助けたいと常に思っていました。

最良の答えはすでに受け入れられていますが、マネージャーが作業できるのは「タスクの割り当て」だけではないことを誰も指摘していないことに驚いています。「平均以上のコミュニケーションスキル」も持っている「平均以上のプログラマ」は、同様のプログラミングスキルと弱いコミュニケーションスキルを持っている人よりも（他のすべてが同等で）有料/上級開発者である必要があります。これは、チームから認識される「お気に入り」を相殺するのに役立ちます。（一部の組織では、「要件分析」で平均以上のスキルを持ち、他の分野で平均以下のスキルを持っていることは、行われている作業の種類により、会社にとってはるかに価値があります。マネージャーとして、これを処理する方法を決定する必要があります）

気を付けるべきもう1つのことは、問題の人にプログラミングタスク以外の何も与えないことは、長期的に隔離されることにつながります。他の部門/チームから見えるようにし、他の部門/チームから見えるようにするために、他のタスク（ただし、うまくいくことができ、ネガティブフィードバックを設定しないでください!!）

彼らが見た場合に最後に...他のチームメンバーと、チェックインいかなる定期的にチームの割り当てにおける不平等を。これはあなたにとって大きな懸念かもしれませんが、他の人のリストでは＃15です。

あなた自身の評価では、この1人のプログラマーがチームで最高であるため、ある意味では、その人に目的の仕事を与えることは「公平」です（最高の能力を発揮した結果）。結局のところ、おそらくこの会社で働きたいと思っていたのに、まったく雇われなかった人たちがいたでしょう。しかし、彼らがこのコーディングを行わないと「公平」ではないと言う人はいません。

公平なアプローチは、より多くのコーディングを行うことを望んでいるチームのスキルの低い別のメンバーに伝えることだと思います。 xとyのスキルを学んだことを実証できれば、次に来ることです。」

答えた他の人たちのように、私はあなたの立場を理解しており、同様の野心を抱いています。

それは、それを実行するのに最も適した人々にタスクを与えることが理にかなっていると言えますが、動的で柔軟なチームを提供するために人々のスキルを広げることにも意味があります。

この人が自分の役割で非コーディング要素を行う必要があるが、彼のコミュニケーションスキルが本当に必要とされるよりも劣っている場合、彼は改善する必要があります。何らかの開発レビュー/評価システムがあると仮定して、今こそ問題を提起する時です。

重要な問題は、あなたが彼に必要なものを明確に計画し、彼が遵守するスキルを持っているかどうかを評価し、それを可能にするためのトレーニング計画を立てることです。トレーニングは必ずしも正式なものである必要はありませんが、必要なスキルを習得できるようにする必要があります。

彼が単に気にすることができない場合、それは最終的に懲戒処分の問題になります。あなたが試みてサポートされたにもかかわらず、彼が能力を持っていない場合、懲戒処分が可能かもしれません（私はそれは厳しいと非生産的だと主張します）が、あなたは彼がそうでないことを受け入れることができます特定のタスクをカットします。

男と話すことはあなたの最初の寄港地の1つです。あなたは彼が自信や洞察力に欠けていることに気付くかもしれません。また、彼は非常に敏感であり、自分自身を改善する機会を高く評価するでしょう。

あなたはすべてのうなり声の仕事をするために後輩を雇うべきです、そして、彼らが彼/彼女が援助を求めるもので彼を助ける必要があることを皆に知らせてください。

彼らは彼らの能力のために「平均以上」のコーダーを煩わす傾向があり、チームの他のメンバーは新たな不利益を被ります。後輩は一から学ぶようになり、会社は最終的には丸みのある従業員になります。

誰もが同じコミュニケーションスキルを持つことを期待することは、不自由な人にチームの他のメンバーと同じくらい速く走るように教えることを期待するのと同じくらい合理的です。

人は異なり、スキルも弱さも異なります。優れたプログラマーをコミュニケーションスキルで他の人に追いつかないという理由だけで解雇することは、彼が他の人ほど速く歩けないために足の不自由な男を解雇するようなものです。それは倫理的な観点から不公平であり、仕事を成し遂げることはあなた自身の経済的利益に反するでしょう。

過去にこれを実行できなかった場合は、最初にアスペルガー症候群について読んでください。貧しい社会的スキルは、その症候群の主要な指標です。

第二に、好きな人を雇って解雇できますが、従業員の強みと弱点に対処できないと、平均的なプログラマーがたくさんいます。 。

アダムという映画があります。この映画では、彼が期待していなかったものを書いたという理由だけで、プログラマーが解雇されます。彼のアイデアは雇用主に多くのお金をもたらすことができましたが、彼は彼の「原則」に集中していたため、チャンスを利用できませんでした。