1. 項目延期怎麼處理
1.項目預估時間偏差。
這其實是最重點的問題，百分之六十以上的項目延期就是因為預估時間出現問題。基本上在需求確認過程中會開一個評審會，講解需求並評審每個功能預期的時間。但是這個評審往往只預估了理想狀態下的開發時間，忽略了一些技術難點，調試，聯調，測試等特別是涉及到後台業務數據這塊的一些功能設計所需要的時間。b端產品涉及到的數據流轉非常復雜，有時候還需要與其他項目進行對接或者調通介面。
針對這種問題比較好的解決方法是項目初始階段在日程上記錄幾個比較重要的時間節點以及具體到每月每人的任務線，當然也是在對工作量有較為准確的前提下去完成這個工作。任務線確定了之後一但遇到首個任務延期的情況就要及時找出問題並且判斷後面一些任務中可能遇到類似的事情。第二個是要確定項目結束時，每個人需要提交的東西。比如prd，設計稿，交互原型，版本代碼，測試報告等然後根據這個輸出過程去做一個項目分解，搞清楚每部分之間的關聯性和項目之間的關系，使各部分人員對現有系統邏輯有比較清楚的認識。
2.需求對現有業務流造成改動。
b端產品中，業務流在主線確定之後往往只會做上層的拓展和延伸。由於主觀的邏輯優化或者政策、實際業務改變等客觀因素的影響就需要對現有主線進行不同程度的調整。
如果一次性進行大規模的修改，開發對需求的把控，客服對新邏輯的理解以及客戶的接受程度都會面臨考驗。所以面對比較大的調整，可以採用對需求進行分期規劃，逐層推進以達到預期效果的方式去進行。好的需求分期規劃能讓所有人看清產品發展的路徑，甚至在第一期功能完成時就感知到預期目標只是順勢發展的結果。
3.需求變更或新增需求。
很多時候在開發過程中難免會遇到對現有需求進行更變或者突然插入一些緊急程度較高需求。可能修改點的工作量並不是非常大，但是積少成多之後也會對項目進程有一定的影響。曾經有一次在開發中為了頁面內容更清晰地展現把一個頁面由標簽欄改成了菜單欄，因為涉及到頁面內聯框架的調整所以給開發增加了兩天的工作量，事後我才意識到問題的嚴重性，因為這樣的優化導致項目延期十分得不償失。
4.開發/測試人員對需求的理解有偏差
這種情況往往是因為溝通不到位導致的。溝通在任何團隊任何項目中都是大問題，在b端項目中尤為明顯。前面提到b端產品的系統邏輯可能異常復雜，特別是一些小的分支邏輯產生不同的結果以及數據操作之後的流向，這些都會造成理解與記憶上的偏差。所以在與開發溝通的過程中不單是口頭確認，最好的方式還是有書面的憑證。一段時間內也對系統新舊邏輯進行梳理，整理數據流向，許可權管理和邏輯功能的表單。只有團隊所有人員對系統的認知一致時，才能保證工作高效地完成。
法律依據：
《中華人民共和國標准化法》第二條本法所稱標准（含標准樣品），是指農業、工業、服務業以及社會事業等領域需要統一的技術要求。
標准包括國家標准、行業標准、地方標准和團體標准、企業標准。國家標准分為強制性標准、推薦性標准，行業標准、地方標準是推薦性標准。
強制性標准必須執行。國家鼓勵採用推薦性標准。