沒有永恆的東西，即使是那個我爲之開發了3年的App 影秀城。影秀城是集團所建的商業綜合體，這個App就是與之配套的移動互聯網平臺。
功能涵蓋了：優惠券，套餐券，自定義套餐券，活動專題，商戶動態，商家展示，超市掃碼購物，停車場支付，停車場導航，室內導航，會員積分，預充值消費，收藏；以及支持運營的相關工具，掃碼掉寶，定時搶，免費搶，人手禮物，動態換膚，首頁動態運營內容配置；再加上很多零碎的頁面共110張。再算上之前用戶可以發影秀圈的功能，甚至還有個小遊戲頁面，那就頁面更多了。之中我們還進行過2次大改版和2次小改版。這個App還有個難點，對接了相當多系統：超市erp，商城erp，停車場系統，還有室內導航系統。
說這麼多無非就想，我們是非常高效的小團隊。至於產品好不好，大家可以下載看看。 哈哈...
這裏回想和記錄下技術團隊在App開發中走過的4個認知階段。
第一階段 App必須忠實貫徹UI稿和產品需求
記得第一次迭代出來，被我家產品經理好好數落了下。這個UI不對，那個UI不對；這個需求不是這樣的，那個也不是這樣的。當時很不服氣，不就差一點點，至於嘛。畢竟證據在那裏，確實不一致，那就回爐再修改過。第一次回爐花了好幾天時間，重新看需求，重新對UI，基本花了一個迭代的時間。而且回爐實在太痛苦了。重新修改後確實看起來順眼多了。這時才深刻的理解到，開發人員必須忠實實現產品需求、嚴格重現UI稿。
之後的開發，我們都會先理解產品需求，在做的過程中嚴格按照UI稿進行佈局；（這也是專業和非專業的區別）之後幾經人員更迭，發現每次新人進來還是不會尊重產品需求和UI稿，看來這開發人員的通病了。
幾個好的實踐：
1，產品介紹完需求後，開發人員再重述一遍。
2，早期用Markman量取位置，很不好用。後來設計師改用了Sketch。
3，發明了一個簡單有效覈對UI的方式：把設計稿放到iPhone 6上，同時在另個iPhone 6上運行開發好的App；這樣放一起，非常容易發現不一致的地方。
4，交付前針對產品原型過一遍頁面，確定需求都已滿足。
第二階段 加強App對於細節的處理
什麼算是細節？
1，比方頁面加載過程中需要顯示個loading框，而不是一張空白頁面。
2，什麼時候顯示獨佔框，什麼時候顯示非獨佔框。
3，加載頁面在不同出錯情況下，出現不同佔位圖。
4，在轉場、用戶點擊時的動畫效果。。。
這裏很多細節不是來自產品經理的要求，而是開發人員開始帶有產品思維，去思考自己App的不足。所以很多細節的加強是開發自己加上的。有了細節，App看上去會更細膩。這也是大廠App和小廠App的差別。
第三階段 運營工具化&常態化
當App正式上線後，發現運營團隊總是有各種多變需求。
1，比方而且每次節日，活動還不同，所以我們做了一個通用的掃碼掉寶入口。用戶在現場拿出手機掃碼，具體結果就看每次配置的活動了。
2，活動頁面不同，需要各種樣式，各種內容，各種順序。所以開發了運營可定製的頁面。
3，節日換膚：每次節日都要上個換膚版本就太痛苦了；做了個動態換膚功能。
4，首頁banner頁面動態配置：這個動態真的是非常動態，我們用了混合開發。內容、樣式、排放格式都是在後臺按網頁方式配置。完全可以隨心所欲。
第四階段 更加快速響應產品和運營需求
這是去年主要做的事情。也就是我在之前文章裏寫的：組件化、頁面按MVVM方式搭建、頁面路由可配、公用下沉。
總結
看過太多吐槽產品經理的問題，也聽過很多開發團隊吐槽產品經理和運營團隊的話。但在我們這裏技術、產品、運營大家關係非常融洽，每個團隊心裏想的都是一件事 - 如何把App做好，把用戶服務好。
在商業綜合體業務方向專研了3年，歡迎大家找我交流。