說到 DevOps 免不了會讓人直接聯想到各式各樣的工具，而這也是 DevOps 之所以能夠加速軟體生產力的方法之一。
工具的使用，如果只限於個人，那麼就只是個人的意願問題而已，但如果把工具引入團隊內，那麼這問題就會稍稍變得複雜！比方說：
- 團隊內的成員是否熟悉這類工具？
- 工具要如何融入團隊目前的工作模式？
- 如果是工具舊換新，那麼資料要如何遷移？
- 團隊是否有空做出改變？
- 工具使用的成本是否可以承擔？
可別在這邊危言聳聽~
上述的問題，運氣好的話的確有可能經過一陣摩擦後順利落地。運氣好不好這得端看工具影響的範圍和深度而定，結局就又回到上述各個問題。筆者就曾經遇過團隊花了大價錢買了工具全年的訂閱也請了外部講師做了一套培訓，結局是工具從一開始的零星使用到最後無人使用。這樣的故事並不少見，而當工具導入擴及到全組織時，那問題就又顯得更加麻煩。當然講到這邊都還只是提到工具而已，而 DevOps 可不只有工具，還有許多工程上的最佳實務做法… 所以到底該怎辦比較好？
掌握工具或實務做法的影響範圍是做出任何改變的重要第一步！
流程說穿就是完成一件事情的一連串活動和做法。如果我們能夠了解導入目標所相關的流程的話，那不就可以順著流程知道哪些活動、人和工具會受到影響，從而掌握影響範圍。因此，筆者在協助企業進行各式 DevOps 導入時，第一件會做的事情就是進行流程對照(Process Mapping)的活動。流程對照名詞聽起來很厲害，但其實就是透過視覺化的方式來把做事過程塑模下來的活動。進行這類活動有以下幾個步驟：
- 確定要進行分析的目的與流程範圍
- 收集資料。通常收集的方式有「訪談」、「資料盤查」、「以工作坊方式協作」、「實際訪查」
- 繪製流程圖
- 針對分析目的調整或改善既有流程
以筆者的經驗來說，如果條件允許的話，通常所有收集方式都會用上。此外，還會透過 POWERS 模型1來協助自己在收集資料上不要忽略需要注意的面向和議題，因為通常這類活動的最大難處在於參與者和外部顧問的認知有落差，而使得關鍵問題未能被識別。這樣的落差會使得稍後的改善規劃產生偏差，而降低整體改善或導入效益。
POWERS 模型1是用來觀察和管理「人、工具和流程所構成的系統」。它可以協助我們看見全貌，而它的每一個字分別代表一種面向：
P(Process, 流程)：代表目標流程與該流程的上下游和分支的流程，以便了解完整產出所存在的相依性特徵，也能協助找出利害關係人；O(Objective, 目標)：以盤點角度來看，此處的目標代表的是受盤點流程的目標；W(Window, 影響窗口)：指的是該流程在人事時地物上的邊界特徵，比方說有哪些不同角色參與其中、系統或團隊所在的地理環境等；E(Evaluation, 評估)：此面向指的是關於該流程目前所收集的指標。通常這類指標都是用來評估該流程達成其目標的程度，或該流程中某活動的執行狀況等可以產出客觀數值以便進行後續決策的資料；R(Relation, 互動關係)：指的是人或軟體的互動關係。這個面向聽起來抽象，卻是最為重要的特徵。比方說目標流程的利害關係人的溝通方式與期望管理作法、執行流程中的活動該遵守的準則(比方說應該進行哪些測試和測試應該達到的程度為何等)或採用的標準(通常與合規有關)；S(Structure, 結構)：指的是與流程相關的組織、團隊、成員、專案或產品的結構
在做完上述分析活動後，會對即將做出的改變有更深的了解，也能夠更順利地讓想導入的做法或工具獲得更多支持並且做出更合理的導入規劃。
看到這裡可能會想是不是每次都要如此大費周章的進行盤點？
一般來說，若組織或團隊對於目標流程有相當程度的掌握和資訊留存，上述的盤點與分析通常不會耗費太多時間也不會太複雜，畢竟資料很全。若掌握程度不足或改變程度過大，通常會較費些時間。不過，如果這些議題都只限於團隊內，那麼可能時間耗費也不會太多，尤其團隊對於流程和 POWERS 模型已經有一定熟悉後，那可能時間花費的更少。
若分析與盤點過程中，參與者之間產生明顯的摩擦而無法消除時，則可能需要進一步地思考如何縮小範圍或確認是否有未討論到的細節。當然尋求其他中立第三者的協助也是很好的做法。當然如果初次進行上述分析與盤點，擔心無法周全整個活動，也可以聯絡我們，畢竟協助企業成長並且在轉變中找到更多成長機會是靖本行策一直以來的堅持！