對員工寬容的公司，都死掉了嗎？

如何評價文章《對員工寬容的公司，都死掉了》？

最近在知乎上看到一篇文章，引發熱議，說的是對員工是否需要寬容的問題，這裡結合一些想法，說兩句。

先來看一個對員工寬容的例子，當然除了Google以外，Google所有人都知道了嘛：

讓594名員工在全世界57個國家遠程辦公,也許這就是未來的公司應該有的樣子

這篇文章裡面有一段話寫得非常好，摘抄如下：

他認為目前大部分公司的管理模式，都來自於上世紀由大型財閥主導創立的商學院（例如哈佛商學院，沃頓等），這套管理體系主要服務於製造業，銀行業和基礎建設等傳統行業，其主要特點就是企業以職業經理人為中心，而這些企業所涉及的工作也大多是重複性的勞動工作。而在互聯網時代，由於慣性原因，這樣的管理體系被大部分公司沿襲下來，但是逐漸體現出了它的缺陷和對知識經濟時代的不適應性，浪費生命的通勤，少得可憐的帶薪假期，沒有節制的加班，都是這種不適應性的直接體現，特別是對於創造者們（程序員，寫作者，設計師）而言，這樣的管理制度成為了扼殺他們創造力和效率的罪魁禍首。

同時呢，我也想到了這篇文章：

圓胖腫：如何看待「機器學習不需要數學，很多演算法封裝好了，調個包就行」這種說法？

我的回答：

讀書時候的事，同樣用java，有一次我給老師發郵件，說，這個作業數據的size是不是太小了？我寫的代碼大概42s多一點就搞定了，老師回郵件說，真的嗎？別人都說size太大了，你把你的程序發給我看看，我就發了，然後老師回復說，的確，下次搞大點

然後第二天，我上課見到同學，同學說，哎呀，這個size太大了，我寫的程序，跑了一個晚上都沒跑完，我說哈？

後來看了下，她是暴力解，複雜度是n^3，俺用了hashcode的amortized constant的複雜度

現在越來越反對各種框架啊，引擎啊，把人都變笨了

另外一個例子，我們在Vert.x群里討論，招人應該招什麼樣的人，一部分人認為，應該流程化招聘，招螺絲釘，另外一部分人認為，人不宜多，人貴精不貴多，招一個腦子好用的，可以頂三個以上搞體力勞動的；但是現在軟體開發，很多環節都流程化了，對於很多需求來說，不需要知道什麼複雜度，不需要知道網路，不需要知道線程和進程，只需要知道if else for loop，就能開始碼代碼了，這是好事還是壞事，暫且不表，反正存在即合理，那我們可以看到技術發展有兩種走向：

1. 一種是以JEE，Spring等框架為代表的流程化工序化開發方式；
2. 另外一種是以Devops，全棧，Agile，Vert.x等為代表的全能開發方式。

後者顯然對於開發人員要求更高，在後者的開發方式下，要求一個人什麼都要會，不會就去學，不要找理由找借口，搞不定可能就會被滾蛋，比如Netflix就是這種搞法，我說的是文化，Netflix的Java代碼中還是有比較多JEE的成份，但是也在逐步降低，隨著RxJava等的引入。

而對於前者，要求顯然偏低，說到底，什麼都不懂的技術人員，培訓一下，一樣可以做到貢獻代碼，這是完全可能的，我們可以在面試過程中遇到大量基礎極為不牢固的開發人員。

值得注意的是，這兩種文化和走向，是Mutually exclusive滴，用群里上海-H君的話說就是：

我覺得吧 團隊是選擇技術的首要標準 不上升到掃不掃天下的高度 一幫相信orm的人聚在一起可以做成事情 一幫不相信orm的人聚在一起也能做成事情 但這兩種人組隊就難干成事情

而我們回到對員工寬容還是不寬容的話題上去，那對員工寬容，是有前提的，這個前提就是：要求寬容的員工，首先自身必需具備有被寬容的資本，說白了，如果一個程序猿，只會死套框架，從管理上說，要求寬容，恐怕不太合適。

為啥？

因為在這個時候，軟體開發是體力勞動，重複性的勞動肯定會使人厭煩，這是人的本性，進而激發出人的惰性，所以體力勞動最大的敵人是人的惰性，如果這個時候採用寬容的文化，只能讓人偷懶，就類似富士康的流水線生產，沒有本質上的區別，所以管理方式和經驗，向富士康取經是比較合理的。

反過來，如果軟體開發是腦力勞動，這個時候可以對員工寬容，管理者設定目標便可，將目標切割，然後由員工獨立完成，工具可以不限，或者說給予一定的自由度，比如用Vert.x，可以有7種語言選擇，員工可以根據自己的喜好，選擇其中一種，比如JS，Java，Groovy，Kotlin，Scala是比較容易被選中，Ruby，Ceylon相對少一點，管理方式適用於結果導向制，在開發中可使用Test Driven方式，上班也不用每天打卡，沒有意義，總之目標明確，實現便可，管理者要做的就是制定戰略，並將戰略目標切割成戰術目標，同時這也對制定戰略者提出了更高的要求，因為曾經的名言：

不要用戰術上的勤奮，去掩蓋戰略上的懶惰

說懶惰其實是委婉的表達了，應該說是戰略上的失誤；

所以對不對員工寬容，也取決於戰略決策者的眼界和能力，如果戰略上錯誤了，不是說要不要用戰術上勤奮不掩蓋的問題，是戰略決策者一定會用戰術上的勤奮去掩蓋戰略上的失誤，坑總要填的嘛。

所謂一將無能，累死三軍，說的可能就是這個道理吧；

當然這個時候，如果管理者願意誠懇認錯，往往容易收到奇效，經驗告訴我，如果管理者誠心認錯，員工往往會無腦滋持老闆，這個時候坑反而更容易填上，當然認錯這種事不在我們的文化中，所以一般這種情況也比較少發生。

最後別搞錯了，不是只有Java有框架，其他語言一樣有各種框架，比如Ruby的ROR。

最後說一下，我們的理想就是做一家真正對員工寬容，而且能夠讓程序猿，設計師，寫作者們都能夠發揮創造力的公司，但是能不能做得到，我們心中也沒底，可能可以，可能不行，we dont know yet, bye