許多前輩一再疾呼:「敏捷不是快,不是研發得更快,而是應變得快。」不過,言者諄諄,聽者藐藐,這仍是名列前茅的迷思。

就算知道了,但仍常會被詢問:「那麼,有辦法再快一點嗎?」



快,其實是有方法的,也是有原理根據的;只是,你能夠接受這類方法嗎?

譬如說,敏捷圈或精實圈都推崇的 Little's law,你能夠接受嗎?

譬如說,越是符合 INVEST 的 story 越能如預期的進行,那麼,你願意投入 5%~10% 的時間扎實地進行 refinement 嗎?

譬如說,越是切實進行 SBE 之類的協作建模活動,就越能避免 contract game 及後續的返工率,那麼,你願意委身學習並操練這項技藝嗎?

很多自以為聰明的人,覺得自己有能力 tailor 一些自認為既不必要、又浪費團隊寶貴生產時間的「無用環節」。 熊熊想到閃電麥坤第一集第一場比賽的劇情:“No no no. No tire; just gas.

愛因斯坦說:「瘋狂的定義就是,一直重複相同的事情,卻期待不同的結果。



快,另一個面向是產能。

可想而知,也常會被連帶詢問:「那麼,產能有辦法再提高一點嗎?」

產能,其實是有方法的,也是有原理根據的;只是,你可能用錯方法了。

緊迫盯人的量測是最容易犯的錯誤。量測,並非不行,但請先深思量測的副作用,尤其是可載舟亦可覆舟的績效指標。這議題,請見兩年前的舊文〈專案的一般症狀〉及一年前的舊文〈估時砍半的邏輯〉,或是去上李君婷老師超級精彩的【510 / 專案監管的系統思考及 KPI 設計攻防】課程。

不僅可能用錯方法,更可能用錯順序。

就以我屢次引用的《持續改善:TOC 生產管理指南》一書來說,它的 MTO (make to order) 解決方案,就極力主張不要先試圖處理產能(常反映在 lead time 指標),而應該先處理準交率 (DDP; due-date performance)。

此書的論點是:

  • 強烈建議不要在開始實施 TOC MTO 解決方案時,就關注產能問題。由於一開始有些混亂,最好先將系統梳理有序,再處理產能問題。 (p.133)
  • 第一步是實現穩定且可靠的準時達交。如果開始是低 DDP 的狀態,那麼先證實準時達交的立即改善效果,後續才縮短交期前置時間。 (p.98)
  • 只有在擁有很高且可靠的 DDP,和所有保障穩定運行的機制到位時,才能採取縮短生產前置時間的步驟。而縮短面向市場的交期前置時間,必須是公司整體計畫的一部分。 (p.70)

讀到這裡,請立刻以敏捷角度思考兩個問題:上述的「所有保障穩定運行的機制到位」這句話,指的是哪些敏捷實踐手法?上述的「縮短面向市場的交期前置時間,必須是公司整體計畫的一部分」這句話,指的又是哪些措施?



即使最後,終究來到了要正視產能的一天,起手式也不是直接處理產能,而是像《鳳凰專案》小說中的要角埃瑞克所講的,要先理解所謂「工作的內涵」:

「你還沒有達到解決專案可交付成果、故障處理、審計合規等問題所需要的那種對工作的理解程度。在你對工作的內涵有更好的理解之前,任何關於控制工作的討論都會讓你茫然無措。正所謂:夏蟲不可語冰。」



所以,你認為,現在是正面處理產能之謎的時機點嗎?