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

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

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

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

奇怪的是，這樣的環境下，天然有人在各類抱怨，但就是沒有人試圖去發起改變。（固然，後來我知道了，爲何沒有人想去改變）

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

可是，對於剛剛畢業的畢業生來說就不同了，這是一羣沒怎麼見過世面可是可塑性又很是強的人。

想一下，他們剛剛參加工做就進入了這樣的環境進行軟件開發工做。而後他們中大部分就會天然而然的認爲：軟件開發這個工種就是這樣子的……而後慢慢造成思惟習慣……（因此，那些有能力的應屆畢業生們，找工做要當心哈。）

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

這真的還不是個例，基本上能夠稱做是廣泛現象。（多年以後，老同事們聚會，基本上你們都會感慨：能有當初咱們的團隊的軟件開發管理水準的國內公司，少之又少，不論大小。​）

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