私の同僚はナイスガイですが、彼のパフォーマンスは平均以下です。上司に伝えますか？[閉まっている]

私は約3か月前にプロジェクトに参加しましたが、それまで遅れていたため、新しく雇われた1人の開発者によって開発されていました。公平を期すと、このプロジェクトは、微妙な点が多く、比較的複雑な医療機器へのインターフェイスであるため、会社で経験のない人物を1人プロジェクトに配置することは、経営者の観点からはおそらく悪い決断でした。

とにかく、いったん作業を開始すると、...うまくいきませんでした。UIは素晴らしく見えましたが、実際には何もしませんでした。繰り返しになりますが、これは多くの場合、この開発者がデバイスへのインターフェイスを作成する準備が適切に行われていないためです。しかし、適切なコードが壊れやすく、保守が非常に難しいこともすぐにわかりました。

今、私は世界で最高のプログラマーであると主張していません。私は、私よりも優れた開発者である非常に頭の良い人たちと仕事をしています。しかし、できる限りシンプルで堅牢なコードを書くことは非常に難しいです。チェックインをテストします。コードが乱雑になり、作業が難しくなっていることがわかった場合は、変更します。私は同僚がより良いコードを書くのを手伝うために、同僚と何度か話をしました。a）彼は20年以上の分野での経験があり、私は5歳しかいません。b）彼はいわゆる「UXエキスパート」として雇われ、他の人は彼を経験豊富な個人と見なしています。

とは言っても、私はそれを見ないだけです。彼はとてもいい人であり、理にかなっていますが、壊れやすいコードを何度もチェックインし、最も楽観的なケースでのみ動作し、10回のうち9回は彼の作品のバグを修正します。彼のコードはアマチュアっぽいようで、明らかに、彼が雇われたときに持っていたと主張するレベルの経験を持っていません。彼のコードのリファクタリングとバグの修正に費やした余分な時間が私に負担をかけたというところまで来ました。私がそれを見る方法には、2つのオプションがあります：

1. 何もせず、この製品が時間通りに出て、堅牢であり、将来的に彼が失敗するのを待つために、お尻をつぶしてください（最初のリリースの後、このプロジェクトで彼と一緒に仕事をするつもりはありません）
2. 上司に彼のパフォーマンスについて話してください。私の上司は理にかなった人ですが、このアプローチをとるのは気まずいです。私は同僚を「バッシング」するのが好きではありません（より良い用語がないため）同僚と私は彼がそれを取る方法を知りません。

だから、それはそれについてです。彼の実装が機能しない理由や、コードをより保守しやすくする方法を説明することで、同僚とこれを解決しようとしましたが、彼は同じ間違いを犯し続けています。他の人が同じような状況をどのように扱っているのか、特に現在管理職の人たちがどのように扱っているかを聞くことに非常に興味があります。アドバイスをありがとうございます。

少なくとも、彼がUXの人として雇われた場合、彼から本当に素晴らしいコードを期待する人は誰もいないという可能性を考えます-彼のコードは基本的にUXの概要を示すプロトタイプにすぎないと期待するかもしれません。それに基づいてプロダクションコードを記述するのは、他のコーダー次第です。

今、私は確かにそうだと言っているわけではありませんが、それは驚くほど驚くことではありません。少なくとも私の経験では、UXの人々が主にプロトタイプやストーリーボードなどを作成することはめったにありません。どちらかといえば、その男が特にUXスペシャリストとして本当に雇われていたら、私は彼がコードをチェックインするという概念にまったくショックを受けています。私はそれが行われたことを見たことがないと確信しています。

その人が本当にUXの専門家である場合、治療法としては、より良いコードを生成させることではなく、完全にコーディング（少なくともプロトタイプ以外）から抜け出すことです。彼は正直だ場合は良い UXの設計では、本当の間違いであっても、すべての生産コードを書くために彼を尋ねると、おそらくです。代わりに、彼はおそらく（せいぜい）UXプロトタイプサンドボックスで作業する必要があります。そこでは、彼の結果を使用して、生成される実際のコードの次のラウンドをガイドします。

私は常に、プロジェクトに影響を与えるものについて上司に通知するというルールを設けようとしています。肯定的および否定的に...そしてこのような場合、私はそれを書いた人とは対照的に、コードのようなものを非難しようとします。同僚を叩いているようなものではなく、製品の品質を向上させようとしているように聞こえます。

管理の観点から、この状況で従業員に対処する一般的な方法は3つあります。

1. 弱点を制御する
2. 彼らの強みを生かして
3. それらを取り除きます（実際にはあなたの選択ではありません）

外部の助けを求めることで、彼らの弱点を制御します。

ちょっとボス、私はコードの状態について少し心配しています...それは非常に壊れやすく、多くのことを壊しています。信頼できると思う状態にするには、ある程度の作業が必要です。良いデザインを思いつくことができるかどうかを確認するために、1人か2人で建築家の一人を借りることができる可能性はありますか？

他の人にプロジェクトへの参加を求めているのではなく、短期間の「専門家の入力」をもっと求めているのです。アーキテクトが望むのであれば、必要なドキュメント、UMLダイアグラム、コードスニペットを作成します。彼らはコードがどのような状態にあるかを見るでしょう、そしてあなたの上司はあなたの意見をエコーする誰かを持っているでしょう。

ミーティングから、あなたと他の開発者の両方が彼が多くのことを台無しにすることなく従うことができる、より良いデザインを得ることができます。多くの場合、これが設計と仕様の目的です。悪い開発者ができるダメージを減らすことです。

彼らの強みを生かして

こんにちはBoss、私はプロジェクトxのコードを扱っていますが、それは素晴らしいです。一方、コードはかなりの作業を使用する可能性があります。[UXガイ]がUXにもっと集中できれば、プロジェクトはより良いものになると思いますが、より安定した状態にするためにリファクタリングを行います。UXが安定したら、プロジェクトbはおそらくMidasタッチを使用できます。

ここで、あなたの上司はそれを見通すでしょう。他の開発者はあまり良くないということを彼に言っているのですが...少なくともあなたはそれについて嫌いな人ではありません。そして、もし彼がUXの仕事に正直に本当に優れているなら、彼は各プロジェクトに飛び乗って安定性のあるポジションを見つけ、ユーザビリティの観点から素晴らしいものにするかもしれません。彼もその方が良いと思うと思います。

彼の間違いを繰り返し修正するのを止めてください。彼は学びません。しません。

プログラミングは主に論理的なタスクですが、メモリの再収集も伴います。よくあるコードを頻繁に書くとき、最後に解決策を実装した方法を思い出します。彼が正しいコードを実装したことがない場合、彼が同じ間違いを繰り返し続ける理由がわかります。

彼が間違ったことを見せて、おそらく最初にそれを修正します。同じインシデントがさらに発生した場合は、あなたに見せた修正を実装してもらいます。

私はいくつかの理由で本当に注意します：

1. 最初のリリース後に彼と一緒に仕事をしないことをどのように確信していますか？あなたの経営者は、「なんというチーム、彼らが一緒にこの素晴らしさをどのように提供したか見てください！」一緒にいたい

2. あなたが上司に行った場合、あなたは自分の立場を説明しようとしてどの程度技術的になりたいですか？同僚のパフォーマンスの低下について、どのくらいのドキュメントがありますか？

それらは私があなたが尋ねたことから注意したい落とし穴です。コードについて彼に聞いて、なぜそうなっているのかについて正当な理由があるかどうかを確認することをお勧めします。おそらく彼はそれをコーディングしている間に輪になって走り、それがいくつかの問題を引き起こしているのでしょう。円は、あなたが何かをコーディングし、一連の変更を通じて、最終的に誰かの変更リストがキャンセルされるときに開始したのとほぼ同じポイントで終わる場所です。私はそれが変化し、変化の後に元に戻すのが非常に早く疲れる状況にありました。

彼の仕事をすべてやり直さずに、プロジェクトを失敗させた場合の結果は何ですか？あなたへの結果は私が意味する。

確かに彼の経験レベルと位置の誰かが偶然そこにたどり着かなかったので、彼の仕事はあなたが感じるほど悪くはないか、彼のキャリア全体は彼を運ぶあなたのような人々で構成されています。

いずれかのプロジェクトで週に50時間以上作業している場合、それらは深刻な問題であり、PMの注意を喚起しないか、辞めることで自分自身を傷つけます。私は、HARDERではなくSMARTERを使用することを強く推奨しています。

スマート50を使用し、プロジェクトがうまくいかない場合、それはあなたの障害ではありません。彼の無能のために失敗し、彼らがあなたを責めるなら、それはおそらくあなたがとにかく働きたい環境ではないでしょう。

私の多くの友人は、失敗や成功があなたのキャリア全体に直接影響することを理解していない場合、失敗を恐れているので、間違った管理されたプロジェクトで典型的な40 /週以上よく働きます。

プロジェクトの80％以上が失敗しましたが、それは恥ずべきことではありません。

そのピアレビューと呼ばれます。あなたの上司はあなたにそれを期待しており、彼の貴重な開発者の時間がどこに費やされているかを知らされなければなりません。私は彼がこれについてすでに知らないことに驚いています-しかし、再び、私は悪化しました。

他の人の観点から彼に話をしないでください、あなたが行う毎日の仕事の観点から彼に話してください。それが彼のコードを破棄することを意味するのであれば、それもそうです。チェックインリンクなどを用意して、日常業務の何らかの証拠を提供します。あなたのマネージャーはあなたからまさにこれを望んでいるかもしれません-彼は20年のUXを持ち込み、あなたは堅牢なコードを手に入れます。ワイヤーフレームを作成する代わりに、プロトタイプレベルのコードを作成するだけです。上司に相談してください。

そして、あなたが彼のベビーシッターとして雇われていないことを願っています。がんばろう。

彼の作品を書き直したりやり直したりする必要がなかった場合、プロジェクトはより早く開始されますか？それは予算の範囲内で役立つでしょうか？個人的に懸念を表明するために、あなたはバッシュする必要はありません。ここで、ほとんどの人が間違いを犯し、ソリューションを提供せずに文句を言います。

結果を改善する上司に提供できる具体的な推奨事項はありますか。より良いドキュメント？堅牢なユーザーテスト？あなたの目標は、会社、プロジェクト、同僚、そしてあなた自身を成功させることです。問題がないふりをすることで、4つのうち3つが失敗することが保証されます。そして、あなたは幸運な人ではありません。

あなたはすぐに上司に行き、ここであなたが言ったことをはっきりと彼に伝える必要があります。

まず、これは医療機器です。バグがある場合、誰かが負傷したり死んだりする可能性はありますか？人々の生活や健康に依存するコードは、人間にとって可能な限り堅牢である必要があり、最適なシナリオのために楽観主義者によって書かれたバグだらけのジャンクではありません。

さて、私の元マネージャーの帽子をかぶっています...あなたの上司がこれを知っているかどうか、それが彼へのニュースなら彼の反応がどうなるかはわかりません。しかし、彼が知らないなら、彼はする必要があります、そして、あなたはこの情報を隠すことによって彼を疑うべきではありません。この方法でコーディングしている同僚に問題がなければ、彼に知らせてくれます。

私は何年も前にこのような状況に遭遇しました。「ネットワーキングの第一人者」と私は請負業者として概念実証に取り組んでいた。実際、彼はほとんど何もしていませんでした。ある日、上司から、デモが予定されていると言われました。すぐに、「ネットワーキングの第一人者」は多くの無言の電話をかけ始め、ついに彼はデモの前に別の契約ギグをするために去るつもりだと私に言った。上司を一人にできるとすぐに、私は彼にそれについて話しました。彼は「ネットワーキングの第一人者」を捨てて、私が推薦した誰かを連れてきました。彼は、「グル」が3か月でしたよりも3日間多くのコードを作成しました。デモは大ヒットでしたが、私が黙っていれば、プロジェクトは完全に失敗していました。

はい、上司に言ってください。それから、あなたがそれがあなたがそこに場違いなものではないかどうかを見るでしょう。チームがどのように働いているかを知ることはマネージャーの仕事であり、上司がまだ気付いていない場合は、適切なコーディングのためにあなたと同じくらい気にしないかもしれません-私が行った多くの多くの場所のように。

そして、これらすべての異なる職場の中で、すでに多くの友人たちのうちの5人の友人を手に入れた場合、それはすでに大きな数です。彼らにはみんなナイスガイとギャルがいましたが、あなたは仕事をすることで友情を失うことはありません-あなたがそれらを失った場合、それは良いことです。あなたの場合、彼はあなたよりも仕事を評価しているでしょう。

確かに、彼を解雇する試みではありません。これは、プロジェクトの幸福に対する懸念を示しているだけです。だからこそ、皆さんがそこにいる（またはそうあるべき）のです。

結局のところ、彼と話をしようとしましたが、何もしなければ、実際にそこで仕事を危険にさらしています。