闲话前端业务
我们常常自嘲是打工人，搬砖人，但是除了knowledge前端知识，也要了解业务，这样经过思考以后，会做的更好。
比如我之前就梳理过公司核心系统，明确哪些是核心业务，其他是辅助。那么在改一些需求的时候，你就可以有主动权，主动提出质疑。
有的需求并不合理，你花时间做了，也许以后还得还原。
所以思考是否值得做，更重要。
1. 了解业务
1.1 业务和需求
在了解业务之前，首先我们要知道，业务跟需求是不一样的。理解需求并不等于理解业务，需求是业务经过产品消化后的产物，可能已经经过演绎或者拆解，因此需求并不是业务本身，当然了解的需求越多，对业务的全貌也会更加了解。
那么什么是业务呢？业界对"业务"有多种定义，但是其主要思想基本不变，业务就是一系列人通过一系列活动完成某一任务的过程，因此，业务可大可小，可以无限拆分。
1.2 前端为什么要学习业务
前端即使不学习业务，其实也不影响做需求，毕竟你只要告诉我交互是什么样的，前端就可以帮你实现，而且已经有产品经理的角色了，大家各司其职不就好了，为什么一个做技术的，要狗拿耗子、或者是越俎代庖呢？这就要说到：
-
只有了解业务，才能从技术的角度想到业务方不曾想到的地方；不了解业务，你可能听不懂业务方要什么，甚至连需求的业务逻辑都搞不清，这种情况的合作模式只有一种，需求下来了，你接住，然后给排期。也许，这个需求的设计不合理，你不知道；这个需求有更好的实现方案，你不知道；这个需求可以通过现成的关联产品方案解决，省时省人力，你也不知道。
-
只有了解到业务背后的原因，才能从全局的视角去规划技术的未来。不了解业务，会让你离用户的真实需求很远，你越难发现其中的一些痛点和挑战，没法真正提出你的思考和解决方案，去解决用户的难题。
-
作为一名产品研发工程师，自然是希望亲手打磨一款解决用户问题、体验友好的产品，如果产品能得到用户认可，产生影响力、自然会特别有成就感。
1.3 你了解业务吗？
那么目前你了解你对接的业务吗？不妨尝试回答下以下问题：
- 业务做的是什么？产品大图有吗？
- 业务的核心指标是什么？KPI目标是什么，这些数字背后的含义是什么？要达成这些目标，业务策略是什么？
- 业务的用户是谁？流量怎么分层？占比多少？分别在业务中是怎样的定位？
- 业务的商业模式？靠什么吸引流量，盈利模式是怎样的？
- 我们做的页面是什么东西？为业务带来什么价值？要创造更多的价值，我们可以做什么？
1.4 如何学习业务?
1.4.1 业务领域知识的阅读
找到该领域相关的评分较好的书籍集中阅读，快速形成知识框架。
1.4.2 了解业务背景和规划
- 刚刚接手新的业务，可以邀请业务方老板或者资深的运营/产品同学，给你讲讲这块业务的过去、现在、未来、愿景、财年规划，以及对技术同学的期望；
- 花时间读合作方（运营、产品、研发）的周报，了解现在在发生什么，是不是离目标越来越近了；
- 了解业务目标、落地策略、衡量目标的数据口径，关注数据，关注目前做的项目是否为了达成目标而战，如果不是，提出你的想法和建议；
- 多参会，建立产品 sense。收集信息最好的方式就是参加所处业务老大的 KO 会，各种 KO 会会把战略上的拆解和背后的思考整体梳理之后宣讲传达给 BU 或部门的同学，
1.4.3 多交流，多倾听
与服务端同学聊天，与 PM 聊天，与用户聊天，多角度看业务，但要注意的是，针对专业型比较强的业务，需要先做功课，至少一些英文的缩写要清楚的明白意思。
1.4.4 从日常需求入手
对于项目中的需求，我们要尝试分析背后的目的和价值，做了之后有什么预期的收益，为什么这么做就可以达到这个收益，跟总体目标是否契合，还要判断业务方提到的点是不是有效的方案或者说成本太大的方案，看能不能给出替代方案，用现有的方案或者小成本的方式来满足业务方。
而在项目提测上线后，还要仔细分析以及多关注上线之后的业务数据和效果，会有如下好处：
-
提高自己对业务的理解能力，你在关注业务数据的同时，也就会更多的从业务的角度来看到这个功能所带来的价值是否符合预期，当出现不符合预期的时候，可以和业务方一起进行数据漏斗的分析从而找到问题所在，避免我们的劳动成果成为一次性的工作。
-
总结的同时可以帮助自己梳理这个项目中自己哪些地方做的不足，或者相关推进中存在什么问题，以及后面怎么改进，提高了下次项目中的迭代效率和质量。比如这个项目是否存在需求理解不到位存在返工，或者沟通 & 联调低效，环境不稳定，自己设计的方案是否合理等问题，后续要怎么解决。
-
也可以从数据和总结中判断出什么样的需求是靠谱的 & 什么的样业务方是靠谱的，频繁争取资源上线效果又不好的业务方，下次再有需求过来则需要多增加一个心眼和思考的过程。
1.4.5 坚持
业务思考力，没有个至少半年是不会见效的
2. 助力业务
2.1 思考
尽管平时的业务很忙，但再忙，也要抽时间思考，那么思考哪些内容呢？以下举一些例子：
- 养成每天记工作内容的习惯，分析一下自己的时间到底耗在哪了
- 在业务开发中，有遇到让你特别想吐槽的点吗？想下问题背后的原因，有什么方法可以避免下次不犯，能不能提炼为更加通用的解决方案，其他同学怎么解决的，我可以怎么解决？
- 不断地输入、观察，业务的真实需求是什么？站在业务方的角度思考，业务遇到的痛点、挑战在哪里？
2.2 沟通
和老板、团队同学、业务方对焦，确认“我想做的”是不是“大家想要的”？
你可能会提出很多意见，但一般会遭到老板或者业务方无情的拒绝，而且问得你一脸懵逼，就比如：
- 当前业务背景下，为什么要做？（有什么业务价值？有什么技术价值？）
- 现在必须做么？
- 为什么是你做？
- 怎么做？（体系化、全链路、单点技术挑战）
- 有什么业务和技术结果？能否被复用？
而这往往是因为你提出要做的事情，有价值但不是必须做的，没有结合目前业务需要什么。也就是说，你想做的技术是个人和纯技术角度思考的，没有基于业务的现状和痛点去考虑技术方案，不接地气，投入产出比不高。
所以给技术产出先找好业务的阵地，看看有没有可以借力的地方，不要重复造轮子。快速验证这个方向的正确性后，再逐渐多加投入、丰满技术设计。不要自己YY、默默地做完，这样做出来的东西没有业务场景埋单。
2.3 站在巨人的肩膀上
当你需要制定一个产品化的方案或者工具和框架的时候，最好先放眼集团内部和行业进行一番调研，看看业界和其他同事是怎么解决这个问题的。尽量站在别人的肩膀上做出创新或者参与共建，避免小团队内造出重复和质量低的轮子
3. 技术深度
3.1 技术知识与技术能力
“技术”不能是一个笼统的词汇，我想它至少可以分为“技术知识”和“技术能力”两大部分。
什么是“技术知识”？知识就是 I KNOW
- 《TypeScript 从入门到放弃》
- 《React 从入门到放弃》
- 《Webpack 从入门到放弃》
- ......
什么是“技术能力”？能力就是 I CAN
- 我用 TypeScript 重构了一个大型系统，代码健壮性及研发效率大幅提升。
- 我用 React Hooks 给全栈同学进行前端培训，培训效果大幅提升。
- 我深入研究了 Webpack，优化配置，使得系统构建速度大幅提升。
- .....
3.2 培养技术视野
- 关注日常业界新技术。不一定要深入了解，但对新技术保持好奇心，大概了解它是做什么的，如果在工作中遇到匹配的落地环境，可以考虑写个 demo 看看是不是有价值
- 关注集团和业界的解决方案。在业务中发现问题，做解决方案的时候，我们很容易陷入自己的设计中，一脑子地想把所有东西都自己做出来，但投入会非常大，产出的价值是否一样大呢？不知道。大部分情况下，你想做的，在ATA能搜到，前人踩的坑，或者已有的成熟的解决方案，只要你去沟通去接触，就可以轻松地接进来，为什么要花大量的时间去造轮子呢？可以借力的地方，就去借力吧，把时间省下来，做你的解决方案中更核心更有价值的事情。
3.3 技术深度
一聊到“技术深度”，可能很自然地会认为是在某项技术上挖得很深，或者解决了一个业界公认难度很高的技术难题，但这只是“技术深度”的其中一部分：
- 体系化 / 系统化
体系化思维是认识事物的一种方式，在面对问题的时候，能够针对复杂的问题，列出关键的要素和解决方法，将散乱无序的问题，变得逻辑清晰，有章可循。
在问题的定位和解决的体现，从表象到本质，拆解出造成问题背后的原因，针对性地去解决本质的原因，而非治标不治本，有解决方案有节奏地解决。 - 全链路
除了前端的部分，向前向后的技术栈，还能挖多深。 - 单点技术挑战
在某个技术挑战上，你的思考和解决方案是怎样的。
3.4 技术与业务共赢
真正有突破性的、带来重大价值的业务成果必然伴随着技术上的深入乃至创新，所以在做业务成果的时候，一定会有让我们增加技术深度的场景。
4. 给你更多体感
培养业务感确实是一件非常有难度的事情，他要求你以业务而非技术为第一视角，这可能违背了很多人内心的“技术坚持”，但如果一直做技术，其实是很难有非常大的突破的，在工作中，如果能实现技术与业务共赢，将会助力你到达更高的高度。
改变的确很难，但结果值得冒险。
————
另贴上之前写的，关于系统优化的思考。
