軟件需求變更的分級管理和應(yīng)對辦法（軟件需求變更的分級管理和應(yīng)對辦法是什么）

在軟件開發(fā)中的一大挑戰(zhàn)是客戶需求的變更，以下一些熟悉的場景每天都在發(fā)生：

客戶：你看這個(gè)頁面能不能調(diào)整成藍(lán)色，綠色不好看。（藍(lán)色多好，大氣！）

乙方：我們統(tǒng)一顏色都是基于綠色的，這塊調(diào)整成藍(lán)色不好吧。（無力吐槽。。。）

客戶：那你先調(diào)整成藍(lán)色我看看。（我還是覺得藍(lán)色好看）

乙方：好的，馬上給你調(diào)。（看我隨便瞎調(diào)給你看看就知道了）

客戶：算了，還是用綠色吧，但是綠色能不能深一點(diǎn)，我們主色調(diào)有用這個(gè)顏色。（綠色勉強(qiáng)也能接受）

乙方：那統(tǒng)一基色都調(diào)整成這樣好了。（無力反駁）

客戶：可以。（看，好多了吧，還是我有眼光！）

客戶：小王啊，這個(gè)按鈕是啥？不要了，那個(gè)菜單我也不要了。（太干擾了，看著不順眼）

乙方：好的。（還好去掉功能簡單！要是增加啥的那就。。。）

客戶：還有這里能否增加一個(gè)查看詳情的，要能打印和導(dǎo)出PDF。（領(lǐng)導(dǎo)肯定喜歡）

乙方：要不導(dǎo)出PDF后再打印，這樣打印更好看。（還是逃不脫，能簡單就簡單吧）

客戶：這樣太麻煩了，還是在線打印吧。（這不是一樣的？為啥還要下載再打印？）

乙方：好的。（咳，還是多了兩個(gè)功能！）

客戶：我們有個(gè)數(shù)據(jù)中臺，這些數(shù)據(jù)都得回傳到我們的數(shù)據(jù)中心。（早上一早突然才想到了）

乙方：我們系統(tǒng)上都有統(tǒng)計(jì)匯總，非常全面。（又要對接，一聽就頭大）

客戶：不行，公司有規(guī)定的，必須要進(jìn)數(shù)據(jù)中心。（我也沒辦法，過不了的）

乙方：那你們直接從我們這里取數(shù)據(jù)，我們有詳細(xì)的接口文檔。（我們經(jīng)驗(yàn)豐富）

客戶：我們不主動(dòng)對接的，需要你們主動(dòng)傳遞到我們中臺，我發(fā)給你文檔。（你們做不是更方便嘛！）

乙方：好的。（這文檔都發(fā)來了。。。）

客戶：這里我要增加這些字段，我們業(yè)務(wù)上有需要。

乙方：好的。（意料之中）

客戶：對了，我們有些領(lǐng)導(dǎo)是分管領(lǐng)導(dǎo)。但是主要在A事業(yè)部，B事業(yè)部是雙領(lǐng)導(dǎo)管理。

乙方：啊？你原先不是說都是單線領(lǐng)導(dǎo)的？（這時(shí)候突然這樣，要死人的）

客戶：剛接到的通知，因?yàn)椴①徚诵鹿荆瑯I(yè)務(wù)變更了，改成事業(yè)部了，需要雙線領(lǐng)導(dǎo)。（不就是單線變雙線領(lǐng)導(dǎo)嘛）。

乙方：那整個(gè)結(jié)構(gòu)要大調(diào)整的，原來的權(quán)限，流程都是按照單線走的。（這時(shí)候絕對不能大變動(dòng)，否則就慘了）

客戶：不調(diào)整我們就沒法用了，這個(gè)事業(yè)部是我們的核心業(yè)務(wù)，不用的話，項(xiàng)目就實(shí)施不了。你想想辦法。（這個(gè)我也沒辦法，計(jì)劃沒有變化快。）

乙方：我們先內(nèi)部溝通下。（能想什么辦法？只能把風(fēng)險(xiǎn)盡量降低到最小）

客戶：好的，感謝。（希望盡快調(diào)整，項(xiàng)目不能再拖了）

我們姑且不去討論需求變更怎么管控，怎么管理，又是怎么合理的拒絕。需求的不斷變更是項(xiàng)目成功與否的一大攔路虎，假設(shè)需求變更通過的情況下，如何解決好才是問題的關(guān)鍵。

其實(shí)從以上的對話中，我們可以總結(jié)出需求變更的共性，并對這些需求變更進(jìn)行分類。

為了更好的標(biāo)明需求變更的性質(zhì)，對此進(jìn)行以下四個(gè)維度的劃分：

1. 難度系數(shù)，即為了實(shí)現(xiàn)本需求變更，在實(shí)現(xiàn)上需要多大的時(shí)間和人力成本。

2. 風(fēng)險(xiǎn)系數(shù)，為了實(shí)現(xiàn)需求變更，可能對系統(tǒng)造成的風(fēng)險(xiǎn)，比如性能，安全，穩(wěn)定。

3. 重要程度，變更對客戶來說非常重要，否則無法使用，有些可能可有可無。

4. 緊急程度，需求變更非常的緊急，需要優(yōu)先處理。

由此可以對需求變更進(jìn)行分類管理，以平臺化的思想應(yīng)對，并基于平臺制定統(tǒng)一的處理方案：

1. UI樣式調(diào)整，很多客戶都有自己的用色規(guī)則和個(gè)人喜好，這個(gè)是非常常見的需求。因?yàn)橄到y(tǒng)的使用人多，領(lǐng)導(dǎo)也多，意見不一致很正常，所以朝令夕改的情況也時(shí)有發(fā)生。

難度系數(shù)?

風(fēng)險(xiǎn)程度?

緊急程度?

重要程度?

針對此類需求變更，平臺需要支持主題切換，直接平臺中在線所見即所得的方式去調(diào)整，調(diào)整的范圍需要分客戶級（平臺為多租戶模式），模塊級（多模塊），用戶級，頁面級，盡量簡單高效。這種方式可以大大減少開發(fā)和發(fā)布流程，節(jié)省時(shí)間，提高穩(wěn)定性。

2. 功能性的調(diào)整，增減功能，有些變更可能看起來很小，但技術(shù)風(fēng)險(xiǎn)很大。

難度系數(shù)??

風(fēng)險(xiǎn)程度??

緊急程度???

重要程度???

已有功能的去留無非是通過權(quán)限控制，系統(tǒng)配置，元數(shù)據(jù)方式來實(shí)現(xiàn)。考慮到相關(guān)的功能會越來越多，平臺應(yīng)以數(shù)據(jù)的方式來實(shí)現(xiàn)對功能的描述（元數(shù)據(jù)），處理數(shù)據(jù)就是處理功能的相關(guān)特性及去留，增加的功能（或模塊）也要以元數(shù)據(jù)的方式存在，以應(yīng)對將來可能的需求變更。

3. 權(quán)限的調(diào)整，按組織架構(gòu)，按上下級，按團(tuán)隊(duì)，按角色等調(diào)整各種權(quán)限。

難度系數(shù)????

風(fēng)險(xiǎn)系數(shù)????

緊急程度????

重要程度?????

以企業(yè)為例，組織架構(gòu)方式都大同小異，基于RBAC的增強(qiáng)模式可以解決絕大部分問題，采用此的統(tǒng)一架構(gòu)體系去應(yīng)對各種需求變更。平臺需支持多根樹的組織架構(gòu)（含虛擬部門），多對多的上下級關(guān)系，多級角色，團(tuán)隊(duì)四個(gè)維度去控制各個(gè)資源的權(quán)限。各種需求通過這四個(gè)維度組合去實(shí)現(xiàn)，核心思想以不變以萬變。

4. 接口對接，包括數(shù)據(jù)輸入，輸出，集成等。

難度系數(shù)???

風(fēng)險(xiǎn)系數(shù)???

緊急程度???

重要程度????

接口對接分兩種：

一，對方接入本平臺，需要平臺有完善的接口和規(guī)范，有詳細(xì)的文檔。后續(xù)只需配合調(diào)試即可。

二，接入對方系統(tǒng)，標(biāo)準(zhǔn)的接口采用統(tǒng)一的對接子系統(tǒng)，通過平臺配置方式來對接，平臺要有完善的對接數(shù)據(jù)監(jiān)控和錯(cuò)誤處理機(jī)制。非標(biāo)準(zhǔn)接口采用擴(kuò)展開發(fā)方式注入平臺。

5. 結(jié)構(gòu)性調(diào)整，加字段，加表，變流程，變關(guān)系（一對一，一對多，多對多，樹形結(jié)構(gòu)，圖）。

難度系數(shù)?????

風(fēng)險(xiǎn)系數(shù)?????

緊急程度?????

重要程度?????

結(jié)構(gòu)性調(diào)整是最為復(fù)雜的需求變更，搞不好項(xiàng)目直接就崩了。針對這種變更，低代碼平臺或零代碼平臺的思想就可以有效應(yīng)對。通過平臺進(jìn)行操作（可能需要專業(yè)人士），外加擴(kuò)展開發(fā)，可以大大的提高效率和系統(tǒng)的穩(wěn)定性，降低風(fēng)險(xiǎn)。但是這樣的平臺還不夠，還需要能夠進(jìn)行變更的比對和版本管理，回滾機(jī)制，結(jié)構(gòu)復(fù)用，調(diào)整風(fēng)險(xiǎn)智能提示，預(yù)發(fā)布等，真正實(shí)現(xiàn)統(tǒng)一的平臺方式來應(yīng)對各種需求變更。

需求是無窮無盡，如果避免疲于應(yīng)付，需要有前瞻性，提前做好預(yù)案，以不變?nèi)f變。由此可見并非客戶的需求變更都是洪水猛獸，做好準(zhǔn)備，隨時(shí)歡迎客戶提出的寶貴意見并悉心采納。