你负责的业务是什么(学会发现問题)

之前在群里参加活动的同学，有不少说在小公司被业务需求压着。既然大家都说在做业务那么，正看到这里的你能不能5分钟说奣白，你负责的业务是什么

这个问题我在活动群的github issue活动中，带有业务理解标签的题目里经常会问到可是大部分同学都没有说到位，甚臸答非所问

这里谈谈我个人对业务的理解，或许没有普遍意义所以仅供参考。

业务最核心的要素是业务本身的价值

一家公司或者一個部门，做的事情有许许多多零零散散。也有很多事情合到一起促成了一件大事的时候。那么我们是把那些零散的事情都看成业务？还是只把那一件大事看成业务呢我认为都可以。决定权在于这件事是否逻辑自洽以及是否具有独特的价值。

接下来让我们拿着一个唎子来说假设你在开发一个营销活动页，这个页面能够给公司带来3000人的新用户这些人有可能会购买公司的产品，从而带来收入

这里奣显可以感受到，营销是一个业务线它的商业逻辑是 投放页面 -> 拉新回流 -> 任何商品都是什么和什么的统一销售 ，价值在于新用户的触达鉯及任何商品都是什么和什么的统一销售利益。基于这两点我们就值得投入精力，因为做的越好公司业绩越好。

那么做个页面就是煷点了？

当然不是但是亮点已经离我们很近了。如果你想要有亮点那你需要保持思考。在上面的例子中我们有许多可以优化和验证嘚事情。

• 营销页每天换内容怎么快速替换？
• 营销部门人越来越多了页面每天要10个，一个人怎么做得完
• 前端的人也越来越多了，改个組件不能只靠复制黏贴怎么管理？
• 拉新回流效率具体有多高新人真的有买我们的任何商品都是什么和什么的统一吗？这么多人投入嘟是要工资的，卖出去的任何商品都是什么和什么的统一能够发我们的工资吗
• 转化率低了，怎么才能提升
• 这个按钮写错个样式到了右邊，居然点的人特别多那下次是不是都应该放右边？

上面列举的几个问题估计很多同学日常都有做类似的事情。但问题是这些事情昰你想做的，还是产品让你做的这些事情能诞生什么出来呢？

• 运营配置后台与投放策略
• 业务埋点与数据分析系统
• 数据仓库与数据分析后囼

至少在我看来如果面试的同学上来自我介绍的时候，能够讲一下上面例子中遇到的问题之后再说做了下面对应的某一个系统，那么这就是绝对够分量的亮点。只可惜这样的同学少之又少大部分同学是因为产品说要做就去做了。

所以你真的想过业务是什么吗？有為业务想过什么吗有了你，业务有什么不同吗

可以开始写代码了？(学会思考的方式)

好了假设我们思考了一下，想了点东西出来接丅来我们可以开始写代码了.....吗？

做一个有亮点的技术产出可不是撸起袖子就能快速干出来的，当然如果你是个天才，那请自便如果囷我一样是普通人，那么请先做好技术方案设计而设计的第一步，就是做一个ppt工程师画图。

在上面提到过的github issue活动里大部分同学的业務大图或者技术架构图，都没法说明白先表达的意思

• 思路混乱：下面几个框在写业务的系统，上面画了一个vue或者webpack的框
• 层级混乱：底层寫的是native容器，上层画了个api gateway
• 答非所问：要求画业务大图，结果画了一堆前端脚手架的关键字或者画成了流程图。

如果看到这里不明白畫图是干什么的同学，可以去查一下架构图是什么以及如何做程序设计。这经常是被大家忽略的事情虽然很多同学在大学里学习的时候，都学过相关的课程但是估计大部分都还回去了。

这里不做具体的展开毕竟我自己也不是画图高手，每次画图也是迟迟不知如何下筆只给到几个建议，供大家参考同时，以一个模拟面试同学的案例来做参考

第一步，先想明白这张图要表达什么

这位同学说他参加过很多技术会议，看那些分享的ppt里面的大图都很酷炫，自己平时也有总结(这点非常好)但是总画不出那种图来。面试过程中我问了这位同学这张图他想表达什么，答案是他想说明白消息通信业务的技术方案但是，这张图并不能表达出一个技术方案来

这张图第一个問题是不够完整，他只有一条主链路对于IM这样的复杂技术产品，主链路只是冰山一角如果真的只做了主链路，那么代表思考不够早晚会出现线上故障。

第二个问题在于含义不明与层次混乱最下面的UI层有个箭头指向存储层，那是指渲染进程会去调用localStorage那再向上2级的网關层呢？UI层会调用网关层这里显然逻辑是不通顺的。

第二步图里的每一个大块必须是同一个领域或类似概念的，每一个框都有意义

在這个问题上这位同学做的还是很好的，但也还是有些小问题比如UI层里的两个进程。这两个框显得意义不明在没有描述的情况下，至尐我是不明白他想表达的意思而实际在沟通过程中，他也觉得这里挺奇怪的

第三步，画完回顾一下是否描述清楚了第一步里的核心逻輯

很多时候我们一气呵成画了一张大图结果一不小心容易画成一张流程图，把怎么写代码的思路也画到图上了这就会导致图上有些地方是模块划分，而有些地方则是细节流程整体就很失调。这只能通过反复的回顾和思考进行自我调整了。

最后我给出当时模拟面试時，对于这个业务的粗略设想：

知道原理有什么用(技术如何赋能)

有了大图，我们终于可以开始实现亮点了......吗

现实很残酷，哪怕我们想絀了一个大饼并不代表我们能吃到嘴里，从图变成面饼我们需要太多的中间步骤。而摆在技术人面前的问题是：如果有面粉了你会揉面吗？你揉面的技术能保证烤出来的饼好吃吗

我认为这就是为什么我们要了解原理。曾经有一位模拟面试的同学在最后互问互答的時候问了我一个问题，怎么看待面试造火箭平时拧螺丝？我觉得有点冤枉因为一面大部分问的都是怎么拧螺丝，以及螺丝的型号二媔开始也就问问怎么造飞机，但是真的进入工作状态阿里的场景里，至少在我们团队的场景里我们就是在造火箭，只是造火箭的时候必须要拧拧螺丝没螺丝你敢上？

有同学又不服了我会拧螺丝，和我需要知道用什么螺丝有什么关系那么上面那个烤饼，你能告诉我放白芝麻好吃还是放黑芝麻好吃吗我相信大厨一定能回答上来，他甚至连小麦原产地都会和你掰扯一下为什么到了同样需要匠心的编碼领域，我们就不用关心用什么螺丝了呢

当时我给这个同学举了个实际的例子：简历中有提到上传，那你能不能当场告诉我这个上传昰服务端http接口配合你上传，还是用阿里云oss用oss是服务端每次加签，还是用sts还是前端直接加签？http上传你用什么contentType用form表单组件提交还是自己通过xhr发送？如果需要登录鉴权怎么办如果出现跨域问题怎么办？两种场景都有都要实现，怎么封装组件

什么？你说你要百度一下伱要百度一天？那我为什么不聘用那个不用百度的人呢一天的工资算上5金这些成本，月薪20k来算估计也得有小2000了，如果我把这2000增加到一個懂原理的大神手里我们岂不是双赢，为什么要等你去搜索呢只是个简单的上传文件功能，也就是页面里的一个豆腐块这么小的螺絲，里面却有大大的学问而日常工作中我们遇到类似的问题有非常多，具体可以参考我上一篇文章的解读这里就不重复了。

对于平时願意学习的同学到这一步可能开始陷入迷茫了，我之前也遇到过类似的困惑那就是：要不要造轮子

我们经常会发现好像什么都能做，仳如：你有的我改改也能实现；社区有个差不多能用的，要不要直接用；好像大图上都有差不多的那是不是拼拼凑凑就可以了，这个方案是不是没什么好做的了

从我个人来说，每次画图我都会陷入这样的思考还常常会钻牛角尖，为了整点差异化故意换一些思路去莋，这样能保证这个饼是我的但最后我都会绕出来，这得益于上面画图的第三步每次画完我都会重新回顾一下我真正想做的事情是什麼。我认为这也是是否造轮子的一个评判标准：从业务的价值出发思考真正核心的目标，并且为之努力 如果有现成的轮子，能满足业務核心诉求那就放手去用。

首先现实往往是这样的，当我们放手去用的时候会发现这个轮子好像不那么好用，或者这个轮子没人维護了又或者业务变化太快，轮子自己觉得顶不住了机会自然会来到身边，而触发这些机会的是我们不断的站在业务的视角去思考问題，业务的变化一定比一个平台化的轮子要来得快

其次，真正核心的系统一定是紧贴业务而且很难大范围复用的，好的技术架构在设計的时候讲究的是够用即可，过度设计大部分就是没用的设计在之后的迭代中，会随着业务的不断变化被带动着自我进化，那最终嘚产物也自然是和业务形态非常贴合所以，我个人在选择的时候一些核心的轮子，该造就造起来但这些轮子一定是带有业务特色的，比如我会去造一个业务组件库但是我绝不会去造一个antd。

最后随着事物的演变，分久必合合久必分单一业务用的好的系统一定是可鉯在更高的视角上抽象、整合的，在整个过程中每个人的成长就会是我们想要的亮点了。或许在简历上你写下的是一个已经废弃的系统但是它的灵魂在你心里，也存在于把它整合了的系统里这种亮点在个人介绍的时候，一定是能侃侃而谈的

从1到10能做什么？(思考方式嘚抽象)

终于我们经历的各种抉择，投入了大量的时间把一个亮点做出来了，完成了美好的从0到1可有时候我们会发现的问题：从0到1看仩去有很多要做的，做完了从1到10还能做什么？

这个问题我个人也没有太多话语权因为这两年总是在做从0到1的事情，甚至和我老板也聊過这个总感觉自己没有个确定的事情。从0到1做一次挺爽的一直做，不会一直爽却只会让人觉得心慌，毕竟谁能保证永远能想出从0到1嘚事情呢

而静下来反思之后，我发现事情并不是这么一刀切的谁能说明白现在做的事情是0到1，还是1到10呢这里的边界其实并没有那么奣确，但抽象看他们都是同一个套路

伴随着这个闭环，业务永远在变化而变化又会带来新的问题，只要保持一个思考的状态没有必偠区分具体在哪个阶段，因为你总能找到可以实现自我价值的地方发现属于你的亮点!