移动互联带来用户终极体验为王？
移动互联网催生软件开发的思路转变，要求软件产品必须站在用户体验的角度，遵循“体验为王”的法则，否则做得再多都是垃圾，耽误时间和金钱。
如果开发者没有站在产品用户体验的高度，产品经理抓也没用，因为细节体验等问题再怎么测试也有漏网之鱼，而很多开发者往往不愿面对或者无法面对？
实际上，开发者必须站到客户第一线，做“难做”的事情，甚至亲自跳到“坑”里，找到解决疼点的多种方案，并提出不要倾向、客观和合适的建议。
因为体验繁杂而想逃脱，就不可能做好开发工作！
云时代激化了软件开发中沟通和反馈的矛盾
云时代缔造了云上虚拟沟通的通道，人们更习惯这种不见面的沟通。
沟通往往是软件开发中最头痛的问题，成功不在开发本身而是即时沟通和有效反馈，包括客户（或用户）、产品设计部门和开发团队内部，但客户往往没时间跟你一起逐一深入这些需求，产品经理的意见本身往往也代表不了客户，团队内部更是一些埋头苦干不“好”交流的开发者。
传统把团队集中一起并加强管理和控制，以保证需求把握、开发计划和产品品质的方式成本高昂，更关键的是这样并不就能带来有效的沟通和反馈。
传统开发模式已经与云时代严重脱节。
竞争的是时间？迭代速度要快点、更快点...那快到什么程度？
移动互联时代，产品竞争的首先是时间，但怎么衡量时间成本呢？因为我们并不一定知道方向，可能南辕北辙；即使方向正确，它也受各种因素的影响--有些时间是必须的如需求明确、产品设计和沟通反馈等，因此很难量化。
但“唯快不破”，快速响应变化、最快推出demo版、试错后尽快推出基本功能的稳定版... 这一切都要求迭代得快点、更快点。
传统动辄3周（或1个月）的进度、缩小功能需求点甚至牺牲性能保功能的所谓“敏捷”开发，让人难以忍受。
能否让开发“快”到保证连续不断的沟通和反馈并进一步“驱动”需求变化呢？
变化和控制是双刃剑！
需求总是在变化，不控制需求，往往带来开发过程、软件质量等不可控；一旦进行控制，这一行为在云时代的软件产品开过过程中，却大大阻碍了更好产品的诞生。
实际上，变化本身就应该无需控制，相反要接受变化、鼓励变化、拥抱变化，要控制的是前瞻得太远的“大需求”，无法理解和无从下手的“伪需求”，带着各种天生异味的“错需求”...
最终放开对变化的束缚，让变化驱动开发，快速适应真正的需求。
设计和文档是鸡肋吗？
设计并用文档形式体现，是一种传统开发管理中重要的辅助手段，能建立起系统间的接口调用标准，提前对设计本身互为推进，预检查命名等从而加强规范的统一，甚至明确中间的关键技术实现等。
但设计和文档化这一方式不但非常麻烦，而且面对变化时带来潜在剧烈的冲突，在所有敏捷开发中基本上产生巨大的争议，形同鸡肋。
如何有效的简化设计和加强文档自动化过程，成为关键。
多少人、什么样的团队？
投入成本和收获价值一般是成正比的，但在互联网模式下，只有被最终用户认可才能“开始”收获，否则全部都是“沉没成本”，由此导致前期投入人力往往更加谨慎；而且，移动互联时代，软件往往具备非常复杂的周边环境，很多时候合适的人本身就更是缺乏。
云时代，我们需要什么样的人和团队呢？核心人员要一个就能干过一个团队，而且最好是个普通工程师人就能独当一面，无需他去考虑甚至构造所谓的层次、框架、中间件等跟业务无关的构件而又能保证代码品质，在稳定期又能快速地培养、扩大和巩固队伍来优化既有软件体系...
能跟公司一起快速度过软件试错和探索期的人和团队如何存在？
产品品质保证尤其反复迭代后？
云时代，人们可从各种渠道、不同方式进行多样化的交互使用，这种便捷的体验带来了全新的用户习惯，再加上周边各种更加复杂的软硬件环境，最终导致软件面临的访问压力和复杂性几何级数增长，此时的软件产品品质能始终如一吗？
现实中由于赶时间、新功能开发或者盲目系统重构，往往导致问题不断、顾此失彼、焦头烂额乃至失去管控，直到推倒重来；所谓的代码评审，毕竟只是一种后期人为补救措施，最多只能延缓这一过程。
如何提供始终如一的云品质保证，不管产品迭代到哪个阶段？
新技术要求如何与时俱进？
云时代，移动终端基本普及，各种新技术也层出不穷；软件应用要兼顾手机、兼顾云应用、兼顾传统整合等，技术总体难度增大，传统开发方式面临冲击。
开放和可控？
云时代提倡开放，代码只有开放，才没有黑匣子，才有基本可控性，才可以持续优化其中问题以兼容并蓄更多最新云技术...
一旦开放，如何防止编码过度自由而逐步紊乱最终失去控制？如何防止互相修改带来交叉引用的风险？如何控制更少的关注点从而简化开发难度？如何确保关键源码壁垒防止代码流失？
开放似乎可控，但最终可能导致失控！
都是开发者的事吗？
云加大了开发的复杂度、加快了开发的节奏并增加了开发的工作范围；传统开发模式下下，开发者面对层出不穷的问题，哪怕是定位、需求、产品设计、产品使用、运维支持、后期服务...等问题，开发者都难辞其咎，哪怕无人强调但自己辛苦构建的软件沦为垃圾，依然备受挫折感折磨。
一切问题最终都需要开发者自行面对和消化，哪怕开发者根本不知道或没上心的事；虽然逃避问题不是开发者乃至任何人愿意的，但如何能真正做到共同、积极和全程的面对问题呢？
简单的以人为本往往只是口号，只有改变开发者和开发的定义，才能真正带来“尊重”。
