G 觀點

這次訪談對象是來自一間提供金融交易數位服務公司 PMO 的一位資深管理人員。從訪談間可以了解到該組織的管理者對於時間調配和公司規則都是帶頭施行，以身作則，因此公司在相關營運流程上的管理不僅嚴謹也有效率，更重要的是員工對於這樣的文化充滿了自信。「我相信能做到如此的業界同行也是相當少數。」受訪者如此地跟我說道。 由於此次的訪談仍然是和敏捷有關，因此在圍繞背景資訊閒聊一陣後，便提到敏捷。讓我意外的是對方表示「所採用的實務做法是否為敏捷，並非他們所在意的。他們只是因為需要解決實際問題，而採用了一些實務做法，重要的是解決問題，而非是否採用了哪個框架或做法。若採用的實務做法恰為敏捷裡的實務做法，那也只是剛好而已。」這樣的說法相較於敏捷到只剩下做法的狀況來說，顯然還算不錯。 敏捷性的追求沒有絕對的套路 敏捷性的追求，不會有絕對要如何遵從的套路，準則抓的對，持續改善漸進改變也是很好的過程，甚至能夠讓敏捷變得更加有效。只不過應該要注意的是實務做法之間往往彼此有相關聯性。單獨採用某個實務做法，有時並不能最大化實務做法帶來的好處，還是要回到目的、資源和風險三方面來了解自己最適合的方式是什麼。 接近訪談的尾聲時，意外地聽到了受訪者的另一個焦慮，那就是該如何進行規模化的敏捷。對於一個並不矜持於敏捷，只追求務實解決問題的組織來說，到底他們正面對怎樣的狀況，而使得所提的疑問有種越級打怪的感覺，或許是因為受訪者正在面對一個更加緊迫的市場環境，使得他們不得不思考如何讓專案和產品能夠更好的面對市場變化，從而達到降本增效的效果。 關注實務做法間的連動關係 面對此次的訪談，不得不說面對危機和競爭，敏捷是企業會想到的好解方，但敏捷的落地需要更為系統性的規劃才能夠獲得明確的效益。受訪者應該思考的是： 此次對於規模化敏捷的企求想達成的目的是什麼？ 過往較為嚴格且緊迫的時間管理方式，是否會讓面對改變的組織成員難以消化“規模化敏捷”的好處？ 盤點當前的作法和敏捷之間的關聯性來了解自己的情境和落差，以便知道“規模化敏捷”的內容與方向。 工程所體現的系統性，並非單純地展現在單一實務做法上。相同目標而在不同面相上的實務做法往往會有互相連動的關係，進而成為一種解決目標的系統性作法。當期望將此類做法導入企業，尤其是全面導入時，更應該關注既有做法、想解決的問題和想導入的做法彼此之間的關係，並且階段性的導入，畢竟羅馬不是一天造成的。 – 如果你也正在思考如何規模化敏捷並且為組織帶來改變，CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

隨著當前經濟情勢越來越有挑戰，企業就會希望能夠讓資源更能花在刀口上。這次相談所的對象是來自金融體系的受訪者。 金融行業的複雜 IT 系統和對於系統穩定和正確性的強烈要求是不難想像的背景狀況。此次受訪者是來自金融行業內的大數據處理部門，他們被要求能夠有效地提供業務必要資料，以便能夠即時地反應市場的樣貌，讓業務部門能夠採取正確的行動，然而面對研發大量外包且系統各自獨立的狀況，時常導致行內成員和外包成員的工作負載，不僅增加成本也降低了工作滿意度，大家總是叫苦連天😫 為了能夠改善此一狀況，該團隊透過看板視覺化所有成員的工作和變更動態、採用固定迭代週期來約束需求方的需求和口語化的任務描述來破除外包商彼此間的穀倉，降低因為相依需求而造成的變更衝突，最終讓工作負載回歸正常，也讓交付變得更加準時。 視覺化能夠讓團隊了解當前的工作動態和促進討論，從而降低開發風險。對於因為需求衝突和變更而導致無法準時交付的苦命團隊來說，視覺化和看板絕對是好的起點。 – 如果你也正在思考如何提升效率或看板，CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

為什麼需要從價值流開始？ 當想到要如何提升交付能力時，迸出腦海的往往是以下的做法： 增加自動化比例 期望工程師學習更多的技能 引入其他生產力“工具”或是增加人力 要達成軟體服務交付，從商業構想到向客戶交付價值需要經歷的一系列的流程活動（價值流），而上述的改善往往只專注在局部優化。這也正是在改善過程中團隊需要先理解流程活動的原因，並基於價值流對照（Value Stream Mapping, VSM）使用關鍵指標來分析目前的狀態，因為這有助於團隊識別價值流裡真正的瓶頸點與浪費，進一步制定改善目標與計畫。 DORA 指標 VSM 來自於精實（Lean）管理，常見於製造業的產線分析與管理。DevOps Research and Assessment（DORA） 團隊進一步以軟體交付與維運為面向，透過五項指標衡量團隊的 DevOps 績效，分別為： 前置時間（Lead Time） 部署頻率（Deployment Frequency） 變更失敗率（Change Failure Rate） 平均復原時間（Mean Time to Recovery, MTTR） 可靠性（Reliability） 這些指標分別針對團隊的產出量（Throughput）[指標 1,2]、服務運行的穩定性（Stability）[指標 3,4]和可靠性[指標 5]進行衡量，這也意味了團隊在實踐 DevOps 的過程中，必須兼顧速度與品質。

有多少次... 我們在各自的觀點與理解下，一起錯過了該有的機會？！ 明明是再簡單不過的功能需求，卻無法實現？! 投影片中，Mary 洞悉市場了解領域知識，Peter 熟於管理需求的實現，John 則是有著豐沛經驗的工程師。良好的機會本應帶來甜美的果實，但最終卻是以 Mary 痛哭流涕作結。到底是什麼問題導致了這樣讓人遺憾的結果？ 需求的缺損！ 市場驅動需求的產生，接著我們會探索需求並且描述需求的樣貌，然後透過工程與管理進而實現需求，並且交付需求。過程中，具備不同職能的專家會依照自己的觀點與理解來傳達資訊，一些隱含在需求中的情境資訊，免不了會在傳遞過程中遺失。然而，只有完整的需求才能創造真正的價值。因此，改善需求傳遞時，情境缺損所造成的需求缺損是一個直觀且重要的議題。此外，不同角色對於軟體產生的過程也有不同的關注點。銷售人員關注的是產品是否實現需求，管理人員關注的是如何調控過程，然而工程人員關注的是如何交付需求。不同的關注點會造成對於需求價值的認知不同，進而影響需求的流動。 BizDevOps 正是為了解決上述的問題而存在，所以 BizDevOps 就是： 在原汁原味的產品需求理解下，讓商業人員、管理人員和工程人員能夠有共同認知並且協作達成商業目的 實現 BizDevOps 該處理的第一件事：需求理解問題 如上述，需求傳遞免不了因為情境和領域知識的不夠，而使得不同的人對於需求有不同程度的理解。為了能夠解決這樣的問題，組建一個完整的團隊對於解決理解需求是相當重要的事情。 完整的團隊存在著具有不同技能的成員。為了讓團隊能夠盡量有能力獨立實現需求，團隊中的成員需要不排斥擁抱跨職能，跨職能不是只意味著一人多用，或者是取代誰的工作，更重要的是讓團隊成員能夠在需要的時候互相幫忙，並且可以擁有共通的知識讓溝通和理解更加順利。常見的團隊人數為 8~12 人，然而最佳的人數還是得回到實際開發的需求。根據 Dunbar’s number 可以知道團隊人數在 15 人以內時，成員之間可以建立深厚的信賴關係，所以在組建團隊時別忘了考量人數規模。人不是多就好，多人就會提高溝通與管理的成本。