當前企業在進行數字化轉型時，一支專業的技術團隊是標配，特別是規模企業會同時擁有IT運維及軟件開發兩支隊伍，尤其是軟件開發團隊是數字化建設的主力軍，肩負著企業個性化場景的軟件開發重任，但在實際的管理工作中，會存在以下痛點：? 1.正常開發節奏經常被打亂；? 2.人員配備低，導致大量開發任務排隊；? 3.需求總是被業務反復推翻；? 4.開發的軟件應用率低；

以上問題直接導致的后果就是：?

第一，雖然開發團隊加班加點，但仍趕不上業務需求變化的速度，搞的開發團隊疲于奔命；?

第二，軟件需求反復推翻，軟件架構反復設計，搞的開發身心疲憊無成就感；??

第三，需求大量排隊，給業務部門造成的印象就是開發部門效率太低；?

第四，開發的系統不應用，讓開發部門價值難以體現，價值存在感低；?

以上這些都是企業數字化轉型過程中的一個典型場景，很多企業以為自己成立了軟件開發團隊，就可以解決任何數字化系統的難題，但豈不知數字化轉型是一個系統工程，涉及技術更涉及業務、運營，如果數字化部門不能很好的把控業務需求、合理推進工作任務，缺乏管理意識，數字化運營意識，那么就會陷入“打亂仗”的死循環中。

今天老楊就來講一講開發團隊如何避免打亂仗。? ? 我們知道企業內部開發一款數字化系統需要經過如下環節：項目立項、方案確定、系統開發、系統測試、上線運行五大環節，而每一環節都有若干需要完成的工作，這些細小環節工作構成一個系統化的標準工作流程，如果這些細小環節未實現精細化管理，那么可能引起連鎖反應，導致整個項目處于混亂狀態，這就是打亂仗的開端。那么開發團隊如何實現過程管理精細化呢？

1、項目立項階段： 立項是項目的開端，決定是否做與不做。但在此環節上技術部門容易被業務部門的“偽需求”所迷惑，此時的需求可能是某一個部門人員或某位領導的一廂情愿的想法，缺乏部門驗證，如此時開發部門不加驗證，就匆匆接下該需求，那么極有可能有推翻重來的可能，所以此時開發部門應嚴格遵循三不原則： 分管領導不知情不做； 業務需求不明不做； 沒有業務骨干參與不做； 在與業務部門確定好系統需求后，開發部門應出具業務需求文檔、系統功能清單、系統工時評估表并與業務部門達成共識，此時不要忘記還需要業務部門分管領導簽字確認。這就是一個標準的立項過程，開發部門一定要注意，不要以為自己是企業內部的部門就將以上工作忽略，否則日后一旦與業務部門產生分歧，將無證可依，成為名副其實的“背鍋俠”，同時軟件開發工時評估表也是開發部門價值的體現，要讓業務部門知曉一款業務系統上線需要投入多少人力成本，讓業務部門在第一時間珍惜數字化建設成果。

項目立項階段標準文檔內容： 《業務部門原始訴求溝通記錄》；?? ?《需求文檔》；? ? 《工時評估表》；? ? 《系統功能清單明細表》? ? 《項目立項審批表》

2、解決方案確定階段： 此環節包括以下工作節點：軟件原型設計、需求文檔編寫、技術文檔編寫、UI設計；只有業務部門需求方案確定了，開發部門才能進行這一步的工作，切忌在業務部門需求反復期間就輕易做解決方案，此時開發部門要沉的住心，寧愿與業務部在需求方面多花時間溝通，也不能在開發期間反復。? ? 為什么開發部門會打亂仗？解決方案確定階段就是開端，企業的開發部門往往以人手不足為由不做相關文檔編寫工作，如業務需求文檔，內部工作均有口頭傳達為主，這樣造成的后果就是對內用戶需求交接不清，造成后期開發工作反復，對外與業務部門需求溝通存在理解偏差風險，當后期用戶對功能開發提出質疑時、內部開發人員工作反復時，各種扯皮隨即而來，混亂開始了。? ? 所以開發部門一定要按標準化管理推進工作，不能以工期緊、業務部門催的急為借口打亂仗，在解決方案確定階段需要提交的文檔有： 《系統原型設計》? 《業務需求文檔》? 《后端接口文檔》? 《數據庫文檔》? 《平臺架構設計文檔》? 《UI設計》其中《系統原型設計》、《UI設計》一定要業務部門負責人簽字確認。

3、系統開發階段： 此階段很好理解，就是軟件開發工程師按照產品經理提供的系統原型設計及UI設計師提供的UI設計進行軟件開發工作，但此時對項目經理的把控能力要求很高，在系統開發階段，尤其是企業內部，業務部門會產生這樣的假象：以為開發部門是企業自己的，不會產生費用，就對需求反復修改，甚至朝定夕改，讓開發部門疲于應付，所以前期的需求確定在此時顯得格外重要，但業務部門在軟件開發期間修改需求也是時有發生的，如何把控需求，項目經理此時非常關鍵，一方面要滿足業務部門的需求，讓系統在上線后能應用起來，另一方面要控制業務部門的需求無限發散，讓系統上線遙遙無期，因此項目經理的溝通、規劃能力十分重要。? ? 同時對團隊內部項目經理要合理分配工作、安排進度，有條不紊的推進工作，按期交付產品，所以在此階段需要產生的管理文檔有： 《任務進度計劃表》? 《任務分工表》? 《需求修改確認表》? ? 系統開發階段，如控制不好，同樣會打亂仗，現實中，開發部門會同時進行多個項目的推進，如不進行科學的管理，會陷入對外需求變更管理混亂、對內工作安排推進混亂。

4、測試階段： 測試關乎軟件質量，但在企業開發團隊中會存在測試人員缺編、人手不足的現狀，導致一部分開發人員也擔負測試的工作，但此時標準的測試工作流程一樣不能少，上線前的測試報告一樣不能少，此時需要提交的標準文檔很簡單，就是《系統測試報告》。

5、上線階段： 軟件通過測試后，開發工作告一段落，接下來就是重要的時刻，用戶體驗上線階段，此時開發部門也馬虎不得，不能以為是企業內部人員，直接將系統網址提交給客戶就行，隨便培訓一下就草草交付，相對于技術，業務部門是非專業的，需要手把手的功能培訓，看系統功能是否匹配用戶需求，并做好用戶新需求記錄，此時需交付的文檔有： 《用戶操作手冊》? 《培訓文檔》? 《培訓記錄表》? ? 此時開發部門還要關注用戶應用情況，對用戶的相關問題進行跟蹤、反饋，唯有如此數字化建設工作才能有條不紊順利的開展。? ? 綜上所述，在企業內部一個業務需求從提出要系統實現要經歷：立項、方案確定、系統開發、系統測試、系統上線五大關鍵步驟，每一個步驟要實現標準化的管理，才能保障過程管理不混亂、不打亂仗。

要記住：任務多、工期緊、人手少均不是打亂仗的借口，不甩鍋、勇擔當才能打硬仗，嚴格執行標準化、制度化、流程化才能打勝仗！