より良いコーディング手法を採用するように同僚に刺激を与えますか？
私の時代遅れの同僚を扱う の質問では、さまざまな人々がnwillingである自分のワークフローをチームのワークフローと統合する同僚に対処するための戦略について話し合いました。
できれば、単に無知現代の技術とツールであり、おそらく少し無関心な同僚を「教える」ためのいくつかの戦略を学びたいと思います。
最近まで会社の別の部分で比較的孤立して働いていたプログラマーと一緒に働き始めました。彼は広範なドメインの知識を持ち、最も重要なことに、彼は優れた問題解決スキルを示しました。これは多くの候補者には欠けているようです。
ただし、私が見た実際の（C＃）コードは、VB6時代への逆戻りです。手続き型構造、ハンガリー語表記、グローバル変数（staticの乱用）、インターフェースなし、テストなし、ジェネリックスの非使用、System.Exceptionのスロー...
このプログラマーは私よりかなり年上で、少なくとも第一印象では積極的に活動していませんseekポジティブな変化。 抵抗変更するつもりはありません。これは、トピックがどのようにブロークされるかという問題の大部分だと思います 、私は準備したいと思います。
プログラマーは頑固な人々である傾向があり、銃を燃やし、細断処理されたコードレビューと厳格に施行されたポリシーを導入することは非常に可能性が高いですnot私が望む最終結果を生み出すつもりです。これが新入社員、ジュニアプログラマであれば、「メンター」の立場を取ることを二度と考えませんが、経験豊富な従業員を無知な初心者として扱うことは非常に警戒しています（彼はそうではありません-彼はまだしていません）分野の特定の進歩に遅れをとることはありませんでした）。
穏やかな説得と重要でないインセンティブを通じて、この開発者のコード品質基準をデールカーネギーの方法で引き上げるにはどうすればよいですか？敵対的な状況を作らずに、微妙で段階的な変化をもたらすための最良の戦略は何でしょうか？
他の人々-特にリード開発者-は以前にこのような状況にあったことがありますか？興味を刺激し、積極的なグループダイナミックスを生み出すのに成功した戦略はどれですか。 成功しないどの戦略が成功し、回避した方が良いでしょうか？
明確化：
質問の細かいところを全部読まずに、何人かの人が個人的な気持ちで答えているように感じます。次のことに注意してください。これは暗黙のうちに示されているはずですが、現在は明示的にしています。
この同僚は年齢のおかげで私の「先輩」にすぎません。彼の肩書き、影響力の範囲、または組織での年月が私のものを超えているとは決して言わなかったし、実際、これらのことはどれも真実ではない。彼はメインの開発ショップに夢中になっているLOBプログラマーです。それでおしまい。
私は、新入社員、ジュニアプログラマーなど、一夜にして会社を変革するという壮大な計画を持つナイーブではありません。私は基本的にソフトウェアのプロセスを担当していますが、「リード」として働いてきた多くの人が知っているように、責任は常に組織図と正確に相関するとは限りません。
私はではない方法を人々に尋ねる私の方法を取得し、地獄または高水面に来る。私が望むならそれを行うことができ、その結果、この人は憤慨したり、辞任したりしました。 social、cooperativeメソッドを探していることを理解してみてください変化の推進.
"...グローバル変数...テストなし...
System.Exception"をスローすることの言及は、問題が表面的または美的だけではないことを示すことを目的としています =。比較的小さなCRUDアプリで機能するプラクティスは、必ずしも大規模なエンタープライズアプリで機能するとは限りません。実際、これまでのところ、実際に統合テストに合格したコードはありません。
質問を額面どおりに受け止め、私が実際に話していることを知っていることを受け入れて、実際に尋ねた質問に答えてくださいまたは次に進みます。
PS前提について議論するのではなく、建設的なアドバイスをしてくれた人たちに心から感謝しています。実世界での体験についてもっと聞きたいと思っているので、しばらくこのままにしておくつもりです。
出発点は聴衆を知るです。あなたは、これをすでに理解しているようです。なぜなら、後輩のメンターと先輩への影響の違いを知っているからです。
この特定の個人をやる気にさせるものを理解する必要があります。 （私のような）1つの古いギーザーで機能するものは、古いギーザーでは機能しない可能性があります。
彼がメンターや他の人に教えることを好む場合は、「なぜあなたはこのようにするのですか？」のように質問するで問題に取り組むことができます。そうすれば、新しいアプローチを評価して意見を述べるように頼むことができるダイアログが表示されます。
それがうまくいかない場合は、バグを指摘して、彼に採用してもらいたい方法やスタイルを使用することで回避できます。バグを見つけ、奨励したい振る舞いがどのように役立つかを示す必要があるため、これにはさらに多くの作業が必要です。
もし彼が他の人を助けようとするなら、あなたは初心者を助けたいという彼の欲求に訴えるができます。 「今日の子供たち」は彼のコーディングスタイルを見るのに慣れておらず、そのため彼のコードを壊す可能性が高いことを説明します。
時々、あなたは彼の顔に入るで問題を強制する必要があるかもしれません。あなたはこれらの戦いを注意深く選ぶ必要があります。より良い方法があることを彼に証明できることがわかっているトピックから始めることを確認してください。
あなたは正しい態度を持っていると思います。すでに言ったすべての素晴らしいことを言うことを忘れないでください-優れた問題解決スキル、ビジネスの徹底的な把握など、グループの現在の基準を示すために少しだけ時間をかけてください使用して、彼にそれらについていくつかの質問をする機会を与えます。
一緒に集まったら、彼にコーヒーか何かを持ってきて、彼があなたの既存のコードをサポートしやすくし、誰かが彼を助けてもらえるようにすることを容易にすることで、標準に取り組むことは彼に利益をもたらすことを彼に知らせてください仕事でカバーされます（孤立して働いていた人にとって大きなプラス）、など。
彼が関与し、なぜあなたがしていることをするのかについての適切な説明を得ていることを確認し、彼がしていることをしてはならない理由に焦点を当てないでください。必要に応じて他の人を招き、彼らに説明してもらいます。質問がある場合は、後で参照できるようにし、基準の例として参照できるいくつかの場所でフォローアップします。
彼がその後興味がない場合は、リンクした最初の質問を参照できます。
それは本当にあなたのマネージャーの仕事です
- 会社がmustにコーディング標準があることを認識してください。会社の規模に関係なく、いくらか専門的な会社はすべてこれを持っています。
- みんなで一緒に座って、標準を作成し始めます。そうすることで、誰もが発言権を持つことができ、標準に従うように動機づけられます。
上司が自分でこれを認識していない場合、彼らは彼らの仕事の資格がありません。もしそうなら、あなたは彼らに上記の2つ以上のナッジを与えるべきです。コーディング標準を持つことの利点は非常に多く、それを持つことに反対する議論は実際にはありません。 （プログラマーが「アーティスト」であり、プロフェッショナリズムの境界によって制限されるべきではないと感じているプログラマーは、代わりに美術を行う仕事を得るべきです。）
コーディング標準自体は、何よりもまず、危険な行為と危険なライブラリ関数の禁止に焦点を当てるべきです。使用している言語のより安全で純粋なサブセットに向けて取り組みます。コーディングスタイルは同意するのがはるかに難しく、それほど重要ではないため、コーディング標準を「コーディングスタイル」から解放します。ある会社がコーディング標準を作成することを決めた後、すぐに{}括弧を配置する場所についての白熱したナンセンスな議論に行き詰まるのはかなり古典的です。
参考までに、MISRA-C/C++およびCERT C/C++/Java標準の作成方法を確認してください。
まず、この人の働き方を変えたい理由を明確にする必要があります。美的理由だけの場合は、この人が彼の働き方が実際に機能していることを示しているので、再考する必要があると思います。
ただし、技術的な理由がある場合は、次のような方法で相手にアプローチすることを検討してください。
面倒な時間と会社のお金を節約する方法を提案します。興味ある？
彼らは常に余分な努力を必要とする既存の習慣を変える必要があるため、これはぶら下がり果物であるべきであることに注意してください。
膨大な数の提案がある場合でも、1つまたは2つを選択し、demonstrateを選択すると、より良い変更になります。
これは機能し、さらに提案があるかどうか質問されます。そうでない場合、損傷は1つまたは2つの提案に限定されます。
成功することは非常に重要であり、すぐに成功することに注意してください。
また、注意する必要があります。 very物事が行われている方法で行うことには十分な理由があるかもしれませんが、その理由を知るにはあまりにも新しいのです。したがって、あなたの年長者を尊重し、あなたの提案がより良いと思う前に尋ねてください。あなたは何かを学ぶかもしれません。
そっと彼にそれを壊すことから始めます：私はあなたがフィードバックを与えることにどれだけ経験があり、どれだけ精通しているかはわかりません。あなたはすでに次のことを知っていたり、雇用したり、拒否したりすることもできますが、とにかくここに行きます。誰かの行動を変えたいときにフィードバックを与えることに関するいくつかのガイドラインがあります。私が考えてきた会話構造は、次のようなものです（フィードバックが機能するため）フィードバックを提供したい状況で使用しようとしています。
- あなたが見る行動を説明してください。これは具体的な振る舞いでなければなりません。例：「コードで多くの静的変数を使用しているようです」
- それがあなた/あなたのチームにどのように影響するか説明してください。例：「そのようなコードを維持するのは難しいと思う」
- 合理的なソリューションを提供します。 （可能な解決策は他の答えで言及されています、そして私は後でこの答えをいくつか私自身に手を出します）
- 解決策について話し合う機会を彼に与えます。彼に解決策についてどう思うか尋ねてください。彼の反応を額面通りに受け止めてください。あなたは彼にあなたの意見を与えました、そして彼はそれを受け入れるかどうかは自由です。
フィードバックに関する簡単なリソースは、たとえば http://managementhelp.org/communicationsskills/feedback.htm で見つけることができます（ただし、この種のものはウェブ上に多面的です）。
ソリューションの部分では、私があなたの回答で読んでいることから、彼はかなり賢く、正しい考え方を持っていますが、彼は現代の優れた実践に少し遅れています。それらについて習得するには、そもそも実際に学ぶこととは別に、時間と労力が必要です。そのため、機会を提供する必要があります。それはおそらく、出発点として学習リソース（Web、雑誌、本など）を収集し、それらを研究するための自由な時間を彼に提供することを意味します。毎週金曜日の午後に、プログラミングスタイルの視野を広げるために彼に与えることを想像することができます。人々は相続的に自分自身を改善したいと考えています。資料と時間を提供すれば、彼らはそれをうまく利用するでしょう。
おそらく最も重要なこととして、一晩での変化を期待しないでください。彼は長い間自分のやり方で物事を行っており、おそらくかなり上手になっています。新しいやり方でうまくいくにはしばらく時間がかかり、しばらくの間、彼はおそらく新しい方法であまり価値を見いださないでしょう。なぜなら、最初は何もないからです。彼の古いやり方はおそらくしばらくの間より効果的でしょう。
*注：会話の面白い点は、会話をモデル化するのが非常に難しいことです。彼らは彼ら自身の人生を持っているので、それは紙の上でそれは素敵に見えますが、それは少し濁りがちです。
彼の顔に入るからあなたをひどく落胆させたいと思います。これは状況が急速に悪化する原因となるからです。それが最後の手段として取り上げられたことは承知していますが、私の経験では、現時点では、開発者は機能的に参加を停止しています。
問題を強制すると、個人が敵になり、あなたのあらゆる行動と戦います。それは本当にチームに悪影響を及ぼし、誰かがやめるか解雇されるまでそれは終わりません。
この個人が本当に必要な/欲しいドメインの知識を持っている場合は、その知識を文書化してもらいます。
どのように物事をやりたいかを説明し、プロジェクトの開始時に、彼が取り組むプロジェクトの設計およびアーキテクチャ上の選択とどのように機能するかを彼に示します。 1つずつ（そして私的に）座って、彼の以前のコーディングで見た問題と、それらがこのプロジェクトの問題である理由を説明してください。彼が良くなるために何が必要かを彼に尋ねるが、良くならないことは選択肢ではないことを明確にしてください。
次に、コードレビューをツールとして使用して、作業方法を調整します。最初の人のために長い時間を計画し、それよりもなぜこれを好むのかについて実際に話し、彼に彼の推論を説明させてください。本当に彼の意見を聞くようにしてください。人々は、懸念が解消されたと感じたときに、より変化しやすくなります。最初のタスクをやり直すことを計画に期待します（ただし、そのことは伝えないでください）。チームの基準を満たすまでは受け入れません。彼があなたが何を期待しているかを理解し、それを時間の都合で滑らせないようにしたら、おそらく彼はあなたの働き方に出くわすでしょう。ただし、コードレビューをいくつかの反復の教育ツールとして使用する必要がある場合があります。基準を満たすまで仕事を受け入れないことを嫌がる必要はありませんが、しっかりと一貫性を保つ必要があります。ときどき滑らせて、他の人に滑らせないでください。