用企业 IT 部门通常使用的生命周期流程设计和制造赛车如何？听起来似乎是个好主意，嗬？不，糟透了，但是脑力激荡一下看看今天的企业 IT 出了什么问题倒是很有趣。首先我们来假设一下，做这件事情有 4 个部门。设计团队（相当于 IT 架构师）、制造团队（研发）、安全团队（安全）以及机械师（运营）。下面我们就来推演一下。

1、设计

　　一项要求提供新赛车的请求得到批准后被直接转交到设计团队手上经办。设计团队然后着手设计一款该公司有史以来最伟大的赛车。他们勤奋工作，采用了业界的最佳实践和通用的设计哲学。与此同时，也在与制造或安全甚至机械团队通力协作，避免其实际的担忧，确保其完美设计的实现可期。他们进行自我评审，并把设计以自认为是最合适的格式打包给制造方，如 Word 或 Visio。紧接着设计团队着手下一个项目。

2、制造

　　制造团队几天前刚把上一辆赛车造好发了出去，正偷得浮生半日闲，然后他们就收到了新的原型设计电子邮件。“TMD”，邮件还没打开大家就一下子炸开锅了。打开邮件后情况变得更加糟糕。“白日做梦”、“过度乐观”、“脱离现实”是他们对设计的评论，但是最常见的结语还是“垃圾”。功能关注点和高级性能指标才是他们要关心的。他们知道管理层关注的汽车主要特征是汽车的最高时速，加速性能以及吸引眼球的东西。对其他的元素没那么关注。安全和可维护性是其中两个关键的要素之一，不过这些东西在制造环节完成之前并不明显。记住，我们是按照 IT 项目的运作方式来造汽车。

3、安全

　　好吧。汽车还是造出来了。可它的样子跟最初的设计已经不怎么相像，但是不管怎么说，制造团队还是按期完成了。安全团队终于还是拿到了他们的输入。结果不算太好。安全问题清单列出了长长的一串，但预算和时间上的限制令他们只能采取减轻而非解决问题的方案。但是汽车在所有重大的安全问题解决之前是不能出厂的，所以有人开始提议通过某些有问题的调整来将问题降低。

4、机械团队

　　好吧，研发到了这里阶段，汽车多少已经变成了一个笑话。大家都在取笑它。不过当然，机械师和车手可没这份闲心。汽车已经交到他们的手上，一度展现给他们的美好前景很快就变得黯淡无光。车子操控起来就像拉着一条狗。时不时熄火罢工。车手为此给它起了个外号，叫会飞的棺材。这个过程听起来似乎很可耻，但是的确是稀松平常。管理层早已宣布项目成功结束。除非有人死没人再会关注。机械团队本来已经列出了一堆改进建议，但却被告知最好束之高阁，通过规避措施来解决问题。

结论

　　如果要用一句话总结的话，那就是问题依旧。企业 IT 团队之间的协作仍然是一个主要问题。虽然敏捷取得了一定的进展，但是其成功往往仅限于功能需求。DevOps 运动的进展表明开发者和运营者这件的关系有所改善。但是这个能否延伸到与其他领域（如架构和安全）的关系改善吗？不尽然。

　　你无法一直都让团队表现出色。但是你可以让他们记录下自己的需求。配置是 IT 各个领域都有的一个元素。像安全和性能这些非功能需求也是可以用配置的方式确定下来的，你得有的放矢。一旦这些需求变得可执行了，也就变得可移植和可实施了，这样你就可以确保开发流程能不断地经受其他团队需求的检验。这样当大家回顾项目的一生时，就不会感慨说太晚来不及改变了。