也談“精益”
精益對大家來說都不陌生了，無論是最開始提取的豐田制造原型，還是后面延伸出來的物流供應鏈管理，再到近兩年頗為流行的精益創業(Lean Startup)，都在不停刷新著“精益”這個概念。最近也不乏把精益當成“熱詞”來包裝的各種理論，以至于很多客戶建議我另外給“精益企業”取個名字。我一般都會禮貌回答說：看看精益房子(見下圖)吧，我們并沒有發明什么新東西。
當然，精益房子所表達的架構其實還蠻復雜的，也不是一兩篇文章可以論證的，日本和美國管理學界也沒有達成完全的一致。很多人的疑惑是咱們好歹是21世紀的新興產業，肯定跟上個世紀的汽車制造業有不同吧?還用精益思想合適嗎?這里我來談談自己的理解，拋磚引玉。
精益思想為什么適合于咱們這個行業，在我看來有以下兩點：
- 追求快速價值交付的小批量生產模式
- 追求***卓越的匠藝文化
追求快速價值交付的小批量生產模式
“這個誰都知道”、“這不等于白說嗎”、“這個太虛，來點干貨吧” ...
這些都是每次拋出這句時會收到的反饋。然后我反問，“能給我講一下你最近交付的一個功能掙了多少錢嗎?”一般這個時候對方會回避我真誠的目光，嘴巴上說著“我們的系統很復雜，一個功能太小了...”。
那么我們再來看看各個崗位的績效考核吧?開發了多少條需求和測試出了多少bug，橫比環比增長了多少都是報告中的常客。這里的“價值”被定義為了每個角色、每個人的階段輸出，類似富士康流水線上生產一個iPhone零部件的工人，至于***是iPhone 6還是7于這個工人其實并沒有太大關系，反正這批訂單200萬臺，本周得搞定，做的越多個人收入自然會更多。
上面的例子告訴我們，并不是所有的生產模式都是追求“小批量”的，富士康在生產模式上是成功的，甚至是行業標桿。而豐田制造當年形成精益的生產模式，其核心是追求對市場變化的響應力，即用戶一旦變了口味想開SUV，我的轎車生產團隊及流水線能夠很快調整開始生產SUV，并且我能夠通過這種能力快速驗證SUV的市場是不是真的。
在這樣的生產模式下，較之每個員工的資源利用率及輸出，我們更關心的是“需求”是否能夠在團隊快速流動產出***的產品，應運而生的是對生產批次小規模化及人員跨職能的要求。持續交付(Continuous Delivery)顯然是咱們這個行業對這小批量生產模式的總結。
當然不用論證的是科技行業的市場是持續變化的，具有不確定性，所以邏輯上這種生產方式應該是必須的，即使是所謂的后臺核心系統，其需求也不得不跟著所謂的前臺用戶需求變。很多人會說這個很自然啊，咱們拆了User Story做迭代不都是這樣嗎?那么有多少次大家會說“這幾個User Story關聯很緊，客戶都要，我一起開發(測試)了，效率高一些”、“上線走流程麻煩死了，咱們還是一個月上線一次吧”、“所有都是Must Have，砍不下去了，PM上去磕客戶了” ...
當然我們不否認有的時候這些意見表達的可能是正確的選擇，但顯然，堅守這樣的生產方式就需要在這些時刻去思考是否大家真的都運用了精益思想來指導自己日常的生產工作。
這個時候可能會有大牛又跳出來拍一磚：”看吧，還是管理的人不懂精益!”
那么技術人員真的理解了“小批量”的含義嗎?在你的內心深處有理解包括TDD這樣的基礎技術實踐是在踐行精益“小批量”的價值觀嗎?用測試來描述一個業務小場景，然后加以實現，這種小步前進的方式正是個人對精益思想的日常修煉!每個“小批次”業務場景實現后，都要嚴格重構，追求代碼的***簡潔，這又是我們接下來談的對”匠藝“的卓越追求。那么環顧四方、環顧行業，有多少工程師能夠堅持TDD呢?當開發進度緊張成為壓力的時候，有多少人是選擇***個放棄TDD，將“小批量”原則***個放到褲兜里的呢?!
追求***卓越的生產匠藝
回到富士康流水線上，一個殺馬特造型的青年在熟練地完成著iPhone屏幕的組裝，他下意識地拿著工具鉗咯噔一下，熟練地把一個屏幕扣入了iPhone的背殼，時間不到10秒鐘，然后他開始重復循環。他的眼神好像有點游離，嘴角不時露出微笑，腦子里在回憶著昨晚和兄弟們擼串時的高談闊論。他到崗1個月，***天就學會了這道工藝，除了有一次把屏幕扣反了，這一個月還沒出過啥問題。最近談戀愛花錢不少，他每天都工作10個小時，雖然辛苦但想到和女友的甜蜜時光還是覺得值。
上面對等的場景是一個蓬頭的程序員，對象(OO)也搞了5年了，這次遇上了函數(FP)項目，于是“WTF”成了口頭禪，有時候在pair時忍不住說了還得道歉。最近code review出來問題很多，功能是沒問題了，但老是想著修改變量值。每天盯著屏幕的眼睛有幾根血絲，腦子里不時閃過無數馬匹從Monad身上壓過去，都上項目一個月了，最近幾個User Story還是被QA揪出不少問題。
雖然“心”苦，這段時間還是覺得很充實的，回家地鐵成了***的思考地兒，有時候突然開悟，回家興奮著也想來個session，當然結果一般都是家人2次元的眼神。每每這個時候都希望第二天快點開始，能夠去把代碼重構了，實踐一把自己在地鐵上的靈感。
上面的兩個場景很普通，在這兩個行業里可能比比皆是。經常我們會開玩笑說一個賣體力，一個賣腦力。但其實本質的不同是生產者采用的生產方式的不同：在流水線上的殺馬特少年需要的是嚴格遵循制造工藝的每一道工序，通過不停的重復形成機體的記憶;而程序員需要的是認清自己認知的局限性，通過不停的學習形成更好的解決方案。
好的流水線生產者能夠通過認真練習、快速形成機體的記憶，使自己產出的效率和成功率都能夠達到一個高水平。好的程序員能夠通過刻意練習形成大腦的思維體系，從而能夠持續提升自己面臨新問題時的響應力。由于豐田當時的“特殊”市場環境，迫使其表面看是一個偏重于前者的流水線，但實際卻走出了一條持續學習和提高的文化之路，收獲了對市場需求變化的高響應力。
所以有人會說：“對嘛!管理層都想著用熟練工，所以沒法有精益的文化了!”
咱們還是小處著手，剛才談了TDD，現在談談pair。曾經作為一名PM，我也為兩個人結對指著代碼論道半天非常惱火，雖然內心萬馬奔騰，但對“匠藝”的認可還是阻止了我去拆散這對pair，畢竟我清楚兩人確實是在討論重構而非其它瑣事。當然事實證明這對pair現在都是業界有名的敏捷和架構專家了，好歹也算是對我當年苦難的回報。
再次環顧四方、環顧行業，有多少工程師能夠堅持pair，甚至code review?有多少人希望能夠在功能已經實現的代碼之上持續追求卓越，而不是想著我自己干實現快一點好交差。至少這么多年的咨詢生涯所見者有限，令人慚愧的是code review成了咨詢需要去說服團隊的日常工作之一。如果都沒有分享和交流，甚至是爭論，又哪里來的真正意義上對***卓越的追求呢?
小結
上面兩點可能只是整個精益思想落地層面的兩個具體方面，但就我個人的體會而言，要做到已經非常困難了!即使在對敏捷高度認可和實踐的團隊里，要堅持做也可謂是一件艱苦卓絕的事情。什么事情喊口號容易，持之以恒的一萬小時是每個希望成為精益踐行者必須經歷的磨練。“著眼長遠”這一精益的另一基本原則送給還在堅持的同學們。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
