重要的是持续优化的过程，最终交付只是作为副产品之一产生，顺水推舟而已。

记得在某个场合，跟仝键有这样大致的对话。

面前一段旅程，从起点出发，往着目标进发。这是每个人都会有的功课。对于组织而言，要有自己的目标，商业盈利还是社会公益，也都无可厚非。但我们多少已经习惯，目标的实现，即等同于定义的成功。全神贯注于目标，并致力于实现它，成为普世意义上唯一衡量是否努力的标准。

但在软件行业，是否存在另外一个可以思考的空间。

软件构建相比较其他行业而言，最大的一个区别莫过于，它是知识消费和创造的过程。从业务诉求和价值定义，所有与此相关的信息在人们的头脑和言语间传递和转换。令人失望的是，除去那些自欺欺人的所谓满意以外，我们并没有足够的经验和能力，能表明我们在这些信息承转之间，获得到了足够的心安理得。需求模棱两可，在过程中反复无常，曾经自以为的目标交付物也可以沦落到谬以千里，触目惊心。

瀑布方法已经被证明一板一眼无法再有面对不确定性的从容。敏捷以适应性和响应性，挺身而出。敏捷之中诸多的原则和实践，是显而易见的改进手段，唾手可得，耍将起来也煞有介事。短时间取得显而易见的效果，本就是理所当然。它们一度填充了人们在恐惧面对不确定性洪流时的安全皮筏。但人们也就此误以为，这就是可以赖以顺流直下的救命稻草。

然后就此认为改进完成，已然敏捷。

如果仅仅是就此原地踏步，也算万事大吉。但无奈怎样都会是事与愿违。敏捷实践的整体性诉求，以及企业组织和文化的惯性，总是很容易让团队的微弱努力顷刻烟消云散。不安全感再度笼罩。

迎难而上的改进，是向不确定性讨要回掌控感的本能。但一如字面意义，持续改进，难的不是改进，而是在持续。

持续二字，既是对改进这件事一如既往的执着态度，也是对不确定性和不安全感出自内心的认可。适时后退一步，并不意味着低头，在后退间反而得到片刻静默，以及观察的机遇。

历经辛苦，找到改进的良药，实属不易。解决了一个技术难题，或者澄清了纠结已久的需求，都是件值得庆贺的事情。当下的事情，都可以某种更明快的节奏往前推进。怎么都被看做一件值得庆贺的事情。但起点（需求）和终点（目标）对于确定性的双重挤压，仍然会将我们置回于似曾相识的失落境地。不再奏效的不只是曾经成功的经验，还有尚未消失殆尽的成就感。

这时候，我们可曾有过妄议，哪怕迈出大胆的一小步，质疑我们开头来的路，以及我们要去的方向。