昨天我們為 IT 團隊再造導入了敏捷框架，然而敏捷框架依舊要有有效的工作內容安排，
所以針對團隊既有的工作內容也必須重新調整，以下就是團隊進行重組工作的過程~

Situation

原本的團隊編制和各自工作執掌內容是這樣的：

• 1 web dev: 對外網站桌機版 (php) 與已經無法進行任何維護的受助者網站 (java)
• 1 web dev: 對外網站手機版(asp.net), 內部系統 (asp.net)
• 1 dev: 內部客服系統資料排程處理、列印功能處理
• 1 report: 負責產出各式報表
• 1 operator: 負責與金流網站 (php) 外包商溝通，程式更新。
• 1 operator: 負責手動操作及處理 CRM 例行作業
• 3 MIS: 管理內部所有硬體、網路、軟體、權限、處理辦公室資訊使用等議題

可以看到團隊的工作執掌配合前幾篇我們所談論既有團隊的狀況就可知道，
由單一人員進行服務的開發與維護的結果造成現有的服務難以維運與開發。
開發人員日常也會被其他部門專人找尋，通常是因為某些開發人員很好配合，以至於所有需求都會找比較好找的開發人員，也打斷該人員應該進行的開發作業。
而維運人員日常工作則是隨 call 隨到，常常就像小弟一樣一通電話就要去對方的座位處理事情
其中包含簡單電腦開關機、電源問題等等

Task

對齊我們對團隊的期許，希望 IT 團隊是專業、有效率的，每個人員所負責的工作就必須要能有效的模組化，收攏。同時間我們也需要解決外包系統已經無人維護的風險，對應的系統必須要要對應的負責人員。

• 所有 IT 人員都是某個領域的專家: 網站、CRM、內部系統、報表…etc
• 整合開發人力：將開發人力分為網頁開發 (前端和後端) 和 CRM 開發
• 整合維運人力: 調整 MIS 分 SRE、Helpdesk，負責處理維運、合規、資安等角色。

Action

• 開發人力要能整合，技術棧就必須先整合。如之前提到，原本對外網站有 4 個網域、3 種語言，因此優先收攏網站的技術棧。當技術棧陸續整合時，開發人力就可以逐步收攏、釋出。

• 針對國外外包商開發已經超過維護期限的 CRM ，陸續將重要功能盤點抽離轉往 MS D365 平台。針對沒有開發經驗的新平台，先引進外包廠商進行 pilot 開發，上線後之後再與開發廠商簽訂顧問約，協助將技術移轉給 IT 成員並提供諮詢。

• 原有 MIS 人員主要負責的大多為系統、軟體問題排除等工作，適切調整工作內容，轉為 Help Desk (原 MIS 事務型工作項目），同時將其他成員轉型為合規、預算管理、供應商管理、資安、以及流程自動化等角色。

• 產品開發上線後要能夠穩定提供服務，SRE 的角色功不可沒，舉凡監控、告警、備份等等維持服務運作穩定等事項都需要安排人力進行。

Result

工作執掌重組不可避免也連帶會有人員重組的狀況，即使轉型有時間壓力，所有成員仍然都會先給予時間和機會嘗試新的角色和執掌。最後根據對團隊的規劃，人員執掌結構如下：

• 1 architect: 負責網站架構以及規劃 CRM 與 Web 串接等流程及技術選型
• 2 frontend: 前端統一使用 nodejs + vue
• 2 backend: 除了負責網站後端及 API ，同時也使用 php 處理 CRM 系統需要的排程。進行內部系統的開發及產出報表等。
• 2 Dynamics 365 developer: 主要使用 .NET 開發，也使用 Dynamics 365 進行 low code 開發。
• 2 infra: 合規, 政策, 網路, 防火牆等管理設定。備份, 供應鏈管理, FInOps, 預算執行追蹤等。
• 1 SRE: 內部工作流自動化 (IAM 管理、排程管理)，設定開發 pipeline，監控告警等串接。
• 2 help desk: 第一線處理內部人員回報問題，軟硬體相關需求處理等。

這裡看到維運比比較高的原因，也是因為現有組織在轉型中有很多面向要處理：

• 既有的地端服務要開始走向混合雲、最終要走向全上雲的系統流程於環境建置
• DevOps 流程建置 (release pipeline)(release)
• SRE 建立監控機制(monitoring)
• 資訊安全議題
• MIS 走向自動化辦公室
• 稽核、合規議題