工作996，生病ICU！996的起源分析

最近996的話題很火啊，網上似乎有兩種聲音，一方是老闆及吃瓜群眾黨，一幫程式設計師黨。老闆們的意思無非是，你們這幫菜鳥、弱B、老油條，不想拼命幹活就能賺錢？覺得不好可以滾啊！吃瓜群眾們紛紛表示贊同，不想幹可以自己屈膝抱頭重心前傾獲得動量。程式設計師們的意思，也無非是資本家壓迫勞動人民啦！無產階級要站起來啊！這一類的表達。


不過，似乎沒有人對996的工作內容去仔細的分析一下，到底是什麼造成了這麼長的工作時間。在本人寫了二十年程式碼的過程裡，也不乏大量的加班時間，回頭看來，加班所做的事情，無非是幾類：

• 學習
• 修Bug
• 拼命堆功能趕工期
• 發版本
• 白天開會/打雜/各種溝通，晚上幹活
  

我們可以自信來分析一下這5種情況。

首先是“學習”這種情況，因為專案需要用到一些還沒掌握的技術，所以需要儘快學習掌握，這種情況對於畢業生或者經驗較少的程式設計師來說，是最常見的。但是即便是有多年經驗的程式設計師，要涉及一個不同的技術體系，也是需要時間去學習的，只不過老鳥們的學習速度往往會比新手更快。我們往往說，老程式設計師頭腦僵化，學習能力下降，但實際情況是，老程式設計師們的掌握速度往往會比新程式設計師更快，只不過有時候新程式設計師有時候會比較莽撞的就開始動手寫東西做產品，所以看起來好像速度很快。當然這也不排除老程式設計師不願意走出舒適區，或者是評價者對老程式設計師的期望比新手要高的原因。對於這種情況的加班，我相信有上進心的程式設計師都是應該願意付出的。對於需要提高技術水平的加班時間，我也認可這是一種奮鬥必須的代價，不付出當然就沒有回報。

第二種情況，修bug。這個問題應該細緻點來分析，有一些bug，是由於自己學藝不精寫下來的，對於這種情況，本質上和第一種是一樣的，是一種學習。這也是進步必須要付出的代價。還有一些bug，其實是一種技術債務，由於早期的設計缺陷，或者追求短期利益導致的。對於這種情況，從本質上說也是技術人員自己所必須克服的。當然，有很多時候，程式設計師會說，進度壓太緊啦，不可能不欠技術債務啦……這確實也是實話，但是無可否認的是，對於一個注重開發效率，軟體工程知識熟練的程式設計師來說，是能把這類問題解決的更好的。我是常常會發現，身邊很多程式設計師只在意演算法，作業系統底層知識，執行效能這方面的知識，而極度忽視軟體工程類知識的學習和實踐，導致自己給自己挖了大量的坑而不自知。所以我認為修bug導致加班這件事背後，還是程式設計師自己的原因多一些，但解決方案卻不是安排更多人力和加班時間，而是徹底的扭轉自己的技術價值觀。

第三種情況，趕工期。這個加班的鍋，我覺得程式設計師和需求人員應該各背一半。軟體開發的最大矛盾，就是不明確不穩定的需求，和落後的軟體開發效率之間的矛盾。這個問題有兩個方向的解決方案，一個方案是儘量提高開發效率。今年來流行的敏捷、持續整合、DevOps，還有各種新的語言、框架、模式，都是為了提高開發效率。我們的程式設計師有多少人是真心擁抱這些技術呢？還是僅僅沉浸在固步自封的熟練技術裡重複解決問題？當然，另外一個方向，就是要有高質量的軟體需求。我也常見，一些不負責任的需求方，因為自己受到巨大的市場壓力，而放棄了自己思考的能力，妄圖通過不停的抄襲競爭對手來增強自己的產品實力；又或者沒有仔細的考慮開發成本，隨意提出需求，然後再開發完成後又隨意推翻，僅僅是因為自己缺乏足夠的鑑別能力和想象力，讓整個開發團隊的工作量浪費在自己無盡的試錯上。我就所見，大量的產品特性，在開發出來後，根本沒有給使用者試用過，就被產品人員以自己的喜好草率的推翻，這種情況，越是在大公司裡面越常見，殊不知這才是對造成的老闆最大損失。從這個角度說，造成996就是一種很不負責任，並且不人道的做法。如果這叫做奮鬥，只不過是浪費老闆的投資，浪費同事的生命。

第四種情況，發版本。專業術語叫做系統整合，由於網際網路產品的版本週期快，所以這種整合頻率會越來越高。針對這個問題，在“持續整合”這個熱門的話題裡，業界已經有普遍的討論。但是我們還有很多團隊並不能使用這些現成的經驗，原因是“太忙了所以沒空搞”。大家都知道磨刀不誤砍柴工，但是在軟體開發領域，偏偏就是很多人都不願意磨刀。這裡有我們的行業專業水平底的原因，也有因為我國對於勞動者權益缺乏保護的原因。由於可以無限制的要求加班，所以自然降低了提高工具，採用新技術的需求。長期來看這並不是好事。我最擔心的就是，大量的公司管理者，都認為996是天經地義的，有事就加班，不去考慮提高開發效率，不去更新勞動工具。最常見的錯誤，就是給程式設計師配備落後緩慢的開發電腦，顯示器都不捨得配個大的，這種做法真是愚蠢之至。所以發版本加班這個事，看起來是程式設計師的鍋，但實際上是管理者的鍋。發版本的加班，是因為平時缺乏專案管理體制，沒有自動化測試，整合工具手工落後....等等一系列管理失敗，最終造成了996。

第五種情況，白天打雜（摸魚），晚上幹活。曾幾何時，我也覺得晚上安靜，最合適寫程式了。但是如果白天能有足夠安靜的環境，生物鐘還是更適合在白天工作的。很多996的團隊，基本上在太陽下山前，是沒有多少真正產出的，原因有很多，歸結起來一條，就是：上若好之，下必甚焉。除了一些老闆喜歡用工作時長來判斷員工的產出，還有一些原因是，老闆本身就拿開會當成工作的主要工作形式——有一些管理者，自己缺乏主動學習的意願，更希望讓下屬把情報和知識“嚼爛了餵給自己”，所以各種彙報會議就層出不窮。正常的討論型會議，應該是會前就同步完資訊，會上直接開始討論預定的，需要選擇決策的問題。但是太多的會議沉浸在輪流彙報，同步資訊上，這就直接造成了白天的會議佔用太多時間，要幹活只好放到晚上了。

回過頭來看996這個話題，我漸漸覺得並不是一個簡單的問題。如果996是基於自我的選擇，那這個並不值得關注，如果是被迫的996，可能並不能幫助專案的成功。我們要消滅不是996，而是消滅低效的開發過程和落後的價值觀。


原文：https://mp.weixin.qq.com/s/SE--4Zg9oO8R11m9jD2X0Q