在互联网、移动互联网高速发展的当下，我们对于软件交付的周期有着更高的期望。以前以年、季度为单位的交付周期正渐渐被月、天所取代。有人说，只要业务有需求，我们随时可以发布。而这观点正演变成一种标准，成为无数人努力的方向。在这种大趋势下，我们产品（或项目）的交付节奏应该何去何从？是举起持续交付的大旗，追赶面前的先行者；还是独善其身，以不变应万变？我们一起聊聊如何选择合理的交付周期。
在寻找答案的路上，我们先来分析影响交付周期的四种力量。
投放市场周期（time to market）
不同的市场竞争环境对投放市场周期有不同的需求。市场竞争越激烈，对投放的需求越频繁。上周，Chrome挤掉IE占据了浏览器市场的第一份额。在激烈的市场竞争中，IE从出道时的五年一个版本发展到每年一次重大更新，而竞争对手Chrome为了更快的给客户提供新功能，一直保持着以月为单位的交付周期。正是由于Chrome的步步紧逼，IE被迫提速极力挽回正在失去的市场。如果你的产品处于白热化竞争环境，那请参考你的竞争对手制定投放市场周期；反之对于垄断型产品（蓝海市场），你会有更大的自主权。
市场不确定性（uncertainty）
当前的市场环境在内、外部均存在更高的不确定性。迫使我们需要更频繁的通过内、外部来检验我们的产品，减少错上加错的浪费。
从外部业务的角度分析，即使资深的产品经理，也不能在投入市场前100%保证需求的正确性。尤其是面对海量用户的互联网产品，我们很难在调研阶段确定所有用户的每一项诉求。小批量频繁发布使得我们可以根据市场反馈及时调整方向。上面提到的Chrome便是在发布过程中不断调整，甚至在发布中多次删除了上次刚刚上线的功能（例如：15年的某次发布删除了刚上线不久的通知中心）。我们试想一下，如果发布周期延长，通知中心很可能实现更多的后续功能，从而产生更多的浪费。这也体现出收集反馈的重要性，交付周期的提升只是基础，重点还是在于通过收集反馈的验证，以及根据反馈的调整。
从团队内部的角度分析，我们同样希望通过更短的周期进行内部验证，尽早的发现并修复问题。这种诉求正指导着一批敏捷相关的实践。
需求的可拆解性
持续交付需要需求的可拆解性作为保障，我们要确保每次所交付功能对客户的价值。这就是我们常说的最小化可行产品（MVP），正如字面意思描述的，我们在关注需求最小化的同时，还需保证可行性。如果我们的产品是电梯，我们可以用最短的时间交付给客户没有门的原型机，但我相信没有客户原因承担风险进行体验。
成本
如果你听过业界大牛的介绍，相信你一定听说持续交付是种能力，不管你的交付周期如何，你都应该具备这种能力。但这种能力是需要投资的，随着交付周期的缩短，所需的投资也随之提升。例如，当你的交付周期从三个月转变成一个月，你会需要更全面的自动化测试，你会考虑改变你的代码提交策略让代码合并更顺畅，你会考虑部署的自动化实现，而这一切都需要更多的投资。所以，在投资的时请确认你的回报与之匹配。
最后的选择
我们已经了解了影响我们决策的所有因素，那该如何决策呢？首先请先确定需求的可拆解性，这是我们决策的基线。在此基础上我们来看市场不确定性及与之匹配的投放周期。最后，别忘了计算对应交付周期所需的成本。贵的不一定就是好的，还是要找到适合自己的那一款，祝大家找到合适自己的交付节奏。
