分享一點早年需求管理和變更控制的經驗

此文於2010-04-29被推薦到CSDN首頁如何被推薦？

在學校里學計算機語言時以為，編程和架構是整個軟體生命周期里最了不起的部分，但實際工作後才發現在商業產品里需求管理（包括新需求的發掘）更是一個商業軟體成功與否的關鍵。在以下我和大家分享一點在90年代我經歷的一些需求管理小故事，希望能對剛進入軟體行業的精英們有點概念性的幫助。請理解在這麼小的篇幅里，我們更多地只是概念性地理解需求管理的重要性而已，絕非是要提供完善的解決辦法。

軟體工程里的許多問題，諸如缺陷及資源運用不當，都是源於需求的不確定。在90年代，我曾在美國一個擁有數千員工的公司里從事大型軟體開發工作。該軟體主要是賣給汽車修復廠用的，它可估算出修復汽車的零件及勞力兩項費用，甚至還可以找到提供新零件及舊零件的廠家。軟體的的複雜度相當地高，要界定什麼樣的界面和功能是最適合市場的著實不易。所以，需求一變再變。在聊天時有個同事戲稱：「需求變更乃萬惡之源！」其他的人紛紛響應。當時，所有的需求都是寫在Word文檔里的，那些文檔不是放在一個共享的伺服器里，就是交由負責編寫程序的人員管理。雖然沒用什麼管理平台及工具，但在團隊成員的配合和默契下，一切事情都有序地在進展著。

但有一天產品經理換了個新的，一切事情似乎就全改變了。新的產品經理原是某汽車修復廠的經理，他對修汽車及車廠管理有不少的經驗，但對軟體的開發是很不懂的。很快地下列問題出現了：

（一）需求描述不清楚，導致開發任務的時間估算誤差可到100%，甚至200%；

（二）優先及全由產品經理決定，有時不太重要的任務先做了，重要的反倒後做；

（三）需求變更一再發生，並且當某需求變更了，它的連鎖反應會衝擊其他的部分，許多缺陷因此產生了。

我們幾個資深人員分析整個過程，發現造成問題的原因是這樣的：

（一）我們的現有需求文檔管理太亂，通常是找不到所要的版本。就算是找到要的文檔，常常也沒法找到要的那段內容。

（二）可判斷任務優先順序的因素頗多，可以是在商業層面或技術層面，每人的視角不同，公說公有理，婆說婆有理。

（三）需求文檔、代碼、測試用例及其他的工件（artifacts）之間應是相關聯的，但在系統中我們無法從其中任一個工件找到其他的工件。

由於文檔不全，這位新的產品經理很難在短時間內對整個系統有個概括性的了解。當他和資深人員溝通產品設計理念及歷史緣由時，資深人員也沒能明確地回答他的問題，這導致需求設計不完善，優先順序也有誤。找到原因後，我們想既然需求變更這一頭兇猛野獸是殺不死的，那我們所能做的大概也就是將這獸關在籠子里，使它溫馴點。 為解決這問題，我們建立了以下的體制。

（一）細化需求的時間估算 – 我們將需求分解到程序員能清楚估算出完成時間的小單位，原則上每單位是可以讓一個程序員及一個測試人員在二至十天內做完，而且每個單位都有個編號。

（二）使用版本控制系統管理需求文檔 – 所有需求文檔全保存在一中樞版本控制系統里。

（三）將需求分組並設優先順序 – 所有的需求單位按照不同的版本區分開來，每個需求單位都有個優先順序。

（四）建立工件之間的關聯性 – 將程序及測試用例與相對應的需求單位連接上，明確地寫上需求編號。

（五）建立評審團隊 – 當需求產生或變更時，產品經理及干係人要一起評審，通過後才做更改。

我們開了好些培訓會，務必保證每個程序員、測試人員及產品經理都遵照制度走。在會議室的白板上畫出很多間隔，貼了滿滿的紙條。當然，我們也使用了Excel及一些小工具幫助我們管理需求。當年我們雖不知敏捷方法為何物，但卻採用了好些敏捷操作，如站立會議等。

花了三個月把這個體制建立好後，團隊氣象一新。整個軟體生產的過程嚴謹了許多，需求成為軟體生命周期的核心。在任何階段，需求及相對應的代碼都有人負責。對需求的嚴格審核使得後期的修改及對缺陷的修復減少了許多，效率提高起來。

整體來說，當時我們所作的改進是有成效的。但我們也發現，對這體制的維護相當不易的。舉例來說，需求變更的評審是需要有個流程的。但不同類型的需求要由不同組的人評審，甚至有些是外部修車廠的人員。更糟糕的是，評審流程也隨需求種類的不同而不同。我們將流程寫在文檔里，但流程圖及相關的人員經常在變動。我們不僅需要有專人來維護，有調整時還要開會通知，費力且常發生錯誤。

另外，在大系統里需求變更所產生的連鎖反應是相當可怕的。曾經有一次，我們根據需求的變更找到了出現問題的某些代碼，非常高興地把代碼改了，以為問題得到了解決。但不久，客戶反饋我們在另兩個地方發生錯誤。（實際上恐怕還不止兩處呢！）我們把這兩處改了後，又發現這些修改造成了更多其他多個問題。在代碼的層面這可以是因軟體代碼的耦合。但它不僅是在代碼的層面，更可能是在商業邏輯的層面。比如說，某公司在同一領域發展了三個互補性的軟體產品。這三個產品可能共享一套工具模塊（utility）。當工具模塊里的某個程序被改了，我們需要查驗它是否對其他的兩個產品造成衝擊了。這是在代碼層面的，還相對容易些。在商業邏輯層面的就更難了。這三個軟體產品在設計時必然是建立在一套完整商業邏輯上的。改了其一，必要檢視是否也要對其他兩個做對等的修改。要解決這問題，要依靠知識系統的全備及人員的經驗。我們當時在需求、測試案例及相關工件之間建立的關聯性也僅僅是在項目層面，而非組織（公司）層面。（呵呵！所以，路還遙遠的很。）

兩年之後，因為項目將要完成，人員減少了60%。我是外聘人員（contractor），也在最後一批中離開了。我發現，雖然我們花了不少力氣在需求管理上，雖取得一點成效，但收穫頗為有限。主要的原因是人員變動太多、流程不斷在修改以及太多的機械性工作。現在市面上已有許多相當不錯的需求管理工具及ALM （Application LifecycleManagement）研發管理平台，它們可以幫忙作需求整理、需求量化、版本控制及需求變更控制，ALM研發管理平台里相關的工件可以彼此連接，甚至一個需求單元在整個軟體的生命周期的歷史都可以完全追蹤。這解放了大量的人力成本，跟當年比起來事情應該是要容易得多了。