靖本

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

這次訪談的對象是在中國設了研發單位的香港公司，由於 Covid-19 的影響使得這個年紀尚輕但又稍具規模的研發單位飽受困擾。該公司原先並未有明確的協作工具。成員之間的溝通靠的是線上會議和電子郵件的往來，但由於並沒有具體存放討論內容或思考內容的工具，彼此之間的知識交流也就靠著有有一搭沒一搭的零星紀錄來達成，而誤會和麻煩也就因此而起，比方說： 工作換手困難； 權責難清； 理解時間長； 資訊遺失。 即便這個新單位一開始就以敏捷的方式配置一切，最終迎接他們的就只剩下爭吵和無法達成目標。為此，他們採用了一個需求追蹤系統，其實就是自建了一個開源的知識管理工具，讓所有的人將各自的想法和平時的討論紀錄下來。這樣簡單的做法改善了他們的討論方式和協作的效率。 關鍵的改善往往勝過千萬個煙火式的實務做法，基於需求的單純解決方案，反而更有力量。當我們面對遠距協作需求時，有兩個很大的要點： 資訊共享； 體諒他人。 資訊驅動著人之間的討論。如果沒有一個共有而且即時的管道，人和人之間的討論將單純的基於假設和主觀認為。這樣的情境就算有爭吵也不會是太意外的狀況。不過，當回到了遠距，直覺上可能覺得大家會偷懶，但實際上大家更可能不知不覺地模糊了工作和生活的邊線，進而導致過勞。 因此，當團隊需要進行遠距協作，務必記得下列幾點： 提供便捷取得必要資訊的方式； 建立彼此之間的即時溝通平台； 尊重隱私並且建立溝通和協作原則； 在限制下，提供最多的團隊實體交流機會； 為他人設想。 當工作自由和生活自由重疊時，有時會造就出的不是更自由，而是更不自由且透支的狀態，而且遠距所造成的資訊不連續更是讓效率低落的元兇。此次的訪談對象透過簡單的工具（基本上沒做任何客製或特別技巧）解決了團隊工作推進的問題，並且降低了爭吵的狀況。這便是專注瓶頸解決問題的重要之處。不過，在訪談過程中，可以觀察到由於長時間遠距而加劇穀倉問題。因為他們原先透過明確職責分配和透過工具指派工作的做法，使得跨域成員之間的交流低落。或許他們接下來應該專注的是讓成員意識到跨域交流和技能學習，以及透過建立通用詞語交流需求的技巧！為此，我們還在與對方積極地保持聯絡，也期待能夠協助他們解決跨職能團隊建立和協作的問題。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.

今年有許多機會遇到外包許多 IT 研發人力的組織，組織規模不能說不大，但就是大到人不夠用。當內部開發人力不足時，很容易就遭遇到對技術缺乏良好掌控權和外包的系統理解不夠，甚至是對於其中程式碼的管理有些薄弱。當組織高速成長時，新系統和接連不斷的大功能滿足了組織實力展現需求和市場競爭力的需求，但當外部環境有些動搖時，組織開始希望有更好的成本效率，就不得不回頭檢討昔日的大量外包作為。不過，首要問題便會出在甲乙方交付模式與產出的管理方式了！此時，主事者會很直覺地想到需要開始收回對於產出的管理能力，而開始放大對於「工具」的渴求，彷彿有種工具能夠像神兵利器般解決一切的問題，重點是還很有成效，但事情真能這麼簡單嗎？ 此次的訪談剛好背景也是如此。受訪的組織為了更有效地管理產出，內部研發單位基於開源工具構建了一個管理平台，並且希望組織內的成員和外包商能夠全面運用，以便更好地管理產出和提升效率，但結果是自動化流水線成了上線前的最後一站測試，而整個管理平台最終也只是一個程式碼存放地，持續整合的概念說實在也談不上。受訪者委婉著說道「程式碼的確重回管控，但平台使用率不高，有沒有平台似乎也沒未工程師帶來太多誘因。」訪談過程中既能感受到他對於平台的用心和自信，但同時也感受到他的無奈。 工具對於日常操作的影響 「工具」有著較為具體的形象，既容易想像也能摸得著，但回到軟體開發或者是日常操作，終究得回到人而非單純的工具。在組織中，工具的確為每個成員帶來方便，但這些工具都會成為日常操作與營運的一部分，進而成為習慣。當引進任何工具或者平台時，除了工具的功能外，更應該考量的是工具對於日常操作的影響，比方說： 工具對於原來作法的衝擊； 工具是否對於原來流程產生影響； 組織成員對於工具的陌生感； 工具是否能夠進行客製，以便合於當下所需。 導入新工具前組織應先考量的事 上述都會是工具重要的考量，而非有了工具就能夠改善一切。有時強硬的導入工具反而會造成雙軌做法，徒增組織成員的痛苦。對於外包廠商就更是如此了，畢竟對於他們來說，更重要的是恰如其分的節約工時和不要做出越矩的事情。因此，對於正苦於如何導入新工具的組織來說，有以下的建議： 除了工具，請在意目前的做法； 提供人員足夠的培訓； 透明化目的與工具選擇的原因； 挑選正確的導入時間； 注意工具的必要性。切入重點，而非只為形式美。 與外包商的協作模式 當然對於有眾多外包商的組織來說，如果想要進一步推動外包商，更需要在意： 權限管理； 必要資訊的透明化； 增進外包人員的心理安全，並且引導他們提出改善措施 逐步增加外包人員的認同感和統一化組織價值觀。 訪談的最後，受訪者表示他們的平台在今年已經完備，目前重心就是推廣該平台。期盼他們能有好的結果，CPHT 也會繼續跟蹤後續的狀況，並且提供必要的協助，以便讓一切好事真的都會發生。

前言 GitLab CI/CD 的 job 如何獲取程式碼庫時提供三種策略，分別為： clone fetch none 在比較這三個策略的差異之前，我們需要先了解 Executor 主要的初始作業與結束作業是怎麼運作的。 Executor 初始作業 我們先以一個基礎的 GitLab CI/CD 範例來看，該範例將會運行一個 build job： stages: - build build: stage: build script: - echo "building.