這次筆者要講的主體是關於軟體協作部分，軟體協作筆者在早期公司或在電商領域，甚至在大公司，我很難體會到這樣優勢，因為很少公司沒有協作流程思維概念，我一直覺得是用EMAIL或是LINE通話這些來進行專案開發，一直遇到我曾經共事過的主管，他講解整個專案協作流程的重要性，讓我試者把專案拆解和協作流程與看板及板控策略整合起來，甚至應用DOD的手段，讓我體會到協作流程重要性，筆者滿懷感謝的心特別感謝他，因為協作流程的思考，讓我覺得相當重要，因為工具只是補助，流程才是主角。
沒有協作管理的挑戰
筆者所待過的公司還是用EXCEL去進行做管理，就算有工具也沒有協作流程的概念，其實也只有工具上的形式性，以下你會遇到的問題會是
- 目前手頭有多少專案，這些專案的優先順序
- 工作有哪些事項要處理，開始做，結束日期
- 那些專案任務緊急或是不重要
- 人員異動輪流的狀況下，文件和知識的傳承該怎麼辦
協作專案管理不外乎有這些功能
- 專案
- 需求類型
- 主旨
- 說明
- 狀態
- 優先等級
- 分派者
- 版本
- 預估完成日期
- 測試預估完成日
- 開始日期
- 完成日期
- 預估工時
- 發布日期
- 附件
關於協作流程的工具狀態設定
筆者會思考既有的專案會有哪些流程，有哪些角色，筆者會設計大概如下：
在需求類型的時候設計
- 新需求
- 需求變更
- BUG
- 支援處理
分派的類型會有
- 群組(註記：群組針對可能是部門、也有可能是任務編組的狀況 )
- 個人
狀態部分
- 新建立
- 暫停
- 等待分配
- 進行中
- 測試中
- 拒絕
- 上線前作業
- 上線
- 完成與結束
優先等級
- 緊急24小時處理
- 緊急72小時處理
- 緊急
- 一般
- 嚴重等級：24小時須跟主管和老闆告知
工作日誌狀態
- 開發
- 測試
- 檢查問題
- 寫文件
- 開會與討論
- 安裝
- 支援
最後筆者會結合以下的手段
- 看板管理
- 記錄開發和文件的手段
- 版控策略
筆者認為工單的概念很重要，筆者在接觸生產管理系統工單，其實可以結合在軟體開發週期上，應該要很清楚自己目標，重點不在於開發新功能，修正BUG，重構舊程式…
工單有分三大區塊
- 問題：簡單說明需要達成目的
- 理由：做這件事理由，解決問題能夠幫助那些人
- 品質測試：如確定問題已經獲得修正
最後再結合在git的中步驟如下
- 找出你工單的單號
- 在git 儲存以類型_工單編號-描述格式建立分支 (註記：筆者其實最常用的就是類型-工單單號，也可以查系統，後來覺得多了一道查，應該要擠出查單號時間)
- 確認工作含結果與要提交程式的處理
- 最後進行本機提交開始進行合併動作
- 最後開始push道遠端機器，最後再進行變更工單的狀態已解決(上線前作業、上線)，還不能已結束
最後筆者會依據跟上面報告的部分會有那些格式欄位會有
- 對相關的人、進行日期起訖、內容、結果、參與者(內外)
- 時間軸、做過哪些事情
- 報表數據化
最後對上的老闆要讓他知道，你應該要思考我要怎麼讓老闆知道
- 問題出在哪? (EX:需求變變)
- 這案子哪個地方、預算最沒有效益
- 哪邊可以省、可控制預算
- 時間成本
最後再結合PDCA的思維
在專案的時候開始進行計劃，就可以執行，執行過程會檢查，然後發現風險或缺失，最後進行改善。
例如：原本計畫花10天結果在第7天的時候，覺得可能做不完，可能需要13天，這時候要做降低風險的作法，跟客戶講延後，或是加班，或是加人來做，這就是降低風險的方式之一，客戶事先知道你會延後3天，他也可以去做他能降低他自己風險的事情，但是不可以在第10天的時候才說做不完，那就沒有什麼好方法了。就只能硬頭皮加班做完，然後做不完被k。
但是不可以在第10天的時候才說做不完，那就沒有什麼好方法了，就只能硬頭皮加班做完，然後做不完被k，有時候管理是管理異常，不管理正常。
總結
最後我主管給我一些滿受惠的給我一些啟示曾跟我提到 有一點要注意，我從來不怕預估錯誤，只怕沒有預估，因為預估錯誤，才知道要改善，沒有預估，就無從改善，不會進步，就算錯誤，也知道怎麼死。 從另一個角度看，不想被管理的人，永遠無法管理別人。 就算錯誤，也知道怎麼死。 從另一個角度看，不想被管理的人，永遠無法管理別人。 將來你也會成為主管，我相信你也希望能有自己管理的方式。 但是不去嘗試去做，怎麼教人家對吧?
最後無非是達到這兩個
- 風險控管
- 持續改善
