最近996這個話題很熱，但各路勢力（資方，勞方）的討論都陷在事業開創時期要不要奮斗，勞動利潤怎么合理分配的這個窠臼下相互扯皮攻擊，其中馬爸爸，qjf都親自下場，或高呼“兄弟們的”奮斗精神，或販賣雞湯，要新人們把996當福報，呵呵呵呵…….我這里先下個結論，便于大家有個大體的概念，然后再來看我后面的東拉西扯，那就是：

整個國內的互聯網行業，包括頭部的BATJ這幾家巨頭，在研發管理，業務管理方法論上，不是針對誰，在座的都是垃圾。

996怎么會產生的？只是開發人員不夠資本家不愿投人導致大家整天加班？錯！我們來看一下軟件研發的過程，其實一個現在很流行的詞就已經說明了一切，那就是“碼農”，因為所謂的R&D，幾個大廠干的只是D，并非R，R所研究的對象那是在實驗室和大學里完成的，大廠拿過來只是進行商用開發實現上線。所以其實軟件開發過程可以類比工廠生產線上的生產，那么最近幾十年現代化大生產最重要的命題是什么？當然是精益！（后面我另有篇幅講精益和敏捷之間的關系。）那么現在我們的互聯網軟件整個產品規劃定義和開發實現達到了“精益”的思想了沒有？恐怕離理想狀態差得很遠很遠。

那么產生996的根源究竟是什么？互聯網軟件的開發一直有一個問題很難解決，就是需求和團隊軟件開發實現產能的矛盾，需求變化太快，經常造成軟件產品規劃定義處于邊開發邊定義，由項目開發替代產品版本開發，定制化需求主導產品開發，多線版本并進開發的狀態。產品部門瞎指揮，大量的無用功，活活累死開發團隊。這種問題恐怕不是多招開發團隊就能解決的，因為誰都知道團隊越大溝通成本越高，到最后增加人手并不能加大產出，效率越來越低，但是客戶需求又放在那里，不響應不行，怎么辦？996！大家加班，加到讓客戶滿意為止，于是996就變成互聯網業不成文的規矩了，老實說，很多大廠996還算客氣的，9117這種也不是沒見過。

那么難道就沒辦法了？誰說的……說這話只能說明互聯網業最近幾年實在是風生水起，錢太多，活太糙，整天只知道風口以及風口的豬和怎么做一只時髦的豬，不知道對整個軟件開發過程精益化….這幫家伙根本就是井底之蛙，不知道其實軟件產品規劃定義開發測試上線這一流程幾十年下來，業界已經發展出一套完善的方法論應對上述棘手的局面。類比一下，現在的互聯網業就跟70年代石油危機來臨時的美國汽車業一樣，不知道可以向生產過程要效益，當一個“豐田”出現時，于是就都投降了…….

有人會說，互聯網有敏捷啊，有極限編程啊，有Jerkins，CD/CI，devops啊，對，互聯網的確在最近10年逐步引入了敏捷，但這種管理的改進始終只局限于產品的開發架構到測試上線階段，對于產品規劃定義階段并無觸及，這樣的結果就是只關注開發測試上線，規劃定義階段跟產品開發脫節，產品團隊跟開發團隊對立（就好比網上那個出名的段子，產品和開發勢同水火，互相視若仇寇），很容易造成多線開發，殊不知拉線容易，收線難，merge branch有多痛苦。你試試在不同的branch上同步相同的feature是何種酸爽的感受……

上圖為項目級敏捷流程圖

曾跟A廠的專有云部門中高層坐談過，他們的痛苦就在于一個產品的開發，可能會涉及到和集團內部大大小小80多個部件平臺協同，每個部件內部開發是敏捷了（少則8-10人團隊，多則百人的大團隊），但相互之間步調永遠不一致，需求的同步相當繁復困難。One track開發，多輪PI迭代按時發布永遠是個夢，平臺級的微服務解耦永遠在路上，CD/CI永遠只是在部件內部，而無法在全解決方案層面實現。

那么到底哪些公司真正掌握了大型軟件的開發方法論并和快速變化的客戶需求相匹配呢？要知道在互聯網之前，一直有一個行業也是大兵團作戰，一個主產品開發動輒全球多個site幾百上千人同步，然后還要應付全球客戶源源不斷變化的需求，那就是IT/電信設備業…..

IBM所開發的傳統IPD流程的確從方法論上解決了如何規劃定義架構設計開發測試驗證上線的完整過程，但這是一個瀑布式產品開發流程，且是一個多部門協同，相互牽制的矩陣模式。很多電信設備商用的大多是這個流程的變體，優點很明顯，但是缺點也很明顯，那就是慢…..一個產品版本從規劃到上市要12-18個月，穩是穩了，但是客戶響應太慢。

電信設備商經過最近20年殘酷的競爭，從業廠家早已從20多年前全球將近2位數的跨國廠商大幅歸并到只剩下三大一小，H/N/E外加一個Z，個中過程的慘烈實在只有業內人士說得明白，外界無法想象。但這個過程也的確逼迫業內廠商積極地改進產品規劃定義開發測試上線全流程，向軟件生產過程要效益，做到軟件生產的“精益化”。諸如H家的IPD流程也已經演進到了OBP模式，N家的SAFe也是從一個全流程視角來協同審視產品規劃開發問題，以可數字化的統計結果指導產品定義決策，而不是領導的拍腦袋。說句良心話，那種被T家所標榜吹噓的微信產品上線開發的“光榮歷史”，那種全公司從pony ma半夜三更拍腦然后一路層層下壓執行的產品規劃定義模式真的很low很low，low爆了好不好，丑沒關系，出來丟人現眼就是你的不對了。

真正的全流程多層級產品級敏捷

這里順便談談敏捷和精益的淵源，其實敏捷的很多概念都出自豐田的精益思想，甚至直接照搬了很多術語，例如kaizen（改善），Kanban（看板），很容易就看出這些日語漢音詞的出處，核心的概念很簡單，那就是仔細調查研究生產過程中的每個步驟和工位，消除生產過程中的瓶頸和浪費，從需求到生產運輸全流程視角規劃，生產步驟相互解耦，提高效率，不斷發現問題，持續改進。

曾經請教過豐田系的精益頂級專家，我問了一個“傻問題”：那就是為什么豐田會去搞精益這種看似吃力不討好的事，對方回答，不要忘記豐田再次起家是什么年代，是二戰后，朝鮮戰爭時期，得到了美軍的大量軍車訂單，那時候物資匱乏，每一顆螺絲每一個零部件都是緊缺資源，你必須仔細規劃生產的每一個步驟，最大限度地利用各種資源，努力消除瓶頸，最大限度提高資源的利用率，絞干毛巾里的最后一滴水！那是刻在豐田骨子里的東西，永遠都抹不掉！

一個996背后所顯現出的其實是互聯網業快速發展的后遺癥頗多，管理不善，從來只有粗暴的“管”沒有精細化的“理”，而且以low為榮，以low為美，一時歪論四起，卻從不知根子還是在管理方法論和執行到位否。看來互聯網也只有經歷過電信設備業那種殘酷的大逃殺，才會靜下心來真正想想自己的問題在哪里。