原创 等你加入的 2025-06-20 18:02 上海
在得物，不做前浪后浪！看得物青年技术中坚如何实现跃迁式成长与专业扎根。
上期，我们看到了三位技术同学如何在得物技术快速成长为中流砥柱，勾勒出拥抱变化、勇于担当、持续精进的新一代青年技术中坚群像。
本期，镜头转向更广阔的“战场”——我们来听听他们在复杂业务场景中的深度思考：如何平衡业务需求与技术创新之间的关系？"问题拆解三板斧"是什么？如何在需求会上预判到潜在的技术风险？
关于他们
@渭君：
职业生涯始于一家互联网公司，专注于图像视频内容理解算法的研发。目前在得物技术部算法平台担任美妆AI鉴别项目的负责人，入职时长4年+。
@明天：
曾就职于携程，从事搜索算法工程师岗位。目前是得物技术部算法平台的交易推荐算法工程师，主要负责交易首页混排工作，入职时长5年。
@Fly：
曾就职于华为，负责网关相关工作。目前是得物技术部交易平台-寄存团队的技术负责人，业务内容主要包括寄存入仓、寄存出仓、仓内治理、直发物料、经济快递、履约规则等，入职时长4年+。
Q1：在得物主导或参与的哪个项目
让你感到 " 能力边界被突破 " ？
@渭君：
真正让我突破能力边界的，是在主导AI一致性质检项目的过程中。这个项目不仅深化了我对业务本质的理解，更提升了跨部门协作的效能，让我在独立负责项目的实践中获得了能力上质的飞跃。通过技术方案的持续优化，项目直接提升了供应链质检人员的工作效率，也为公司创造了切实的效益。这一经历不仅拓展了我的技术视野，更重要的是培养了我owner项目的全局思维和决策能力。项目成功的正向反馈，不仅突破了我的能力边界，更让我在技术实力和项目owner能力上获得了双重提升，同时也建立了更强的专业自信。
@Fly：
我主导过最复杂的项目是仓储托管项目，整个项目涉及的协同团队非常多，几乎重构了得物的在仓库存流转体系，项目收益很大但同时业务风险、技术风险都很高。
MRD+PRD阶段，我作为架构师协助业务和产品输出项目的落地方案，过程中基本每天都会评估到很多新的问题需要一起探讨解法。项目方案就绪后，按照业务预期的上线计划，协调拆解需求，评估优先级，最终分三批上线交付全部内容。
项目开发阶段，我作为交易侧的技术Owner，组织各团队输出技术方案，协调解决交付过程中出现的各种技术问题，过程中也出现了很多新识别到的改造内容和业务侧的需求变更，与产品、业务一起评估风险和交付优先级，保障主体链路的交付不受影响；上线前组织技术侧整理上线的checklist、圈品实施的SOP、各种异常情况的处理预案。
对我个人而言，压力和挑战是非常大的，对自己的沟通能力、协同能力、架构能力、业务敏感度、业务细节把控能力、项目管理能力、风险把控能力都是很大的考验和突破。
Q2：在算法模型迭代过程中
如何平衡业务需求与技术创新之间的关系？
@明天：
个人觉得蛮难的，我一般沿着下面两条路摸爬滚打：
业务共性部分，追紧业界前沿技术来提效。
以从事的推荐业务为例，业内有不同的企业和团队在做相关的事情，且存在较大业务共性。在这块，不能闭门造车，充分利用业内开源成果（论文、博客、开源项目等），广纳输入帮助自己少走弯路。
业务特性部分，从技术回到业务中去因地制宜。
就算是共性的技术迁移也需要适配，而不同的业务总有一些自己的特性，对于这部分更需要深入到业务中去，理解痛点。对于推荐算法而言，业务是技术的起源，可以说没有推荐的场景，应该也不会诞生推荐算法这一技术分枝。
@渭君：
不会一味的为了创新而创新，会始终以业务落地为优先级，采用一些调研、小范围控制变量短时间验证创新技术是否适用当前业务，一旦确认可行后，通过分阶段迭代的方式，筛选一段场景较为简单的业务需求采用创新技术来实现，同时制定相对应的业务目标并对齐，也会起到督促作用，同时也会讨论出可兜底的方案，以防创新方案存在风险。这样有方案兜底可以不影响业务目标达成。总之，技术创新是需要长期跟进学习的，才能游刃有余的用起来。
Q3：遇到效果提升瓶颈时
你的系统性解决思路是怎样的？
@明天：
瓶颈还是挺多的，也不是每次都能顺利解决，不少经验也是从南墙中撞出来的：
思路，深入业务，关注前沿。
有思路但不符合预期，回到初衷，控制变量。
23年底精排做的相对深入后，想要升级混排突破瓶颈，但是经验缺乏，业内可参考的思路也不多。调研了同行有限的试错经验，结合业务特性，基本明确场景是合适的，此外在技术选型上明确了生成+评估的Listwise两阶段框架，回过头看大幅减少了试错成本。
在落地过程中，为控风险，一期定位在框架改造论证方向，但刚上线效果不符合预期。因变量太多，结合经验，框架开始做减法功能退化对齐，利于排查问题，而后再做加法增加升级点，一个季度左右完成落地，并成功打开瓶颈，成为了一个主要迭代收益模块。
@渭君：
面对模型效果或业务指标遭遇瓶颈时，一般会分四步走的思路。首先通过数据分析量化瓶颈持续的周期；其次，对影响效果的关键因素进行系统盘点罗列；接着，通过模块化拆解和精细化分析，逐步定位制约效果提升的核心因素；最后，针对性地制定优化方案，通过迭代实验和效果验证，实现瓶颈的渐进式突破。
Q4：当面对复杂系统无从下手时
你的 " 问题拆解三板斧 " 是什么？
@Fly：
明确项目目标：基于目标来看系统架构层面要做什么样的调整来支撑，架构层面的调整会影响到哪些业务模块以及需要哪些协同方；
明确推进节奏：针对每个业务模块需要协同方细分评估改造的影响面、具体方案，根据推进节奏、预计工作量和协同方可用资源确定需求交付的优先级、简化版和完整版方案；
管理项目交付：完成需求方案和技术方案评审，落地的方案要具有可灰度、可监控、可回滚的能力，日会收集进度和风险，将交付的过程风险和上线风险降到最低。
Q5：从什么时候开始
你能在需求会上预判到潜在的技术风险？
培养这种敏感度的秘诀是什么？
@Fly：
预判需求潜在的技术风险是每个开发同学都应该具备的能力，有些同学评估得全面一些，而有些同学可能会稍微弱一点。
我是自从23年4月份做了团队的PM之后，除了自己承接迭代需求外，还需要把控团队整体需求的交付质量，规划团队稳定性保障事项，从那个时候开始，会更加在意这方面的问题。我自己总结了几个方法可以参考：
保持勇于发问的习惯，不要怕别人觉得自己问的问题太低级，有思考才能问出问题，如果没有提问题的习惯，那么就没有思考的习惯；
对团队整体需求要有足够的了解，通过参与日常需求评审和技术方案评审来保持自己业务认知的“新鲜度”。
了解小团队、大团队的技术规划，技术规划一般围绕着[风险问题] > [痛点问题] > [效率提升] > [功能增强] 等方面展开，换句话说其实都是存量需求承接过程中遗留下来的历史债务，从历史债务中吸取经验和教训，要总结如何在增量需求承接中避免再出现这些问题，避免雪球越滚越大。
养成学习的习惯，要给自己充电。如果只会加减法，突然碰到乘除法，想做也力不从心。
Q6：在技术快速迭代的焦虑中
怎样建立自己的判断力而非盲目追新？
@明天：
焦虑是常有的，实话说我也不知道自己能有多少判断力。方法上我尽量做到知彼知己，感觉这个可能帮助大一些。
在知彼上，主要是针对新技术，首先需要学习理解，搞清楚可以解决什么问题、适应场景、应用方式以及注意事项；
在知己上，就是回到自己的业务，分析有没有类似问题，再看适应条件和可行性是否具备，然后再决定技术如何应用。
@Fly：
在生产实践中引入一款新的技术组件之前，需要做好选型比对，包括技术组件的功能清单比对、成熟度、稳定性、运维支撑度等等方面，并经过团队技术专家、运维专家、安全专家Review通过之后再投入使用，技术组件的安全和稳定始终是第一位的。当然我们还是要有持续学习新技术的热情，了解新技术的实现原理，增加自己的技术深度、技术广度、技术经验。
最后 请用一句话形容
你眼中的得物技术团队精神内核
@明天：
拥抱变化。
@Fly：
我们追求的是更高效地写出正确的代码，语法正确、逻辑正确、方向正确，这是件很有挑战的事情。
@渭君：
我眼中的得物技术团队，始终以夯实基础为根本，以鼓励创新为引擎，以解决实际问题为导向，在追求卓越的道路上，矢志打造上海最好的技术团队。
这三位优秀伙伴的故事，是得物技术人才成长的缩影，也印证了技术成长的无限可能——年龄并非界限，持续的学习、务实的实践、开放的心态以及对技术价值的笃信，才是通往未来的关键密钥。
技术星群，期待同频共振
得物技术部始终坚信，优秀的技术人才是驱动创新的核心引擎。我们珍视每一位技术人的成长潜力，致力于打造一个能让技术人实现价值、共同成长的平台。如果你也渴望在业务洪流中锤炼真本领，在技术浪潮里实现自我跃迁，欢迎加入我们，共同探索技术的星辰大海！
得物技术众多岗位热招中：
往期回顾
“
扫码添加小助手微信
如有任何疑问，或想要了解更多技术资讯，请添加小助手微信：
