愛因斯坦曾經說過，如果他有一小時來拯救世界，他會花 55 分鐘來定義問題，只花 5 分鐘去尋找解決方案。除了在問題和解決方案上所花費的時間比例之外，我完全同意他對于在設法解決問題之前先理解問題的重視程度。

　　沒有充分理解問題的后果

　　在軟件工程中，理解問題是在系統需求定義階段早期必須完成的工作。一個沒有被充分理解的問題，將導致定義不清和不完整的需求，并最終導致不成功的項目。多年來，有關失敗的項目和相關費用的統計數字一直令人失望。僅舉其中幾個作為示例：

　　根據 Standish Group 的數據：

• 41% 的項目無法增加價值和產生足夠的投資回報 (ROI)
• 49% 的項目超出最初的成本估計
• 只有 28% 的項目在預算范圍內按時完成

　　Standish Group 還將缺乏成功的原因歸結為以下因素：

• 缺乏用戶參與
• 業務目標不明確
• 無法捕獲基本需求
• 缺乏對項目范圍的控制
• 缺乏高管的支持

　　IDC (International Data Corporation) 甚至更具體地指出了失敗的原因。他們發現，在軟件開發中超過 80% 的失敗由需求發現、管理或分析中的問題直接導致的。

　　并且根據 IAG Consulting 的數據，超過 40% 的 IT 預算將用于對較差的需求規范上。

　　這些數字證明愛因斯坦是正確的。

　　為什么不愿意投入時間

　　就軟件開發而言，投入時間去理解問題，意味著要理解業務目標，正確識別利益相關者，提出正確的問題以探討問題，并使用合適的技術來描述系統應該做什么，以及為什么要創建這個系統。雖然這看起來很明顯，軟件行業的人都明白必須要這樣做，但為什么花時間去理解問題卻很困難呢？

　　我認為困難源自以下原因：

• 急于針對所需要的某件事情找到一個快速的解決方案，這是人性的特點。一個沒有經驗的分析師會覺得沒有詳細理解需求就去解決問題是一個特別大的挑戰。通常情況下，他考慮是否使用在以前的項目中創建的組件，即使用戶不斷解釋自己的困難也是徒勞。這種對解決方案的焦慮出現在許多層面。項目經理和區域協調員都只有在他們看到像代碼行這樣實實在在的東西時才會感覺到進步。只要他們不會在忽略理解業務問題的重要性時鼓勵開始實施，這就不是一個問題。
• 系統分析師和工程師不愿意冒險進入他們通常不熟悉的知識領域，例如，業務流程和行業專業知識。談論表格、報告、函數和數據總是更容易一些的。
• IT 專業人士在大多數大專院校中并沒有接受此學科領域的相應培訓。我們在計算機科學和工程方面受到了良好的培訓。我們了解操作系統、統計、微積分、物理、編譯器和編程語言等。但沒有關注人文學科或心理學，所以我們可以學著與缺乏這些技術知識的人溝通。
• 在項目過程中，較低的用戶參與程度往往涉及到級聯開發流程（又稱為瀑布 開發）所強加的文化，該流程在巴西仍被廣泛使用，僅在項目開始定義需求的時候以及項目結束驗收系統的時候，才需要用戶參與。

　　改變文化的三種方式

　　好消息是，我們有辦法克服這些困難。要實現在軟件工程學科中實現或提高成熟度所需的文化轉變，則需要在以下三大支柱的建設方面進行投資：流程、工具和人員。

　　投資于流程

　　在流程方面，在最近幾年已經有巨大的發展。一些值得注意的示例包括，傳統的 Rational Unified Process、Agile Unified Process 或 XP (eXtreme Programming) 等敏捷流程，或 Scrum 項目管理方法。每個方法都有自己的特點，并且不同程度地強調要維護與需求相關的基本要點，如：

• 用戶和利益相關者的持續參與
• 并非在項目開始時指定所有需求，而是以迭代方式指定需求。
• 使用適當的技術來促進流程

　　在名為 Agile Modeling: Effective Practices for ExtremeProgramming and the Unified Process 的這本書中，Scott W. Ambler 解釋了建模和文檔在任何軟件項目中的重要性，包括使用敏捷方法的項目。他強調，如聯合應用程序開發 (JAD)、用例、訪談和觀察等傳統的技術，可以適應敏捷流程，而利益相關者的持續參與則是成功的關鍵。取決于不同的流程，發生變化的是，使用該技術的正式程度，以及花在該活動上的時間。

　　投資于工具

　　至于工具，一些極端的敏捷開發只捍衛紙張的使用。另一些則使用多種技術和工具。考慮到該系統將在組織中保留幾年或幾十年，并且將接受維護，我們必須利用資源使其記錄和修改更容易。除了地理分布的開發變得習以為常這個事實外，對協作開發支持工具的需求已非常緊迫。

　　在這方面，對于正式程度要求較低的項目中的敏捷開發以及往往要接受監管和審計的傳統項目來說，IBM® Rational® Requirements Composer 都是一個非常好的選擇。它構建于 IBM® Rational® Jazz™ 技術之上，這是一個協作式平臺，并且它包括支持問題理解、需求發現和需求定義階段的特性。

　　投資于人員

　　至于人員，我們首先需要選擇有適當經驗的分析師，并提供培訓和指導。有些技術和最佳實踐可以改善團隊合作。Donald Gause 和 Gerald Weinberg （見 參考資料）將 問題 定義為在 感知的 當前狀態 和 期望狀態之間的現有 差距。從這個意義上講，問題有不同的解決方式。

　　提供期望的狀態并非總是最好的解決方案。改變對當前狀態的看法，可能會改變對問題的定義。例如，Microsoft 所收到的大部分關于產品（如 Word）的改進請求，都要求增加該產品已經具備的特性。

　　更好的解決辦法應當是改變目前的看法，也許通過培訓可以實現。解釋在解決方案中所涉及的成本和其他方面，這可能會改變客戶對期望狀態的看法。有時，客戶要求的特性并不會解決他們的問題，所以他們不會使用這些特性，這是因為他們對期望狀態的感知可能是扭曲的。這方面的證據有 Standish Group 所公布的一個數字：“通常，系統中有 20-40% 的代碼行從未被使用”。

　　分析問題的其他好處

　　問題分析技術教我們要問正確的問題，將關注點轉移到探討不同的觀點，并分解問題以找出看似問題實則只是一種表現的根源。

　　最令人印象深刻的是，這些技能一般能幫助其他領域的專業人士為獲得成功做好準備。銷售能否成功與對客戶業務問題的理解能力有關。營銷人員必須了解市場需求和消費者行為。良好的溝通和問題分析能力有助于我們處理家庭關系。要理解十幾歲孩子的行為背后的原因，可能比您在了解客戶的情況時所面臨的阻力和困難更大。您需要知道如何與帶有不同觀點的人打交道，以及如何讓自己站在別人的立場，以真正了解他們的困難和需要。有些人天生就具有這種能力，而其他人必須認識到自己的局限性，并通過適當的技巧和培訓來磨練自己的技能。

　　奇妙的是，37 年前，Gerald Weinberg 出版了一本名為 The Psychology of Computer Programming 的書，該書在今天仍然適用，因為一些基本的和明顯相同的問題已經持續了幾十年。根據 Gerald Weinberg 的書，是否懂得應用一點心理學和人文科學可能是一個人的成功以及軟件開發團隊的成功的關鍵。　　

　　為什么高管的支持至關重要

　　為了讓三大支柱（流程、工具和人員）可以在組織內部和諧地合作，高管的支持非常關鍵，因為必須妥善處理 “昨天獲得” 的焦慮和壓力。數字表明，只是維持現狀對業務和 IT 都是不利的。應該考慮使用一些方法來改變軟件工程的未來，并因此改變人們對 IT 的看法，使其成為一個能夠通過技術創新增加業務價值的成本中心。

it知識庫：為了在軟件工程中獲得成功，我們必須更像心理學家而不是工程師，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。