重視生產力的管理者, 幾乎不會投入長期的改善
重視品質的管理者, 長期下來就能不斷提高生產力
~ John Seddon
高績效的組織把軟體視為一種策略優勢, 依靠的是 IT 組織能和其他部門之間的一致性, 還有執行 IT 的能力. 這件事情可以在"人人成長的文化 銳意發展型組織”一書中看到, 為了達到透明度以及即時回饋, 必須有系統產生這樣的資訊, 並且要能方便產生, 和快速讓大家都看到, 這些都是要資訊系統幫忙. 所以這些公司對於資訊系統軟體的投資都是非常高的.
這些公司通常會準時交付工作, 並且簡化系統, 以更地的成本實現更好的業務成果. 唯有不斷降低複雜度, 才能建立可靠的系統. 要做到這些可以嘗試使用 Improvement Kata 來實現.
什麼是 Improvement Kata 呢? 你可以參考這本書:
豐田形學: 持續改善與教育式領導的關鍵智慧
如果覺得太複雜, 可以看看 Improvement theme kata 的做法
Toyota Kata
改進的套路: Improvement Theme Kata
不過, 這邊我們要看的是 HP LaserJet 團隊如何利用 Improvement Kata 的案例.
HP LaserJet 負責建構韌體, 支援所有掃描器, 印表機, 和多功能設備. 這個部門的成員分佈於美國, 巴西, 和印度, 大約有 400 個員工. 在 2008 年時他們遇到一個問題: 部門運作過慢. 他們無法快速交付新功能, 每當有用戶提出一些新需求, 他們會說: 你們需求我們會在未來 6-12 個月中, 處理其中最終要的 1-2 件需求. 他們試過很多方法, 但是沒有一個有用. 他們需要一些新的做法.
所以 HP 第一步是先了解時間花到哪邊了, 下表是他們所花的時間的分佈
|
成本
|
活動
|
|
10%
|
程式碼整合
|
|
20%
|
細部規劃
|
|
25%
|
在分支間移植程式碼
|
|
25%
|
產品支援
|
|
15%
|
手動測試
|
|
~5%
|
創新
|
從這個分佈中, 你可以了解到他們的瓶頸在這三個方面
(1) 產品支援: 產品品質有問題, 需要花時間修復問題
(2) 在分支間移植程式碼: 因為有類似功能但支援不同硬體設備, 所以有大量移植問題
(3) 細部規劃: 行銷部門不相信產品部門能準時交付, 因此需要產品部門產生詳細計畫
HP 採用循環式改善方式: Toyota 的 improvement kata. 來進行變革. 首先塌陷確認挑戰的方向. 因此, 為了這三個問題, HP LaserJet 團隊定義改進的目標如下:
(1) 提升品質降低韌體發布時所需手
(2) 移植程式碼不要耗太多時間
(3) 降低規劃時間
至於怎麼做的細節, 領導階層一開始並不知道, 也沒有打算定義他, 但利用了迭代演進的方式來處理, 每 4 週一個迭代, 定義下一次的目標狀態. 下表是他第 30 次迭代的目標狀態:
|
優先順序
|
主題
|
準則
|
|
0
|
品質門檻
|
P1 解決時間 < 1週
L2 測試失敗, 24 小時回應
|
|
1
|
每季發佈的位元數
|
發佈準則的可靠性錯誤率
|
|
2
|
新平台的穩定度和測試覆蓋率
|
顧客接受測試的通過率為 100%
所有 L2 測試核心的通過率為 100%
新產品的 L4 測試執行率為 100%
|
|
3
|
Product turn on 依賴性和主要功能
|
每小時的影印速度
啟動省電模式
執行夜間測試套件執行
|
|
4
|
建構下一代產品
|
新處理器的端到端系統建置
新產品的高階效能分析
|
|
5
|
旗艦產品整合計畫
|
端到端測試與系統測試實驗室兩者的內容與時間表一致性
|
基本上, 你不可能設定一套雄心勃勃的目標, 又能包含眾多品質標準, 有能準時做到所有規劃項目. 大多數狀況你需要根據現時不斷調整, 甚至還要有心理準備, 接受妥協和折衷.
HP 花了兩年的改善, 才推出新的韌體平台: FutureSmart. 並且還打造出一套流程和工具, 減低了交付過程中非增值活動的成本, 同時還顯著提升生產效率. 這是 20 年來第一次, 韌體脫離新產品發佈的關鍵路徑, 並且反過來贏得產品行銷部門的信賴.
下表是改善後, 在 2011 年所進行調查, 這時候的時間分佈和之前大大不同:
|
成本
|
活動
|
改善前
|
|
2%
|
持續整合
|
10%
|
|
5%
|
敏捷規劃
|
20%
|
|
15%
|
單一主要的分支
|
25%
|
|
10%
|
產品支援
|
25%
|
|
5%
|
手動測試
|
15%
|
|
23%
|
建立與維護自動化測試套件
|
0%
|
|
~40%
|
創新
|
~5%
|
你有發現到嗎? 這時候時間分配的比例改變了:
(1) 更輕量的規劃過程, 不在把時間花在無法掌握的規劃上面.
(2) 他利用了 Trunk based development 的方式來進行開發
(3) 更多時間投資在自動化測試上面
(4) 更多時間用來創新
參考資料:
A Practical Approach to Large-Scale Agile Development
大規模敏捷開發實踐：HP LaserJet產品線敏捷轉型的成功經驗（簡體書）
全站熱搜
留言列表
