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

整個國內(nèi)的互聯(lián)網(wǎng)行業(yè)，包括頭部的BATJ這幾家巨頭，在研發(fā)管理，業(yè)務(wù)管理方法論上，不是針對誰，在座的都是垃圾。

996怎么會產(chǎn)生的？只是開發(fā)人員不夠資本家不愿投人導(dǎo)致大家整天加班？錯！我們來看一下軟件研發(fā)的過程，其實一個現(xiàn)在很流行的詞就已經(jīng)說明了一切，那就是“碼農(nóng)”，因為所謂的R&D，幾個大廠干的只是D，并非R，R所研究的對象那是在實驗室和大學(xué)里完成的，大廠拿過來只是進(jìn)行商用開發(fā)實現(xiàn)上線。所以其實軟件開發(fā)過程可以類比工廠生產(chǎn)線上的生產(chǎn)，那么最近幾十年現(xiàn)代化大生產(chǎn)最重要的命題是什么？當(dāng)然是精益?。ê竺嫖伊碛衅v精益和敏捷之間的關(guān)系。）那么現(xiàn)在我們的互聯(lián)網(wǎng)軟件整個產(chǎn)品規(guī)劃定義和開發(fā)實現(xiàn)達(dá)到了“精益”的思想了沒有？恐怕離理想狀態(tài)差得很遠(yuǎn)很遠(yuǎn)。

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

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

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

上圖為項目級敏捷流程圖

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

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

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

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

真正的全流程多層級產(chǎn)品級敏捷

這里順便談?wù)劽艚莺途娴臏Y源，其實敏捷的很多概念都出自豐田的精益思想，甚至直接照搬了很多術(shù)語，例如kaizen（改善），Kanban（看板），很容易就看出這些日語漢音詞的出處，核心的概念很簡單，那就是仔細(xì)調(diào)查研究生產(chǎn)過程中的每個步驟和工位，消除生產(chǎn)過程中的瓶頸和浪費(fèi)，從需求到生產(chǎn)運(yùn)輸全流程視角規(guī)劃，生產(chǎn)步驟相互解耦，提高效率，不斷發(fā)現(xiàn)問題，持續(xù)改進(jìn)。

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

一個996背后所顯現(xiàn)出的其實是互聯(lián)網(wǎng)業(yè)快速發(fā)展的后遺癥頗多，管理不善，從來只有粗暴的“管”沒有精細(xì)化的“理”，而且以low為榮，以low為美，一時歪論四起，卻從不知根子還是在管理方法論和執(zhí)行到位否?？磥砘ヂ?lián)網(wǎng)也只有經(jīng)歷過電信設(shè)備業(yè)那種殘酷的大逃殺，才會靜下心來真正想想自己的問題在哪里。