第二个故事让我来给你们讲一个故事：这是关于大概25年前开发的一个系统的故事。它是一个瑞典大公司的重要业务系统。我说这是一个重要业务系统，是因为它处理的业务是公司80%的收入来源。 自打一开始，他们就思考的面面俱到，保留的极详细的文档。他们还制定了一套严格的需求变更规范。他们要求尽量避免这样的系统里的变更，因为风险很大，一旦出错会造成巨大的影响。 公司如此为这种事情担心，以至于他们编写了一系列的措施来预防系统出现问题；所有的代码要经非代码原作者的第二人用伪代码注释一遍。而且测试工作不能由代码的作者来执行。 同样，也制定了各种风险管理措施，来管控软件规格说明书的制定。写规格书的人被分成了几个等级，以此确保在递交给相关IT业务部门前经过层层检查。 很 快25年过去，如今这些编写文档和管控风险的部门仍然在忙碌。这套措施很少出问题，但却效率很低。一个修改从列入计划到提交到产品中大概要30周的时间。 一个想法到正式被写入规格说明书要经过20多个不同级别人的审批。拿着这种说明书的程序员都称自己为“施工人员”，因为他们实际的工作是把伪代码翻译成 COBOL语言。 所有围绕这个系统做的事情都是为了掌控风险和需求变更，把稳定放在第一位。他们认为只要修改就会产生意外。但不幸的是，对于一个业务来说，唯一可能发生的事情就是：改变。而且改变的频率会越来越高。 他们为稳定而优化系统。 我想强调一点，第二个故事里的这种想法的人在生活中不占少数。他们是很优秀的人，但他们却被安排去开发以稳定为第一位的系统。这才是真正的风险。 结论这两个故事让我思考很多：
你优化系统的目标是什么？ |
