常见做法是把维护单独列出来
团队通常会给产品排一个功能路线图，再另外排一个维护计划。功能路线图决定做什么，维护计划负责收拾残局。这种分法很自然，但它默认了一件事：维护是可以被推迟、被压缩、被“下个版本一起处理”的。
在操作系统这类产品上，这个默认假设是错的。
维护成本是产品的组成部分
用户长期留在一个系统上，靠的是三件事：老数据还能用、习惯没被推翻、出了问题有人管。这三件事都不在功能列表里，却直接决定产品能不能被用上三年。
把它们当成额外成本，结果就是每次赶进度第一个被砍掉的都是它们；而被砍掉的次数多了，产品就会在某次升级之后失去用户。
我们的做法
兼容与迁移进版本计划。 每个版本的功能项里必须包含对应的迁移方案，没有迁移方案的改动不允许进入版本。
发布之后设观察期。 版本上线后的一段时间内不启动新的功能开发，专心处理这一版暴露出来的问题。
问题响应有人负责到底。 每个方向都有明确的负责人，从问题确认一直跟到修复上线，不转手。
代价与好处
代价是功能推进的速度明显变慢。同样的时间，别人能发三个功能，我们可能只发了一个，还要花时间写迁移。
好处是用户不必在每次升级前犹豫。对我们来说，这种信任比多一个功能重要，因为操作系统是被长期使用的东西，任何一次让用户损失数据的升级，都会抵消掉之前所有的功能积累。