老翟書摘：從《大野耐一的現場管理》看軟件工程管理

前年，接觸到了《豐田生產方式》，就對大野耐一這我的十分感興趣，就專門找他的書來看。

同時，我一直都有一種「感受」：咱們軟件工程的管理方式都是從傳統工業借鑑的。好比被吹上天的「精益」概念及「看板」概念。然而，這些概念裏，少有人說明這樣地借鑑的理由及借鑑了哪些，放棄了哪些。想回答這個問題就必須分別弄清楚傳統工業和軟件工程的本質。

我嘗試在這本書瞭解一些關於傳統工業的管理概念。如下是書摘：

####「精益」的概念的產生

1990年，美國麻省理工學院的詹姆斯 沃麥克等多位教授，在《改變世界的機器》一書中，首次以「精益生產」（learn production）爲核心介紹豐田生產方式，自此，歐美的一些企業纔開始把豐田生產方式做爲全球化以及提升生產率的標準和尺度。

####領導說服力：坦誠即表明強勁的說服力

要想說服別人或是獲得理解，若沒有什麼根據或道理是行不通的。

不要老是認爲本身的言行沒有錯誤，意識到錯以後就應該爽快地說出來。若是有了這種胸懷，指揮現場以及下屬不就變得垂手可得了嗎？

犯了錯誤以後，應該不吝於向他人甚至的下屬道歉，懷着這樣坦誠的態度，怎麼會沒有說服力呢？

爲了造成強勁的說服力，重要條件之一就是管理者自身應該懷着謙虛的胸襟。

現實生活中，人們彷佛隨着知識愈來愈豐富，產生錯覺的可能性反而越大。

傳統工業也會遇到咱們軟件工程同樣的問題：面對一樣一份工做，存在不一樣的意見。傳統工業時裏的體現多是組裝配件有兩種方式，哪一個效率更高；軟件工程裏的體現是實現某個功能，怎麼實現更快（不要忘了，咱們還要考慮可維護性，可讀性）。當存在不一樣的意見時，雙方容易在無用的爭論上浪費時間，大野耐一是這麼處理的：

在產生兩種意見的狀況下，各給雙方一個工做日的時間，讓他們按照本身的意見試着作一作，最後比較結果，直到讓你們完全理解、贊同爲止。

其實，這樣處理的最大好處是將**「實踐出真理」**的文化慢慢帶入企業。

####要提升生產效率，「意識革命」是首要問題

從上層管理者到中層管理者甚至工做在生產一線的做業員們，因爲你們都是普通人，因此都有可能被禁錮在錯覺之中，認爲現行的作法是最科學的；或者說即便不認爲是最好的，也以爲別無選擇，這就是被常識化了。

咱們軟件行業更是如此，特別是一畢業就只在一家公司待好久的人。很容易被「常識化」，認爲軟件開發就只有一種方式：手工將jar包下載回來，導入到IDE中，而後寫代碼；部署軟件也就是ssh上服務器，而後stop,start。

大野耐一說：

如果不改變從管理頂層到一線做業員以及工會的意識、觀念和想法，那麼怎麼可能探索出作好工做的新方法呢？組織上的改革或許相對容易，可是「意識革命」應該會更加困難一些吧。

再好比不少人認爲寫單元測試會致使進度被拖慢。其實，關於單元測試是否加快進度，須要更多的數據支撐。因此，須要軟件項目管理工具爲咱們提供更全面的統計工具，來收集這些數據。這也說明了軟件行業和傳統工業的一個很大的不一樣。傳統工業中不少工做是重複的（產品一般是批量生產），能夠快速實驗，快速看效果。而軟件行業中，根本沒有批量生產某一軟件的說法。

####無效率的動做不是工做

身爲生產現場的管理者和主管，必須具備分辨「動」和「働」的慧眼，也就是說，必須可以分辨清楚哪些動做是無效率的，哪些動做與工做是無關的。

這裏，對於這個「無效率」的定義會有爭議。我是這樣認爲的，若是不能幫助我寫出可讀、可維護、用戶可用的軟件的動做都是無效率的。好比手動去管理軟件依賴、手動部署、需求溝通須要等上一個星期、新加入團隊的成員須要花兩天的時間搭建開發環境、重複手工測試、單元測試寫在main方法裏、寫代碼過程分心看微博，動彈……

做爲leader，發現這些無效率動做，而後找到改善辦法是一項重中重的工做。

####改善應該按順序進行

所謂做業改善，就是可以讓現有的設備更好地發揮做用。在改善過程當中，首先須要考慮的不是購買設備，而是最佳的工做方法。

我認爲首先須要進行的是做業改善，以後才依次爲設備改善、工序改善，也就是改善應該有前後順序。

軟件行業中，順序應該是軟件開發流程改善，以後依次是實現技術改善、軟件開發工具改善。緣由是軟件開發流程的成本收益率比實現技術改善、軟件開發工具改善更高。這只是個人片面之詞。但願有數據的同窗能幫我證明。

####產品質量問題

若是某個零件比較容易在前幾道工序的時候出現問題，是否是應該考慮將檢驗工做提早呢？提早發現並剔除不良品，總比讓它們一直往下走要好得好多。

品質融於生產過程當中，所以，若是能在必要的地方作好檢驗工做，那麼就沒必要等到工程的最後才發現不良品，或者說到工序的最後階段只須要重點檢驗某些部分便可。

產品質量融於軟件開發過程當中，將風險高的軟件模塊提早開發。QA在功能開發前就參與需求的討論，並提出驗收條件AC。

####下降成本

若是有人問我，爲何要拼命減小庫存、下降成本，我會告訴他，是爲了讓資金週轉更加輕鬆。

然而，只要提到下降成本，你們就會以爲這是財務人員的責任，其實否則，財務人員根本沒法促使成本下降，這隻能經過集體的努力實現。

所以，所謂的下降成本，惟有依靠生產現場來進行，現場的下降成本的意識要作到比鬼還要精才行啊。

減小浪費也能夠下降成本。關鍵是咱們如何看待浪費。在《豐田生產方式》中定義的浪費：

1.過量生產的無效勞動：軟件行業中指在不合適的時候開發多餘的功能
2.窩工的時間浪費
3.搬運的無效勞動：需求溝通不完整，致使重複溝通
4.加工自己的無效勞動和浪費
5.庫存的浪費
6.動做上的無效勞動：花費過多的時候搭建開發環境
7.製造次品的無效勞動和浪費：品質沒有融於生產過程當中

從這裏就能夠看出光靠架構師是不能完全杜絕浪費，更不可能靠財務了。

####小結 這本書給我最大的啓發是：高高在上不接地氣的技術管理是沒法管理好團隊的。高高在上意味着他沒法或很難及時、準確得知開發現場的狀況的。若是你連「施工現場」的狀況都不瞭解，談何改善？

同時，我也發現軟件行業的代碼審查、每日站會就很好的體現了大野耐一的現場管理思想。經過這兩個實踐，咱們的leader纔有更多機會靠近「現場」。這纔是代碼審查、每日站會背後更深層的緣由。

半年後再次重讀這本小書，又知新。

==========

老翟書摘說明

==========

書摘內容徹底來自原書，若是原書的做者或出版商以爲我侵權了。請經過開源中國 @翟志軍 聯繫我。

老翟書摘旨在經過一種書摘的方式讓你們花最少的時間瞭解一本書，從而決定要不要繼續讀下去。書摘的每一本書都是本人親自讀過並理解的。