新しい機能セットを開発するために管理者の承認を得る必要があるエンタープライズ プロジェクトに取り組んでいるとします。通常、経営陣は、輝かしい新しい UI 機能を問題なく承認します。残念ながら、トランザクション、データの整合性、ワークフローのルーティング、構成可能性、セキュリティなど、アプリケーションの健全性にとって重要な舞台裏の問題を理解するのに苦労しています。これらの問題は技術的ではなく、すぐには見えないため、これが重要であることは明らかではありません。
これらのインフラストラクチャの問題に対処する必要があり、それがビジネス プロセスにとって重要であることをどのように彼らに納得させましたか?
すべての工芸品には、セクシーでない側面があります。やらなければならないことなのに、誰も直接気づかない。食料品店では、食料品の棚をいつ、どのように満たすかを整理して、常に新鮮に見えるようにする必要があります。ランドリーでは、顧客が時間内に衣服を手に入れることができるように、プロセスを最適化する方法を考える人が必要です。
トリッキーな部分: 顧客は、これらの微妙なことが欠けていることに気付くまで、これらの微妙なことが正しく行われたときに気付かない. たとえば、洗濯物が時間通りに準備できずに 2 日遅れたり、スーパーマーケットの野菜に茶色の斑点ができて見栄えが悪い場合などです。
ITも同じです。主要な顧客があなたのドアをノックして、あなたの製品のデータベース エントリが不思議なことに混同されたために重要で高価なプロジェクトが失敗したことを告げるまで、あなたは良い取引に気付きません。顧客のクレジット カード情報がElboniaに表示されるまで(そしてすぐに全国紙にあなたの会社の顧客に警告する言葉が掲載されるまで)、セキュリティの良さに気付きません。
何度も何度も打ち込まなければならないことは、ソフトウェアは静的ではないということです。初期の開発段階が終わった後でも、世話をする必要があります。一度買って忘れてしまうだけの商品ではありません。すべての自動車メーカーは、自社の製品にとってサービスが最も重要であることを認識しています。ソフトウェアも同じです。
プレゼンテーションを作成し、視覚化し、言語化し、技術情報を利益に変換します。ビジネス関係者は、リファクタリング プロジェクトでコードの美学に対するあなたの希望を気にしませんが、あなたの変更が製品の信頼性を高め、評判を高め、将来のサービス リクエストの量を減らすのに役立つことを理解するでしょう。メリットを見せて理解してもらいましょう！
人々が何千年も前から行ってきたことと同じこと、それは絵を描くことです。問題を図解し、聴衆になじみのある視覚的な比喩を使用して、問題を彼らの領域にドラッグします。
彼らが意図的に鈍くなっていないと仮定すると...
類推と比喩のための大きな+1。可能であれば、視聴者の個人的な関心に共鳴するものを見つけます (1 ～ 2 人の場合)。一般的な例えで言えば、私はなぜか通勤電車や地下鉄を利用していることがよくあります。
例: 現在、OODB から Postgres/Hibernate にアプリを移行しています。この作業の大部分は、リリース '4' で行われています。多くのドメイン エキスパートは、R4 にユーザー向けの機能がほとんどない理由を尋ねてきました。私は定期的に彼らに、私たちは「地下鉄を建設するために街を壊している」と話している. 非常に費用がかかり、リスクが高いことは間違いありませんが、実現すれば、R5+ のメリットは本当に驚くべきものになるでしょう。」本当の会話はもっと複雑ですが、R4 のかなり後で、このテーマに何度でも戻ることができます。今から数ヶ月後、私は「あなたは X を求めましたが、今は非常に簡単です。まさにあなたが地下鉄を R4 に戻すことを許可してくれたからです」と言いたいと思っています。
上層部の管理職に開発作業を任せてもらう最も確実な方法は、それを定量化できる方法で提示することです。理想的には、この定量化可能な尺度は $$ です。データの整合性、セキュリティ、トランザクションなどを軽視した場合の結果と、それが顧客やユーザーのコミュニティ、そして最終的に収益にどのように影響するかを説明する必要があります。管理者は、これらの非機能要件が「機能する」ことを期待する場合があるため、これらの状況には注意する必要があります。このような場合は、高い見積もりをして、目に見える UI 作業と並行してこれらの項目に取り組むか (無知であることは至福です)、または管理者とやり取りする際にこれらの必要な領域を文書化する必要があります。危機に瀕しているのはあなたの仕事ではありません。
適切な種類の対抗質問は秘密です。
残念ながら、このようなものに値する注目を集めるには、通常、1、2 回の災害が必要です。
それはあなたの経営陣がどのようなものであるかに大きく依存しますが、私は古き良き正直な恐怖を煽る幸運に恵まれました. いくつかの災害シナリオを経験し、誰かが起こった場合に非難されることを指摘すると、それは彼らの追跡本能を働かせ、最終的に注意を払うのに十分です:)
私は本質的に同じ種類の状況と戦っています。経営陣による承認であろうと、ユーザー/スポンサーによる承認であろうと、問題は依然として異なる語彙、優先順位、視点の 1 つです。ここで同様の質問をしました。
私はまた、興味をそそるほど有用に近い多様な答えを得ましたが、十分に決定的ではありません. 関連するキーワードを使用して SO を参照および検索すると、関連のない多くの質問にまたがるさまざまな回答に有用な洞察が見つかりました。これらの宝石を見つけて抽出するために、サイトマイニングでこの質問をするようになりました。
さまざまな回答にフラグを立てて、それらすべてを 1 つのリストで表示できると便利でしたが、残念ながら、その機能は SO ではまだ利用できません。uservoice で提案しました。
私が提供した参考文献から使用できるものを見つけてください。
車のアナロジー。
その「システム」は誰もが知っており、悲惨な状況を描写するには十分に複雑です。
説明的な写真は、技術者以外の人があなたが話していることを理解するのに本当に役立ちます。たとえば、以下は、やや複雑なアプリケーションの1つで情報がどのように処理されるかを説明するSunの例です。
（出典：sun.com）
このアプリケーションを言葉で説明しようとすることは、技術者でない人には不可能です。ダイアグラムを指して見て言うと、この部分は私たちの弱点であり、改善する必要があります。それは彼らにとって理にかなっています。彼らがあなたがしていることをある程度理解していると感じれば、彼らはあなたの要求をはるかに喜んでサポートするでしょう。
堅牢性。結局のところ、あなたは彼らの言葉を話す必要があり、それが彼らの収益にどのように影響するかです. セキュリティまたは正確性の問題である場合は、見た目がどんなに優れていても、顧客は不適切な動作をする製品を望んでいないことを伝える必要があります。
私は技術的負債の考え方が好きです。なぜなら、技術的問題を (大まかにではありますが) お金の問題に変換できるからです。お金はほとんどのマネージャーが理解しているものです。
技術的負債の考え方はもともとアーキテクチャの問題に適用されたものですが、最初から正しく行うよりも、近道をとらなければならない、つまり技術的負債に陥るというプレッシャーがあるあらゆる種類の状況に、より広く使用できます。時間。（それを正しく行うことは、クレジットで購入して借金をするのではなく、何かを購入するために貯蓄することと同じです-時間がかかります. ）
負債に良いもの (住宅ローンなど) と悪いもの (クレジット カードなど) があるように、技術的負債にも良いものと悪いものがあります。違いを完全に特徴付けるつもりはありませんが、優れた技術的負債は正確に追跡できるため、負債がどれだけあるかがわかります。
したがって、UI 以外の重要な問題を技術的負債の観点から説明し、それを修正しない場合のコストを、その負債に対する利息の支払いという観点から説明してください。
