9年前，还是前端小白的我，在知乎上写下了第一个问题：
这是一个前端经典问题，具体如下：
先扯点题外话。
那时候我刚入职阿里半年，平时只是做一些零零碎碎的前端工作，切切图，写写静态页，对企业级的前端工程全貌并不了解。
工作本身并没什么好吐槽的，那个年头的整体氛围啥的都还不错，但我遇到了一个创业的机会，于是便开始筹备辞职创业的事情。
而创业这件事意味着，辞职之前，我必须尽快尽可能多地了解到企业研发流程的全貌。毕竟创业初期人不多，一个人当几个人用是很常见的事，作为技术合伙人的我需要能独当一面。
回到正题。
让我没想到的是，我的问题刚发布不到2小时，前端大佬张云龙就来回答了（早期前端大佬，不认识的可以搜一下）。
云龙哥搬运了他另一个高赞帖，恰好完美解答了我的问题。
整个回答鞭辟入里，通俗易懂，即便是放到10年后的现在，那整套工程化方案也都是没有过时的。
那么我提这个陈年往事是为啥呢？
是因为，写文章的3个月以来，我陆续接触到一些“新一届”前端小白，他们虽然晚我十年入场，虽然身在数字信息高度发达的2023，但他们对于前端领域普遍性的疑问，却和十年前的我相差无几。
他们有的刚开始学前端三件套(Html,Css,Js)；有的学完三件套开始学UI框架(React/Vue)；有的学完UI框架开始学Redux，RxJs，Nuxt，Next，Nest，Node，Deno……一堆乱七八糟一辈子都学不完的「轮子」。
学习能力不强的，很快就被“轮子”们劝退了；学习能力强的，学着学着也学不动了，开始迷茫，不知道接下来要往哪个方向学习，于是不约而同的问出了这个问题：
「大公司的前端开发是什么样的？」
这可像极了当年的我。
而前端工程师的成长分界线，也就在这了。
初级工程师往往只停留在各式各样的轮子面前，痴迷的啃食着，沉醉着。而高级工程师，早已把目光放回了软件开发的本质问题上：工程。
没错，不管时代怎么发展，框架怎么推陈出新，程序员要面临的一个亘古不变的问题，就是工程问题，而不是具体某个框架某个库的语法问题。
在这个意义上，其实前端后端的界限已经模糊不清了，因此大厂的高级工程师多半也都会是全栈工程师，他们的日常工作是用工程化手段，去解决一个个复杂问题。
于是你会发现，大厂的前端大佬们，日常研究的东西很可能早就脱离了你所认知的“前端”领域，早已不再拘泥于HTML那一亩三分地，而是根据不同的业务场景，不同的问题领域，把求知的大网，撒向更广阔的天地。
要说清楚大厂的前端什么样，可以拆解为两个话题：
1. 大厂的企业级开发流程长什么样？
2. 大厂的前端大佬们平时都在做什么？
再多提一嘴，之前有不少同学反馈说文章太长了懒得看，所以我打算分两篇文章来把这件事说清楚，今天这篇先聊第一个问题。
按照惯例，开篇先上一张图：
这是我画的一个需求研发流程的简化模型，实际生产过程可能比这个要复杂一些。不过虽说简化，这个模型也基本是Devops完备的，我们就以此展开。
1
前置环节 Preliminary Stage
软件工程的前置环节位于图片的左上方，包含了「商机发现」，「目标制定」，「立项」三个环节。
之所以称之为前置也很好理解，软件诞生的意义一定是为了解决某个现实世界的问题，从而获得一定的商业回报。因此在进入软件工程之前的筹备和探索工作，自然就是前置环节啦。
这部分在公司里通常是业务负责人在关注，产研团队一般接触不到，所以我们不说太多，合并在一起快速跳过。
2
需求梳理 Requirements Sorting
需求梳理又可以划分为「需求分析」和「需求拆解」。
说到需求分析，就不得不祭出这张经典图来：
漫画很直观，我不过多解释，这其实就充分说明了需求分析环节的复杂度和重要性。
不同角色不同能力的人，面对同一个需求，往往表达出大相径庭的理解。而一旦理解出错，那么就会将一个错误的需求层层传递下去。
不少团队在这个环节掉以轻心，不当回事，经常做一些「口头需求」，实际上是极不负责任的行为，轻则浪费人力返工，造成交付延期，重则酿成生产事故和团队矛盾。
再来说说需求拆解，这部分也是日常工作中最容易被人忽视的环节，而且哪怕是资历颇丰的职场老手，也不见得真正懂如何合理拆解需求。
「User Story」用户故事拆分，这是一种在敏捷交付团队里最常用和有效的需求拆解方式，其目的就是将复杂的事务做细粒度拆分，从而降低复杂度。
通常情况下，可以从上往下依次拆解为Epic -> Feature -> Story。
拆解原则可以参考INVEST准则
这部分内容也非常庞杂，有机会单独开一篇聊，这里不继续展开了。
3
产品设计 Product Design
在消费互联网盛行的时代，也就是所谓的toC产品，其产品设计基本上是强依赖于产品策划人员的（我个人不喜欢产品经理这个词，我更愿意将他们区分为产品策划和产品运营）。
但是到了当下的工业互联网时代，也就是当下流行的toB/G产品，其产品设计工作，技术人员也陆续参与甚至主导了起来。为什么会有这种根本性的变化？本质上还是因为产品功能和定位所需的技能点发生了变化。toB产品的诞生是为了解决某些行业，领域，业务流程的效率问题，而流程(Flow)的重点在逻辑，在工艺设计，流程的提效就需要大量的领域知识和技术背景。
所以互联网发展重心转移到产业互联网之后，「产品型技术人员」和「技术型产品经理」就更加的稀缺和重要了。总之，产品设计环节直接决定了产品的有效性，但并不是说只有产品经理才能干这件事，一个优秀的高级工程师，本身也应该具备一定的产品思维能力。
4
指标制定 Indicator Formulation
很多产研团队在做产品的时候，往往拿到需求文档就直接开干了，无意或刻意的跳过了指标制定的环节。
等到了绩效考核，或者晋升答辩的时候，努力的想要从各种地方搜寻一些「数据」成果，来支撑自己“做了很多牛X的事“的结论。很明显，这种临时抱佛脚的事情往往效果并不好，搜刮来的数据要么不完整，要么不对口，就那么囫囵吞枣的喂给你的汇报对象去，很难不被叼一顿。
因此，做事之前先定指标，显得格外重要。
好了，你现在有了定指标的意识了，那么如何定好指标呢？这又是一个老大难的问题，据我不完全统计，身边90%的人都不会定指标。我这还是在大厂了，周围同事都挺优秀，这个比例要是放在中小企业，估计还得再夸张些。
首先你要分清楚，目标和指标的区别。
目标是终点，是本次研发工作所要拿到的成果，是解决某个问题。而指标，是用来度量这个成果是否达成的参考维度。
那怎么定指标才合情合理，真实有效呢？
这事儿和目标关系不大，和你要解决的问题，你要做的事息息相关。
营收类指标是最好定的，无非就是某个周期内达成多少营业额，多少利润，多少增速。达不达成另说，但指标是直观的，显而易见的。
基建类技术指标也是好定的，比如你需要优化某个页面的首屏渲染时间，3秒首开率，系统稳定性4个9等等。这些指标也都是能直接拿到的。
最麻烦的，还是业务型技术指标的制定，这部分非常考验一个技术人的功力。
举个例子，你接到一个需求，要做一个页面A，用来「拉新促活」，页面做出来上线了，产品同学拿到了他想要的PV/UV/转化率，得意洋洋的去跟老板邀功去了，那么你作为技术人员，你的贡献在哪呢？
PV/UV增长了1000%，跟你的代码有关系么？好像有，又好像没有……你是不是经常陷入这种困惑？这就对了，你困惑就是因为你没有一个强有力的指标来证明你的代码和运营成果的关联性。
也正因为你无法证明，所以脏活累活都你干了，苦哈哈的加班撸代码，没想到却是给产品同学打工，看着他们捧着大把奖金的背影，留下了妒忌的泪水……
点到为止，具体怎么定指标，感兴趣的评论区交流。
