反 996 有理：催程序员交代码，写不出好软件( 三 ) _996

哪些会被修复？当然，时间压力并不会导致所有的混乱被忽视。下面我列出的内容，是往往会被修复的。但是，这些被修复的内容给了组织一种虚假的安全感。

很明显，任何错误都会导致软件无法构建这一点之所以值得一提，是因为我见过一些早熟的组织非常注重防止破坏构建，甚至有副总裁威胁要开除任何破坏构建的人，结果是人们直到交付日期前几周才合并到主线上。
非常明显的功能问题即使是时间压力很大的组织，对于可以延迟的明显失效的功能也是有限度的。根据我的经验，这个极限并不像你想象的那么低。
用户界面中的拼写错误
用户界面中错误的营销形象
由于数据输入错误导致的数据损坏有相当多的这类问题被推迟，因为客户可以被告知“不要那样做”，但是，只要修复不会花费太长时间，防止错误数据输入的更改通常还是会获批的。

将高价值的软件项目推到一个任意日期交付，最终的结果将是，产品混乱不堪，公司在市场的声誉因此受损。因为有偿付能力的公司都有一个现有的、稳定的现金牛投资产品组合，因此，只要公司还有资金，并且愿意尝试，就会重复犯下这个错误。这就导致我们目前的情况，即开发新软件的努力以失败而著称。而失败往往是最好的结果，最坏的结果之一是产品获得足够多的采用率，使公司能够保持盈亏平衡，公司被迫维持其产品运行多年，以避免被起诉违约。
预测性规划适用于部署，而非新颖、高价值的软件项目那么，为什么我们一再看到那么多老牌大公司在创造新颖的、有价值的、客户喜爱的产品方面完全失败呢？事实证明，发现新事物所需要的技能与支持和部署已经存在的事物所需要的技能是不同的。将现有的现金牛产品技术用于新产品开发的公司注定要失败。现金牛主要需要部署工作，而部署工作有利于预测性规划，因为可以可靠地计算出一个交付日期。当有精明的客户参与其中，能够对团队的增量进行良好的反馈时，敏捷开发才会有帮助。然而，大多数公司不会让工程团队与客户一起迭代，而且由于大多数成熟的公司都是严重依赖交付日期，所以他们最终将敏捷开发变成了日期 Scrum 模式，由内部的产品负责人来指导构建。

什么是日期 Scrum？这种研发模式的主要区别在于，每天的 Scrum 会议是一个状态和风险管理会议，在这个会议上，团队要反复地重新关注于按特定日期交付。这种模式不利于发现新的、有价值的软件。

创造人们需要和想要的新软件产品是不大可能在一个庞大的工程中全部铺排在甘特图上的。它们之间的差异，可以想象成蚂蚁如何寻找饼干：那些还没找到饼干的蚂蚁会如何四处游荡寻找，而我们都见到，有序排队的蚂蚁找到了饼干！那一队队游荡的蚂蚁正在并行地进行价值尝试，每只蚂蚁的成本相对较低。现在想象一下，如果游荡的蚂蚁群中有一个强有力的领导者，带领它们朝着一个方向前进会怎么样？当你将现金牛技术应用于新产品开发上，你就会得到这样的结果。更糟糕的是，根据我的经验，这些强大的领导者实际上并不知道新的价值在何处。如果一个团队希望创造一些真正新颖的事物，那么根据定义，这一事物的表现形式是未知的，否则它就不算是新事物！当多个团队成员进行有组织的、并行的价值尝试时，发现未知的工作效果会更好，这些尝试可以扩大对以下内容的了解：

客户的需求
最佳技术解决方案（原型制作）
最佳交付方式（网站、应用等）

总之，时间压力会放大新的、高价值的软件产品尝试中的混乱，而要完全摧毁价值并不需要太多的混乱。除了放大混乱以外，时间压力也会抑制发现不好的产品 / 市场契合度，因为团队盲目地、高度专注于那个截止日期。新产品就存在于市场的黑暗空间里。要找到这些新产品，就需要在黑暗的空间里进行无数次低成本的价值尝试，看看有什么可以击中。当这些价值尝试准备好了，并且没有混乱的时候，再去激发这些价值尝试，而不是在达到某个任意的日期的时候！
作者介绍：
具有 20 多年的软件开发经验，国际软件管理研究所（International Institute of Software Management，iiSM.org）主任兼撰稿人。
原文链接：
https://iism.org/article/the-value-destroying-effect-of-arbitrary-date-pressure-on-code-52