做一個移動互聯網的項目，其很重要的一點就是快速迭代、快速更新，在江湖上有人稱爲“互聯網思維”，且不說這個觀點是不是在任何情況下是否正確，當一個產品經理看着競爭對手在“互聯網思維”的指導不斷地增加新功能時，能不慌張麼？
所以常常會出現“軍備競賽的”的局面，今天你增加個功能，明天我再來個功能或者是爲了增加功能而增加功能，一旦出現這種死循環的局面，其實最爲危險的是開發團隊。
我已經看到過不少這樣的案例了，產品經理爲了趕功能，程序員開始無休止的堆代碼，中間根本沒有多少時間停下來進行代碼重構和調整，隨着功能的進一步增多，爲了照顧以前糟糕的邏輯，不斷在代碼上進行妥協和讓步，慢慢的讓整個代碼架構越來越糟糕，直到有一天出現了代碼的萬劫不復，整個項目無法進行下去了，只好全部停止增加新功能，然後整個重新寫代碼，移動互聯網的迭代不等人，這一停下來，也許就是大大的落後甚至是死亡。
當然這一切在直覺上都可以怪罪到程序員的身上，誰讓你不一開始就寫個超牛逼的架構呢？就說程序員苦逼呢，背了黑鍋也沒有太多的理由反駁。
這一切其實產品管理至少也是有着不可推卸的責任的，爲什麼不給開發團隊一段調整的時間呢？改改遺留的問題，調整程序的架構，這些調整的時間其實也不需要很長，只要在一個產品的週期類階段性的做下去就好了，每次的調整也不需要是整個的調整，可以一部分一部分的來。
後面你會發現驚人的效果的，你的產品按照自己的節奏穩步前進，而競爭對手開始可能看起來很快，後面慢慢可能就不行了。
突然想到了以前看過的一場馬拉松賽跑，有個運動員在開始的時候就發力，甩開大部隊很遠跑了前半程，在後半程由於體力消耗過大慢慢的就不行了，最後被大部隊甩到了九霄之外。
不掉隊，保持自己的節奏，很多時候結果還是要看後半程的。
====
我的微博：@最牛傻蛋 微信訂閱號：niudan8