こんなジョークがある：

1. プログラマーは自分にBugがないと思うコードを書く。

2. ソフトウェアテストで20個のBugが見つかった。

3. プログラマーは10個のBugを修正し、テストチームに残り10個はBugではないと伝えた。

4. テストチームはそのうち5つの修正がまったく機能しないことを発見し、同時に15個の新しいBugを見つけた。

5. ステップ3とステップ4を3回繰り返す。

6. 市場からの圧力により、当初立てた過度に楽観的なリリーススケジュールに合わせるため、製品はついに市場に出た。

7. ユーザーは137件の新しいバグを発見しました。

8. プロジェクトボーナスを受け取ったプログラマーはどこかへ消えてしまった。

9. 新しく編成されたプロジェクトチームは、ほぼすべての137個のBugを修正したが、また456個の新しいBugを発見した。

10. 最初のプログラマーはフィジーから、給与未払いに苦しむテストチームに絵葉書を送ってきた。テストチームは全員で集団辞職した。

11. 会社は競合他社に敵対的買収された。買収時点で、ソフトウェアの最終版には783個のBugが含まれていた。

12. 新しいCEOが就任した。会社は新しいプログラマーを雇い、そのソフトウェアを書き直させた。

13. プログラマーは自分にBugがないと思うコードを書く。

私に言わせれば、本当にそんな会社があるなら、倒産しなければ国民に申し訳ない。

このジョークはプログラマーから始まり、プログラマーで終わり、最初から最後までプログラマーの非を言っている。しかし私が言いたいのは、これは完全に管理者の失敗であり、そのプロセス全体を通して管理業務は何も見られない。そういう管理者は無知無能であるだけでなく、恥知らずでもある——自分の失敗の責任をプログラマーに押し付けている。

1. プログラマーは何をもって自分のコードにBugがないと証明するのか？Test caseはあるのか？Code reviewはあるのか？この部分は管理が欠けている。

2. テストでBugが見つかったとき、Bug管理を行ったのか？追跡はしたのか？この部分は管理が欠けている。

3. 何をもってプログラマーがその10個のBugを修正したと証明するのか？残り10個はなぜBugではないのか？Bugの評価基準はプログラマーの言い分で決まるのか？この部分は管理が欠けている。

4. 機能しない5つのBug修正について責任は追及されたのか？新しいBugが増えるのは修正プロセスにおいて避けられないことだが、効果的なユニットテストの仕組みがあれば、こうした状況を大幅に減らせる。この部分は管理が欠けている。

5. イテレーションは正常だが、問題が収束に向かうのではなく発散したままになっている。効果的な管理の調整がないことが分かる。この部分は管理が欠けている。

6. 過度に楽観的なスケジュールと達成不可能な締め切りは、管理者の無知と無能を示している。そういう状況で無理に製品を出すのは、「無知な者は怖いもの知らず」ということだ。

7. これはユーザーに対する無責任な行為であり、管理者が最大の責任を負うべきだ。

8. こんな状況でプロジェクトボーナスを支払うとは、管理者は並大抵の愚かさではないと言わざるを得ない。

9. 管理業務には何の改善もなく、問題は依然として発散的なイテレーション状態にある。管理業務は依然として行き届いていない。

10. テスト部門への給与未払いは、管理者が品質管理業務を軽視していることと、人的資源管理についてまったく無知であることを示している。

11. 買収された側に贈る言葉は二言：「自業自得」。買収した側に贈る言葉も二言：「目が節穴」。

12. 新しい管理者も旧管理者もどんぐりの背比べで、問題の根本を認識していないことが分かる。ただし、こんな会社を買収するという決断ができるのは、そういう管理者だけだ。

13. 歴史の再演は必然である。

正常な企業やプロジェクトであれば、その運営は循環しながら上昇していくものでなければならない。そして、そのような運営を保証する仕事が管理である。管理業務の主な内容はコントロールであり、循環のペースをコントロールすること（速すぎず遅すぎず）、発展の方向をコントロールすること（上昇のみで下降しない）、運営の安定をコントロールすること（大きく浮き沈みしたり、集まったり散ったりしないこと）などが含まれる。

そして、これらのすべては、この例の中では見られない。

このジョークの例では、すべてが開発作業によって駆動されている。これはまず第一に方向性の誤りである。製品はユーザーのためにあるのだから、当然ユーザーと市場を駆動力とし、自社の能力を考慮した上で最終的に業務の重点を定めるべきだ。この誤りは、管理者が管理対象の内容をよく理解しておらず、より理解しているプログラマーにいいように操られるしかなかったことを反映している——実際、彼らは技術以外のことをもっと理解しているわけではない。

管理者は、自分が管理する内容を理解していなければ、うまく管理することはできない。

これは疑いの余地のないことだが、中国のソフトウェア業界はどうもこの点を信じていないようだ。中国ソフトウェア業界で最も害毒が深く浸透している嘘の一つが、「管理者は管理が分かっていればよく、技術を理解する必要はない」というものだ。

実際、これは無知無能で恥知らずな管理者が金を騙し取るためにでっち上げたものにすぎない。この言葉を信じる者は必ず金銭的な代償を払うことになるだろう。

次に品質管理。基本的な品質管理の常識は、各サイクルが終わる前に最も重要な作業は総括と改善であると教えている。そうして初めて、サイクルが制御を失って下向きに進むのではなく、上向きに発展することを保証できる。また、効果的な品質管理があって初めて、反復プロセスが収束的に発展し、最終的に目標を達成できる。しかしこの例では、この部分は明らかに欠けている——テスト部門はあるが、その役割は品質管理の中の品質検査の部分だけであり、管理の部分は依然として欠けている。

そして人的資源管理。ソフトウェア開発は労働集約型の仕事であり、頭脳労働ではあるが、同様に人的要因がその中で決定的な地位を占めることを意味する。この例では、Bugを修正し終えていないプログラマーがプロジェクトボーナスを受け取り、同じように懸命に働いたテスト担当者は給与を滞納されていた。これは、管理者が彼らの仕事の内容を理解していないこと、品質管理業務を軽視していることを示すだけでなく、管理者が人をまったく管理できないことも示している。これはチームを殺す行為である——チームを殺すことは、作るよりもはるかに簡単だ。

最後に、この失敗した管理者は自分の経験をこのジョークに仕立て上げ、プログラマーたちにどれだけひどい目に遭わされたかを皆に見せ、プログラマーを詐欺師の集団として妖魔化した。しかし、管理を少しでも理解している人が簡単に分析すればわかるように、この人物の現在の結果はただ彼の無知と無能によるものであり、責任を他人に押し付ける行為はさらに彼の恥知らずさを露呈している。高い地位にある管理者として、負うべき責任まで回避するのであれば、彼らに何が務まるというのだろうか。

来源：http://blog.csdn.net/raptor/article/details/727299