當企業或組織內有人離職或請長假時，相信許多人都將面臨「交接」難題，往往由某個人負責的領域業務，總是極難無縫接軌給職務代理人，甚至是尚未到職的新人。為了面對以及解決這樣的困境，平常時候可以透過「公車指數」（Bus Factor）這項指標，衡量團隊是否會因為人員變動造成工作停擺的衝擊。

公車指數的意思？

鈦坦策略顧問黑手阿一在網誌「黑手阿一的敏捷實戰報告」是這樣形容「公車指數」：

公車指數的由來是，假設有一天，你接到電話說，團隊一起出去吃飯，有人被撞公車撞到了。如果是一個人被撞到，這個人剛好是團隊的超級核心，對專案有巨大影響，公車指數就是【1】。如果是兩個人同時被撞到，才會對產生巨大影響，那公車指數就是【2】。

也就是說，公車指數可評估團隊或專案因為人員變動造成的影響。若最重要的一個成員出意外即刻帶來衝擊，公車指數為１；最重要的兩個成員出意外即刻帶來衝擊，公車指數為2；最重要的三個成員出意外即刻帶來衝擊，公車指數【3】…並以此類推。

公車指數也是組織、團隊用來評估「資訊共享度」的衡量標準，指數越高代表團隊資訊共享度越高，個人的影響力較小；反之，指數越低就代表當一位專業角色離開時，工作越容易陷入停擺狀態。

鈦坦科技活用公車指數的案例分享

相信大家經常遇到當組織有人離職或告長假，必須找人交接工作困境，身為軟體公司，除了常見接手難題外，還可能因為有人離開團隊，面臨程式重寫的情況。這時公車指數在平時就可派上用場，拿來衡量團隊狀態，評估是否需要採取行動。

鈦坦科技在企業故事書《鯨游藍海－鈦坦科技的敏捷之路》裡的「鈦坦人真心話」單元，分享了使用「公車指數」的實體案例。

導入敏捷前，鈦坦過去的公車指數只有一，而現在，公車指數基本上都是大於一。

鈦坦剛起步時，就像劃分領地般，每個人鑽研於自己專精領域，具備三頭六臂完成自身項目即可，鮮少顧及其他人的工作項目。因此，每當有成員請假，團隊就會變得混亂與繁忙，甚至是以一種「祈禱夥伴不生病、不休假、熱愛公司也不會被公車撞」的方式營運。

如此不健康的狀態，直到導入敏捷後，採用端到端的團隊，透過每日站會（Daily Scrum）彼此分享工作進度，在每個Sprint由團隊為主體共同參與後，有所改善。

開發具體實例，還有當鈦坦導入敏捷後，為了避免遇到團隊成員離職，便沒有人會維護原本系統導致「程式重寫」（Code Rewrite）困境，採取了「結對編程」（Pair Programming）的做法。

結對編程是一種敏捷軟體開發的方法，由兩位軟體工程師共同編寫程式，其中一位負責撰寫；另一位則盯著螢幕檢查錯誤或給予建議，額外帶來還能帶來相互學習討論、帶領年輕夥伴成長的長期好處。

在一些新開的專案初期，鈦坦工程師會啟動多人協作編程（Mob Programming），透過群體智慧來建構系統架構的基礎，讓團隊更了解此專案的核心商業需求，掌握系統設計背後的商業邏輯。

透過這樣的工作模式，工程師提前溝通想法，減少實作時落差，並從過程中學習如何說服別人。最後寫出來的程式由於經過多人思考會降低盲點，連帶提升程式碼的品質。

回顧導入敏捷後，鈦坦沒有再重寫過任何一個程式或專案，雖然還是會遇到日常開發經常性的代碼重構（Code Refactoring），不過已經很少聽到有團隊發生「因為某個人離職而造成非常大的震盪」相關議題。

鈦坦科技相當重視每位夥伴，投入許多心力，全力做到讓任何夥伴離開公司時，不會影響到組織、團隊運作，帶來長久正面的營運模式。「公車指數」是否有勾起你的好奇心呢？若想瞭解更多鈦坦科技一路來導入的實務變革，誠摯邀請你前往閱讀鈦坦出版的企業故事書《鯨游藍海－鈦坦科技的敏捷之路》！>> https://gotica.io/鯨游藍海_鈦坦官網/ AS2022

鈦坦 Medium 看更多好文分享！一起 Never Stop Improving~ >> https://gotica.io/鈦坦好文/AS2022