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

　　沒有充分理解問題的后果

　　在軟件工程中，理解問題是在系統(tǒng)需求定義階段早期必須完成的工作。一個(gè)沒有被充分理解的問題，將導(dǎo)致定義不清和不完整的需求，并最終導(dǎo)致不成功的項(xiàng)目。多年來，有關(guān)失敗的項(xiàng)目和相關(guān)費(fèi)用的統(tǒng)計(jì)數(shù)字一直令人失望。僅舉其中幾個(gè)作為示例：

　　根據(jù) Standish Group 的數(shù)據(jù)：

• 41% 的項(xiàng)目無法增加價(jià)值和產(chǎn)生足夠的投資回報(bào) (ROI)
• 49% 的項(xiàng)目超出最初的成本估計(jì)
• 只有 28% 的項(xiàng)目在預(yù)算范圍內(nèi)按時(shí)完成

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

• 缺乏用戶參與
• 業(yè)務(wù)目標(biāo)不明確
• 無法捕獲基本需求
• 缺乏對項(xiàng)目范圍的控制
• 缺乏高管的支持

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

　　并且根據(jù) IAG Consulting 的數(shù)據(jù)，超過 40% 的 IT 預(yù)算將用于對較差的需求規(guī)范上。

　　這些數(shù)字證明愛因斯坦是正確的。

　　為什么不愿意投入時(shí)間

　　就軟件開發(fā)而言，投入時(shí)間去理解問題，意味著要理解業(yè)務(wù)目標(biāo)，正確識別利益相關(guān)者，提出正確的問題以探討問題，并使用合適的技術(shù)來描述系統(tǒng)應(yīng)該做什么，以及為什么要?jiǎng)?chuàng)建這個(gè)系統(tǒng)。雖然這看起來很明顯，軟件行業(yè)的人都明白必須要這樣做，但為什么花時(shí)間去理解問題卻很困難呢？

　　我認(rèn)為困難源自以下原因：

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

　　改變文化的三種方式

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

　　投資于流程

　　在流程方面，在最近幾年已經(jīng)有巨大的發(fā)展。一些值得注意的示例包括，傳統(tǒng)的 Rational Unified Process、Agile Unified Process 或 XP (eXtreme Programming) 等敏捷流程，或 Scrum 項(xiàng)目管理方法。每個(gè)方法都有自己的特點(diǎn)，并且不同程度地強(qiáng)調(diào)要維護(hù)與需求相關(guān)的基本要點(diǎn)，如：

• 用戶和利益相關(guān)者的持續(xù)參與
• 并非在項(xiàng)目開始時(shí)指定所有需求，而是以迭代方式指定需求。
• 使用適當(dāng)?shù)募夹g(shù)來促進(jìn)流程

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

　　投資于工具

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

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

　　投資于人員

　　至于人員，我們首先需要選擇有適當(dāng)經(jīng)驗(yàn)的分析師，并提供培訓(xùn)和指導(dǎo)。有些技術(shù)和最佳實(shí)踐可以改善團(tuán)隊(duì)合作。Donald Gause 和 Gerald Weinberg （見 參考資料）將 問題 定義為在 感知的 當(dāng)前狀態(tài) 和 期望狀態(tài)之間的現(xiàn)有 差距。從這個(gè)意義上講，問題有不同的解決方式。

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

　　更好的解決辦法應(yīng)當(dāng)是改變目前的看法，也許通過培訓(xùn)可以實(shí)現(xiàn)。解釋在解決方案中所涉及的成本和其他方面，這可能會改變客戶對期望狀態(tài)的看法。有時(shí)，客戶要求的特性并不會解決他們的問題，所以他們不會使用這些特性，這是因?yàn)樗麄儗ζ谕麪顟B(tài)的感知可能是扭曲的。這方面的證據(jù)有 Standish Group 所公布的一個(gè)數(shù)字：“通常，系統(tǒng)中有 20-40% 的代碼行從未被使用”。

　　分析問題的其他好處

　　問題分析技術(shù)教我們要問正確的問題，將關(guān)注點(diǎn)轉(zhuǎn)移到探討不同的觀點(diǎn)，并分解問題以找出看似問題實(shí)則只是一種表現(xiàn)的根源。

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

　　奇妙的是，37 年前，Gerald Weinberg 出版了一本名為 The Psychology of Computer Programming 的書，該書在今天仍然適用，因?yàn)橐恍┗镜暮兔黠@相同的問題已經(jīng)持續(xù)了幾十年。根據(jù) Gerald Weinberg 的書，是否懂得應(yīng)用一點(diǎn)心理學(xué)和人文科學(xué)可能是一個(gè)人的成功以及軟件開發(fā)團(tuán)隊(duì)的成功的關(guān)鍵。　　

　　為什么高管的支持至關(guān)重要

　　為了讓三大支柱（流程、工具和人員）可以在組織內(nèi)部和諧地合作，高管的支持非常關(guān)鍵，因?yàn)楸仨毻咨铺幚?“昨天獲得” 的焦慮和壓力。數(shù)字表明，只是維持現(xiàn)狀對業(yè)務(wù)和 IT 都是不利的。應(yīng)該考慮使用一些方法來改變軟件工程的未來，并因此改變?nèi)藗儗?IT 的看法，使其成為一個(gè)能夠通過技術(shù)創(chuàng)新增加業(yè)務(wù)價(jià)值的成本中心。

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

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。