[轉]主題：咱們應當怎樣作需求分析

又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟件業發展最快的10年。當咱們剛剛畢業的時候，還在使用VB、PB開發一些簡單的數據庫應用，而如今卻幾乎看不到它們的蹤跡，換來的是諸如J2EE和.NET這樣的大型web應用。而這期間，RUP、XP、敏捷開發、持續集成••••••一個接一個的新概念層出不窮，使人眼花繚亂。如今想來，恍如隔世。 但更令我印象深入而難以忘懷的，是我親自經歷的、親眼目擊的、道聽途說的一個又一個的軟件項目，它們有的得到了成功，但更多的是使人沮喪的失敗。套用一下大文豪托爾斯泰體：幸福的家庭都是同樣的，不幸的家庭卻各有各的不幸；幸福的軟件項目都是同樣的，不幸的軟件項目卻各有各的不幸；或者說，成功的軟件項目都是同樣的，失敗的項目卻各有各的問題。我經常在想，咱們的項目開發到底怎麼了，進而把它們一個一個的剝開來深刻分析，居然觸目驚心。它們有的是需求的問題，有的是客戶關係的問題，還有設計的問題、技術的問題、時間管理的問題、人員培養的問題••••••但歸根到底更多的仍是需求的問題。需求分析既是一份體力活兒，更是一份技術活兒，它既是人際交往的藝術，又是邏輯分析與嚴密思考的產物。正是咱們在需求分析過程存在的巨大隱患，最終致使了那麼多項目的失敗。也許你認爲我在危言聳聽，好吧，我來舉幾個典型事例分析分析吧。 個人第一個故事來自大名鼎鼎的東軟。我在2005年接一個項目的時候，據說這個項目以前是東軟作的。當時東軟在作這個項目的時候，整個過程經歷了10屢次結構性的大變動，局部性的調整更是不可勝數。聽說某天早上，客戶對某個功能不滿意，他們不得不對幾百處程序進行修改。以後客戶對修改的內容仍是不滿意，又不得不將幾百處修改從新改回來。最後這個項目致使的結果是，整個這個項目組的全部成員都離開了東軟，並彷佛今後不肯涉足軟件開發領域。多麼慘痛的教訓啊！我經常聽到網友抱怨客戶老是對需求改來改去，但客戶對需求改來改去的真正緣由是什麼呢？當咱們對客戶的需求沒有真正理解清楚時，咱們作出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，因而就在一點兒一點兒試，因而這種反覆變動就這樣發生了。若是咱們明白了這一點，深刻地去理解客戶的業務，進而想到客戶的心坎兒上去，最後作出來的東西必然是客戶滿意的。記住，當客戶提出業務變動的時候，咱們必定不能被客戶牽着走，客戶說啥就是啥。咱們要從業務角度深刻的去分析，他爲何提出變動，提得合不合理，我有沒有更合理的方案知足這個需求。當咱們提出更加合理的方案時，客戶是樂於接受的，變動也變得可控了。 第二個故事來自我本身的項目，一個早期的項目。在這個項目中，客戶扔給了咱們不少他們目前正在使用的統計報表，要咱們按照報表的格式作出來。這些報表都是手工報表，許多格式既不規範，又很難於被計算機實現。這些報表令我耗費了很多腦細胞，直到最終項目失敗都無法完成。這件事留給個人深入教訓是，不能客戶怎麼說軟件就怎麼作。客戶提出的原始需求每每是不考慮技術實現，基於非計算機管理的操做模式提出來的。他們提出的不少需求經常比較理想而不切實際，畢竟人家是非技術的。但咱們做爲技術人員，需求分析必須實事求是的、基於技術能夠實現的角度去考慮。那種「有條件要上，沒有條件創造條件也要上」的魯莽行事，結果必然是悲慘的。因此咱們必需要基於技術實現去引導客戶的需求。同時，計算機信息化管理就是一次改革，對以往手工管理模式的改革。若是咱們上了信息化管理系統，採用的管理模式卻依然是過去的手工模式，新系統的優點從何而來呢？所以，咱們作需求就應當首先理解現有的管理模式，而後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操做與管理。 2007年，我參與了一個集團信息化建設的項目。這個項目中的客戶是一個龐大的羣體，他們分別扮演着各類角色。從機構層次劃分，有集團領導、二級機構人員、三級機構人員；從職能角色劃分，有高層領導、財務人員、生產管理員、採購人員、銷售人員，等等。在這樣一個複雜場景中，不一樣人員對這個項目的需求是各自不一樣的。很是遺憾的是，咱們在進行需求分析的時候沒有認真分析清楚全部類型人員的需求。在進行需求調研的時候，老是集團領導帶領咱們到基層單位，而後基層單位將各方面的人員叫來開大會。這樣的大會，各種型的人員七嘴八舌各說各自的需求，還有不少基層人員在大會上由於羞澀根本就沒有提出本身的需求。這樣通過數次開會，需求調研就草草收場。咱們拿着一個不充分的需求分析結果就開始項目開發，最終的結果可想而知。直到項目上線之後，咱們才發現許多更加細節的業務需求都沒能分析到，系統根本無法運行，不得不宣告失敗。一個軟件項目的需求調研首先必需要進行角色分析，而後對不一樣的角色分別進行調研。需求調研的最初須要召開項目動員大會，這是十分必要的。但真正要完成需求分析，應該是一個一個的小會，1~3個業務專家，只討論某個領域的業務需求，而且不少問題都不是能一蹴而就完成的，咱們必須與專家創建聯繫，反覆溝通後完成。需求分析必須聽從的是必定的科學方法，而不是盲目的大上快上。 個人最後一個故事可能典型到幾乎每一個人都曾經遇到過。咱們的項目從需求分析到設計、開發、測試都十分順利。但到了項目進行的後期，快到達最後期限時，咱們將咱們的開發成果提交給客戶看，客戶卻對開發成果不滿意，提出了一大堆修改，並且這些修改工做量還不小。怎麼辦呢？加班、趕工，測試時間被最大限度壓縮。最後項目卻是如期上線了，但你們疲憊不堪，而且上線之後才發現許多的BUG。需求分析不是一蹴而就的，它應當貫穿整個開發週期，不斷的分析確認的過程。以上這個事例，若是咱們提前將開發成果給客戶看，提前解決問題，後面的狀況就將再也不發生。這就是敏捷開發倡導的需求反饋。敏捷開發認爲，需求分析階段不可能解決全部的需求問題，所以在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時得到反饋。只有這樣才能及時糾正需求理解的誤差，保證項目的成功。 以上的故事各有各自的不幸，各自都在不一樣的開發環節出現了問題。但通過深刻的分析，各自的問題最終都歸結爲需求分析出現了問題。爲了使咱們從此的軟件項目不會重蹈覆轍，彷佛真的有必要討論一下咱們應該怎樣作需求分析。