假設您正在開發一個企業項目，在該項目中您必須獲得管理簽署才能開發新功能集。通常您的管理層在簽署一些明亮閃亮的新用戶界面功能時沒有問題。不幸的是，他們很難理解對於應用程序的福祉至關重要的一些幕後問題，例如交易，數據完整性，工作流程路線，可配置性，安全性等。由於它們是非技術性的並且這些問題是不立即可見，這對他們來說並不明顯，這是至關重要的。如何讓非技術人員欣賞非UI問題？
您是如何說服他們這些基礎設施問題必須處理並且對他們的業務流程至關重要的？
每種手藝都有其不和諧的一面。必須完成的事情，但沒有人直接注意到它們。在一家雜貨店，有人必須組織如何以及何時填補雜貨架，以便他們總是看起來新鮮。在洗衣店裏，你需要有人思考如何優化流程，以便顧客及時得到衣服。
棘手的部分是：客戶不會注意到這些微妙的事情已經完成的權利，直到他的聲明他們是失蹤！就像洗衣機沒有按時準備，但遲到兩天，或者超級市場的蔬菜有褐色斑點，看起來很糟糕。
同樣適用於IT。除非您的主要客戶敲你的門並告訴您一個重要且昂貴的項目失敗，因爲您的產品的數據庫條目神祕地混淆了，否則您不會注意到良好的交易。直到客戶的信用卡信息顯示在Elbonia（並且很快出現在貴公司的國家報紙警告客戶之後），您纔會注意到安全性。
你真的不得不一次又一次地敲入的東西是軟件不是靜態的。即使在最初的開發階段結束之後，它也必須得到關注。這不僅僅是一次購買而忘記的產品。每個汽車製造商都知道，服務對於他們構建的產品來說至關重要，只是因爲必須要修復和改進的東西纔會出現。這與軟件是一樣的。
因此，做一個演示文稿，可視化，表達，將您的技術信息轉化爲收益。業務人員並不關心重構項目中代碼美學的願望，但他們會理解，您的更改將有助於產品變得更加可靠，獲得更好的聲譽並減少未來服務請求的數量。通過向他們展示其好處讓他們瞭解！
同樣的事情人們已經做了幾千年：繪製圖片。分析問題，使用您的聽衆熟悉的視覺隱喻，將問題拖入其領域。
假設他們不是故意鈍的...
即使所有我們拿出的照片，無論是我們的分析師或管理上的吸收有點慢......所以我們要衝洗和重複......我們已經dilberted！ – Alan 2008-10-04 18:54:51
健壯性。當它歸結時，你需要談論他們的語言，這是它如何影響他們的底線。如果它是一個安全或正確的問題，你需要告訴他們，顧客不會想要不正確的行爲產品，無論他們看起來多麼好看。
類比和隱喻的大+1。如果可能的話，找到一個能夠引起觀衆個人興趣的共鳴（如果是1-2人）。對於一般的隱喻，出於某種原因，我經常發現自己使用通勤交通或地鐵。
例如我們目前正在將一個應用程序從OODB遷移到Postgres/Hibernate：這項工作的大部分工作都是在Release 4中完成的。許多領域專家一直在問爲什麼R4中面向用戶的功能非常少。我經常告訴他們，我們一直在「撕毀城市，投入地鐵。這是非常昂貴且無可否認的風險，但一旦完成，R5 +的優勢將會真正令人震驚。「真正的談話更加涉及，但我可以在R4之後一次又一次地回到這個主題。幾個月後，我希望說「你問X，現在很容易 - 正是因爲你讓我們把這個地鐵放回R4」。
讓上級管理層購買開發工作的最可靠方法是以可量化的方式呈現它。理想情況下，這種可量化的衡量標準爲$$。您需要向他們解釋減少數據完整性，安全性，交易等的後果，以及這將如何影響客戶和用戶社區，並最終影響到底線。在這些情況下，你應該小心，因爲管理層有時希望這些非功能性需求「能夠正常工作」。如果是這樣的話，你應該估計高點，並在可見的UI工作旁邊處理這些項目（無知是幸福的），或者當你與管理層溝通時需要記錄這些需求領域，所以如果事情確實如你所期望的那樣糟糕，這不是你的工作。
不幸的是，在這些東西得到應有的重視之前，通常需要一兩次災難。
這確實取決於你的管理層是什麼樣的人，但我很幸運，有很好的誠實善良的恐懼感。如果你經歷了一些災難情景，並指出某人如果它們發生會受到指責，那可能足以使他們的情緒本能踢進去並最終關注:)
我是與基本上相同的情況作鬥爭。無論是由管理層簽署還是由用戶/贊助商接受，問題仍然是不同的詞彙表，優先事項和觀點之一。 I asked a simmilar question here。
我也有不同的答案，很接近有用，但不夠明確。使用相關關鍵字瀏覽和搜索SO使我能夠在各種答案中找到有用的見解，並分散在許多不相關的問題上。找到並提取這些寶石導致我構成this question on site-mining。
能夠標記各種答案並在單個列表中查看所有答案會很有用，但是很遺憾，該功能在SO中尚不可用。我suggested it on uservoice。
希望你能從我給的參考資料中找到可以使用的東西。
汽車類比。
大家都知道這個'系統'，它描述了這個可怕的情況是非常複雜的。
是的，我喜歡說，但是每一個多次反覆的船員需要進站迭代燃料汽車，更改等通常遊戲作品有些輪胎。 – 2008-10-04 13:48:49
正確的反對問題是祕密。
描述性圖片確實可以幫助非技術人員理解您在說什麼。例如，下面是Sun公司描述信息如何在其中一個有點複雜的應用程序中處理的例子。
diagram from docs.sun.com http://docs.sun.com/source/816-7152-10/images/wsgoverview3.gif
試圖解釋在單詞本申請將是不可能的非易怒。指出圖表並說出看，這部分是我們的弱點，我們需要改進它。這對他們是有意義的。如果他們覺得自己對自己在做什麼有一些瞭解，他們會更願意支持您的請求。
我喜歡Technical Debt的想法，因爲它可以將技術問題翻譯成（儘管鬆散地）成金錢問題 - 而金錢是大多數管理人員都理解的。
雖然技術債務的概念最初是應用於建築問題，它可以被更廣泛地用於任何類型的情況下有壓力，走了一條捷徑 - 即進入技術債務 - 而不是做這是第一次。 （正確的做法相當於節省購買東西 - 這需要時間 - 而不是通過信貸購買並進入債務。）
正如債務可以是好的（例如住房貸款）和壞的如信用卡），所以技術債務可以是好的和壞的。我不會試圖完全表徵分歧，但良好的技術債能夠準確地進行跟蹤，讓你知道你是多麼的債務。
所以，儘量在技術債務方面來解釋你的重要，非UI問題，並在支付這些債務利息的條款不固定它的成本。
很好的答案。它強調了客戶和開發人員對交付後支持的需求。雙方的代表都處於危險之中。 – slashmais 2008-10-04 07:39:14