做一个移动互联网的项目，其非常重要的一点就是高速迭代、高速更新，在江湖上有人称为“互联网思维”，且不说这个观点是不是在不论什么情况下是否正确，当一个产品经理看着竞争对手在“互联网思维”的指导不断地添加�新功能时，能不慌张么？
所以经常会出现“军备竞赛的”的局面，今天你添加�个功能，明天我再来个功能或者是为了添加�功能而添加�功能，一旦出现这样的死循环的局面，事实上最为危急的是开发团队。
我已经看到过不少这种案例了，产品经理为了赶功能，程序猿開始无休止的堆代码，中间根本没有多少时间停下来进行代码重构和调整，随着功能的进一步增多，为了照应曾经糟糕的逻辑，不断在代码上进行妥协和让步，慢慢的让整个代码架构越来越糟糕，直到有一天出现了代码的万劫不复，整个项目无法进行下去了，仅仅好所有停止添加�新功能，然后整个又一次写代码，移动互联网的迭代不等人，这一停下来，或许就是大大的落后甚至是死亡。
当然这一切在直觉上都能够怪罪到程序猿的身上，谁让你不一開始就写个超牛逼的架构呢？就说程序猿苦逼呢，背了黑锅也没有太多的理由反驳。
这一切事实上产品管理至少也是有着不可推卸的责任的，为什么不给开发团队一段调整的时间呢？改改遗留的问题，调整程序的架构，这些调整的时间事实上也不须要非常长，仅仅要在一个产品的周期类阶段性的做下去就好了，每次的调整也不须要是整个的调整，能够一部分一部分的来。
后面你会发现惊人的效果的，你的产品依照自己的节奏稳步前进，而竞争对手開始可能看起来非常快，后面慢慢可能就不行了。
突然想到了曾经看过的一场马拉松赛跑，有个运动员在開始的时候就发力，甩开大部队非常远跑了前半程，在后半程因为体力消耗过大慢慢的就不行了，最后被大部队甩到了九霄之外。
不掉队，保持自己的节奏，非常多时候结果还是要看后半程的。
====
我的微博：@最牛傻蛋 微信订阅号：niudan8