賴 san(
くん ) 說他有一個五人團隊, 工作內容則是開發維護零零總總的五套軟體系統, 原本的規劃應有十個人, 但因為景氣不好公司裁員外加人員外流, 目前人事也凍結, 但開發工作已排好未來的半年計畫, 而且還有一堆已知的需求尚未排入, 更恐怖的還有已等待超過一年的需求等著排. 外加三不五時必須應付上頭安插的非預期工作或是一定要先安插的工作.
聽賴 くん 講到這只有哇的一聲, 心想 : 嗯, 工作確實吃重.
賴 くん 繼續說著, 這些系統都不是小系統, 還有部份的系統是與產線有關或控制的系統, 平時電話就不少. 又有資料分析系統, 使用者對資料有疑問, 必須發不少與上游系統溝通及追蹤.
聽賴 くん 講到這忍不住說 : 你那不是五人團隊, 是無敵鐵金鋼團隊.
賴 くん 問到, 其實我是要問像我這種狀況要怎樣處理?
我回答 : 是不是找新工作會比較好一點, 而且簡單.
賴 san( くん ) 這個問題真的很棘手, 光想想像就很恐怖了, 真的遇到了, 日子應該蠻慘的. 但想想現在的景氣, 應該也有人有相同的情況與問題, 替賴 san( くん ) 分析一下也不錯. 賴 san( くん ) 目前所遇到的問題應該有 :
1. 工作量多, 人員不足. 時程安排策略.
2. 系統眾多, 人員配置策略.
3. 系統眾多, 互相支援策略.
4. 既是產線系統, 值班及備援策略.
5. 編制十人的團隊管理策略.
6. 上游系統溝通及追蹤策略.
看看賴 san( くん ) 的型態, 有一些大方向是一定要抓住的.
1. 十人團隊, 團隊的運作要有一定的流程,準則或方向.
2. 所有系統一定要有負責人, 掌管所有大小事.
3. 既然是產線系統, 系統人力備援一定要有, 值班相關準則規範.
上述三大方向的實行細則, 及注意事項 :
1. 十人團隊, 團隊的運作要有一定的流程,準則或方向.
要管理一個十人團隊, 況且系統這麼多, 真的不容易, 所以 :
1.1 團隊的運作流程一定要流暢, 做事方向大家都要清楚, 例如 : 一個新的需求下來, 一定要先瞭解需求, 確認需求無誤之後才可以開工, 至於需求怎要叫做無誤呢? 當需求範圍大時, 就必須要制定需求文件, 請需求者確認畫押, 當需求範圍小時, 有一定的進度就要和需求者再做一次的確認. 如果以時間來看, 最好一個星期一定要和需求者開一次會, 有實際的進度看成果(例如操作畫面), 沒有實際的進度就看文件, 這樣的作法不僅可以和需求者建立緊密的關係, 對於內部也可以有推升的效果.
1.2 該注意的方向一定要明確, 不要變來變去. 一個產線的系統, 品質一定很重要, 所以開發過程中, 要怎樣作法品質的把關, 就必須明確定義, 例如一定要有人最後的品質認證, 或是軟體的單元測試(Unit Test).
所以有時候也可以把流程與項目合併, 例如開發的流程中有一個步驟是品質管控, 而管控的方式就用單元測試實作.
1.3 仔細且頻繁的確認一切事項. 軟體開發看是簡單, 卻時常錯誤百出. 最好每天都要確認一切的事項都是在軌道上正常的運作.
2. 所有系統一定要有負責人, 掌管所有大小事.
2.1 挑選系統負責人. 開發行為和維護行為有著不一樣的注意構面, 也有不一樣的深度, 開發行為從無到有, 所費時間較長, 可以從長計議, 事情單一專注; 維護行為必須, 反應迅速, 舉一反三, 事情多且雜. 但無論怎樣, 一個系統一定要有人負責.
2.2 負責人全權負責. 系統除了要有負責人外, 這個人也要有能立全權處理所有事物.
3. 既然是產線系統, 系統人力備援一定要有, 值班相關準則規範.
3.1第二系統負責人. 系統既然多, 又是產線的系統. 一個系統不能只有一個人會, 一個人不可能只會(或管)一套系統.
3.2 值班規則. 既是產線系統, 問題發生了, 必須要再第一時間恢復. 但問題出在系統這麼多, 並不是所有的系統都是自己開發的, 所以疑難排解標準手冊就變的很重要.
