有一部分996竟然是這樣產生的
摘要：
大約在10年以前，我跳槽到了一家上市公司。該公司當時在IT行業說不上是大名鼎鼎，但也算有名有號那個水準的。
很快，我很失望的發現，大型上市公司的軟體開發團隊軟體工程和專案管理的水平竟然是這樣的：
在立項之初，專案經理就被要求【編制】一份非常詳細的專案進度計劃提交給客戶方和專案...
大約在10年以前，我跳槽到了一家上市公司。該公司當時在IT行業說不上是大名鼎鼎，但也算有名有號那個水準的。
很快，我很失望的發現，大型上市公司的軟體開發團隊軟體工程和專案管理的水平竟然是這樣的：
- 在立項之初，專案經理就被要求【編制】一份非常詳細的專案進度計劃提交給客戶方和專案管理辦公室。詳細到什麼程度呢？一個週期半年的專案，被要求任務分解至少要有一兩千行吧……所以，專案經理處理這樣的專案計劃的方式就的確是【編制】；
- 我曾經要求專案組的需求分析人員（對於現在的年輕人來講，可以理解成“產品經理”）在系統分析階段就需要給出系統原型圖（線框圖）的設計，沒想到居然引起了一番有諸多高手參加的廣泛的討論：系統原型設計應該在分析階段完成還是在系統設計（現在年輕的開發人員可能不清楚，那個時候系統設計指的是技術和架構層面的設計了）階段完成？
- 有一個專案團隊大約80人，專案經理的專案計劃中向公司申請15名專職的測試人員（包括3名測試經理）；結果被部門經理給拒絕了（事業部經理親口講：讓程式設計師自己測測就行了），最終配給專案組2名實習生作為測試人員；
- 資深的技術經理們寫出來的分析文件格式五花八門，各自有各自認為最好的表達方式，就是基本上沒有人使用用例分析的方法來表達；
- 大的軟體部門中，一共有3個比較大的團隊是大領導分別從不同的軟體公司挖過來的，因此山頭林立……
- 為了讓客戶覺得合同金額是值得的，因此組建大規模的軟體團隊常住客戶現場（所以必須配備相當比例的初級開發人員）；為了讓客戶覺得合同金額是值得的，因此實行制度化的996；
- 專案的驗收和收款不是靠按時保質的提交專案成果，而是靠讓使用者覺得開發人員實在太辛苦了，實在不忍心不付款了……（這麼說真的一點都不誇張）
奇怪的是，這樣的環境下，自然有人在各種抱怨，但就是沒有人試圖去發起改變。（當然，後來我知道了，為什麼沒有人想去改變）
當然，哪個公司都一樣，自然有一小部分老員工都成精了。
但是，對於剛剛畢業的畢業生來講就不一樣了，這是一群沒怎麼見過世面但是可塑性又非常強的人。
想一下，他們剛剛參加工作就進入了這樣的環境進行軟體開發工作。然後他們中大部分就會自然而然的認為：軟體開發這個工種就是這樣子的……然後慢慢形成思維習慣……（所以，那些有能力的應屆畢業生們，找工作要小心哈。）
當我給大家介紹，軟體開發專案可以按時提交、可以不加班、可以保證質量的時候，大家看我的眼神……我基本上可以猜出來他們在想什麼：這個大忽悠。
這真的還不是個例，基本上可以稱作是普遍現象。（多年之後，老同事們聚會，基本上大家都會感慨：能有當初我們的團隊的軟體開發管理水準的國內公司，少之又少，不論大小。）
10年過去了，他們中的一部分人可能已經成為老闆了吧，然後你就會看到，這些新興的企業正在實行【非常正常】的996工作制。