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

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

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

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

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

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

可是，对于刚刚毕业的毕业生来说就不同了，这是一群没怎么见过世面可是可塑性又很是强的人。

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

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

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

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