在軟件開發(fā)中的一大挑戰(zhàn)是客戶需求的變更，以下一些熟悉的場景每天都在發(fā)生：
客戶：你看這個頁面能不能調(diào)整成藍(lán)色，綠色不好看。（藍(lán)色多好，大氣?。?/p>
乙方：我們統(tǒng)一顏色都是基于綠色的，這塊調(diào)整成藍(lán)色不好吧。（無力吐槽。。。）
客戶：那你先調(diào)整成藍(lán)色我看看。（我還是覺得藍(lán)色好看）
乙方：好的，馬上給你調(diào)。（看我隨便瞎調(diào)給你看看就知道了）
客戶：算了，還是用綠色吧，但是綠色能不能深一點，我們主色調(diào)有用這個顏色。（綠色勉強也能接受）
乙方：那統(tǒng)一基色都調(diào)整成這樣好了。（無力反駁）
客戶：可以。（看，好多了吧，還是我有眼光！）
客戶：小王啊，這個按鈕是啥？不要了，那個菜單我也不要了。（太干擾了，看著不順眼）
乙方：好的。（還好去掉功能簡單！要是增加啥的那就。。。）
客戶：還有這里能否增加一個查看詳情的，要能打印和導(dǎo)出PDF。（領(lǐng)導(dǎo)肯定喜歡）
乙方：要不導(dǎo)出PDF后再打印，這樣打印更好看。（還是逃不脫，能簡單就簡單吧）
客戶：這樣太麻煩了，還是在線打印吧。（這不是一樣的？為啥還要下載再打??？）
乙方：好的。（咳，還是多了兩個功能?。?/p>
客戶：我們有個數(shù)據(jù)中臺，這些數(shù)據(jù)都得回傳到我們的數(shù)據(jù)中心。（早上一早突然才想到了）
乙方：我們系統(tǒng)上都有統(tǒng)計匯總，非常全面。（又要對接，一聽就頭大）
客戶：不行，公司有規(guī)定的，必須要進(jìn)數(shù)據(jù)中心。（我也沒辦法，過不了的）
乙方：那你們直接從我們這里取數(shù)據(jù)，我們有詳細(xì)的接口文檔。（我們經(jīng)驗豐富）
客戶：我們不主動對接的，需要你們主動傳遞到我們中臺，我發(fā)給你文檔。（你們做不是更方便嘛?。?/p>
乙方：好的。（這文檔都發(fā)來了。。。）
客戶：這里我要增加這些字段，我們業(yè)務(wù)上有需要。
乙方：好的。（意料之中）
客戶：對了，我們有些領(lǐng)導(dǎo)是分管領(lǐng)導(dǎo)。但是主要在A事業(yè)部，B事業(yè)部是雙領(lǐng)導(dǎo)管理。
乙方：?。磕阍炔皇钦f都是單線領(lǐng)導(dǎo)的？（這時候突然這樣，要死人的）
客戶：剛接到的通知，因為并購了新公司，業(yè)務(wù)變更了，改成事業(yè)部了，需要雙線領(lǐng)導(dǎo)。（不就是單線變雙線領(lǐng)導(dǎo)嘛）。
乙方：那整個結(jié)構(gòu)要大調(diào)整的，原來的權(quán)限，流程都是按照單線走的。（這時候絕對不能大變動，否則就慘了）
客戶：不調(diào)整我們就沒法用了，這個事業(yè)部是我們的核心業(yè)務(wù)，不用的話，項目就實施不了。你想想辦法。（這個我也沒辦法，計劃沒有變化快。）
乙方：我們先內(nèi)部溝通下。（能想什么辦法？只能把風(fēng)險盡量降低到最?。?/p>
客戶：好的，感謝。（希望盡快調(diào)整，項目不能再拖了）
我們姑且不去討論需求變更怎么管控，怎么管理，又是怎么合理的拒絕。需求的不斷變更是項目成功與否的一大攔路虎，假設(shè)需求變更通過的情況下，如何解決好才是問題的關(guān)鍵。
其實從以上的對話中，我們可以總結(jié)出需求變更的共性，并對這些需求變更進(jìn)行分類。
為了更好的標(biāo)明需求變更的性質(zhì)，對此進(jìn)行以下四個維度的劃分：
1. 難度系數(shù)，即為了實現(xiàn)本需求變更，在實現(xiàn)上需要多大的時間和人力成本。
2. 風(fēng)險系數(shù)，為了實現(xiàn)需求變更，可能對系統(tǒng)造成的風(fēng)險，比如性能，安全，穩(wěn)定。
3. 重要程度，變更對客戶來說非常重要，否則無法使用，有些可能可有可無。
4. 緊急程度，需求變更非常的緊急，需要優(yōu)先處理。
由此可以對需求變更進(jìn)行分類管理，以平臺化的思想應(yīng)對，并基于平臺制定統(tǒng)一的處理方案：
1. UI樣式調(diào)整，很多客戶都有自己的用色規(guī)則和個人喜好，這個是非常常見的需求。因為系統(tǒng)的使用人多，領(lǐng)導(dǎo)也多，意見不一致很正常，所以朝令夕改的情況也時有發(fā)生。
難度系數(shù)?
風(fēng)險程度?
緊急程度?
重要程度?
針對此類需求變更，平臺需要支持主題切換，直接平臺中在線所見即所得的方式去調(diào)整，調(diào)整的范圍需要分客戶級（平臺為多租戶模式），模塊級（多模塊），用戶級，頁面級，盡量簡單高效。這種方式可以大大減少開發(fā)和發(fā)布流程，節(jié)省時間，提高穩(wěn)定性。
2. 功能性的調(diào)整，增減功能，有些變更可能看起來很小，但技術(shù)風(fēng)險很大。
難度系數(shù)??
風(fēng)險程度??
緊急程度???
重要程度???
已有功能的去留無非是通過權(quán)限控制，系統(tǒng)配置，元數(shù)據(jù)方式來實現(xiàn)?？紤]到相關(guān)的功能會越來越多，平臺應(yīng)以數(shù)據(jù)的方式來實現(xiàn)對功能的描述（元數(shù)據(jù)），處理數(shù)據(jù)就是處理功能的相關(guān)特性及去留，增加的功能（或模塊）也要以元數(shù)據(jù)的方式存在，以應(yīng)對將來可能的需求變更。
3. 權(quán)限的調(diào)整，按組織架構(gòu)，按上下級，按團(tuán)隊，按角色等調(diào)整各種權(quán)限。
難度系數(shù)????
風(fēng)險系數(shù)????
緊急程度????
重要程度?????
以企業(yè)為例，組織架構(gòu)方式都大同小異，基于RBAC的增強模式可以解決絕大部分問題，采用此的統(tǒng)一架構(gòu)體系去應(yīng)對各種需求變更。平臺需支持多根樹的組織架構(gòu)（含虛擬部門），多對多的上下級關(guān)系，多級角色，團(tuán)隊四個維度去控制各個資源的權(quán)限。各種需求通過這四個維度組合去實現(xiàn)，核心思想以不變以萬變。
4. 接口對接，包括數(shù)據(jù)輸入，輸出，集成等。
難度系數(shù)???
風(fēng)險系數(shù)???
緊急程度???
重要程度????
接口對接分兩種：
一，對方接入本平臺，需要平臺有完善的接口和規(guī)范，有詳細(xì)的文檔。后續(xù)只需配合調(diào)試即可。
二，接入對方系統(tǒng)，標(biāo)準(zhǔn)的接口采用統(tǒng)一的對接子系統(tǒng)，通過平臺配置方式來對接，平臺要有完善的對接數(shù)據(jù)監(jiān)控和錯誤處理機制。非標(biāo)準(zhǔn)接口采用擴(kuò)展開發(fā)方式注入平臺。
5. 結(jié)構(gòu)性調(diào)整，加字段，加表，變流程，變關(guān)系（一對一，一對多，多對多，樹形結(jié)構(gòu)，圖）。
難度系數(shù)?????
風(fēng)險系數(shù)?????
緊急程度?????
重要程度?????
結(jié)構(gòu)性調(diào)整是最為復(fù)雜的需求變更，搞不好項目直接就崩了。針對這種變更，低代碼平臺或零代碼平臺的思想就可以有效應(yīng)對。通過平臺進(jìn)行操作（可能需要專業(yè)人士），外加擴(kuò)展開發(fā)，可以大大的提高效率和系統(tǒng)的穩(wěn)定性，降低風(fēng)險。但是這樣的平臺還不夠，還需要能夠進(jìn)行變更的比對和版本管理，回滾機制，結(jié)構(gòu)復(fù)用，調(diào)整風(fēng)險智能提示，預(yù)發(fā)布等，真正實現(xiàn)統(tǒng)一的平臺方式來應(yīng)對各種需求變更。
需求是無窮無盡，如果避免疲于應(yīng)付，需要有前瞻性，提前做好預(yù)案，以不變?nèi)f變。由此可見并非客戶的需求變更都是洪水猛獸，做好準(zhǔn)備，隨時歡迎客戶提出的寶貴意見并悉心采納。
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。
