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