私は約3か月前に、それまで遅れていたため、1人の新しく採用された開発者によって開発中だったプロジェクトに配置されました。公平に言うと、このプロジェクトは、多くの微妙な要素があり、比較的複雑な医療機器へのインターフェースであるため、会社での経験のない1人をプロジェクトに配置することは、おそらく管理上の観点からは悪い決定でした。
とにかく、私がそれに取り組み始めたとき、私はそれを理解しました...まあ、それはまったく機能しませんでした。 UIは見栄えが良かったのですが、実際にはほとんど何もせず、何をしたのかが間違っていました。繰り返しになりますが、公平に言うと、これの多くは、この開発者がデバイスへのインターフェースを作成する準備が適切にできていなかったためです。ただし、配置されているコードは壊れやすく、保守が非常に難しいことにもすぐに気付きました。
今、私は世界で最高のプログラマーであると主張していません。私は私よりも優れた開発者である多くの非常に賢い人々と仕事をしています。しかし、私はできる限りシンプルで堅牢なコードを書くために一生懸命努力しています。チェックインをテストします。コードが乱雑になり、早い段階での作業が困難になっていることがわかった場合は、コードを変更します。彼がより良いコードを書くのを助けるために、同僚と何度か話し合いました。これは少しトリッキーです。a)彼は20年以上の分野での経験があり、私はたった5人しかいません。b)彼はいわゆる「UXエキスパート」として雇われており、他の人は彼を経験豊富な個人と見なしています。
そうは言っても、私にはそれが見えません。彼は非常にナイスガイであり、合理的ですが、脆弱なコードを何度もチェックインし、最も楽観的なケースでのみ機能します。10回のうち9回は、彼の作業のバグを修正します。彼のコードは素人っぽいだけで、彼が雇われたときに持っていたと主張しているレベルの経験を明らかに持っていません。私が彼のコードをリファクタリングし、彼のバグを修正するために費やす余分な時間が、私に大きな負担をかけるようになりました。私の見方では、2つのオプションがあります。
それで、それで終わりです。彼の実装が機能しない理由、または彼のコードをより保守しやすくする方法を説明することによって、同僚と一緒にこれを処理しようとしましたが、彼は同じ過ちを犯し続けています。他の人々が同様の状況、特に現在管理職にいる人々をどのように処理したかを聞くのはとても興味深いです。あなたが私に提供できるアドバイスを事前にありがとう。
私は少なくとも彼がUXの人として雇われた場合、誰も本当に期待しない本当に素晴らしいコードがないかもしれないという可能性を検討します-彼らは彼のコードは基本的にはUXの概要を示すプロトタイプであり、それに基づいて製品コードを作成するかどうかは他のプログラマー次第です。
さて、確かにisとは言っていませんが、驚くほど驚くことではありません。少なくとも私の経験では、UXの人々が主にプロトタイプやストーリーボードのようなものを制作することは決して珍しいことではありません。どちらかといえば、もしその人が本当にUXスペシャリストとして雇われていたなら、私は彼がコードをチェックインするという概念にまったく衝撃を受けました。私はそれが行われたのを見たことがないとかなり確信しています。
その人が本当にUXスペシャリストである場合、彼をより良いコードを生成させるのではなく、完全に彼がコーディング(少なくともプロトタイプ以外)をやめるようにするのが治療法かもしれません。彼が正直にUXデザインでgoodである場合、本当の間違いはおそらく、本番用のコードを書くように頼むことです。代わりに、彼はおそらく(最大で)UXプロトタイピングサンドボックスで作業しているはずです。そこでは、彼の結果を使用して、生成される実際のコードの次のラウンドをガイドしますが、実稼働コードとしてチェックインすることはありません。
私は、上司にプロジェクトに影響を与えることを常に知らせておくというルールを設けるようにしています。正と負...そしてこのような場合、私はそれを書いた人とは対照的にコードのようなものを非難しようとします。同僚を殴っているようではなく、製品の品質を向上させようとしているように聞こえます。
管理の観点から、この状況で従業員に対処するための3つの一般的な方法があります。
外部の助けを求めることにより、弱点をコントロールできます。
ちょっとボス、私はコードの状態について少し心配しています...それはかなり壊れやすく、たくさん壊れています。信頼できると感じる状態になるまでには、少し手間がかかります。建築家の1人を1日か2日借りて、優れたデザインを思いつくかどうかを確認する可能性はありますか。
他の人にプロジェクトへの参加を求めているのではなく、短時間でより多くの「専門家の意見」を求めています。アーキテクトが望んでいるものであれば、必要なドキュメント、UML図、コードスニペットを作成します。彼らは、コードがどのような状態にあるかを確認し、上司が誰かにあなたの意見を反響させるでしょう。
会議から、あなたはうまくいけば、あなたと他の開発者の両方がそれをたくさんねじ込むことなく従うことができるより良いデザインを得るでしょう。これが多くの場合の設計と仕様です。悪意のある開発者ができるダメージを減らすことです。
強みを発揮
こんにちは、私はプロジェクトxのコードを扱っています。一方、コードはかなりの作業量を使用する可能性があります。 [UXガイ]がUXにもっと集中できるようになれば、プロジェクトはうまくいくと思いますが、より安定した状態にするためにリファクタリングを行います。 UXが安定したら、project bはおそらく彼のMidasタッチを使用できます。
ここで、あなたの上司はそれをよく見通すでしょう。あなたが彼に他の開発者があまり良くないと言っていることを...それでも少なくともあなたはそれについて嫌いではありません。そして、もし彼がUXの仕事に正直本当に上手いのなら、彼は各プロジェクトに飛びついて、使いやすさの観点からそれらを素晴らしいものにする安定したポジションを見つけるかもしれません。彼もそうした方がいいと思います。
やめる繰り返し彼の間違いを修正する。彼は学びません。私はそうしないでしょう。
プログラミングは主に論理的なタスクですが、メモリの再収集も必要です。一般的なコードを頻繁に記述する場合、すべてを再計算するのではなく、リコールソリューションの実装方法前回を使用します。彼が正しいコードを実装したことがない場合は、なぜ彼が同じ間違いを繰り返し続けているのかがわかります。
彼が間違ったことを彼に示し、おそらくそれを最初に修正します。同じインシデントがさらに発生する場合は、提示した修正を彼に実装してもらいます。
私はいくつかの理由で本当に慎重になるでしょう:
最初のリリース後に彼と一緒に仕事をしないとどうやって確信しますか?あなたの経営者は、「なんてチームだ、彼らがどのようにしてこの素晴らしいものを一緒に提供したか見てくれ!あなたを一緒に保ちたいのです。
上司のところに行った場合、自分の立場を説明するためにどの程度技術的にやりたいですか。同僚のパフォーマンスが低い文書はどれくらいありますか?
それらは、あなたが尋ねたものから私がメモした落とし穴でしょう。私はあなたに彼にコードについて尋ねて、彼がなぜそれがそうであるのかについていくつかの正当化があるかどうか確かめることをお勧めします。おそらく彼はそれをコーディングしている間に円を描いて実行しているため、いくつかの問題が発生します。サークルは何かをコーディングする場所であり、一連の変更を通じて、誰かの変更のリストが最後にキャンセルされるので、開始したときとほぼ同じ時点で終了します。私は、それが変化し、変化のたびに変化を元に戻し、すぐに疲れてしまうような状況にありました。
すべての作業をやり直さずにプロジェクトを失敗させるとどうなりますか?つまり、あなたへの影響です。
確かに彼の経験レベルと地位の誰かが偶然にそこに到達しなかったので、彼の仕事はあなたがそれを認識しているほど悪くはないか、彼のキャリア全体はあなたのような人が一緒に持っている人で構成されています。
週に50時間を超えるプロジェクトで作業している場合、プロジェクトは深刻な問題であり、PMの注意を引くように呼びかけたり、退社したりすることによって、自分自身を傷つけます。私は強いですハードではなくスマートに働くことの支持者。
スマート50で作業し、プロジェクトがうまくいかない場合は、IT IS NOT YOUR FAULT。彼の能力不足のために失敗し、彼らがあなたを責める場合、それはおそらくあなたが望む環境ではありませんとにかく働くために。
私の友人の多くは、失敗したプロジェクトがどれほど少ないかを理解していないと失敗を恐れているので、誤って管理されたプロジェクトで通常40 /週以上うまく仕事をしていますOR成功は全体に直接影響しますあなたのキャリア。
プロジェクトの80%以上が失敗していることには、恥はありません。
そのピアレビューと呼ばれています。あなたのマネージャーはあなたにそれを期待していて、彼の貴重な開発者の時間がどこで費やされているか知らされなければなりません。私は彼がこれについてすでに知らないことに驚いています-しかし、再び、私はさらに悪いことを見てきました。
他の人に関して彼に話しかけるのではなく、あなたが行う毎日の仕事に関して彼に話しなさい。それが彼のコードを解体することを意味するなら、そうです。チェックインリンクなどで武装して、毎日の仕事の何らかの証拠を提供します。マネージャーはあなたからこれを正確に求められるかもしれません-彼は20年のUXをもたらし、あなたは堅牢なコードを手に入れます。ワイヤーフレームを作成する代わりに、プロトタイプレベルのコードを作成します。上司に相談してください。
そして、あなたが彼のベビーシッターとして雇われなかったことを望みます。幸運を。
彼の仕事を書き直したりやり直したりする必要がなかった場合、プロジェクトはより早く開始されますか?予算を下回るのに役立ちますか?個人的に懸念を表明するために、バッシングする必要はありません。ここでほとんどの人が間違いを犯し、解決策を提供せずに文句を言います。
結果を改善する上司に提供できる具体的な推奨事項はありますか。より良いドキュメント?堅牢なユーザーテスト?あなたの目標は、会社、プロジェクト、同僚、そしてあなた自身を成功させることです。問題がないふりをすることで、4つのうち3つが失敗することが保証されます---そしてあなたは幸運な人ではありません。
あなたはできるだけ早く上司のところに行き、ここであなたが言ったことをはっきりと彼に伝える必要があります。
まず、これは医療機器です。バグがあると誰かが怪我をしたり、死んだりする可能性はありますか?人々の生活や健康に依存するコードは、最善のシナリオのために楽天家によって書かれたバグのあるジャンクではなく、人間として可能な限り堅牢である必要があります。
さて、私の元マネージャーの帽子をかぶって...あなたはあなたの上司がこれについて知っているかどうか、それが彼へのニュースである場合の彼の反応がどうなるかわかりません。しかし、彼が知らなければ、彼はそれをする必要があり、あなたはこの情報を隠すことによって彼を推測するべきではありません。同僚がこのようにコーディングしても問題がなければ、彼はあなたに知らせます。
何年も前にこのような状況に遭遇しました。 「ネットワーキングの第一人者」と私は、請負業者として概念実証に取り組んでいました。実際、彼はほとんど何もしていませんでした、そしてほとんどが間抜けでした。ある日、上司からデモが来ると言われました。すぐに、「ネットワーキングの第一人者」が口ずさむほど多くの電話を受け始め、デモの前に別の契約ギグを取るために去るつもりであると彼はようやく私に言った。上司を一人にすることができるとすぐに、私は彼にそれについて話しました。彼は「ネットワーキングの第一人者」を捨て、私が推薦した誰かを連れてきました。その人は3日間で「グル」が3か月で行ったよりも多くのコードをクランクアウトしました。デモは大ヒットでしたが、私が静かにしておけば、プロジェクトは完全に失敗したでしょう。
はい、上司に言ってください。それから、それがあなたがそこの場違いなものではないかどうかを確認します。チームがどのように働いているかを知り、上司がまだ気づいていない場合は、適切なコーディングのためにあなたがするほど多くのことを気にしていないのはマネージャーの仕事です。
そして、これらすべてのさまざまな職場の中で、私がそれらすべてから友達の手をいっぱいにした場合(つまり5)、それはすでに大きな数です。彼らは皆ニースの男とギャルがいましたが、あなたは仕事をすることで友情を失うことはありません-あなたがそれらを失うならそれは良いことです。あなたの例では、彼はあなたよりも仕事を大切にしています。
確かに、それは彼を解雇しようとする試みではありません。それは、プロジェクトの健全性に対する懸念を示しているだけです。それが、皆さん全員がそこにいる(またはいる必要がある)理由です。
結局のところ、彼と話をしてみましたが、何もしなければ、実際にその仕事を危険にさらしています。