プログラマーのパフォーマンスが低いかどうかを確認する方法は？
私は5人以上の開発者を擁するチームリーダーです。私は開発者（彼と呼ぶことにしましょう[〜＃〜] a [〜＃〜]）は優れたプログラマーであり、きれいで理解しやすいコードを書いています。しかし、彼はいくらか管理するのが難しく、時々私は彼が本当にパフォーマンスが悪いかどうか疑問に思います。
- 私たちの会社は、プログラマを監視するだけでなく、利害関係者に進捗状況を知らせ続けるためにではなく、開発者に、使用するバグ追跡システムで作業の進捗状況を示すことを要求しています。問題は[〜＃〜] a [〜＃〜]タスクの進捗状況が更新されたとき（たぶん最初に作業してから3週間後）にのみ更新され、これにより、誰もが何が起こっているのか疑問に思う開発週の途中で。プロービングを繰り返しても、彼は習慣を変えなかったでしょう。 （大丈夫です、開発者は書類を嫌います、私もそうです）
- 最近の2〜3か月は、さまざまなイベントのために非常に頻繁に休暇を取っています。彼は病気であるか、または多くの個人的なイベントなどに出席しなければなりません。
- 毎月のスプリント、つまりロードマップを定義します。そして、スプリントの最初に、各開発者がスプリントで行う必要がある作業の量と開発者は各タスクに必要な時間を設定することができますについて説明します。彼は通常、それらすべてを完了することはできません。 （それは問題ありません。開発者は、自分の責任によるものではなく、定期的に締め切りを逃しています。）.
- 私はシンガポールを拠点としています。それが重要かどうかはわかりません。ええ、アジア人は無口であることが知られていますが、それは重要ですか？
上記のイベントが1つまたは2つだけ発生した場合、[〜＃〜] a [〜＃〜]のパフォーマンスが悪いとは思われませんが、すべてが同時に発生します。だから、私は感じ[〜＃〜] a [〜＃〜]のパフォーマンスが低く、おそらく-神は禁じられています---落ち着きます。
これは、プログラマーとしての長年の経験に基づく気持ちにすぎません。しかし、私は間違っている可能性があります。
2つのタスクすべてが類似しているわけではなく、プログラマーの会社への関与を測定するための標準的な目標がないため、プログラマーの作業を測定することは悪名高く有名です。プログラマーが自分の仕事をしているのか、それとも怠けているのかを見分けることはまったく不可能です。あなたができることは、それらを信頼することです-そうです、信頼して彼らに自律性を与えることが、プログラマーが働くための最良の方法です、私は知っていますだから、なぜあなたの講義を始めないでくださいあなたのプログラマーを信頼する必要があります、ありがとうございます-しかし、彼らがあなたの信頼を乱用した場合、あなたは知ることができますか？
結果：
私は彼のパフォーマンスに対する私の認識について彼と直接話をしました。私は彼が彼の最高のレベルで演奏していないと感じたと私が示唆したとき彼は憤慨していた。これはまったくの不公平な感じだと彼は感じた。それからこれが私の気持ちだと答えましたが、私の気持ちが正しいかどうかはわかりませんでした。彼はこれを何も持たず、すぐに議論を終えた。
彼が去る前に、彼は非常に冷たい口調で「もっと会社にもっと貢献しようとするだろう」と言った。私は彼の反応にびっくりした。私は彼をいくつかの点で気分を害したと確信しています。それが私が彼にとても率直に言ったのは正しいことだったのかどうかも分かりませんが。
私の質問は：プログラマーのパフォーマンスが低いかどうかはどうすればわかりますか？確かに、これについて私よりもよく知っている経験豊富なチームリーダーがいますか？
追記：
- 私はマイクロマネージメントが嫌いです。ソフトウェアプロセスに必要なのはSprintだけです（タスクに優先順位を付けて割り当て、月末に行われた作業量を確認します）。開発者は、毎日のようにタスクを更新する必要があります。
- スタンドアップミーティングなどはありません。主に私たちには自宅で仕事をする自由があり、誰もがこの自由を大切にしているからです。
- 締め切りを設定するのは私ですが、開発者が各タスクの見積もりを提供し、見積もりに基づいて、特定のスプリントに入るタスクを決定します。彼らがスプリントの最後にタスクを完了できない場合、私はそれらを次へプッシュします。したがって、理論的には、スプリント全体で1つまたは2つのタスクしか実行できず、残りの99タスクを次のスプリントにプッシュできますが、これを正当化する限り、毎日の作業進捗の更新という形で問題はありません。
これは驚くほど簡単に解決できる問題です。
彼ともう一度会う。あなたが受け入れるのは、おそらくあなたの現実の認識が間違っているということを彼に伝えてください。次に「それが当てはまる場合は、私の知覚を向上させるために協力する必要があります」とそれを修飾します。最後に彼に挑戦してその問題を解決するため、彼はミクロな管理を感じません。
このことはずっと前に私に起こりました。私にとっての問題は、私が自分の仕事をするだけで追加のクレジットを求めていると誰もが思う可能性を嫌うことでした。そして、それは十分に公平でした、しかしスタッフのメンバーとそのラインマネージャーの間に定期的なフィードバックループがなければなりません。
ない場合は、これらの問題が発生します。
定期的、計画的、1：1は素晴らしいアイデアです。そして、人々が指摘したように、スタンドアップは在宅勤務と直交する必要はありません。しかし、彼らは3つの質問を含まなければなりません：あなたは昨日何をしましたか？今日は何をする予定ですか？そして、ほとんどの人が忘れているのは...何かを（もしあれば）何があなたを支えているのですか？
とはいえ、あなたはチームメンバーが一緒に作業することが決してない状況を思いとどまらせるように努めるべきです。私は以前そのような状況で働いたことがあり、チーム内とチーム外に不信をもたらしました。あなたが全員オフィスに来る定期的な日を過ごしてください。定期的な会議を開き、人々がプロセスの改善などについてアイデアを表明できるようにします。
行を報告するイベントにしないでください。ただ話す機会にしてください。あなたはあなたが学ぶものに驚かれることでしょう。可能であれば、それを社交イベントに変えて、結合の練習として、勤務時間に飲み物を2杯飲んでください。
ここにはすばらしいアドバイスがたくさんあります。私はそれを取り上げたくないので、これを別の回答として投稿します。
まず、私（そして明らかに他の人）には、問題の根本を発見していないことが明らかです。あなたは症状を見つめ、それを治そうとしています。あなた自身とこの開発者の間の多くの摩擦を引き起こしているものを見つける必要があります。おそらく、あなたはあまりにも権威的です（私のプロダクトオーナーは最近、プロジェクトに対して「無限の力」を持っていると自分自身を説明し、彼女がそれを言ったときに笑ったにもかかわらず、それは私にとって不快でした）。おそらく、彼は家族の深刻な問題を抱えているでしょう（仕事をしていないときはいつも説明するでしょう）。ここには根本的な問題があり、それが見つかるまで、これは修正されません。
グッドキャッチ！
もし彼のパフォーマンスがもっと良いのなら、あなたがそれを決めたのは素晴らしいことです。ただし、もし彼の悪いパフォーマンスがそれでも良いパフォーマンスであるなら、優れた開発者を失うことを避けるために注意深く踏む必要があることを覚えておいてください。優れた開発者は手に入れるのが難しく、優れた開発者は非常に具体的なものを必要とします。おそらく Joel Test を見て、彼のニーズが満たされているかどうかを確認します。
問題の原因を見つける
彼がしている仕事に関連した何かに不満がある場合は、問題の原因を特定することによってのみ修正できます。はっきりさせておきますが、プログラマーが良いコードを書いたとおっしゃいました。つまり、彼はプログラミングが大好きです。 （会議の説明から）彼が仕事でイライラしていることは明らかであり、おそらく彼のパフォーマンスが本来あるべき位置を下回っていることはおそらく正しいですが、仮定しないでください。多くのプログラマーは社会的スキルを持っていないことを覚えておいてください。
あなたは完璧ではない
時々あなたは人格の衝突を起こすことになることを覚えておいてください特に内向的。これが人格紛争であることが判明した場合は、パフォーマンスの向上を得るためにどれだけ進んで進んでいくかを検討してください（1を参照）
言ったすべて
プログラマーの管理に関するブログ投稿を書きました。読んだ方がいいと思います。
http://deltreey.blogspot.com/2012/07/managing-programmers.html
その投稿の最後の部分は十分に強調することはできません。
あなたの開発者が少しでも良い人なら、彼らはコーディングしたいと思っています。
あなたのプログラマーは、たとえたるんでいても、たるみたくはありません。あなたはこの問題の根本を見つける必要があり、それは単に修正できないものであり、彼を手放さなければならないことが判明するかもしれませんが、それが何であれ、それを決定せずに情報に基づいた決定をすることはできません。
あなたが説明するように誰かが「管理するのがやや難しい」と感じた場合、そのパフォーマンスを理解し、開発チームのメンバーの生産性に影響を与える問題（客観的または主観的）があるかどうかを理解するには、優れた記事で紹介されているように、チームメンバーとの通常の1：1更新、ベント、および災害 ：
...私は1：1ごとに深く隠された緊急災害を発見するための曲がりくねった出来事であるとは示唆していませんが、不満が静かに現れる可能性がある毎週の場所を作成したいと思います。 1：1は、チームの健全性を理解しながら、予防保全を毎週行うチャンスです。
...成功した1：1の療法を取り巻く音は沈黙です。 1対1で行われるリスニング、質問、およびディスカッションはすべて、管理上の予防的なメンテナンスです。プロジェクトへの関心が弱まり、仕事の不満になる前に行動を起こす時期がわかります。 2人の従業員間の緊張について聞いて、それが会議で叫ぶ試合になる前にディスカッションをモデレートします。健康的な1：1の文化に対する報酬は、ドラマの明確な欠如です。
言及された記事の非常に強力な点は、それが自己完結型であるということです利点を説明することに加えて、基本的に定期的に練習を開始できるようにする一連の実践的な推奨事項も提供します1：1は他のソースを掘り下げることなく（追加の情報を探しても害はありませんが）。
明らかに、ここには大きなコミュニケーションの問題があります。彼は素晴らしい仕事をしているのかもしれませんが、彼が何をしているのかわからないという気持ちがあるなら、それ自体が問題です。そして、もし彼が何をしているのかわからなければ、彼の同僚もおそらく知らないでしょう。これは、2週間前のコードをチェックインするときに問題を引き起こす可能性があります。特に、同様の領域で作業している人がいた場合はそうです。
この種の競合を最小限に抑えるために、彼が更新をより定期的にチェックイン/提供することを常に提案できます。これにより、「あなたが何をしているのかわからない」ではなく、チームを支援するという観点からリクエストを処理できます。
スタンドアップは大嫌いになることは知っていますが、実際には同じ部屋で開催する必要はありません。 1日1回のクイックコールまたはグループSkypeの更新は非常に迅速であり、全員を同じページに保ちます。
私は現在、アイルランドのチームと一緒にインドから働いており、毎日彼らとコミュニケーションをとっていないとは想像できません。彼らのそれぞれが何であるかを大まかに知っているか、非常にすばやく見つけることができます。
無意味
毎日のステータス更新は無意味です。 「今日私は2.5％完了している」、「今日私は3.74％完了している」と人々に報告させるのはばかげています。
それは利害関係者に価値を提供せず、仕事をしている人々を困らせます。
邪魔されずに仕事に任せてください。
ベースレス
開発者Aが「パフォーマンスが低い」とはどういう理由で推測しますか？彼/彼女の仕事が時間通りに行われている場合、それで十分です。
あなたはマイクロマネージメントが嫌いだと言いますが、あなたが説明したのはまさにそれです。
私たちの会社は、プログラマを監視するだけでなく、利害関係者に進捗状況を知らせ続けるためにではなく、開発者に、使用するバグ追跡システムで作業の進捗状況を示すことを要求しています。 ...開発者は、毎日のようにタスクを更新する必要があります。
これは無意味です（上記を参照）ナンセンスです。あなたのチームはハンバーガーを弾くのではなく、技術的なソリューションを作り上げています。進捗状況は直線的ではなく、簡単に測定または推定することもできません。 たとえあったとしても、そのような毎日の測定値や推定値には価値がありません。
危険な
開発者Aが「パフォーマンスが低い」という「感じ」の根拠を再検討してください。彼/彼女はもっと上手くできると思いますが、どのような証拠に基づいていますか？
不満！=パフォーマンスが低い
説明どおりに続けると、ある時点で、開発者Aはおそらく自分が過小評価されていると判断し、会社に十分に提供し、別の会社を見つけるでしょう。従業員の努力の最後の0.01％を圧迫することは、彼らを長期間保持することよりもはるかに重要ではありません。
開発者は、自分が何をしているのかを文書化してステータスを更新する努力を嫌うかもしれませんが、それはプロの開発者であることの一部です。問題ログの彼の最新の更新が彼の仕事の不必要な否定的な認識を引き起こしていることを彼に指摘してみることをお勧めします。彼がコミュニケーションに失敗したことがパフォーマンスの問題であることがわからない場合は-あなたは彼のチームリーダーです。 彼に教えてくださいということです。
見積もりについて-それは古典的な問題です。 Steve McConnellによる「Software Estimation-Demystifying the black art」を読むことをお勧めします。この場合、ほとんどの開発者は過小評価しているような印象を与えます。不思議なことに、これは正常であり、ほとんど対処されていません。この個人ではなく、推定プロセス自体に問題があることをお勧めします。
見積もり-メジャー-レビューの「ループを閉じる」ようにして、改善してください。その後、開発者が時間通りに定期的にやって来て、この1人の個人がそうでない場合は、彼に対して何をすべきかを検討できます。
最後に、スタンドアップミーティングを行います。インスタントメッセージによる場合でも。必要なのは、「私が何をしたか、今日何をしているか、どんな問題も」知っている人だけです。また、問題がある場合は、後で議論するためにオフラインにしてください。それは私が以前にやったことであり、それはそのチームにとって成功しました。
まず、なぜあなたのスプリントはそんなに長いのですか？スプリントは2週間を超えてはなりません。あなたの問題の大部分はそこにあると思います。トライアルベースでスプリント時間を短縮してから、もう一度質問を分析することをお勧めします。
コードチェックインについてはどうですか？彼はいつもコードをチェックインしていますか？個人的にはプログラマーは本当に管理人ではないと思います、そしてあなたが管理しようとすればするほど、彼らはよりいらいらするでしょう。実際、私はそれらの更新タスクを行うのが嫌いで、おそらくそれがPMとLeadsがそこにいる理由です。しかし、同時に、スクラムミーティング中またはミーティングのたびにステータスを提供します。タスクを割り当てると、タスクはタイムラインにコミットしますか、それともタイムラインを割り当てたのはあなたですか？
したがって、誰かがパフォーマンスが低下しているかどうかを確認できる唯一の方法は、コミットされたタイムラインを完了した作業の割合にマップすることです。もちろん、2つの数値を合計するメソッドを作成するのに2日かかると誰かが言った場合、問題があることがわかっているので、タイムラインは現実的なものであり、両者によって合意されているはずです。
このようにしてください。1時間でコードを記述できる場合は、1時間+バッファを追加してください。彼がその時間内にあなたにそれを届けているなら、私たちはあなたたちがうまくやっていると思います。彼が彼に質問していない場合は、後で彼が合理的な説明を提供しているかどうかを決定するのはあなた次第です。
あなたができることの一つは、XPlannerのようなものをバージョン管理ツールと統合することです。
だまされている人を特定することに関しては、プログラミングの専門家が他の専門家と本質的に異なるとは思いません。あなたはあなたの腸に行かなければならないかもしれません。
個人的には、Aが一度に何週間もアップデートを提供することを拒否するのは奇妙だと思います。私は自宅で仕事をしているプログラマーです。私と私の雇用主の間には、進捗状況を毎日更新する必要のある暗黙の契約があります。これらは「公式」のアップデートではなく、私が作成するために支払われているソフトウェアで何が起こっているかを彼に知らせる短い電子メールまたはIMです。更新の作成には1〜2分もかからず、私たち2人とも閉鎖されます。バグ修正については、その日の終わりまでに、チケットをバグトラッカーで解決済みとしてマークします。これらは私にとって難しい手順ではありませんが、書類はほとんどなく、リラックスした作業環境を楽しんでいます。
カジュアルなアップデートでも彼から来ていただければ幸いです。あなたの投稿はとても寛大に聞こえます。彼が長い間怠けているのではないかと疑っていた場合、彼と一緒に対処するための別の言い訳は必要ありません。
Skypeを介して、またはチャットルームで毎日のスタンドアップはこれを回避する方法ですが、ステークホルダーの更新として扱う場合はそうではありません。 1日1回チーム全体がチェックインして、彼らが取り組んでいること、彼らが直面している課題、彼らが次に何を計画しているのかを言うとき、あなたはいくつかの勝利を得ます：
良い理由と悪い理由のどちらで時間を無駄にしているかにかかわらず、何かに時間がかかりすぎていることはより明確になり、開発者は必要なときに助けを求め、おそらく必要のない研究に行き過ぎないように働きかけますまたは、チームの他のメンバーからの入力が問題をより迅速にノックアウトするのに役立つときに、問題を解決して問題を解決します。
あなたは、マネージャーとして、人々が最も頻繁に障害物に遭遇している場所を確認できるため、時間/お金を浪費している根本的な問題をより適切に推定し、解決できる可能性があります。
IMO、それは、チームが比較的簡単なことでも時々行うのに通常どれだけの時間がかかるかを見ることができるときに、チームがより良い見積もりを約束することを学ぶのを本当に助けます。
チームメンバーが次に何をするつもりなのかをチームメンバーが言うと、優先順位を再設定するという観点から、伝達する必要があることをよく思い出されます。
したがって、「完了率」を忘れてください。みんなと同じようにみんなに正直になり、より多くの経験を積むにつれてより良い/より信頼できる見積もりを出し、それを気にせずに進捗状況を報告するように人々にもう少し動機を与えるプロセスを作るだけです。 -実際にはできないものに数字を付けるナンバリング演習。
上級管理職は、期限が常に満たされるとは限らないことを理解しているようです。スタンドアップを毎日行うと、その面でより多くの弾薬が得られます。なぜなら、彼らが攻撃されない理由についてより具体的なアイデアが得られるからです。
そして、最初にそれらをしないでください。常に間違いIMO。すべての問題がIMOであるかどうかをより確実に報告する前に、人々は問題に歯を戻す時間が必要です。
私の意見では、アカウンタビリティよりもコミュニケーションについて、そして単に目標を設定することに関するクイックスタンドアップは、何よりもアジャイルな作業を可能にするものです。私が取るか去ることができる残り、特に私が幹部/利害関係者のヘビ油と見なすようになったスクラム。
パフォーマンスが悪い？
人のキャリアの中で、激しさは衰退します。彼の費用よりも価値がある場合は、彼と話して、彼の仕事を簡単にするようにしてください。または、代替品を探し始めます。
コミュニケーション
毎週の会議に頼らないでください。ほとんどの人は完全なブレインダンプをするつもりはありません。さらに1：1をスケジュールします。どのように進んでいるのか、あなたがもっと上手くできること、そしてあなたが彼らが上手にできると感じていることを彼らに尋ねます。時々、話すことは何もありませんが、それは大丈夫です。 1：1を増やすことで、彼らが何かについて言及することを覚えておく可能性が高まります。
より永続的なコミュニケーション手段を持っている
余分な雑用のように感じさせない場合、人々からより多くの情報を得ることができます。すべてリモートの場合は、HipchatやIRCなどのログ機能を備えたチャットプログラムを使用するように依頼します。より永続的なコミュニケーション手段を持つことで、人々はより多く話すようになります。模範を示し、頻繁に話し合い、他の人にも同じことをするように促します。少なくとも1日1回、プロジェクトのどこにいるのかを人々に話してもらいます。時々、チャットを見ているだけで、物事の進行状況を感じることができます。
ソース管理
全員にコードを毎日チェックしてもらいます。 gitを使用している場合は、会社のリポジトリの独自のブランチにプッシュしてもらいます。コミットを確認することで、コミットの状態を確認できます。
手段を両端から分離する
利害関係者は更新したいですか？自分で利害関係者に対処します。マネージャーとしてのあなたの仕事の一部は、たわごとの傘になることです。そのため、コーダーは自分の仕事に集中できます。チャットログとコミットを確認し、状況を要約します。