82

私は小さな会社で開発者チームを「管理」するという不安定な立場にいます。私が「管理する」と言うのは、仕事を割り当て、その業績についてフィードバックを提供するが、実際に個人を懲らしめる手段がないからです。

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

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

私たちはペア プログラミングを試し、授業料の支払いを申し出たり、書籍を購入したり、勤務時間中にトレーニングに時間を割いたり、さらにはチームのトレーニングに丸一日かかったりしました。

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

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

「The Mythical Man Month」と「Code Complete」のセクションを含む文書を経営陣に送信して、開発サイクルを通じて平凡な人々を引きずり出さなければならないことが本当に妨げになっていることを統計で説明できるように、すでに準備しています。

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

4

17 に答える 17

32

面白いことに、管理スキルが不足している可能性があるとは誰も言いませんでした。

かつて、1 年半のトレーニングの後、ループをコーディングできない人々と一緒に仕事をすることになりました。彼らがフル機能の Web フレームワークを使えるようになるまで、私は彼らを訓練しました。それにはわずか 1 か月しかかかりませんでした。

トレーニングを受けたほうがいいかもしれません。

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

私はあなたを攻撃するために言っているのではありません。全くない。私も過去にチームを管理できなかったので、問題をよく理解しています。

しかし、ボールをかわしてはいけません。人生でどれだけ優れた実践に関する文献を読んだとしても、チームで起こっていることの主な責任はあなたにあります。

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

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

于 2010-02-12T20:49:35.387 に答える
26

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

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

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

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

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

最後に、部下にとって最高のリーダーになりましょう。彼らを助ける。彼らが仕事をすることができるように、ブロックされていない状態にしておいてください。あなたの仕事の一部は、上層部の政治から部下を守り、まともな職場環境を維持して、彼らができる限り最高の仕事をすることに集中できるようにすることです. 言い換えれば、あなたの人々があなたを信頼できることを確認してください.

于 2010-02-12T15:38:16.753 に答える
15

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

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

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

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

于 2010-02-12T15:29:02.053 に答える
6

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

それが完了したら、彼らが失敗したと仮定して、彼らがどのように義務を果たしていないかを説明するために、彼らと直接的かつ的を絞ったミーティングを行います。同じことをもう 1 回か 2 回繰り返します。チェーンを文書化して通信している限り、それらを押し出すことができるはずです。厳しいかもしれませんが、ステップアップする人が必要なように思えますが、それを行うのに適切な人がいません。

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

于 2010-02-12T15:39:55.207 に答える
5

私のアドバイスは次のとおりです。

あなたがマネージャーである場合、あなたは自分の責任に伴う権利を持っている必要があります。これらの権利には、あなたの下にいる人々の懲戒が含まれます。上層部があなたにそれらの権利を与えることを拒否した場合、その責任を負うことを拒否してください。

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

于 2010-02-12T20:58:57.033 に答える
2

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

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

于 2010-02-12T15:29:58.427 に答える
2

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

ナード・ハーディング

于 2010-02-13T01:26:41.867 に答える
2

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

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

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

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

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

于 2010-02-12T16:16:08.897 に答える
1

Peopleware は、リストに追加する必要があるもう 1 つの本です。

しかし、私がそれを読んだとき、会社の誰もその推奨事項を試したがらなかったので、私はそれが実用的であるとは思いませんでした.

于 2010-02-12T22:36:07.810 に答える
1

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

そう：

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

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

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

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

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

于 2010-02-12T15:29:28.953 に答える
0

ここにあなたのための別の考えがあります：彼らが壊すものを直さないでください。何が間違っているのか、修正方法（一般的な用語のみ）とcc管理を伝えて、やり直しのためにメールで返送してください。これが最終期限にどのように影響するかを管理者が正確に理解していることに注意してください。これにより、パフォーマンスの問題に関するドキュメントが作成され、一部の問題は、独自の混乱を修正する必要があるときに、それほど悪くなくなる可能性があります。

于 2010-02-19T22:48:33.157 に答える
0

ただのアイデア。

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

于 2010-02-18T12:09:51.200 に答える
0

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

全体にさまざまなセクションがありますが、重要なモジュールのいくつかが「テスト不可」とマークされたとき、経営陣は非常に目を見張るものがありました。

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

これをモジュールごとに示すことができたので、加害者を特定するのは簡単だったでしょう (報告はしましたが、報告はしませんでした)。現状では、組織は非難するよりも前進するための改善に向けられていました.

(余談ですが、すべてのコードは現在、レビューのために提出されており、付随するコード分析を提供する必要があります。状況は確実に良くなっています。)

于 2010-02-12T16:13:33.533 に答える
0

本

完全なコード: Steve McConnell によるソフトウェア構築の実践的ハンドブック

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

各開発者にこれを読み、ディスカッションで学ぶように求めることは、少しは役立つかもしれませんが、最も重要なことは結果を定量化することです。自分自身とチームの他のメンバーの給与を計算し、他の人の間違いを修正するためにどれだけの余分な時間を費やさなければならないかを計算します。

次に、優れた開発者のチームが ROI を改善する方法を示します。

于 2010-02-12T15:33:08.687 に答える
0

これは、経営陣との良好な牽引力がなければ不可能です。私の経験上、無理に押し込もうとすると大変なことになるかもしれません。

于 2010-02-12T21:04:30.423 に答える
0

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

于 2010-02-12T15:50:19.440 に答える