技术层——

　　原有的系统在不断的补丁过程中，无法承受快速灵活的应变，必须改版；

　　适应新技术的发展；

　　战略商业层——

　　业务流程的变更，或者说是商业目标的变化、转型；

　　为了延长产品的生命周期；（见：贯穿整个产品生命周期的用户研究一文）

　　上面三方面六点原因，大部分情况下是交织在一起的。基本上一个是被动改版，一个是主动改版。

　　有时候，第一次产品上线后，往往实现的只有80%，剩余的20%是由于各种各样的原因（成本、收益，这一点都讨论到了）而没有实现。在后续发展过程中，这20%的慢慢实现过程，我觉得并不能算作改版，而是有节奏的计划，和原来的产品开发周期是在一起的。

　　有意思的是，大家都比较认同大规模改版的周期是两年。我觉得这又是因公司而异了（当然还有对改版这个概念的理解），特别是和业务类型密切相关。

　　期望达到的目标

　　我为什么把“期望达到的目标”重点提出来，原因是在于沟通。

　　我们在改版开始之前，往往会有一份改版建议书，内容是：1、改哪些东西，2、改过之后的效果，也就是期望达到的目标（注意量化）。

　　这一点谈及的比较少。但另一个问题“改什么”是与此接近的话题，而“改什么”是由上面第一个问题延伸出来的。

　　上面说到的三个层面，基本上代表了三个人群：管理人员及其他涉众、产品设计部门、技术部门。商业层更关注成本和收益，产品设计部门更关注用户需求的满足，技术部门更关注产品技术层面（代码、数据库等）的可扩展性和效率。各自有各自的目标。比较完美的情况下，无论这三者谁发起了改版，就必须将期望达到的目标写清楚，并且告诉另外两者。不然容易使得沟通无效。

　　另外讨论中还提及的是改版与其他涉众之间的关系，比如改版之后，销售部门、客服部门的跟进，培训计划的实施等。这里不再展开。

　　如何改版？

　　在如何改版这个问题上，我觉得没有太多必要展开和深入了。设计流程这个话题，是我最不愿意谈得一个话题。没有最正确，只有最合适。

　　这点基本上就没有太多讨论，因为本身也与新产品设计流程比较接近。继续跑入迭代的设计流程（区别在于，是在原来基础之上），用户研究、信息架构、交互设计、视觉设计、界面制作……

　　改版后的如何测试？

　　对照改版时的“期望达到的目标”，很容易评价出这一次改版的效果。这对战略商业层、设计层、技术层都是一个很好的交代。