非技術者に非UIの問題をどのように評価させるのですか？ [閉まっている]

Question

新しい機能セットを開発するために、管理プロジェクトのサインオフを取得する必要があるエンタープライズプロジェクトに取り組んでいるとします。通常、管理者は、明るい光沢のある新しいUI機能にサインオフしても問題ありません。残念なことに、トランザクション、データの整合性、ワークフロールーティング、構成可能性、セキュリティなど、アプリケーションの幸福に不可欠な舞台裏の問題を理解するのに苦労します。すぐには見えませんが、これが重要であることは明らかではありません。

これらのインフラストラクチャの問題に対処する必要があり、ビジネスプロセスにとって重要であることをどのように説得しましたか？

Answer 1

すべてのクラフトには、セクシーではない側面があります。やらなければならないこと、しかし誰も直接それらに気付かないこと。食料品店では、常に新鮮に見えるように、食料品棚をいつどのように満たすかを整理する必要があります。ランドリーでは、顧客が服を間に合うように最適化する方法を考える人が必要です。

注意が必要なのは、これらの微妙なことが正しく行われていることに気付かないことです。洗濯物が時間通りに準備ができていないが2日遅れているとき、またはスーパーマーケットの野菜に茶色の斑点があり、ひどく見えるときのように。

ITにも同じことが言えます。主要な顧客がドアを叩き、製品のデータベースエントリが不可解に混同されたために重要かつ高価なプロジェクトが失敗したことを伝えるまで、良い取引に気付かないでしょう。顧客のクレジットカード情報が Elbonia に表示されるまで（そして、すぐにセキュリティが向上することに気付かないあなたの会社の顧客に警告する全国紙にあります）。

あなたが本当に何度も何度も叩かなければならないことは、ソフトウェアは静的ではないということです。最初の開発段階が終わった後でも、手入れが必要です。一度購入して忘れるだけの製品ではありません。すべての自動車メーカーは、修理や改善が必要な事態が発生するという理由だけで、サービスが製造する製品にとって最も重要であることを知っています。ソフトウェアでも同じです。

そのため、プレゼンテーションを作成し、視覚化し、言語化し、技術情報をメリットに翻訳します。ビジネスの人々は、リファクタリングプロジェクトでのコードの美学に対する希望を気にしませんが、あなたの変更が製品の信頼性を高め、評判を高め、将来のサービスリクエストの量を減らすのに役立つことを理解します。メリットを示して理解を深めてください！

Answer 2

人々が何千年も同じことをしているのは、絵を描くことです。問題を図式化し、視聴者になじみのある視覚的なメタファーを使用して、問題を領域にドラッグします。

意図的に鈍感ではないと仮定して...

Answer 3

類推と比phorのための大きな+1。可能であれば、視聴者の個人的な関心に共鳴するものを見つけてください（1〜2人の場合）。一般的な比phorでは、何らかの理由で通勤や地下鉄を使用することがよくあります。

e.g。現在、アプリケーションをOODBからPostgres / Hibernateに移行しています。この作業の大部分はリリース '4'で行われています。多くのドメインの専門家が、R4にユーザー向けの機能がそれほど多くない理由を尋ねてきました。私は定期的に彼らに「地下鉄を入れるために街を引き裂いている」と言っています。それは非常に高価であり、紛れもなくリスクを伴いますが、それが完了すると、R5 +のメリットは驚くべきものになります。」真の会話はより複雑ですが、R4のかなり後に、何度も何度もこのテーマに戻ることができます。今から数か月後、「Xを要求しましたが、非常に簡単になりました。まさに、地下鉄をR4に戻したからです」と言いたいと思います。

Answer 4

上位レベルの管理者が開発作業を買収する最も確実な方法は、それを定量化可能な方法で提示することです。理想的には、この定量化可能な尺度は$$単位です。データの整合性、セキュリティ、トランザクションなどをスキッピングした結果と、それが顧客/ユーザーコミュニティに影響を与え、最終的に収益に与える影響を説明する必要があります。これらの状況では注意が必要です。管理者は、これらの非機能要件が「正常に機能する」ことを期待する場合があるためです。この場合、高いと推定してこれらのアイテムを目に見えるUIの作業と一緒に作業するか（無知は至福です）、または管理者と通信するときに必要なこれらの領域を文書化する必要があります。あなたの仕事ではありません。

Answer 5

残念なことに、このようなものがそれにふさわしい注意を得るには、通常1〜2回の災害が発生します。

それは本当にあなたの管理がどのようなものかによって異なりますが、私は古き良き誠実さへの恐怖心で運がありました。いくつかの災害シナリオを経験し、発生した場合に誰かが非難されることを指摘すれば、それは彼らの探究本能を開始し、最終的に注意を払うのに十分です：

Answer 6

車のアナロジー。

誰もがその「システム」を知っており、悲惨な状況を表現するには十分に複雑です。

Answer 7

私は本質的に同じ種類の状況と戦っています。管理者によるサインオフであろうと、ユーザー/スポンサーによる受け入れであろうと、問題は依然として異なる語彙、優先順位、視点の1つです。 ここで同様の質問をしました。

私はまた、多様な答えを得ました。有用に近いが、十分に決定的なものではありません。関連するキーワードを使用してSOを参照および検索すると、関連のない多くの質問にまたがるさまざまな回答の有用な洞察が見つかりました。これらの宝石を見つけて抽出するために、サイトマイニングに関するこの質問を提示しました。

さまざまな回答にフラグを立てて、それらすべてを単一のリストに表示できると便利でしたが、残念ながら、その機能はまだSOでは使用できません。 uservoiceで提案。

提供した参考文献から使用できるものを見つけてください。

Answer 8

適切な種類の反論質問は秘密です。

• 5つのWebページごとにクラッシュしても大丈夫ですか？
• クレジットカード番号を保護する必要がありますか？
• 毎週週末にパッチを展開するために請負業者に支払う必要はありますか？
• 今すぐ必要ですか、それとも機能しますか？

Answer 9

堅牢性。結局のところ、あなたは彼らの言語を話す必要があります。それはそれが彼らの収益にどのように影響するかです。セキュリティまたは正当性の問題である場合は、見栄えが良くても、顧客は不正に動作する製品を望んでいないことを伝える必要があります。

Answer 10

技術的債務のアイデアが好きです。技術的問題を翻訳できるからです（大まかに）お金の問題に-そしてお金はほとんどのマネージャーが理解しているものです。

技術的負債の考え方はもともと建築上の問題に適用されていましたが、それを行うのではなく、ショートカットをとる、つまり技術的負債に入るというプレッシャーがあるあらゆるタイプの状況でより広く使用することができます初めて。 （正しく実行することは、クレジットで購入して借金をするのではなく、何かを購入するために貯金するのと同じです。時間がかかります。）

借金は良いもの（例：住宅ローン）と悪いもの（例：クレジットカード）になり得るので、技術的な借金は良くも悪くもなります。違いを完全に特徴付けようとはしませんが、良い技術的負債を正確に追跡できるので、あなたはどのくらいの負債を抱えているかを知ることができます。

だから、あなたの重要な非UIの問題を技術的負債の観点から説明し、その負債の利子を支払うという観点からそれを修正しないコストを説明してください。

Answer 11

説明的な画像は、技術に詳しくない人々があなたが話していることを理解するのに本当に役立ちます。たとえば、以下は、やや複雑なアプリケーションの1つで情報がどのように処理されるかを説明するサンの例です。

_{（ソース： sun.com ）}

このアプリケーションを言葉で説明しようとするのは、技術者でない人には不可能でしょう。図を見て、この部分は弱点であり、改善する必要があります。それは彼らにとって理にかなっています。彼らがあなたが何をしているのかをある程度理解していると感じるなら、彼らはあなたのリクエストをもっと喜んでサポートするでしょう。