唯一の目的が取り出される機能を開発していますか？
個々のコントリビューター（プログラマー/デザイナー）が唯一の目的のためにアーティファクトを開発したパターンの名前は何ですか？管理者が最終的にその機能を削除できるように転用として機能することです製品？
これは、大手ゲーム開発会社で働いていた元同僚から聞いた民間伝承です。その会社では、中間管理職が製品に「入力を与え」、「変更」するように圧力をかけられていることはよく知られています。そうしないと、プロジェクトに貢献していないと見なされるリスクがあります。これらの過剰な「管理インプット」のために、この状況は多くのプロジェクトを遅らせました。
上記の会社の1つのプロジェクトで、アーティストと開発者はすべてのカットシーンに表示され、親指のように突き出た過剰なアニメーションキャラクターを作成しました。彼らは、ゲームが出荷される前に簡単に削除できるように設計しました（これは、ゲームがダウンロード可能な製品ではなく、まだ物理メディアで販売されていたときです）。明らかに、経営陣はその後、アニメーションの削除に投票しました。肯定的な面では、-プロジェクトはプロジェクトを遅らせるような不必要な変更を導入しませんでした彼らは製品に建設的なインプットを提供したことを示したためです。
これプロセスパターンは、企業で働くゲームプログラマの間で名前が付けられていますが、実際の名前を忘れてしまいました。アヒルだと思います---何か。誰もが名前を指摘するのを手伝うことができます、そしておそらくパターンがどのように発達するかについてのいくつかのかなり信頼できる参照？.
Interplayのバトルチェスに由来するとされる伝説から、これはduckと呼ばれています。
これはInterplayの企業伝承の一部として始まりました。プロデューサー（ゲーム業界の立場、PMとほぼ同じ）が、行われたすべてのことを変更しなければならないことはよく知られていました。想定は、無意識のうちに、もしそうでなければ価値を付加していないと感じていたということでした。
バトルチェスのクイーンアニメーションに取り組んでいるアーティストは、この傾向を認識しており、革新的なソリューションを考え出しました。彼は女王のためのアニメーションを自分が最もよく感じる方法で行いましたが、1つ追加しました。彼は女王にペットのアヒルを与えました。彼は女王のすべてのアニメーションを通してこのアヒルをアニメートし、角を曲がったように羽ばたきました。また、「実際の」アニメーションと重複しないように細心の注意を払いました。
結局、プロデューサーが女王のアニメーションセットを確認するときが来ました。プロデューサーは座ってすべてのアニメーションを見ました。彼らが終わったとき、彼は芸術家の方を向いて言った。アヒルを取り除くだけです。」
私は単に、スケジュールされた作業をできるだけ長く延ばすことによって、または人々を忙しくまたは働かせ続けるために無意味な忙しい作業を作成することによって、プロジェクトで自分の目的を検証する管理者としてそれを単に見ます。
私はこれを5つの異なるタイプで個人的に見ました：
政府のプロジェクト-多くの場合、マネージャーのプロジェクトの予算や時間が不足していると、将来、マネージャーにとってうまくいかなくなります。彼らは良い仕事のために賞賛されるかもしれませんが、彼らがそれを正当化することができないならば彼らの予算が来年減らされるというリスクを実行します。政府では予算編成が機能しているため、政府のプロジェクトは割り当てられた予算を可能な限り活用することを目指しています。
大規模なチームと、保守や書き込みが比較的簡単なソフトウェアを担当する、時代遅れの可能性があるマネージャー。企業の世界では危険が現実にあり、彼らが真の重荷を払おうとするとき、彼らは真の責任が最も少ない中間管理職を探し、そこから移動します。彼らは、不要な範囲を過大評価して作成することにより、自分の立場を保護すると感じています。
一部のソフトウェア会社は、基本的にはグッドオルボーイクラブであり、収益性が高いがニッチな市場を追い払うシンプルなソフトウェアまたはレガシーソフトウェアを持っています。通常、お金は比較的簡単で、野心は比較的低く、すべてのマネージャーは親友であり、大きな給料を持ち帰りながらお互いの目的を検証しようとします。そのような会社では、つながっていない限り、進歩の余地はありません。彼らはしばしば、すでに十分に解決された問題に意味のない忙しい仕事を作り出すことによって、自分の重要性を検証しようとします。
一部の契約言語では、ソフトウェアの定期的なリリースと継続的な改善が必要です。よく解決された問題の場合、ユニークで新しい機能を見つけることは困難または不可能です。多くの場合、多忙な作業が割り当てられます。多分多分何かを追加し、次のリリースではほとんど削除することです。
マネージャーは合法的にチームをまとめることに無関心であるか、単にニースになりたいと思っています。彼は自分のチームの目的を検証し、彼らを彼の下で雇用させ続けるでしょう。
私の上司はそれを「噴水戦略」と呼んだ。彼は大規模な噴水が正面にある大学の新しいコンピューター棟を設計しました。ウィングは承認されましたが、計画どおり噴水はありませんでした。
それは50年前のことなので、これは新しいことではありません。
私が取り組んだいくつかのプロジェクトでは、それらを「自転車小屋」と呼んでいますが、これは 自転車小屋問題 という用語への同意です。この用語は、本パーキンソンの法則の一節から来たものであり、原子力発電所は非常に複雑で、管理者が何かに触れるのを恐れているが、自転車が流されていると説明しているとてもシンプルなので、誰もが「ディザリング」して「管理」しているように見せかける必要があります。