平凡な開発者がチームを傷つけていることを経営陣に示す方法[クローズ]

私は小さな会社の開発者チームを「管理」するという不安定な立場にあります。私は「管理」と言います。なぜなら、私は仕事を割り当て、彼らのパフォーマンスについてフィードバックを提供しますが、実際に個人を訓練することに頼ることができないからです。

私のチームの中には、どうしたらよいかわからない人もいます。彼らは自分で作業することができず、大量の手を握る必要があり、放置すると、通常、プロジェクトに大混乱をもたらし、通常は失敗に終わります。失敗が起こったとき、私はプロジェクトを救い出し、フィニッシュラインを越えてそれを押す（時には足を引きずる）ことに任されています。

これらの開発者は、プログラミングの概念に関するスキルが不足しているだけでなく、一般に、コードの問題の解決策を策定する能力も不足しています。ループを書くような単純なことは、問題の解決策を設計して実装することは言うまでもなく、彼らにとって難しいことです。

ペアプログラミング、クラスへの支払いの申し出、本の購入、トレーニングへの勤務時間の割り当て、さらにはチームのトレーニングに丸一日かかることを試みました。

他の上級開発者と私は何をすべきかわかりませんが、私たちの生産性は、これらの個人に日々対処しなければならないことで抑制されています。経営陣は私たちに彼らに仕事を与えることを強制しており、彼らの主な不満は物事が十分に迅速に行われていないことです。

私たちの管理チームは、私と他の上級開発者以外の開発者と直接連携していません。管理は技術的ではなく、すべての開発者が平等に作成されていると信じており、これらのプロジェクトをより早く完了するには、明らかにこれらのプロジェクトにより多くの人員が必要であると考えています。

「人月の神話」と「コードコンプリート」のセクションを含むドキュメントをすでに準備しており、管理者に送信して、開発サイクルを通じて平凡な人々を引きずり込まなければならないことを統計で説明できることを願っています。

他にどのようなリソースがありますか？本、記事、一般的なアドバイスは何でも役に立ちます。

問題は、スキルや能力の欠如、プログラマー側の態度の問題、または優れた労働倫理を促進しない企業文化に起因しますか？

それがスキルなら、あなたはあなたが教えることができないいくつかのことがあることをすでに知っています。会社が進んで（そしてそう思われる）、改善を示すことができれば、私はトレーニングを強化し、どの開発者がその機会に立ち上がるかを確認します。あなたがいない人は手放す必要があります。既存の開発者の一部を手放すことがわかるまで、追加の開発者を雇うことはありません。

プログラマー側の怠惰やその他の態度の問題である場合は、懲戒処分を支持するよう経営陣を説得する必要があります。Scott Vercuskiが説明するように、すべての問題を文書化します。その機会に立ち上がれないプログラマーを徐々に淘汰します。残りのプログラマーに、優れたプログラミング手法とベストプラクティスを学び、それらを使用することが期待されていることを知らせます。

まだ行っていない場合は、コードレビューを行ってください。これを適切に行う方法を説明するリソースはたくさんあります。彼らは試合を叫ぶべきではなく、むしろ望ましい結果を生み出すための戦略セッションとして見られるべきです。コードについて話し合います。どうすれば改善できますか？必要に応じて、レビューに新しいコードを記述します。

管理が問題である場合は、彼らに問題があることを伝え、彼らがそれを修正する方法を示します。しかし、あなたは雄弁で説得力がなければなりません。あなたは彼らの擁護者でなければなりません。問題についての論文を書く。プレゼンテーションをして見せてください。利益の動機に訴える。

最後に、あなたができるあなたの人々のための最高のリーダーになりましょう。彼らを助ける。彼らが仕事をすることができるように、彼らをブロック解除しておいてください。あなたの仕事の一部は、上層部の政治から人々を保護し、ディーセントワーク環境を維持することです。そうすることで、彼らは可能な限り最高の仕事をすることに集中することができます。言い換えれば、あなたの人々があなたを信頼できることを確認してください。

おかしなことに、管理スキルが不足しているとは誰も言わなかった。

かつて、1年半のトレーニングの後でループをコーディングできない人々と一緒に仕事をすることになりました。フル機能のWebフレームワークを使用できるようになるまで、トレーニングを行いました。所要時間はわずか1か月でした。

多分あなたは訓練を受けるべきです。

多分あなたはあなたについてのレポートを読むべきです。

私はあなたを攻撃することを言っているのではありません。どういたしまして。過去にもチームの管理に失敗したので、問題をよく理解しています。

しかし、ボールをかわさないでください。あなたが人生でどれだけ良い練習の文献を読んだとしても、あなたは主にあなたのチームで起こっていることに責任があります。

その場合は、文句を言うのをやめて仕事に取り掛かってください。コーダーとしてではなく、マネージャーとして。

最後に、私は間違っている可能性があります。多分あなたはすべてを正しくやったでしょう。その場合、辞任することができ、おそらく辞任する必要があります。どんなに強くても、手を動かして飛行機が墜落するのを防ごうとするのは無意味です。彼らのスキルを最大限に活用するためにあなたのスキルで奇跡を起こすカジュアルなチームがたくさんあります。

ドキュメントはあなたの最大のリソースです...私の古いマネージャーは私に「あなたがそれを書き留めなければ、それは起こらなかった」と言いました。開発者がタスクを完了するために必要な時間の見積もりを書面で提供し、それらの期限を絶えず（そして大幅に）逃した場合は、文書化する必要があります。

なんらかの計時システムはありますか？または、開発者は時間を記録しますか？問題がX日かかると彼らが述べ、X日後にそれが行われなかった場合、なぜそれが行われなかったのか疑問に思うことができます。

繰り返しになりますが...ドキュメントが重要です。突然誰かを解雇し、訴訟の領域に入る理由について十分なドキュメントがない場合。ドキュメントが多ければ多いほど、後輩の開発者が自分たちの重みを引いていないので、交換する必要があることが経営陣にすぐに明らかになるはずです。

幸運なことに、あなたは非常に険しい道を進んでいるのではないかと思います...私はそこに行ったことがあり、それは長い間引き出されたプロセスです。

私は以前にこのような状況にあり、確かに共感することができます。私がしたことは、私や他の上級開発者が2日かそこらしかかからないはずの小さな自己完結型のタスクを取り除くことでした。このタスクでは、ソリューションの実装方法やデータベースの変更などを特定するドキュメントのスカッドを作成します。次に、開発者と一緒に座って、タスクの概要を説明し、タスクを割り当てます。締め切りは1週間です。週の終わりに、あなたは彼らの仕事を比較することができる具体的な何かを持っています：彼らは仕様を満たしましたか？彼らはどのように行われていますか？QAはいくつのバグを見つけましたか？彼らは何らかの方法でビルドまたはブレークプロセスを中断しましたか？

それが行われると、彼らが失敗したと仮定して、あなたは彼らがどのように彼らの義務を果たしていないかを説明する彼らとの直接のそして鋭い会議を持っています。同じことをあと1、2回行います。文書化してチェーンを上って通信している限り、それらを押し出すことができるはずです。厳しいかもしれませんが、ステップアップする人が必要で、それを行うのに適切な人がいないようです。

また、新しい候補者の面接に必ず参加してください。

私のアドバイスはこれです：

あなたがマネージャーである場合、あなたはあなたの責任に伴う権利を持っている必要があります。これらの権利には、あなたの下にいる者の懲戒が含まれます。上級管理職があなたにそれらの権利を与えることを拒否した場合、その責任を引き受けることを拒否します。

必ずしも上司にそれほど厳しくする必要はありませんが、それが何が起こらなければならないかの本質です。

私のアドバイスは、バグトラッカーを実装してタスクを割り当てることです。これは、チームの誰の生産性も示します。初めて使用したときは、チームを編成し、タスクに取り組む時間を測定することを達成しました。私が気に入った点の1つは、誰かがタスクを割り当てたときに、そのタスクを確認するためにワーカーに電子メールを送信し、他の誰かにコピーを送信したという事実でした。

ちなみに、BugTracker.Netを使用しました。

そもそも、これらの人々はどのようにして会社に入ったのだろうか。

これらの開発者は、プログラミングの概念に関するスキルが不足しているだけでなく、一般に、コードの問題の解決策を策定する能力も不足しています。

ループを書くような単純なことは彼らにとって難しいです...

古いことわざにあるように、あなたの会社は間違いなく、より多くの時間と労力を労働力の採用に投資する必要があります。急いで無駄にする。

さて、あなたが説明するような状況になったら、レポートを完成させて（他の人が示唆しているように）、これが会社にかかる費用を簡潔にして下線を引き、提出して最高のものを待ちます（あなたが言ったように「実際に個人を訓練することに頼る。」）。

私は、プログラマーが最高になりたいと思うように促すことについて、少し前にこれを読みました。

オタク番

あなたはあなたのチームのために「彼らのパフォーマンスに関するフィードバックを提供する」と述べました。

そう：

1. チームと一緒に座ってください。
2. このページのプリントアウトを渡して、投稿したことを伝えます。
3. 彼らにそれを読ませてください。
4. あなたが問題を解決するのを手伝ってくれるように彼らに頼んでください。
5. 聞いて書き留めます。
6. それを管理チームに持っていきます。

ピープルウェアはあなたのリストに加わるべきもう一つの本です。

しかし、それを読んだとき、社内の誰もその推奨事項を試したがらなかったため、実用的ではありませんでした。

あなたは正しい方向に進んでいるようですね。

あなたが彼らに厳しい数字を見せれば、彼らは物事をより明確に見るでしょう-コーディングの割り当てを作成し、それをいくつかの異なるプログラマーに与えて、それぞれが自分で作業します。自分でテストできるようにします。

それぞれにかかる時間、コードが生成する欠陥の数の詳細を保持します。

数字を上級管理職に示してください。彼らは今や納得しているはずです。

本

コードコンプリート：スティーブマコネルによるソフトウェア構築の実用的なハンドブック

ベストプラクティスを学ぶのに役立つ良い情報源です。

各開発者にこれを読んでディスカッションで学ぶように要求することは少し役立つかもしれませんが、最大のことは結果を定量化することです。あなた自身とチームの他のメンバーの給料を取り、開発者が最初に物事を台無しにする追加のコストで他の間違いを修正するために費やす必要がある余分な時間を計算します。

次に、優れた開発者のチームがROIをどのように改善できるかを示します。

レポートは簡潔にしてください。言葉にしないでください。彼らがこれでどれだけのお金を失っているのかという観点から言えば。

これで、コードモジュールの複雑さを測定するツールができました。PL / SQLモジュールで実行されますが、他の環境でも利用できるツールがあると思います。

全体にさまざまなセクションがありますが、主要なモジュールのいくつかが「テスト不可能」とマークされたとき、それは管理者にとって非常に目を見張るものでした。

重複する機能を強調するのに役立つ影響分析ツールと組み合わせて、「技術的負債」の評価としてこれをすべてパッケージ化するようにアプローチしました。

これをモジュールごとに提示できるため、加害者を特定するのは簡単でした（報告しましたが、報告しませんでした）。それがそうであったように、組織は指さしよりも今後の改善に向けられていました。

（余談ですが、すべてのコードがレビューのために送信され、付随するコード分析を提供する必要があります。ここでは間違いなく状況が改善されています。）

あなたが経営陣との良好な牽引力を持っていない限り、これは単に不可能です。私の経験では、それを強制しようとすると、問題が発生する可能性があります。

ただのアイデア。

SVNのようなソースバージョン管理システムを使用していると思います。したがって、コミットを確認し、悪いコミットを拒否するポリシーを作成します。次に、拒否されたコミットの統計を他のマネージャーに表示して、平凡な開発者が会社にとって非常に高価であることを証明します。

ここにあなたのための別の考えがあります：彼らが壊すものを直さないでください。何が間違っているのか、どのように修正するのか（一般的な用語のみ）、およびcc管理を伝えることにより、電子メールでやり直しのために送り返します。これが最終期限にどのように影響するかを経営陣が正確に理解していることに注意してください。これはあなたのためにパフォーマンスの問題のドキュメントを作成し、それらのいくつかは彼ら自身の混乱を修正しなければならないときにそれほど悪くなくなるかもしれません。