移動互聯帶來用戶終極體驗為王？
移動互聯網催生軟件開發的思路轉變，要求軟件產品必須站在用戶體驗的角度，遵循“體驗為王”的法則，否則做得再多都是垃圾，耽誤時間和金錢。
如果開發者沒有站在產品用戶體驗的高度，產品經理抓也沒用，因為細節體驗等問題再怎麽測試也有漏網之魚，而很多開發者往往不願面對或者無法面對？
實際上，開發者必須站到客戶第壹線，做“難做”的事情，甚至親自跳到“坑”裏，找到解決疼點的多種方案，並提出不要傾向、客觀和合適的建議。
因為體驗繁雜而想逃脫，就不可能做好開發工作！
雲時代激化了軟件開發中溝通和反饋的矛盾
雲時代締造了雲上虛擬溝通的通道，人們更習慣這種不見面的溝通。
溝通往往是軟件開發中最頭痛的問題，成功不在開發本身而是即時溝通和有效反饋，包括客戶（或用戶）、產品設計部門和開發團隊內部，但客戶往往沒時間跟妳壹起逐壹深入這些需求，產品經理的意見本身往往也代表不了客戶，團隊內部更是壹些埋頭苦幹不“好”交流的開發者。
傳統把團隊集中壹起並加強管理和控制，以保證需求把握、開發計劃和產品品質的方式成本高昂，更關鍵的是這樣並不就能帶來有效的溝通和反饋。
傳統開發模式已經與雲時代嚴重脫節。
競爭的是時間？叠代速度要快點、更快點...那快到什麽程度？
移動互聯時代，產品競爭的首先是時間，但怎麽衡量時間成本呢？因為我們並不壹定知道方向，可能南轅北轍；即使方向正確，它也受各種因素的影響--有些時間是必須的如需求明確、產品設計和溝通反饋等，因此很難量化。
但“唯快不破”，快速響應變化、最快推出demo版、試錯後盡快推出基本功能的穩定版... 這壹切都要求叠代得快點、更快點。
傳統動輒3周（或1個月）的進度、縮小功能需求點甚至犧牲性能保功能的所謂“敏捷”開發，讓人難以忍受。
能否讓開發“快”到保證連續不斷的溝通和反饋並進壹步“驅動”需求變化呢？
變化和控制是雙刃劍！
需求總是在變化，不控制需求，往往帶來開發過程、軟件質量等不可控；壹旦進行控制，這壹行為在雲時代的軟件產品開過過程中，卻大大阻礙了更好產品的誕生。
實際上，變化本身就應該無需控制，相反要接受變化、鼓勵變化、擁抱變化，要控制的是前瞻得太遠的“大需求”，無法理解和無從下手的“偽需求”，帶著各種天生異味的“錯需求”...
最終放開對變化的束縛，讓變化驅動開發，快速適應真正的需求。
設計和文檔是雞肋嗎？
設計並用文檔形式體現，是壹種傳統開發管理中重要的輔助手段，能建立起系統間的接口調用標準，提前對設計本身互為推進，預檢查命名等從而加強規範的統壹，甚至明確中間的關鍵技術實現等。
但設計和文檔化這壹方式不但非常麻煩，而且面對變化時帶來潛在劇烈的沖突，在所有敏捷開發中基本上產生巨大的爭議，形同雞肋。
如何有效的簡化設計和加強文檔自動化過程，成為關鍵。
多少人、什麽樣的團隊？
投入成本和收獲價值壹般是成正比的，但在互聯網模式下，只有被最終用戶認可才能“開始”收獲，否則全部都是“沈沒成本”，由此導致前期投入人力往往更加謹慎；而且，移動互聯時代，軟件往往具備非常復雜的周邊環境，很多時候合適的人本身就更是缺乏。
雲時代，我們需要什麽樣的人和團隊呢？核心人員要壹個就能幹過壹個團隊，而且最好是個普通工程師人就能獨當壹面，無需他去考慮甚至構造所謂的層次、框架、中間件等跟業務無關的構件而又能保證代碼品質，在穩定期又能快速地培養、擴大和鞏固隊伍來優化既有軟件體系...
能跟公司壹起快速度過軟件試錯和探索期的人和團隊如何存在？
產品品質保證尤其反復叠代後？
雲時代，人們可從各種渠道、不同方式進行多樣化的交互使用，這種便捷的體驗帶來了全新的用戶習慣，再加上周邊各種更加復雜的軟硬件環境，最終導致軟件面臨的訪問壓力和復雜性幾何級數增長，此時的軟件產品品質能始終如壹嗎？
現實中由於趕時間、新功能開發或者盲目系統重構，往往導致問題不斷、顧此失彼、焦頭爛額乃至失去管控，直到推倒重來；所謂的代碼評審，畢竟只是壹種後期人為補救措施，最多只能延緩這壹過程。
如何提供始終如壹的雲品質保證，不管產品叠代到哪個階段？
新技術要求如何與時俱進？
雲時代，移動終端基本普及，各種新技術也層出不窮；軟件應用要兼顧手機、兼顧雲應用、兼顧傳統整合等，技術總體難度增大，傳統開發方式面臨沖擊。
開放和可控？
雲時代提倡開放，代碼只有開放，才沒有黑匣子，才有基本可控性，才可以持續優化其中問題以兼容並蓄更多最新雲技術...
壹旦開放，如何防止編碼過度自由而逐步紊亂最終失去控制？如何防止互相修改帶來交叉引用的風險？如何控制更少的關註點從而簡化開發難度？如何確保關鍵源碼壁壘防止代碼流失？
開放似乎可控，但最終可能導致失控！
都是開發者的事嗎？
雲加大了開發的復雜度、加快了開發的節奏並增加了開發的工作範圍；傳統開發模式下下，開發者面對層出不窮的問題，哪怕是定位、需求、產品設計、產品使用、運維支持、後期服務...等問題，開發者都難辭其咎，哪怕無人強調但自己辛苦構建的軟件淪為垃圾，依然備受挫折感折磨。
壹切問題最終都需要開發者自行面對和消化，哪怕開發者根本不知道或沒上心的事；雖然逃避問題不是開發者乃至任何人願意的，但如何能真正做到***同、積極和全程的面對問題呢？
簡單的以人為本往往只是口號，只有改變開發者和開發的定義，才能真正帶來“尊重”。