有一部分996竟然是这样产生的

大约在 10 年以前，我跳槽到了一家上市公司。该公司当时在 IT 行业说不上是大名鼎鼎，但也算有名有号那个水准的。

很快，我很失望的发现，大型上市公司的软件开发团队软件工程和项目管理的水平竟然是这样的：

1. 在立项之初，项目经理就被要求【编制】一份非常详细的项目进度计划提交给客户方和项目管理办公室。详细到什么程度呢？一个周期半年的项目，被要求任务分解至少要有一两千行吧……所以，项目经理处理这样的项目计划的方式就的确是【编制】；
2. 我曾经要求项目组的需求分析人员（对于现在的年轻人来讲，可以理解成“产品经理”）在系统分析阶段就需要给出系统原型图（线框图）的设计，没想到居然引起了一番有诸多高手参加的广泛的讨论：系统原型设计应该在分析阶段完成还是在系统设计（现在年轻的开发人员可能不清楚，那个时候系统设计指的是技术和架构层面的设计了）阶段完成？
3. 有一个项目团队大约 80 人，项目经理的项目计划中向公司申请 15 名专职的测试人员（包括 3 名测试经理）；结果被部门经理给拒绝了（事业部经理亲口讲：让程序员自己测测就行了），最终配给项目组 2 名实习生作为测试人员；
4. 资深的技术经理们写出来的分析文档格式五花八门，各自有各自认为最好的表达方式，就是基本上没有人使用用例分析的方法来表达；
5. 大的软件部门中，一共有 3 个比较大的团队是大领导分别从不同的软件公司挖过来的，因此山头林立……
6. 为了让客户觉得合同金额是值得的，因此组建大规模的软件团队常住客户现场（所以必须配备相当比例的初级开发人员）；为了让客户觉得合同金额是值得的，因此实行制度化的 996；
7. 项目的验收和收款不是靠按时保质的提交项目成果，而是靠让用户觉得开发人员实在太辛苦了，实在不忍心不付款了……（这么说真的一点都不夸张）

奇怪的是，这样的环境下，自然有人在各种抱怨，但就是没有人试图去发起改变。（当然，后来我知道了，为什么没有人想去改变）

当然，哪个公司都一样，自然有一小部分老员工都成精了。

但是，对于刚刚毕业的毕业生来讲就不一样了，这是一群没怎么见过世面但是可塑性又非常强的人。

想一下，他们刚刚参加工作就进入了这样的环境进行软件开发工作。然后他们中大部分就会自然而然的认为：软件开发这个工种就是这样子的……然后慢慢形成思维习惯……（所以，那些有能力的应届毕业生们，找工作要小心哈。）

当我给大家介绍，软件开发项目可以按时提交、可以不加班、可以保证质量的时候，大家看我的眼神……我基本上可以猜出来他们在想什么：这个大忽悠。

这真的还不是个例，基本上可以称作是普遍现象。（多年之后，老同事们聚会，基本上大家都会感慨：能有当初我们的团队的软件开发管理水准的国内公司，少之又少，不论大小。​）

10 年过去了，他们中的一部分人可能已经成为老板了吧，然后你就会看到，这些新兴的企业正在实行【非常正常】的 996 工作制。