企業內部搞軟體研發的九九八十一難

都說數字化轉型難，那麼究竟難在哪裡?有人說技術難?有人說投入難?有人說轉意識難?有人也說買軟體，用第三方軟體也很難，功能不匹配，搞二次開發要錢，售後也要錢，不如自己成立技術團隊量身訂製搞軟體開發，那麼自己動手數字化建設就會豐衣足食嗎?錯!並不是掌握了技術數字化轉型難題就會迎刃而解，數字化的難題在於意識、在於管理、更在於全員對數字化是否達成共識，技術與業務融合一起來解決問題。

今天老楊將內部開發軟體的相關難題總結如下：

一、立項難

在當前數字化環境下，雖說企業內部對數字化系統的應用有了全新的認識，都清楚軟體系統的應用的好處，但當決定是否做某一個資訊系統時，就難以下決定了，一方面軟體系統的透明性讓某些員工、領導有所顧忌，用軟體意味著透明、灰度沒有了，同時又擔心資料安全;如果不用系統工作效率難以提高，因為傳統的文件、表格用起來實在麻煩;特別又是在企業“降本增效”模式下，大家都秉承多一事不如少一事的心態，擔心搞數字化建設工作出了錯，引起不必要的麻煩，因此除非 非常有必要，否則業務部門不會做數字化專案立項。

立項階段的工作難點還體現在過程溝通上、價格談判上、流程審批上。

1.1. 需要和各級領導、企業負責人溝通，內容如下：

• 解釋為什麼做這套系統?

• 當前的工作痛點是什麼?

• 軟體系統能解決什麼?

• 準備如何做?

• 現在做了什麼?

• 選型過程是怎樣的?

• 為什麼選了**軟體?

• 我們準備如何實施?

• 業務部門如何配合?

• 會遇到什麼問題?如何解決?

• 預計工期多長?

• 什麼時候軟體上線?

• 上線時會有什麼問題?如何解決?

• 上線後預計會達到什麼效果?

1.2.在價格談判上的難點包括：

• 誰主導談判?

• 誰參與談判?

• 談判策略如何?

• 軟體價格計算依據是什麼?

• 後期運維價格如何計算?

• 後期介面提供如何收費?

• 二次開發如何收費?

• 專案人員構成及核算規則是什麼?

• 誰最終在談判中確定系統價格?

• 誰最終同意專案費用?

• 價格雙方如有異議怎麼辦?

• 乙方價格不下調怎麼辦?

1.3.在審批上的難點包括：

• 誰負責向各級領導彙報最終專案建設方案?

• 誰發起審批流程?

• 哪些人參與該專案審批?

• 誰負責起草合同?

• 誰參與審批合同?

• 合同條款有異議怎麼辦?

• 專案急著開工，審批未完成怎麼辦?

從以上各個環節的問題不難看出，軟體系統建設立項工作需精細化運作，需事前充分溝通、確認，與相關領導達成共識後方可進行下一步的工作，未批先建，是數字化建設風險也是大忌。

二、需求收集難

需求收集是數字化建設的重要環節，尤其是涉及企業訂製開發專案。今天老楊主要聊的就是企業內部技術團隊訂製開發業務系統的那些難點那些事。

在老楊經歷的眾多軟體開發專案中，大部分業務部門在專案初期對於需求是模糊的，只會說如下內容：

• 我就要一套ERP系統;

• 軟體我不懂，你們看著搞吧!

• 你們按這個頁面去開發就是了!

• 你們不是專業的嗎?怎麼還問我?我不知道

• 這個功能我不清楚，你問其他部門

造成軟體系統需求收集難、需求不明的原因有如下：

2.1.業務部門對系統的理解停留於技術階段，以為軟體開發知道一切功能需求;

2.2.業務部門只關心自己所使用的功能如何實現，對於功能背後的資料邏輯實現缺乏深度理解;

2.3.或許業務部門連自己想要什麼都不清楚，但什麼都想要;

2.4.業務部門缺乏企業協同力，缺乏系統化思維;

需求不明、需求收集難，對於訂製開發團隊來說是非常致命的陷阱，業務部門對於需求有可能朝令夕改，讓技術開發部門陷入不斷修改、不斷推翻的死迴圈，因此在需求收集階段，產品經理的溝通能力非常重要，一方面要從與業務部門溝通的隻言片語中尋找價值線索，拼湊出一個初步的產品框架，同時又要引導業務部門，防止業務部門的思維不斷髮散，讓產品架構變的非常龐大，功能做的非常臃腫，導致開發週期遙遙無期。

三、開發過程難

需求確定了、立項報告透過了，那麼接下來就是技術部門火力全開搞軟體開發的階段，這個階段也可以說是無比艱辛，要經歷如下磨難：

3.1.業務需求變動頻繁，軟體架構難以成型：

這就是前期業務部門需求不明種下的惡果，因此老楊的建議是寧願在需求調研階段多花時間，也不要在開發階段改來改去，技術部門最忌被業務部門牽著鼻子走，最後時間成本投入了，專案毫無進展;

3.2.時間進度把控難，成本控制難：

造成時間進度難以把控的原因有內外兩部分原因：

內：是指技術部門本身，專案經理缺乏專案管理能力，開發過程缺乏計劃性，有計劃也難以按期保障推進，專案過程把控力弱，同時由於某些技術細節內部存在異議，大量時間花在內部技術協調上，導致專案延期，時間成本上升;

外：是指業務部門，在軟體開發過程中不斷提出新的需求，導致業務功能越來越多，系統越來越臃腫，影響前期既定的開發目標及計劃，造成專案延期;在大部分情況下，業務部門以為開發團隊是自己公司的，不是第三方，不需要成本，這是大錯特錯，技術團隊的正常運營同樣需求管理成本。

所以在軟體開發過程中，時間即成本、需求反覆即成本，業務部門、技術部門均需要有成本意識。

此外，系統開發過程中，專案進行過程中相關人員的異動也是導致時間進度難以把控的主要原因：

3.2.1.技術部門軟體開發人員離職，導致專案開發無法正常進行;

3.2.2.業務部門對接人或業務骨幹離職，導致業務需求及開發成果無法確認;

3.2.3.業務部門領導變動，管理思路改變，導致整個系統架構推倒重來;

3.3.軟體系統質量把控難

由於在開發過程中的時間進度問題、人員問題、技術問題導致軟體進度滯後，在這種情況下軟體的質量也難以把控，由於缺乏專業測試導致相關的軟體效能及功能性測試缺乏，使系統存在巨大的安全隱患。

3.4.精細化過程管理難：

在企業軟體開發過程中除了技術難點，還有管理難點，這個難點就是要求的精細化過程管理與實際管理存在差異的矛盾，例如缺乏開發過程需求文件、需求說明書、測試用例、測試報告、上線審批流程等等標準化過程管理，這就是管理理想很豐滿，但現實是技術人員都在追求開發進度，忽視過程管理很骨幹的管理現狀。

3.5.人員管理難：

體現在專案開發過程中計劃制定、業務及技術交底、人員任務分配、人員權責分配、資料命名規則等開發管理環節，所以對專案經理的能力要求極高，一方面專案經理需要排兵佈陣，把控專案進度，另一方面專案經理需要有成本意識，提高開發效率，如專案有外包部分，還涉及對外包團隊的管理，儘量降低窩工的風險;所以一個優秀的專案經理必須具備較強的專案管理能力，對人員管理、開發進度、開發風險、軟體質量有綜合把控的能力，而非純有技術能力。

四、應用難

軟體開發完成後，專案團隊面臨的另一個問題即是應用難題，這個時候往往忽略的是以為軟體是訂製開發的，完全安裝業務部門需求量身打造的，無需花大量時間精力去推廣，結果導致被業務吐槽軟體不好用、軟體沒有達到預期的管控效果、質疑開發團隊的能力，為什麼會出現該問題，老楊分析如下：

4.1.由於業務需求的高度不確定性、不穩定性、易變性導致實際應用與預期效果存在偏差，這個時候如果溝通不及時、不到位，很容易成為業務部門的吐槽點;

4.2.業務部門人員多，而對接的業務骨幹只有一個，個人的應用習慣並不代表整個部門，所以系統在上線初期，業務人員對系統有一個適應期，這就對軟體的易用性設計提出了很高的要求;

4.3.系統上線後相關配套的管理制度並未出臺，導致系統在應用時資料的規則標準、及時性、完整性、準確性難以保障，導致資料分析應用難，數字化管理失去管理價值;這是系統運營管理的問題，也是應用難的最大問題;

4.4.系統上線後同樣面臨的還有售後的問題，雖說開發團隊是公司自己的，但團隊同樣肩負著眾多的軟體開發專案，這就導致，後期一旦涉及系統調整及修改，面臨響應慢的問題;

綜上所述，企業數字化轉型，不管是購買第三方系統還是自行訂製開發系統，都會面臨各種問題，如技術問題、業務問題、管理問題等，所以在數字化建設上要做到如下幾點：

• 前期立項合法化

• 成本預算透明化

• 需求明確化

• 過程管理標準化

• 開發進度效率化

• 產品質量穩定化

• 應用制度化

• 管理資料化

• 資料標準化

• 後期調整及時化