有一部分996竟然是這樣產生的

大約在10年以前，我跳槽到了一家上市公司。該公司當時在IT行業說不上是大名鼎鼎，但也算有名有號那個水準的。

很快，我很失望的發現，大型上市公司的軟體開發團隊軟體工程和項目管理的水平竟然是這樣的：

1. 在立項之初，項目經理就被要求【編製】一份非常詳細的項目進度計劃提交給客戶方和項目管理辦公室。詳細到什麼程度呢？一個周期半年的項目，被要求任務分解至少要有一兩千行吧……所以，項目經理處理這樣的項目計劃的方式就的確是【編製】；
2. 我曾經要求項目組的需求分析人員（對於現在的年輕人來講，可以理解成「產品經理」）在系統分析階段就需要給出系統原型圖（線框圖）的設計，沒想到居然引起了一番有諸多高手參加的廣泛的討論：系統原型設計應該在分析階段完成還是在系統設計（現在年輕的開發人員可能不清楚，那個時候系統設計指的是技術和架構層面的設計了）階段完成？
3. 有一個項目團隊大約80人，項目經理的項目計劃中向公司申請15名專職的測試人員（包括3名測試經理）；結果被部門經理給拒絕了（事業部經理親口講：讓程序員自己測測就行了?），最終配給項目組2名實習生作為測試人員；
4. 資深的技術經理們寫出來的分析文檔格式五花八門，各自有各自認為最好的表達方式，就是基本上沒有人使用用例分析的方法來表達；
5. 大的軟體部門中，一共有3個比較大的團隊是大領導分別從不同的軟體公司挖過來的，因此山頭林立……
6. 為了讓客戶覺得合同金額是值得的，因此組建大規模的軟體團隊常住客戶現場（所以必須配備相當比例的初級開發人員）；為了讓客戶覺得合同金額是值得的，因此實行制度化的996；
7. 項目的驗收和收款不是靠按時保質的提交項目成果，而是靠讓用戶覺得開發人員實在太辛苦了，實在不忍心不付款了……（這麼說真的一點都不誇張）

奇怪的是，這樣的環境下，自然有人在各種抱怨，但就是沒有人試圖去發起改變。（當然，後來我知道了，為什麼沒有人想去改變）

當然，哪個公司都一樣，自然有一小部分老員工都成精了。

但是，對於剛剛畢業的畢業生來講就不一樣了，這是一群沒怎麼見過世面但是可塑性又非常強的人。

想一下，他們剛剛參加工作就進入了這樣的環境進行軟體開發工作。然後他們中大部分就會自然而然的認為：軟體開發這個工種就是這樣子的……然後慢慢形成思維習慣……

當我給大家介紹，軟體開發項目可以按時提交、可以不加班、可以保證質量的時候，大家看我的眼神……我基本上可以猜出來他們在想什麼：這個大忽悠。

這真的還不是個例，基本上可以稱作是普遍現象。

10年過去了，他們中的一部分人可能已經成為老闆了吧，然後你就會看到，這些新興的企業正在實行【非常正常】的996工作制。