996是个客观存在的现象。存在即合理的理论，并不是说996是合理的，而是暗示我们，造成996这个现象一定存在一个合乎逻辑的链条。因此如果仅仅是简单粗暴的去抵制996，或者用最直观的第一感受去解决996，那么我们其实无法找到996这个问题的最优解。因为这个现象背后的合理逻辑如果没有被打破，那么任何措施都将是治标不治本。其结果要么是效果不佳，要么就是严重影响社会生产效率。所以除非我们已经到了别无选择的境地，那么花点时间认真探究特定现象背后的逻辑，然后找出人类进步的方向才是真正的技术工作者以及管理工作者所应该做的事情。
头痛医头，脚痛医脚。大家都知道这句话不是褒义。不去深入分析客户需求是做不好软件产品的，身为软件行业的你一定表示赞同。所以当用户说口渴的时候，给他一杯水真的是最佳方案吗？
拒绝超时加班，欢迎955应该是一个目标，一个愿景。但这不应该是一个手段。通过妖魔化996公司及其产品，除了能降低社会生产效率以外，并不会带来太多意义。当促使996诞生的强大内在因素及其逻辑链条没有被打破之前，社会最终的形态大概率是多次博弈后的纳什均衡。任何试图打破纳什均衡的行为，本质上都是降低社会整体效率，或者提升交易成本的。
模拟一个最简单的博弈结果。假设目前所有程序员的报酬总额为A，而所有工作时间的总和为B，则现有单位小时工资为 C=A/B。
那么当严格执行955，并且严格支付加班工资后，资本家最简单的做法就是降低单位小时工资。其整体结果大致就是会进一步增加软件工程管理的复杂度，提高项目经理的工资。然后降低大部分不处于超时加班状态码农的收入，提升部分无法逃避996工作状态的人群的收入。
所以，这个结果我认为不是一个理想的结果。至少，当我认为有更好的解决方案的时候，我对直接简单粗暴逃离996表示反对。
本项目将作为一个长期项目存在。致力于在软件开发领域，通过技术手段，对现有软件开发的整体流程进行再造。用软件技术人员的知识，对软件行业本身的业务流程进行再造。通过重新定义软件需求分析师、项目经理、测试经理、开发经理以及广大码农的工作内容和工作方式，努力提高常见商业软件开发效率，缩短开发迭代时间，最终在部分领域从根本上解决996现象。
人类社会日益增长的软件开发与运维的需求，与现有的软件人才储备、培训，现有的软件开发模式、运维模式之间的矛盾。
通过压制软件开发与运维需求，降低社会效率来化解问题不是首选方案。如何提高软件从业人员的能力，提升运维能力才是解决矛盾的真正痛点
整个加班的成因非常复杂，覆盖的面也很广。目前我只能针对其中一部分进行因果分析以及核心成因梳理。非常希望在其他相关领域经验丰富的你能贡献更多有意义的**。
我认为最大的问题在于软件开发行业的经验积累太差劲了。最近几年在持续集成和云平台上所收获的进步，快要被榨干了。而最广大一线的码农们，你们的经验积累和前辈们有多大的区别？似乎和几十年前完全一样，毕业后从某个项目开始，慢慢自己积累经验。熬多少年后自己带人，慢慢成为XX经理。但是即便是经理，也同样是从头学起。软件开发这个行业，不像数学物理那样，隔多少年后，教科书上总会多一些理论出来。后面的学习者可以快速站在巨人的肩膀上。从这个角度出发，软件行业不是一个科学性很强的行业。更像一个手工艺作坊。师傅徒弟言传身教的模式。
这个模式本身不是什么问题。而当**进入21世界，当**的移动互联网规模飞速发展，当人类社会信息化程度越来越深入。对于软件开发的需求就快速释放了出来。而原有的软件行业的模式与整体的软件开发运维需求之间的不匹配才是造成超时加班的核心问题。
但是很明显，学习一门新语言、一个新框架、一个新技术栈无论如何是要时间的。新人成为有经验的熟手甚至大牛总是需要一个过程的。另一方面，当有限的时间内要完成大量的工作，通过增加团队规模并不是永远能解决问题的。这就意味着在上述两个方面，现有的行业模式都遇到了一定的瓶颈，解决问题的钥匙里，一定有一把叫做流程革命。
请移步git wiki(暂缺)
欢迎所有认同本项目愿景，或者有强烈意愿推动软件工程管理模式的朋友一起努力