其实一直想着写这篇文章，但是缺乏灵感，下笔犯难。信息时代发展速度快到令人目不暇接，从最开始的个人PC，到拨号上网，再到光纤入户，再到现在4G/5G移动互联网，一晃也不过短短三四十年。程序主流语言也从最开始的C/C++，到Java/C#，再到JSP/HTML/JS，再到Python/Objective-C，再到现在的百花齐放。真真是旧人未老，新人已至。技术架构也从之前的单机客户端，到C/S架构的胖客户端/瘦服务端，再到B/S架构的瘦客户端/胖服务端，再到现在基于智能手机平台的胖客户端/胖服务端，技术架构在快速演进，然而一大矛盾却是技术从业人员的技术视野与技术思维却不见得跟上了时代。

        因此就产生了很多令人发笑的业余现象，例如某些技术大会的宣讲标题叫《XXX基于千万级用户下的App架构设计》，所谓千万级用户更多的只不过是对后台架构的高并发有要求，对于C/S架构下的App客户端而言，其天然就是分布式的，用户量的大小之于前端架构又能有几毛钱关系？充其量不过是多些用户/机型/场景给你测试试错，对一些内存管理/程序细节要求更高一点而已，但上升不到架构层面的量级差异。

        只是对于行外人士而言，特别是传统行业，这却容易产生一个假象与矛盾，我的平台初期只有那么点用户，为啥前端团队也需要投入那么多人力？其实他们不知道的是，App本身就是一个很贵的东西，要么干脆不做，要做就要舍得投入——因为，App本身的最小功能闭环要求，就已经决定了投入绝对不会少，这既不会因为用户量小就可以人员减半，也不会因为用户量多就需要人员倍增，核心团队规模一直在那里，不需要更多，却也缺一不可。

        误区二是后端指挥前端，其实这一点在后Web时代（前后端完全分离后）就已经被证明是极大的战略错误（后端指挥前端，由于后端不懂用户功能设计与专业产品体验，最终做出来的就只会是一个超级复杂难用的工具应用，典型中的典型就是谷歌跟以前的百度，他们家的所谓产品都只是小儿科加自娱自乐型的实验项目性的东西，不具备作为真正商业产品落地的成熟性）。

        可惜的是，时代虽然变了，但是技术团队特别是后端团队、领导层的那些人大都还是从PC时代过来的“老人”，他们本身的技术意识、产品意识还停留在PC时代，要做革命性改变难比登天。更何况技术团队领导层大多本就是从后端做起来的，只对后端技术了解多一些，要他们去接受、认可 “不可控” 的前端新技术、新产品、新团队运作模式，显然不如呆在自己“熟悉可控”的安逸圈来得实在、轻松、安全。因此在实际运作过程中，不可避免就会把资源往后台倾斜，挤压前端发展空间，殊不知前端才是真正能带来用户、创造持久收益的直接入口。这一点在基金行业更为明显，由于过去主业是第三方对接、内部功能支撑，后台并不面对真正的用户，也没用啥大并发的压力，本身的产品意识与技术架构就已经落后时代了，还要来看时代最前沿而且不熟悉的前端产品，就只能是盲人摸象，靠道听途说来指挥发展方向。

        但是，在移动领域，勤是不能补拙的，因为前端产品与技术都需要较深的基础专业积累——在产品方面，如果你没有专业移动产品设计积累，就只能靠抄袭、复制别家产品来推动自身产品发展，不会具备真正的产品定位落地能力与产品功能规划能力，目前业界至少50%的所谓产品经理根本都还没入门，就更不要谈离门还很远的“基金IT后端”了。

        在前端技术方面，基于手机端计算能力与存储能力的不断提升，App这一“新型”（其实已经很老了，都有十几年了，此口吻只是跟“老人们”说的）产品形态迸发出了比以往任何客户端都绚丽的色彩与光辉。因为App即是各个公司业务的延伸，也是手机硬件能力的抽象扩展，真正优秀的App就是能将这两者完美融合的产物。这一层面的要求可不止老人们说的“前端只管界面展示”那么轻巧。前后端其实也是隔行如隔山的，虽然都叫IT，但各自技术架构侧重基于所面对的业务压力而不同，简略来说。后台注重数据处理的并发能力、容错能力、稳定性、可扩展性；而前端注重功能稳定性、交互响应速度（即操作流畅性）、合理内存运用能力、业务扩展适配能力、系统硬件能力的运用。专业领域最怕的就是外行领导内行。

       时代已然改变，大家都在同一赛道上，你不改变，别人就会率先改变，抢占了领头羊位置，而你就会被挤到后头，到了那个时候，所谓的安逸圈也终会被人挤破。

        在移动时代，前端功能更贴近用户，产品设计也更加强调用户体验，产品需求的导向也越来越向用户倾斜，后端因为远离用户并不适合直接领导前端开发与功能设计，而更现实的是作为一个业务支撑者角色出现，因为用户需求，将前端需求延伸到后台的需求做好实现与支撑即可。当然这少不了一轮轮的博弈，毕竟产品主导权谁都不想拱手让出。

        举个现在很流行的例子——基于大数据分析的智能运营。大数据确实是一个好东西，结合大数据的智能运营也描绘了一个很美好的愿景——基于大数据分析，在用户还未做下一步动作前就已经提前分析出来他所需要的功能。例如在京东上，你刚进入App，他就会自动推荐一些你可能感兴趣的商品了。这些功能当然很好很强大，但是却忽略了两个基本前提：

    1、首先要有京东那样海量的用户群体，才能产生足够多的数据样本，进而得到较准确的客群分析结果；

    2、这类运营手段更多的只是为现有用户提供更好服务与体验，但并不会引流来多少新用户。

        所以在这些高大上的东西上线之前，还是应该先踏踏实实做好产品，做好产品设计、充实产品内容、打造产品生态闭环，然后通过精心策划制造爆点活动来瞬间引流，亦或依靠打造精品应用、提供精品服务，形成用户口碑，进而实现用户规模增长。到了那个时候，才是这些所谓大数据、AI真正的用武之时。而在这之前，还是踏踏实实做好产品，悉心培养种子用户吧。

        误区三，产品设计要与前端开发分离，明确分工，各司其职，不可僭越。

        在移动时代，产品功能设计与UI设计，较之以往有着更高的专业性要求与技术基础性要求，因为苹果打造的这一套用户体验标准，本就是基于他家工艺标准与iPhone系统特性量身定制的，哪怕是最简单的按钮控件，都有着基于技术限制的妥协以及整体页面体验的考究。而这些方面，日日接触App开发的前端开发人员显然更能透彻理解。技术决定产品下限，产品推动技术上限不断提升。移动端的开发还是跟产品结合更紧密一点更能产生鲶鱼效应。

        误区四，人事管理与项目运作耦合在一起，领导特别是技术领导成为团队的专业短板。

        这个问题其实一直都存在，只是在移动时代，因为移动产品专业化要求更高，从而暴露得更加直白明显。在移动时代，团队内各个角色都是一个高度专业化的岗位，毕竟领导的时间精力有限，虽然可能在某一领域有较深专业积累，但是不太可能在所有岗位都有很专业的积累，但如果领导们不自知，总想面面俱到，就不仅会暴露自己的能力短板，更严重的是会成为整个团队的瓶颈，限制团队的进一步成长。

        这一方面华为的经验非常值得借鉴：在华为，部门人事是跟产品运作完全分离的，产品经理人事上属于产品经理部，但是实际工作中会分散到各个业务产品团队；UI设计师亦是如此；而前后端团队分离的更彻底，前端团队属于部门A，后台团队属于部门B，大家是根据产品业务的划分坐在一起办公。这样，产品是由整个产品团队负责，领导层只做战略规划部署与核心环节评审（例如产品定位评审、需求规划季度评审、技术方案评审、重大版本上线评审），不去参与不擅长的产品的具体运作，因为基于领导的角色，他的出现会干扰甚至影响产品团队的决策，而这往往不是明智的选择。

        这一困局，所有传统行业向互联网转型都会面临，这一方面，上策是通过调整组织架构，实行扁平化管理，让专人只做专事，即便领导也不例外；中策是在组织架构调整困难的情况下，调整团队运作方式，严格前后端分离，实行产品化运作，而不是大而全的项目式运作，充分发挥产品团队自己的主观能动性与专业特长，也可以一定程度避免一言堂出现。下策是维持现状，让移动转型缓慢死亡。