ITSM_V1.0_敏捷回顾

转换是我们自己内部套用混流生产的说法，总装线上换装另一个产品时所要做的工作。

如果项目组不停的换业务领域，无法达到业务的成熟，会导致业务分析这个环节的成本高居不下，不停的进行试错和修正，后续的开发环节也会不停的变，导致成本仍然降不下来。精益里面的7种浪费，套用在软件开发上，我觉得很大一部分都是由于业务不成熟这个原因造成的。

我一直认为核心环节首先是业务分析，这块越成熟，后续环节就越容易控制成本。

业务怎么敏捷，我真不知道。

如果在技术上能够让开发组面对变更的时候，对系统的结构性改动不大，可以得到控制，那么我觉得这块就非常厉害了，敏捷现在在这块能够提供一些有益的思路，重点是配置管理上，仅此而已。

对于项目组的业务功能团队来说，拥抱变化就是一场灾难，从这里出去的一点点变化将会被后续的环节逐级放大，所以需求的控制是最重要的。这块没有什么技术手段，完全是靠人的业务经验积累。

一些强势的公司，会将业务不成熟的试错成本转嫁给用户身上，通过合同来保护自己的利益，他们可以拥抱变化，也不怕业务需求怎么去变，但是这样的公司是少数，绝大部分公司是不可能做到这一点的，用户签合同怎样，需求确认签字怎样，要你改你敢不改？也就在喝酒的时候，跟用户诉苦，用户表示理解而已，谁要你不懂业务呢，所以还是老实点吧。

一蓑烟雨任平生说得很有道理。

业务应该敏捷吗？我觉得业务不应该敏捷，好的业务分析师应该能够站在比用户更高的层次来分析业务。那么你必须比用户更懂业务。

如果连业务都不是很熟悉，或者说业务知识没有达到用户的高度，那么必然会产生返工，这个时候拥抱变化也是一种浪费。

用户虽然很懂业务，但是要想将业务转化成产品，用户不擅长，或者说用户也不会考虑很多的附加因素（如引申需求），不懂业务就会跟着用户走，用户今天看到第一个迭代成果，觉得不合适，或者当初没想全面，让你修改，ok，继续迭代下一个版本，那么第一个版本就未产生任何价值造成浪费。

敏捷注重的是不返工，而不是快速返工！

是不是可以结合你的ITSM_V1.0一个典型实战来具体探讨一下，比如用户让你管理cvs，并能根据各种情况进行预警。在你设计的体系里怎么应对这种变化？