核心内容摘要
青春的旋律，友谊的闪光——男生女生“搓搓搓搓”的那些年
那些年程序员背过的“不懂业务”的黑锅深夜十一点办公室还亮着几盏灯。
开发小李正在紧急修复线上bug产品经理发来消息“这个功能能不能加个快捷入口很简单的就几行代码吧”小李盯着屏幕上复杂的调用链路深吸一口气默默关掉了聊天窗口。
第二天晨会领导语重心长“技术人员要多从业务角度思考啊。
”小李想说些什么最终还是把话咽了回去。
这样的场景是不是很熟悉为什么技术人员总被说“不懂业务”“你们技术太技术了” “能不能不要老想着技术实现多想想业务价值”这些话如同紧箍咒常常萦绕在IT人的耳边。
但事实真的是技术人员不愿意思考业务吗我曾经问过一个十年开发经验的老程序员他苦笑“我们想的业务和他们说的业务好像不是一回事。
”技术人员眼中的业务可能是这个功能能承载多少并发数据一致性如何保证系统扩展性怎样而业务人员眼中的业务却是这个按钮放哪里用户更爱点这个流程能不能再少两步这个功能下周能上线吗看大家明明都在说“业务”却在两个平行宇宙里对话。
被误解的“技术思维”不是不懂是维度不同我的朋友张工是个架构师他有个经典比喻“业务人员看到的是冰山上面的部分——功能好不好用、界面美不美观、流程顺不顺畅。
而我们技术人员必须看到冰山下的九成——数据结构怎么设计、接口怎么划分、缓存怎么设置、异常怎么处理。
”当产品经理兴奋地说“我们要做个社交功能”时产品想的是用户互动、增长指标而程序员脑子里已经蹦出了时间线如何实现好友关系怎么存消息推送怎么保证不丢并发高了怎么办这不是不关心业务而是关心得太深、太底层以至于水面上的部分反而被忽略了。
那些无法跨越的“沟通鸿沟”曾经参加过一个需求评审会让我印象深刻。
业务方“这个需求很简单就是用户点一下按钮然后出现个动画然后跳转到新页面。
”技术负责人“这个‘点一下’是在什么场景下用户网络不好怎么办动画要兼容哪些机型跳转前需不需要预加载数据异常怎么处理......”业务方逐渐失去耐心“不用想这么复杂其他APP都有这个功能照做就行。
”技术方“那如果......”会议陷入僵局。
这种对话每天都在无数公司上演。
不是谁对谁错而是思维方式天然存在差异。
业务追求的是快速验证、快速试错技术追求的是稳定可靠、可维护可扩展。
就像两个人一起旅行一个说“咱们去玩得开心点”另一个却开始查天气、规划路线、准备药箱、买保险。
你能说第二个人不想玩得开心吗他只是用另一种方式确保“开心”能够实现。
被忽视的“技术债”今天少想一步明天加班到吐小王曾经在一家创业公司早期为了快速上线很多功能都是“先跑起来再说”。
一年后系统已经成了一团乱麻改一处崩三处。
新来的产品经理提出一个“简单优化”技术评估需要两周。
“这么简单的功能要两周你们技术是不是在偷懒”小王想解释这是历史遗留问题但看着产品经理怀疑的眼神最终只说了一句“我们会尽快。
”技术人员不是不愿意快速响应业务需求而是见过太多“今天图快明天重写”的血泪史。
那些被业务方视为“技术细节”的东西往往是系统能否健康存活的关键。
绩效考核的“隐形导向”在大多数公司技术人员的KPI是什么系统稳定性、bug数、项目按时交付率...... 很少有公司把“业务增长贡献”直接写入技术人员的考核指标。
不是技术人员不想关心业务而是在现有考核体系下保证系统稳定运行已经是巨大的挑战。
一个因为追求业务创新而导致的线上事故远比一个保守但稳定的技术决策后果更严重。
这就像要求消防员在救火的同时还要考虑如何美化火灾现场——不是不能而是首要任务不同。
打破壁垒其实我们可以做得更好那么技术人员真的无法改变这种局面吗当然不是。
多年的观察让我发现那些既能深入技术又能理解业务的技术人往往成长最快。
第一学会“翻译”把技术语言转化为业务价值不要说“我们用了Redis缓存QPS提升到5000”而要说“这个优化可以让同时在线用户增加三倍页面加载时间减少70%”。
第二多问“为什么”深入理解需求背后的真实意图当接到一个需求时不要只问“要做什么”多问“为什么要做”、“希望达到什么效果”、“用户会怎么使用”。
这不仅能帮你做出更合适的实现方案还能发现潜在问题。
第三偶尔“走出机房”体验真实的业务场景如果你做电商系统试着去客服部门听听电话如果你做OA系统去观察员工实际办公流程。
真实场景带来的冲击比一百份需求文档都强烈。
第四建立“技术同理心”主动沟通技术决策的业务影响当因为技术原因需要调整需求时不要只说“做不了”而是解释“如果这样做会导致什么后果如果换种方式能达到类似效果且更稳定/更快/更省钱”。
业务方也请听听技术的声音写到这里我也想对业务侧的同事说几句心里话。
当技术人员说“这个需求有风险”时他们不是推卸责任而是真的看到了你看不到的风险。
当技术人员要求更多时间时他们不是效率低下而是在为系统的长期健康争取空间。
最好的产品永远是业务愿景与技术现实的美妙平衡。
写在最后我们都是一条船上的人说到底技术和业务从来不是对立关系。
技术是引擎业务是方向盘少了哪个车都开不动。
那些最成功的互联网产品背后无一不是技术与业务深度融合的结果。
技术人员懂业务能做出更接地气的方案业务人员懂技术能提出更可行的需求。
下次当你又想说出“你们技术太技术了”时不妨换个说法“这个需求从业务角度我希望达到……从技术角度你看怎么实现更合理”相信我你会收到意想不到的积极回应。
因为最终我们都在为同一件事情努力——做出牛逼的产品。
技术人员不是不关心业务而是用技术人的方式关心着业务。
只是这种方式需要一点翻译需要一点理解也需要一点耐心。
毕竟代码最终要为业务服务而业务也需要代码的坚实支撑。
这世界从来不是非此即彼而是在差异中寻找最优解的艺术。