在我們公司，獲取了一個需求以后，
首先，相關人員會先在DevSpec建立一個條目，添加相應的一些屬性信息，比如標題，內(nèi)容描述，狀態(tài)，對應文檔，優(yōu)先級，緊急程度，負責人，對應版本，對應瀏覽器，對應數(shù)據(jù)庫等等。。。
提交完了條目以后，由于這個條目設置了一個負責人，所以那個負責人登錄系統(tǒng)就可以馬上看到自己名下有這個條目，他就會馬上去處理這個需求。（可能有些人沒登錄系統(tǒng)去看，我們也可以設置Email或者手機短信的自動提醒功能）
這里提到的“負責人”，在不同的過程里，負責人都是不同的，比如“評審”階段就有專門的評審負責人，普通人無法成為評審負責人，哪些人在哪些過程里能成為負責人是可以在流程中設置的。而上面提到的提交完條目后，一般情況第一個過程就是要審核剛獲取的需求，負責人審核通過后就可以把這個需求從“審核”狀態(tài)改到“需求分析”階段了，當然負責人也會改變，“需求分析”過程的負責人就會馬上知道自己有事情干了。
就這樣，經(jīng)過一個一個的過程，經(jīng)手了一個一個的負責人，這個需求就逐漸從一個只有一個思想，到有了輪廓，再設計出里面的框架，然后最后被實現(xiàn)。
其實，大家都是這么來處理需求的，不同的是，我們通過一個工具來管理這個過程，而有些公司只是就人工來做一下。我們這么做，好處和壞處其實都有，正如之前有個客戶問，你們這么做的話，是不是每一個需求的處理效率會降低？對，的確會降低，我們承認，因為這些都是嚴格的流程，而且是在一個系統(tǒng)中管理，肯定沒有他們口頭直接說一下快。但是，我們考慮的是我們是在賣產(chǎn)品，犧牲一部分的效率來確保產(chǎn)品的質(zhì)量，我們覺得劃得來，畢竟質(zhì)量才是最重要。人家雖然速度快，但是問題也來得多，需求多的時候，這個忘做了，那個做錯了，或者相互責任推來推去的事情多著了，最終導致產(chǎn)品質(zhì)量出問題的事情比比皆是。但是我們用了系統(tǒng)以后，就避免了這些事情，實踐也證明了我們這么做以后，產(chǎn)品質(zhì)量是得到保證了的。
當然，產(chǎn)品的質(zhì)量也不是簡簡單單像我說上面說的“經(jīng)過一個一個的過程，經(jīng)手了一個一個的負責人”就能馬上實現(xiàn)了，這里還會涉及到很多細節(jié)注意點了，待我一一道來。
我之前說過需求管理有幾個嚴格的要求，流程化和審核機制大家其實已經(jīng)看到了，其實在某種程度上，審核是流程化的一部分，因為審核過程本身就是需求處理過程中一個過程而已，我們只要在流程中設置了這種過程，安排負責人去負責就行了，當需求進入這個過程，就自然有人會去審核了。
如果把上面兩個要求看成是需求管理的基礎的話，那其他幾個嚴格的要求：歡迎變更、版本控制、可跟蹤性，就可以看成是確保產(chǎn)品質(zhì)量成功的關鍵點了。有了基礎才有可能成功，有了關鍵點才能保證成功！
歡迎變更：
歡迎變更的重要性大家應該知道了，變更其實也就是需求經(jīng)常變，從某種程度上也就意味著產(chǎn)品的質(zhì)量下降，因為這個需求你不斷變化，今天剛寫好這段代碼，明天要改成那樣，后天又要大改，誰都知道有潛在風險，而且還有與之有關聯(lián)的功能呢？你突然改了個接口參數(shù)，人家可能還不知道了。靠測試？測試人員也沒法很好解決這個問題，因為今天剛測完這個功能，明天卻大改了，但是那個測試人員雖然看到這個功能需要測試，但是他卻可能認為昨天已經(jīng)測好了，是不是忘記關閉了，所以就去測其他功能了。
那怎么解決呢？也很簡單，當有變更的時候，
首先，盡量讓相關的人知道，讓開發(fā)知道，讓測試知道，讓需要我們接口的人知道，這樣子大家就都會同步就完成自己要做的事情，不會出現(xiàn)需要做的人卻不知道他要去做這個事的情況。在DevSpec中，我們可以采用變更自動通知功能來實現(xiàn)，因為在DevSpec中一個需求總是和它的開發(fā)任務和測試任務關聯(lián)在一起的，所以當需求有了變更以后，只要發(fā)送一個通知，開發(fā)人員和測試人員就能馬上看到變更，就能及時去做他們的工作了。
第二點就是，盡量把影響的范圍搞得清楚點，讓開發(fā)知道哪些地方可能會影響到，做的時候小心點；讓測試知道這個改動會造成哪些地方有潛在的Bug，需要重點測一下。在DevSpec中，我們會有專門的功能讓設計人員和開發(fā)人員注明影響到的地方，需要重點測的地方，而且這個功能可以設置成強制，只要有變更，設計人員和開發(fā)人員就必須注明，甚至可以要求測試人員也注明測了哪些點，可以讓設計與開發(fā)人員檢查是否有遺漏。
第三點就是，針對任何變更（特別對于瀑布模式那種公司），因為關系到了可能會影響質(zhì)量、進度及成本，風險很大，所以對于變更的內(nèi)容需要專門的評審流程，評審通過后才能開始開發(fā)。在DevSpec中，我們針對這種情況，就會經(jīng)常啟用變更管理視圖，在這個視圖中，會有特別的流程對變更做評審，在次期間，這個需求是沒辦法被任何人轉到開發(fā)環(huán)節(jié)的，也避免了有些人不清楚情況，直接就把沒審核的需求直接讓開發(fā)去做了。（當然，我們現(xiàn)在很多產(chǎn)品已經(jīng)是用敏捷開發(fā)的模式了，所以這個功能就用得比較少了）
這樣子做的話，我們還是能把質(zhì)量掌握在自己的手中，也就是把公司的前途掌握在自己手中。
（未完待續(xù)）