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