|技术人的灵魂 3 问,阿里工程师如何解答?( 三 )


最后的技术结果跟业务结果如何衔接?
其实这个小标题有点伪命题的意思 , 如果一开始我们就把业务理解的很清楚 , 执行没有偏离航道比较专注目标的话 , 不大可能会出现拿不到业务结果的情况 , 最后只剩下一个问题:拿到业务结果的同时技术价值如何体现?
从我自身出发 , 也常常有同学问我 , 在业务做开发 , 重复造轮子会被人挑战 , 但事情都有人干了我们的价值在哪?我之前一直都会回答 , “搞基础技术的团队一直在基础工程/技术领域深耕 , 他们也需要关注从技术价值到业务价值的转变和衔接 , 本质上缺少业务场景 , 如果我们与他们合作就形成了互补 , 既拿到了业务结果同时也能从自身技术成长上得到一定历练” 。
但之后我回想这段对话 , 是有很多问题在里面的 。 从业务工程师角度出发 , 我们要关注的核心就是保障业务先赢 , 如果没有达到这个目标就容易变成工程师自嗨 。 所以我们在业务端需要的是有技术视野能看到集团其他团队或者外部团队在做的事 , 能主动交流让这件事变成共赢 , 如果没有其他人在搞 , 我们去搞要有人站出来看这个投入产出比是否合理?也就是我们在开篇说的议题度和解答质都高的有价值的问题 。 这个问题在集团其他团队是否存在共性 , 我们解决了能否为他们带来价值?当然结合我们在前面讲到的在业务中发现有技术价值的问题 , 其实这里就有一个比较明确的答案 , 重中之重就是做之前把 Why 思考的清楚清晰 , 做最正确的事 。 只有做到这点 , 解决这个问题带来的业务价值就自然而然非常清晰的定位出来 。 所以说最好的工程师必须要懂产品 。
也写给未来
小聊一下题外话 , 组里有同学会问我业务前端未来是否会被淘汰?因为我们在做的 lowcode/nocode 是在革自己的命 。 其实产生这种想法首先就是没有站在集团未来发展的角度去思考也就是常说的屁股太小 , 其次是没有站在整个前端领域去回顾前端发展历程导致的悲观和担忧 。
从目前在做的方向上来说 , 还是要思考如何解决低质量代码建设和低效的重复工作占用工程师大部分精力 , 将工程师的能量解放出来提升集团整体的研发效能 。 另一层面从前端以往在系统分层里的位置一直都属于应用层 , 就是最上层的表象/展现/渲染 , 应用层在过去几十年间经过了不断的变化和演进 , 职业也从最早的 GUI 工程师演进到之后的 web 前端/客户端研发工程师 , 这中间也经历过 flash 工程师的时代 , 在此期间应用层/展现层一直都在变化 , 所以前端同学总觉得状态是一直在学习新知识 。 但这个发展历程其实是有规律可循的 , 所谓万变不离其宗 , 应用层虽然在不断变化但无非都是朝着两个大方向在发展 , 一个是工程效率提升(工程角度出发) , 一个是图形图像研究(用户角度出发) 。 这两个大方向上目前也有非常复杂庞大的树状知识体系 , 并且还在不断延伸 。 同时随着机器学习领域的兴起和硬件性能、网络带宽的提升以及人们在视觉呈现设备上的升级 , 带来的可能又是新一轮的技术洗牌 , 然后在两个方向上再来一次 。 所以从这个视角出发未来前端是不会消亡的可能只是会换一种形式存在 , 但是不学习的工程师是会消亡的 。
最后
最后我想说的是来到一个新业务不要着急的去拿这两个结果(业务和技术) , 所谓“潜龙勿用” 。 要先去看业务在集团所处的位置 , 怎么和其他业务产生关联的 , 要去收集信息和问题 , 带着问题深入去做事情 , 通过跟其他人的信息交流补全业务痛点 。 先收集问题 , 边做边思考 , 先沉下心做业务项目 。 要有导弹型思维 , 就是不管三七二十一 , 先干起来再说 。 在行动中实现智能导航 , 锁定并跟踪目标 , 根据实际情况修正自身路径 , 直至击中目标 。
【|技术人的灵魂 3 问,阿里工程师如何解答?】其实写了比较多 , 也是对我做事情的方法论做了一遍梳理和总结 , 也是说最好不要让业务推着你走 , 而是最终要做到你带着业务走 。 这个“带”可能最初是理解业务打法之后的一种业务朝着你理解的方向去走的体感 , 但经过长期训练 , 这部分其实可以做实 , 最后真的是你通过技术创新引领行业变革最后驱动业务向前推进 。 当然这些是我来阿里三年的体会 , 虽然在来之前也已经工作了七八年 , 但在阿里成长的速度远远超过之前的成长 , 并且也才刚刚三年还是个“新人” , 所以在这里也给自己个寄语 , 希望五年、十年之后我的思考又会升华到一个层次 。 同时也欢迎大家拍砖/评论 ,原来我都是战战兢兢发文跟大家说轻拍 , 需要鼓励 , 但之后也是发现鼓励是最不容易发现问题 , 这会导致发现不了自身思考上的盲点和盲区 , 缺少成长路上的经验值 , 所以这里鼓励大家一起多交流 。


推荐阅读