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