著作权归作者所有。商业转载请联系 Scott 获得授权，非商业转载请注明出处[务必保留全文，勿做删减]。
对于普通人，最大潜水深度一般不超过水下 30 米，极限为水下 40 米，超过 40 米就进入到技术潜水的范畴，就会面临各种复杂的危险状况，需要各种装备的集成和系统化的训练才能保证一定的安全性。
- 为什么技术晋升越来越难了
- 为什么高薪资的岗位 Offer 越来越难拿了
- 为什么公司总是说做技术也要懂业务
- 为什么很多团队主管总把价值挂在嘴边
- 为什么 What/How/Why 必须要搞清楚
- 为什么单纯技术硬很难向前突破了
- 为什么前端开发往上走比之前更难了
- 为什么我想发力却总是懒于动手
- 为什么我趴键盘上看不到明天看不到希望
- ...
红利已逝，今非昔比。对比 2010 年，整个前端生态已经翻新了好几遍，直到近几年的 Node BFF、IDE Cloud，抑或是客户端 AI，还是 Serverless 的建设，前端想要深度参与的话，单纯依靠原来的 HTML/CSS/JS 三件套技能也远远不够了，再抛开技术，整个互联网创业生态也重构了好几遍，生意的本质没变，但做生意的理念和方法论以及辅助的工具都发生了巨大的变化。
新的商业环境下就有新的公司组织架构形态，以及新的产品研发流程和合作模式，这些也对今日的前端开发工程师提出更新更高的要求，无论是技术层面还是意识层面，如今的前端开发已经进入深水区，要在深水区中生存以及捕捞猎物，就需要有深水区所需要的系统化的技能体系以及配套的软硬件能力，以及从浅水区进往深水区所需要的进阶方法论，本文试图向大家传达这样一种观点，希望带给大家一些启示，无论是新人老人都要居安思危，提前做出储备，以应对新的职场挑战，更灵活的延展自己的职业路线。
本文是小菜前端 TL 内训课程中， 《上手技术管理的初级套路》 这一节里面，关于前端已迎来深水区这个观点的展开陈述，文中会截取几页 PPT 来辅助叙述帮大家理解:
浅水区需要哪些技能
站在 2019 年，通常一个工程师履历中体现的是跳槽历史、参与项目的难度、React/Vue/Angular 等框架底层熟悉度、编程方法论的掌握程度以及职位的变迁等，而在工作中的确与编程强相关的技能有很多（该图是我多年前整理修改而来，有同学知道出处可以告知我）：
抛开 BATMD 这种大体量的公司，放在市面上任意一个 50 人规模以下技术团队的公司里面，大概率掌握最好的是 IDE/框架/API 这一层，至于代码实现的足够优雅很难保障，更不要提程序设计的娴熟套路、项目背后沉淀的方法论等等，单纯在这张图上打怪升级花个 5 年 10 年丝毫不为怪，而对于前端工程师，这张图的技能点花个 7 年 10 年全部打满打透，此时也差不多三十而立了，而立之年也就是摸到了技术路线的第一个天花板，这个天花板就是技术专家，即便如此，用 10 年时间碰到这个天花板的人依然是极少数，大部分人需要花费更久甚至一直到不了这个高度，而所有这张图上我把它定义成浅水区技能，是肉眼可见的，是可以量化的，是最容易产生共鸣而形成学习动力的，但是放在如今的新商业环境中就显得很单薄了。
为什么单薄呢？我们把图上的能力和知识体系打碎重组，提炼后就是三个关键字：架构、编程、运维，一个是意识和逻辑层面，一个是过程实现层面，一个是环境保障层面，这些能力依然是落纯技术体系内，并没有跟外部的商业和职场环境发生多少交集。
深水区需要哪些技能
在深水区，脑海中如果只有编程二字是不够的，就算带一些沟通合作也还是远远不够，但是不是一定需要深水区技能才能把工作做好，答案也并不是，深水区技能是更长期性更深刻的，从长期看具备这些特质可以更快更好的跨过技术专家的这个天花板，走到更高的一个 Level，但不具备这些特质也未必会严重影响浅水区的表现。不过当更多同龄人具备深水区能力的时候，只具备浅水区能力的你慢慢就变成了裸泳，而更多更多的新人跳入到浅水区和你一起竞争，此时你跟深水区已经是隔绝的两个世界，看到的和收获也截然不同了。
我把深水区的技能，更口语化的总结为： 技术创新、流程优化、团队合作、影响大盘、驱动业务、商业决策和团队管理，如下图：
每一个能力的解释我也标注在了图上，再通俗的解释一下：
- 技术创新，从技术面、业务和产品面出发，以技术作为突破点，取得技术上的突破，比如兼容多端的框架研发、客户端浅层次 AI 的实现
- 流程优化，更多是从产品研发流程上发力，借助向上向下的管理，推动流程变得更高效，比如前后端的接口联调方式、比如产品 PRD 到测试流程的介入更敏捷的迭代方式，可能是规范可能是工具层面
- 团队合作，这个最好理解也最难做好，同样是从管理和业务的视角切过去，促成团队成员之间有更高层面的共识达成，有更信任的纽带关系，以及有更匹配的使命目标驱动，比如与业务同学一起出差拜访客户，并在过程中发现更多共鸣点，从而驱动彼此更快调整协作方式，最终为客户解决问题
- 影响大盘，所谓大盘就是公司或者部门的业务大盘，这个一定需要对业务的前景有较为客观深刻的认识，并且形成自己的独立判断和决策，去发现业务缺失哪些核心的因素点，并去补全这个遗漏甚至是发现一个机会点，去发掘实现一个新的业务可能性，比如公司的内容生产是一个核心业务，去发现它未来规模化生产会遇到人力瓶颈，有没有可能通过产品化背后的技术能力提供生产力，让业务看到一个新的可能性从而修正整个内容的规划方向
- 驱动业务，与影响大盘不同，驱动业务更多是有实质性的推进而不仅仅是想法，比如通过配套的埋点监控工具，来捕捉用户一些有意义的行为，从而不断从中发现问题并推动业务去优化解决，或者发现有价值的方向，从而开放这些价值点背后的技术能力给到业务和产品，赋能他们更好的迭代业务流程
- 商业决策，这一点更多是从数据价值层面，比如可视化很多时候是从前端来主导研发和推进，从各种展现模型中为业务提供更好的决策视角，但在它之前一定是对业务和产品有足够深的理解才会形成有效的决策路径和模型
- 团队管理，这个则是一个很大的话题了，站在组织的视角把团队从弱带到强，从小带到大，从层次不齐带到规矩有章法能冲能创，成为公司具备核心影响力的团队
经过我们再次简单分析后，可以发现这些技能背后，是四个核心能力，分别是：技术、产品、业务和管理能力，把它们再拆到每个能力上，按照影响的权重，是这样的对应关系：
大部分仅仅是靠技术都不可能去推进了，甚至技术都未必是它的重要影响权重，比如团队合作、影响大盘、商业决策等，统统这些能力的集合就是一个足够资深的工程师，他能在深水区存活，并且靠此打出一片天所需要的软实力了。
怎么修炼深水区能力
聊清楚深水区对于工程师的 What 和 Why 以后，我们来聊一聊 How。开始之前我们必须认识到这些能力不是一蹴而就的，无论是你已经具备了部分能力，还是丝毫不具备，我们都要认识到它的习得需要一个过程，这个过程通常就分为这三个阶段：初级练习阶段、渐变娴熟的阶段、质变内化为能力的阶段，在初级练习阶段没有足够的沉淀前，直接跳往后两个阶段都是不切实际的。
首先是初级阶段怎么练习，我把 PDCA 修改后形成这一个做事套路，大家可以参考：
工作中的每一项具体的任务，都可以按照这个路子走一遍，一开始的时候会不适应，甚至有点僵硬的硬套模仿，多来几次慢慢就会成为一种习惯，举个例子：
团队里有很多表单开发的场景，大家的效率都很低，开发很痛苦，我看到这个问题后，就想要做一个复杂表单组件，我首先就是研究各种市面方案，研究公司的业务场景，研究已有的端产品上业务表达的交互表达方式，团队有没有人研究过表单的方案，我去收集相关的信息，并且我也弄明白为什么要开发这个表单组件，它能为业务带来实际的价值么，这个表单应该承载什么核心功能呢，做完能推动落地么，我本人能推得动么.... 这个环节就是形成判断决策的时候，也就是捉摸。
捉摸明白后，我开始制定目标，这个要符合 SMART 法则，尽量的可量化，比如：我要用 2 周时间开发一个表单组件，这个组件要可以被兼容替换到 AB 两个业务的 DEF 三个产品的 10 个页面的交互中，然后开始制定具体的开发计划，哪个时间点找老板征得同意，开始定出分几个版本来迭代，每个版本的周期是几天，每个版本完成的具体功能是什么，在这个过程中需要哪些资源，比如架构组同学的支持，业务组同学的反馈，交互组同学的设计配合，产品经理同学的理解和认同，然后把整个开发过程以可被感知的方式量化出来，透明化出来，这就是规划的阶段。
规划后开始进行技术方案的设计，模块的设计，三方库等等直到编码完成，开始推动组件在匹配的业务线和产品中使用，推动并帮助其他同学使用该组件，跟踪组件使用的效果并及时的修理 Bug 优化交互等，这个就是执行阶段。
在业务线用了一段时间后，组织一个小小复盘，针对实际应用中的问题做个收集整理，并且把过程中自己的不足也做一个检视，比如经常忘记跟老板同步进度，经常疏忽其他同学的吐槽建议等等，另外根据复盘和反馈来确保这个组件的确有提效的价值。
最后是沉淀开发组件的方法论，相应的技术文档（这个往往在开发过程中就沉淀下来了），以及组件化立项开发的套路，自己个人能力有什么成长，这种能力如何快速复制给其他新手同学...也就是沉淀 Share 的阶段。
实际工作中的问题，往往比一个组件要复杂的多的多，这就需要我们更加谨慎的对待每个阶段，把它们灵活应用并保障每次都比上一次拿到更好的结果，个人每次都比上一次方法论用的更纯熟。
上面抛砖引玉介绍了单纯实现层面可以训练的方法论，这种方法论同样适用了任何能力的练习，但方法论毕竟是方法论，真正决定它们训练结果其实还有一个前置条件，就是你的做事驱动力，也就是能力和意愿的情况。
能力意愿是前置条件
我们先讲了方法论，让大家更明确的感受到一些可执行的套路，然后再来看能力和意愿的重要性，所谓能力就是你判定问题和分析解决问题的能力，所谓意愿就是你面对任何一个突入飞来的难题或者任务，内心是抵触、认同还是兴奋这样的一种情绪。
首先，我们分析下一个员工的做事动机，通常有这几类：
- 不知道不关心，对这个任务不清楚 what/how/why，也不关心它做不做的价值有多大
- 这么做是因为必须这么做，依然不理解它的价值，但知道这样做是因为我是前端工程师，这是我分内事
- 不这么做会有罪疚感，老板对我有信任，我如果不做好会觉得不好意思，心理过不去
- 这么做对我很重要，我认同这件事交给我做的原因和意义，这件事对我的成长及未来晋升都有意义，我很重视
- 喜欢并专注去做，这件事是我一直以来期待的机会，我很喜欢很想去实现它，我很理解它做好的意义
所以一个同学有可能做不同的项目会有不同的动机，即便做同一个项目的不同阶段也会有不同的动机，这是一个完全主观的事情，但是它很重要，因为不同的动机会带来三个结果：老板及周围同事通过你做这件事所看出的你的做事态度，这件事你做完达成的结果，以及你由此而获得的成就感或者成长，当然所有的团队都希望你无论喜欢与否，都至少是理解并执行这个任务：
最怕的是理解不执行和不理解和不执行，最终反映在能力和意愿上，在一个团队的分布中，你就有了不同的象限，是能力好意愿度高的，还是能力高意愿度低的，只有意愿高能力高的人才能获得最大程度的授权和自由空间，反之不仅获得授权会缩水，甚至必须听从具体的拆解后的任务去做执行的角色，所以如何让自己无论能力高低，先让自己具备一个高意愿度都是一个明智的选项。
那么存不存在一些事情是无意义的，做了也是白做呢，一定存在，现在这样高节奏的创业环境中，试错始终是一种常态，做一件事而拿不到结果也是常有的事，但是不是因此就否定了组织的动机，从而把自己束缚的越来越紧，正面看过去好像自己不再亏什么了，反过来看自己却失去了进入深水区而该有的历练，这个历练中一定有汗水也有委屈。
面对深水压力不需紧张
其实何止前端开发，整个技术行业都已步入深水区，只是前端工程师的感知来的晚一些而已。只要把眼光投向深水区，问题就会一个接一个的浮上来，当越来越多问题浮起来的时候，就是你慢慢沉向深水区的时候，这时候不需要太过紧张，此时的发生正在见证者你的成长，欢迎大家文后提问更多问题，我们可以再换一期来针对性讨论，本文主要帮大家引导到深水区已然到来，在它之上需要储备技能的必要性和重要性，目的就达到了。
Scott 近两年无论是面试还是线下线上的技术分享，遇到许许多多前端同学，由于团队原因，个人原因，职业成长，技术方向，甚至家庭等等原因，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，大家可以找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdream，也可以来 关注 Scott 跟进我的动态。