本節書摘來異步社群《高效能程式員的修煉》一書中的第3章，作者： 【美】jeff atwood 譯者： 陸其明 , 張健 責編： 陳冀康, 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
高效能程式員的修煉
軟體開發者們是真心喜愛編寫代碼的。但根據我的經驗，他們當中很少有人可以解釋清楚他們為什麼在編寫代碼。如果你不信，你可以從你的團隊裡找個人來測試一下：問他在做什麼；接着問他為什麼要做那個；繼續問下去，直到你得到一個可以讓你的客戶了解的原因。
你在做什麼？
我在修複這個資料網格的排序問題。
你為什麼要解決這個問題？
因為它在bug清單上。
它為什麼在bug清單上？
因為有個測試人員把它作為一個bug報出來了。
為什麼它被作為一個bug報出來了？
測試人員認為這個字段應該按照數字順序而不是字母順序來排序。
為什麼測試人員這麼認為？
很顯然，如果把“條目2”排在“條目19”的後面，使用者在查找的時候就會有麻煩。
如果這段對話在你看來很奇怪，或許你還沒有跟足夠多的軟體開發者一起工作過。你知道你到底要問多少次“為什麼”才會得到你的客戶真正在意的答案嗎——哪怕隻挨上一點邊？正如“你要舔多少次才能吃完一根tootsie pop棒棒糖”這個問題，答案一定會讓你很吃驚！
這是一個巨大的鴻溝！
軟體開發者認為他們的工作就是編寫代碼。其實不然。（這句話是我從billy hollis那裡“偷”來的。他曾以軟體癡迷者為主題做過15分鐘的精彩演講。）他們的工作應該是解決客戶的問題。當然，我們偏愛通過軟體來解決問題，那的确包含了編寫代碼。但是，我們要有全局的觀點：在傳遞完整的解決方案的過程中，編寫代碼隻是其中一環。它自身并不是目的。
作為軟體開發者，我們花了那麼多時間沉浸在沒完沒了的、支離破碎的細節中，以至于我們太容易掉入為了編碼而編碼的陷阱中。如果沒有明确的焦點或者某種讓我們團結在一起的東西，我們就會隻見代碼這棵樹木而不見整個森林。由此可見，擁有一個清晰的項目遠景聲明（vision statement）是極其重要的，每個人都可以把它當做這個項目的試金石。如果你把遠景聲明搞清楚了，你團隊裡的每個人都應該能通過由陌生人主持的“電梯測試”——在60秒之内，清晰地解釋他們在做什麼，以及為什麼人們會在意他們正在做的事情。
如果你的團隊不能用一種合理的方式向一個外行解釋他們的工作，不管你有沒有意識到，你都已經處在麻煩之中了。所幸的是，你有個好夥伴——jim highsmith可以幫助你。他推薦了一個可以建構項目遠景模型的速效公式：
一個項目遠景模型可以幫助團隊成員通過“電梯測試”——它能賦予團隊成員在2分鐘之内向别人解釋清楚項目的能力。這個模型出自geoffrey moore1的一本書：《跨越鴻溝》（《crossing the chasm》）。它遵循如下的形式：
為了（目标客戶）
他們（關于需求或者機會的說明）
這個（産品名稱）是（産品類别）
它的（關鍵優勢、吸引人的購買理由）
不像（主要競争對手的替代産品）
我們的産品（主要的差異化的特性說明）
建立一個項目遠景聲明可以幫助團隊持續專注于産品的關鍵方面，哪怕細節一直在快速變化也不怕；否則，團隊很容易就會被短期（2～4周）開發疊代中的問題纏住，進而失去對整個項目遠景的控制。
我對這個速效公式并不感冒，因為它太過死闆。但它是一個不錯的開始。玩玩“mad libs”2吧，看你能想到些什麼——絕對不能沒有遠景聲明，但也不要一個毫無感覺、用雜亂無章的拼盤僞裝成的遠景聲明。然而，我認為jim關于開發遠景聲明的第二個建議更能給我們帶來希望。
我認為，即使在一個提供資訊技術服務的組織裡，每個項目都應該被當作是一個創造“産品”的過程。無論這個項目的目标是提升内部的會計系統，還是建立一個全新的電子商務網站，面向産品的思維方式必能帶來豐厚的回報。
我發現有一種做法在讓整個團隊思考産品遠景方面很有效果，那就是“設計産品包裝盒”。這個練習可以在項目啟動階段很好地激發大家的思維和讨論。整個團隊假設産品最終會被裝在一個可拆封的盒子裡，而他們的任務就是設計這個包裝盒的正面和背面。這包括給産品起個名字、一幅圖檔、正面列出3～4個關鍵點來“叫賣”這個産品、背面的詳細特性說明以及運作要求。
實踐證明，想出15～20個産品特性是容易的。難就難在，要選出其中3～4個能促使人們購買這個産品的特性。這個過程中還經常會發生關于“誰是真正的客戶”的激烈争論。
“設計産品包裝盒”是建構遠景聲明的一種極好的方法。它基于一個具體的、真實世界裡的概念，是以大多數人都可以輕松地開動他們的腦筋。忘掉那些空中餡餅式的遠景追求吧，讓我們務實一點：我們（假想）的産品包裝盒看起來會是什麼樣的呢？
我們都是消費者。我們對産品包裝盒的設計目标都很清楚。如果不拿産品包裝盒跟極端的“電梯推介3”相提并論，那它也應該：
用最簡單可行的方法來解釋我們的産品是什麼；
把潛在客戶願意購買這個産品的原因解釋得一清二楚；
與貨架上所有其他的産品包裝盒相比具有獨一無二的辨識度。
這裡有個例子，讓我們來看看命運多舛的microsoft bob4的包裝盒。你該如何解釋為什麼客戶應該購買microsoft bob？甚至你該如何說明這個見鬼的microsoft bob到底是個什麼東西？
看看那些現有的、你覺得引人注目的産品包裝盒是有指導意義的。當然，看看那些你覺得不好的包裝盒也可以引以為戒。我們很清楚我們的産品包裝盒不應該是什麼樣子。
從項目開始的第一天就确立一個堅定的遠景聲明吧！如果你還沒有，那就從jim衆多美妙的建議裡随便挑選一個，然後照着去做，立即建構出一個遠景聲明。在缺乏清晰的遠景聲明時，無法通過“電梯測試”的團隊數目将是令人震驚的——他們不能解釋他們正在做什麼，或者為什麼他們的工作是有意義的。不要犯那樣的錯誤。建構一個了不起的遠景聲明，讓你的隊友們可以使他們的工作與這個遠景相關聯。確定你的團隊可以通過“電梯測試”。
作者在twitter上發的一條短訊：
“當一個編碼瘾君子需要修好一樣東西的時候，他隻會多寫上幾行代碼。” *