軟件開發者們真心喜好編寫代碼。但根據個人經驗，他們當中不多有人能夠解釋清楚他們爲何在編寫代碼。若是你不信，你能夠從你的團隊裏找我的來測試一下：問他在作什麼；接着問他爲何要作那個；繼續問下去，直到你獲得一個你的客戶能夠理解的緣由。微信
你在作什麼？測試
我在修復這個數據網格的排序問題。網站
你爲何要解決這個問題？編碼
由於它在bug清單上。spa
它爲何在bug清單上？.net
由於有個測試人員把它做爲一個bug報出來了。設計
爲何它被做爲一個bug報出來了？orm
測試人員認爲這個字段應該按照數字順序來排序而不是按字母順序。blog
爲何測試人員這麼認爲？排序
很顯然，若是把「條目2」排在「條目19」的後面，用戶在查找的時候就會有麻煩。
若是這段對話在你看起來很奇怪，或許你尚未跟足夠多的軟件開發者一塊兒工做過。你知道你到底要問多少次「爲何」纔會獲得你的客戶真正在乎的答案嗎——哪怕只要捱上一點邊？正如「你要舔多少次才能吃完一根tootsie pop棒棒糖」這個問題，答案必定會讓你很吃驚！
這是一個巨大的鴻溝！
軟件開發者認爲他們的工做就是編寫代碼。其實否則。（這句話是我從Billy Hollis那裏「偷」來的。他曾以軟件癡迷者爲主題作過15分鐘的精彩演講。）他們的工做應該是解決客戶的問題。固然，咱們偏心經過軟件來解決問題，那的確包含了編寫代碼。可是，咱們要有全局的觀點：編寫代碼是咱們爲了交付解決方案所必須完成的其中一環。它自身並非目的。
做爲軟件開發者，咱們花了那麼多時間沉浸在沒完沒了的、支離破碎的細節中，以至於咱們太容易掉入爲了編碼而編碼的陷阱中。若是沒有明確的焦點或者某種讓咱們團結在一塊兒的東西，咱們就會只見代碼這棵樹木而看不見整個森林。因而可知，擁有一個清晰的項目遠景聲明（Vision Statement）是極其重要的，每一個人均可以把它看成這個項目的試金石。若是你把遠景聲明搞清楚了，你團隊裏的每一個人都應該能經過由陌生人主持的「電梯測試」——在60秒以內，清晰地解釋他們在作什麼，以及爲何人們會在乎他們正在作的事情。
若是你的團隊不能用一種合理的方式向一個外行解釋他們的工做，無論你有沒有意識到，你已經處在麻煩之中了。所幸的是，你有個好夥伴——Jim Highsmith能夠幫助你。他推薦了一個能夠構建項目遠景模型的速效公式：
一個項目遠景模型能夠幫助團隊成員經過「電梯測試」——它能賦予團隊成員在2分鐘以內向別人解釋清楚項目的能力。這個模型出自Geoffrey Moore的一本書：《跨越鴻溝》（《Crossing the Chasm》）。它遵循以下的形式：
譯者注：Geoffrey Moore（傑弗裏·摩爾）是美國硅谷的一位高科技產業顧問、風險投資人以及做家。人稱「高科技營銷魔法之父」。他創立的關於技術產品生命週期的定律，被稱爲「新摩爾定律」。摩爾是鴻溝諮詢公司的創始人，同時他還擔任一些聲名顯赫的商業領袖的私人顧問，幫助高科技公司化解企業戰略和經營方針上的危機，惠普、微軟、甲骨文等公司都是摩爾的客戶。他的著做是哈佛、斯坦福等許多著名商學院的必讀書。
爲了（目標客戶）
他們（關於需求或者機會的說明）
這個（產品名稱）是（產品類別）
它的（關鍵優點、吸引人的購買理由）
不像（主要競爭對手的替代產品）
咱們的產品（主要的差別化特性的說明）
建立一個項目遠景聲明能夠幫助團隊持續專一於產品的關鍵方面，哪怕細節一直在快速變化。不然，團隊很容易就會被短時間（2~4周）開發迭代中的問題纏住，從而失去對整個項目遠景的把握。
我對這個速效公式並不感冒，由於它太過死板。但它是一個不錯的開始。玩玩「MadLibs」吧，看你能想到些什麼——絕對不能沒有遠景聲明，也不要一個毫無感受、用雜亂無章的拼盤假裝成的遠景聲明。然而，我認爲Jim關於開發遠景聲明的第二個建議更能給咱們帶來但願。
譯者注：Mad Libs是一個文字模板遊戲，由一方向另外一方提供一系列備選單詞，而後用這些單詞替換故事模板裏的空白，結果經常會很是可笑。
我認爲，即便在一個提供信息技術服務的組織裏，每一個項目都應該被看成是一個創造「產品」的過程。不管這個項目的目標是提高內部的會計系統，仍是創建一個全新的電子商務網站，面向產品的思惟方式必能帶來豐厚的回報。
我發現有一個作法在讓整個團隊思考產品遠景方面頗有效果，那就是「設計產品包裝盒」。這個練習能夠在項目啓動階段很好地激發你們的思惟和討論。整個團隊假設產品最終會被裝在一個可拆封的盒子裏，而他們的任務就是設計這個包裝盒的正面和背面。這包括給產品起個名字、一副圖片、正面列出3~4個關鍵點來「叫賣」這個產品、背面的詳細特性說明、以及運行要求。
實踐證實，想出15~20個產品特性是容易的。難就難在，要選出其中3~4個能促令人們購買這個產品的特性。這個過程當中還常常會發生關於「誰是真正的客戶」的激烈爭論。
「設計產品包裝盒」是構建遠景聲明的一種極好的方法。它基於一個具體的、真實世界裏的概念，所以大多數人均可以輕鬆地開動他們的腦筋。忘掉那些空中餡餅式的遠景追求吧，讓咱們務實一點：咱們（假想）的產品包裝盒看起來會是什麼樣的呢？
咱們都是消費者。咱們對產品包裝盒的設計目標都很清楚。若是不拿產品包裝盒跟極端的「電梯推介」相提並論，那它也應該：
用最簡單可行的方法來解釋咱們的產品是什麼；
把潛在客戶願意購買這個產品的緣由解釋得一清二楚；
與貨架上全部其餘的產品包裝盒相比具備獨一無二的辨識度。
譯者注：電梯推介（elevator pitch），一般是指創業公司在一分鐘以內向投資者介紹本身公司的狀況。時間如此之短，短到彷彿只是兩人共同搭乘了一段電梯。投資的決定固然很難就在這一分鐘以內作出。電梯推介的目的，是引發投資人的興趣，讓他願意給創業公司一個去更詳細介紹本身的機會。
這裏有個例子，讓咱們來看看命運多舛的Microsoft Bob的包裝盒。你該如何解釋爲何客戶應該購買Microsoft Bob？甚至你該如何說明這個見鬼的Microsoft Bob究竟是個什麼東西？
譯者注：Microsoft Bob是微軟於1995年推出的一款產品，它是微軟首次嘗試開發互動性更強、更天然的用戶界面。Microsoft Bob的推出主要是爲了知足初級計算機用戶的需求，雖然有着很好的創意，可是過於簡單，只是講解如何使用計算機，而售價卻高達100美圓，結果在沒有市場的狀況下被淘汰了。
本文分享自微信公衆號 - 軟件測試經驗與教訓（udatest）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。