如何制定一份縝密的網站建設計劃可能并不是網站建設中最難的事情，要應對計劃之外的情況，才是最令大家頭痛的地方。在網站建設實際推進過程中，不加控制的需求改進往往給網站建設帶來沉重的負擔和無法預料的風險。因此，設計一套合適的需求改進管理流程和規范，對網站建設而言都是不可或缺的。
一開始網站建設上并沒有對需求改進的流程規范做清晰的定義，因此網站建設實際推進過程中會出現諸多由改進引發的問題，下面為你們詳細說明：
一：改進多：一開始，網站建設最大的問題是需求改進很多，如果只是猛的一頭扎進流程中去，反而浪費時間，所以我們嘗試去分析這些改進的原因，看看是否能在源頭堵住改進。經過判斷，發現相當一部分改進是因為需求設計不夠健壯或者交互對需求的理解不到位，在后續的階段發現，進而才開始修改或新增需求。
三：問題帶來風險：網站建設過多關注于討論改進本身以及改進的意義，往往忽略了實施改進往往會沖擊原有計劃，缺乏完整的風險分析；在改進執行的時候，沒有相對固定的套路和章法，執行過程很松散，缺乏一些有效的監控，過程風險演變不得而知。
二：改進不規范：改進是在所難免的問題，大家坐下來聊一聊，如果感覺不錯那就把這個改進做了吧，這是我們之前的做法。但，由于缺乏一個明確的基本流程規范，一到改進的時候，處理事情往往丟三落四，進而會出現以下問題：改進需求提出人太多，不知道聽誰的改進提出的太晚，留給網站建設的時間不多了改進到底做不做，什么時候做等信息，在各個角色間的信息不同步。
定義需求改進包含兩個層面，一是在產品設計階段：需求評審結束，PRD文檔定稿后再對需求稿進行更改，定義為需求改進；二是研發排期結束，定稿開發測試上線計劃，之后凡是計劃外的變化都定義為需求改進。
解決方案
我們在給出解法的同時還需注意到，網站建設管理所依賴的流程和規范若太強則使網站建設運轉繁瑣低效；但過弱則又使網站建設松弛散漫。因此，設計對應辦法的時候需要充分考慮各種方案，選取最簡單的方式來實現規范管理。
針對‘一’，可以優化原有的主干流程
網站建設上根據實踐經驗發現僅靠需求評審無法完全保證需求方清楚的澄清所有需求，以及交互方充分的理解需求方的要求，其本質原因在于PRD并不能完整的描述清楚整個場景，許多需求層面的細節和串聯即便在需求評審結束后依然可能覆蓋不全；只有隨著交互設計師把需求完善成結構嚴謹的邏輯圖和場景說明，往往才會發現一開始需求設計不到位的情況，在大版本的情況下，等到整個交互稿都拿出來了再去做改進，改進代價過大/感受也不好。
針對‘二’可以改進如何執行
改進流程的規范涵蓋兩個主要方面，一是明確改進管理的基本理念；二是明確一旦要做改進，需要依序執行的步驟。改進管理的核心在于評估需求改進的價值，然后決定做不做以及是否在當前版本做，我們嘗試從更多角度去思考，包括說產品的規劃，需求的特點。
首先分析產品階段特點：我們處在產品轉型這樣一個新舊交叉時期（簡單說就是一方面要維護原有功能，另一方面更需探索設計新的功能），因此這個時期的需求改進可以劃分成四個維度：原有核心功能，原有周邊功能，新功能核心功能，新功能周邊功能；改進也按上述維度進行分類，再考慮版本上線時間和質量，按照順序去考慮需求。
同時，十分不建議因為緊急需求改進去延遲既定的上線時間，對于網站建設而言，上線時間是一個很嚴肅的事情，不能輕易的去改變，是大家共同守護的目標。因此，我們定義需求改進凍結時點，原則上在凍結點后不接受任何改進。關于需求凍結點如何設置，不同的網站建設需要根據實際情況做分析。
針對‘三’可以改進如何審批
對于較為復雜的設計，在交互評審之前會拆分一個環節出來，做一個交互主場景的評審。通過新增的環節，確保需求的健全和完善，減少流入后續階段的需求改進數量。
這個做法適用于策劃改進PRD頻繁，以及功能過于復雜伴隨較大的潛在改進風險兩個場景。PRD頻繁改進頻繁并不完全因為功能邏輯設計有漏洞，還有可能是產品規劃/商業分析論證等前置流程沒做好，這種背景下光是增加一個主場景的評審是沒用的，讀者需要仔細分析。
其實改進如何執行，并沒有一個一成不變的套路，但結構上其實還是大同小異，筆者給出網站建設上的參考只是一部分經驗總結。想了解更多經驗請到深圳網站建設一度互聯網站留言區留言。
