這次訪談的對象很有趣，為什麼有趣呢？主要是因為受訪者是一家證券商的乙方，而此次談論的主體卻是甲方。受訪者並不是因為想八卦或吐苦水，倒不如說他展現了對於甲方環境的認同感。究其原因或許是配合的時間長而且甲方在領導上也有獨到而體貼之處吧！？不過再深入就變成相談所八卦了，讓我們趕緊來聚焦一下今天的主題吧！
一如常見的配置「業務單位是需求方，IT 單位是實作方」，而這樣配置也出現了一如往常的問題。那就是需求模糊和實作衝突與延遲的狀況。不過，幸運的是甲方領導者對此有所認知，並且也公開支持透過迭代和需求規劃調適等方式來處理，而且還為此制定了需求拆解和評審的機制，然而不幸的是這些做法最終卻在現場撞個粉碎，沒有產生具體的效益。
日子仍然一如往常
價值總會在情境轉換時產生失真和磨耗，透過敏捷的方式能夠讓團隊聚焦於資訊充足且重要的需求上，但這一切都需要商業和工程雙方的搭配 才能夠達成。這不只是工程上的最佳實務做法，也是實現商業價值的最佳實務做法。雖然受訪者單位的領導者支持相關的改善，然而在訪談過程中可以觀察到幾個問題：
商業端最高主管高於工程端最高主管，使得商業端與工程端的衝突並沒有對等的糾紛處理平台，而且也會使得技術人才從組織中流失，或者只寧可轉往做人和商業方向前進，因為這樣才能獲得更好的發展。這種情況對於高度依賴資訊系統的商業體來說是相當危險的事情！這意味著組織裡的資訊系統會因為人才經常性流動而無法培養出具備技術且熟稔該系統的人員，進而使得組織在資訊系統危機處理上相當脆弱。這種不對等狀況也自然會反應在需求分析與調適上，畢竟商業說了算，而且研發人員的經驗相對資淺也難以做出合適判斷。
有條件地忍讓無法為改善做出調整的人。在組織中進行改善是一件涉及所有利害相關人的活動，所以不僅要謹慎地確立目標，而且也需要堅持目標。如果會因為組織中某些較為資深或任何具備特殊條件的人而有所轉彎，會使得其他參與者傾向取得特殊條件或推託執行。改善就只能往失敗的方向前進。
比較讓人感到遺憾的是在訪談過程中也發現了敏捷萎縮的狀況。由於長時間無法達到改善目標，而開始改採評審和各種細節規則的管理措施。倒不是說評審或細節管理不好，而是當制度的設計無視遵守者所處的決策情境時，就會導致制度失效、時間浪費和心理不安全的情況。雖然上述的狀況不容樂觀，但受訪者仍對於所處環境和工作抱持著熱情。訪談就在一來一往過程中接近尾聲，而我們也為訪談過程中的疑問提供了解答和一些改善舉措，並且約定後續保持聯繫來繼續提供建議和支持。
–
如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro