如何有效實現軟體的需求管理 – 7

【本篇為《如何有效實現軟體的需求管理》第七篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇，第八篇）】

 

 

在我們公司，擷取了一個需求以後，

首先，相關人員會先在DevSpec建立一個條目，添加相應的一些屬性資訊，比如標題，內容描述，狀態，對應文檔，優先順序，緊急程度，負責人，對應版本，對應瀏覽器，對應資料庫等等。。。

 

 

 

提交完了條目以後，由於這個條目設定了一個負責人，所以那個負責人登入系統就可以馬上看到自己名下有這個條目，他就會馬上去處理這個需求。（可能有些人沒登入系統去看，我們也可以設定Email或者手機簡訊的自動提醒功能）

 

這裡提到的“負責人”，在不同的過程裡，負責人都是不同的，比如“評審”階段就有專門的評審負責人，普通人無法成為評審負責人，哪些人在哪些過程裡能成為負責人是可以在流程中設定的。而上面提到的提交完條目後，一般情況第一個過程就是要審核剛擷取的需求，負責人審核通過後就可以把這個需求從“審核”狀態改到“需求分析”階段了，當然負責人也會改變，“需求分析”過程的負責人就會馬上知道自己有事情幹了。

 

就這樣，經過一個一個的過程，經手了一個一個的負責人，這個需求就逐漸從一個只有一個思想，到有了輪廓，再設計出裡面的架構，然後最後被實現。

 

其實，大家都是這麼來處理需求的，不同的是，我們通過一個工具來管理這個過程，而有些公司只是就人工來做一下。我們這麼做，好處和壞處其實都有，正如之前有個客戶問，你們這麼做的話，是不是每一個需求的處理效率會降低？對，的確會降低，我們承認，因為這些都是嚴格的流程，而且是在一個系統中管理，肯定沒有他們口頭直接說一下快。但是，我們考慮的是我們是在賣產品，犧牲一部分的效率來確保產品的品質，我們覺得划得來，畢竟品質才是最重要。人家雖然速度快，但是問題也來得多，需求多的時候，這個忘做了，那個做錯了，或者相互責任推來推去的事情多著了，最終導致產品品質出問題的事情比比皆是。但是我們用了系統以後，就避免了這些事情，實踐也證明了我們這麼做以後，產品品質是得到保證了的。

 

當然，產品的品質也不是簡簡單單像我說上面說的“經過一個一個的過程，經手了一個一個的負責人”就能馬上實現了，這裡還會涉及到很多細節注意點了，待我一一道來。

 

我之前說過需求管理有幾個嚴格的要求，流程化和審核機制大家其實已經看到了，其實在某種程度上，審核是流程化的一部分，因為審核過程本身就是需求處理過程中一個過程而已，我們只要在流程中設定了這種過程，安排負責人去負責就行了，當需求進入這個過程，就自然有人會去審核了。

 

如果把上面兩個要求看成是需求管理的基礎的話，那其他幾個嚴格的要求：歡迎變更、版本控制、可跟蹤性，就可以看成是確保產品品質成功的關鍵點了。有了基礎才有可能成功，有了關鍵點才能保證成功！

 

歡迎變更：

 

歡迎變更的重要性大家應該知道了，變更其實也就是需求經常變，從某種程度上也就意味著產品的品質下降，因為這個需求你不斷變化，今天剛寫好這段代碼，明天要改成那樣，後天又要大改，誰都知道有潛在風險，而且還有與之有關聯的功能呢？你突然改了個介面參數，人家可能還不知道了。靠測試？測試人員也沒法很好解決這個問題，因為今天剛測完這個功能，明天卻大改了，但是那個測試人員雖然看到這個功能需要測試，但是他卻可能認為昨天已經測好了，是不是忘記關閉了，所以就去測其他功能了。

 

那怎麼解決呢？也很簡單，當有變更的時候，

 

首先，盡量讓相關的人知道，讓開發知道，讓測試知道，讓需要我們介面的人知道，這樣子大家就都會同步就完成自己要做的事情，不會出現需要做的人卻不知道他要去做這個事的情況。在DevSpec中，我們可以採用變更自動通知功能來實現，因為在DevSpec中一個需求總是和它的開發工作單位和測試工作關聯在一起的，所以當需求有了變更以後，只要發送一個通知，開發人員和測試人員就能馬上看到變更，就能及時去做他們的工作了。

 

第二點就是，盡量把影響的範圍搞得清楚點，讓開發知道哪些地方可能會影響到，做的時候小心點；讓測試知道這個改動會造成哪些地方有潛在的Bug，需要重點測一下。在DevSpec中，我們會有專門的功能讓設計人員和開發人員註明影響到的地方，需要重點測的地方，而且這個功能可以設定成強制，只要有變更，設計人員和開發人員就必須註明，甚至可以要求測試人員也註明測了哪些點，可以讓設計與開發人員檢查是否有遺漏。

 

第三點就是，針對任何變更（特別對於瀑布模式那種公司），因為關係到了可能會影響品質、進度及成本，風險很大，所以對於變更的內容需要專門的評審流程，評審通過後才能開始開發。在DevSpec中，我們針對這種情況，就會經常啟用變更管理視圖，在這個視圖中，會有特別的流程對變更做評審，在次期間，這個需求是沒辦法被任何人轉到開發環節的，也避免了有些人不清楚情況，直接就把沒審核的需求直接讓開發去做了。（當然，我們現在很多產品已經是用敏捷開發的模式了，所以這個功能就用得比較少了）

 

 

這樣子做的話，我們還是能把品質掌握在自己的手中，也就是把公司的前途掌握在自己手中。

 

 

 

（未完待續）