第十二章:晋升后的 “第一仗”:卡在 “快” 与 “稳” 之间
陈默收到 “高级工程师” 任命通知的第二天,就被拉进了 “双 11 促销专项组”—— 牵头负责购物车模块的功能迭代,对接的产品经理是公司出了名的 “快节奏” 李薇。第一次需求沟通会,两人就针尖对麦芒。
“陈哥,这次要加‘购物车商品过期提醒’和‘跨店铺满减自动计算’两个功能,下周三必须上线,赶在预热期前跑通流程。” 李薇把需求文档拍在桌上,语速快得像打机关枪,“运营那边已经定了推广时间,晚一天都不行。”
陈默翻了两页文档,眉头瞬间皱起来:“这两个功能涉及购物车底层数据结构调整,还要对接优惠券系统的接口,至少需要 10 天 ——3 天时间连联调都不够,强行上线肯定出 bug,上次支付模块的教训还没吸取吗?”
“我知道要稳,但业务窗口期就这一次!” 李薇的声音提高了半度,“你总说技术风险,可运营那边每天都在问进度,你让我怎么回复?”
“技术问题不解决,上线了也是崩盘!” 陈默也来了脾气,指着文档里的 “跨店铺满减” 逻辑,“这里的折扣叠加规则都没写清,我怎么评估开发周期?”
两人吵了 20 分钟,最后不欢而散 —— 李薇觉得陈默 “太死板,不懂业务紧急性”,陈默觉得李薇 “拍脑袋提需求,不尊重技术规律”。散会后,陈默坐在工位上叹气:明明自己刚靠 “成果提炼” 证明了技术价值,怎么一到协作环节,又卡壳了?
“听说你和李薇吵僵了?” 张磊端着刚泡好的茶走进来,递给他一杯,“晋升后要带项目,沟通可比写代码难多了吧?你记不记得这周要开始的模块二课程 ——‘技术人的高效沟通’?第 1 课刚好能解决你现在的问题。”
他指着陈默桌上的需求文档:“你刚才和李薇沟通时,是不是一听到‘3 天上线’就急着反驳?有没有问过她‘为什么这么急’‘能不能砍非核心功能’?”
陈默愣了愣:“我只想着 3 天时间不够,没问这些…… 可她只说运营要,我哪知道还有别的原因?”
“这就是技术人最常见的沟通误区 —— 只盯着‘技术可行性’,忽略了‘对方立场’,还没听懂对方的真实需求,就急于反驳。” 张磊放下茶杯,“明天上课好好听,林姐会讲‘沟通的底层逻辑’,核心就是‘先听懂,再说明’—— 你得先知道李薇要‘快’的真正原因,她才会听你说‘稳’的必要性。”
第十三章:沟通的底层逻辑:先 “听懂”,再 “说通”
周三的课程教室,林姐刚开场就抛出了一个问题:“大家有没有遇到过这种情况 —— 和产品 / 运营沟通时,你说技术风险,他说业务紧急,最后吵得像鸡同鸭讲?”
底下瞬间举起一片手,陈默也跟着举了 —— 昨天和李薇的冲突,简直是这个问题的完美写照。
“这不是‘立场对立’,是‘沟通错位’。” 林姐点开 PPT,标题正是 “技术人常见沟通误区”,“咱们技术人很容易犯三个错:第一,只讲‘技术术语’,比如和产品说‘要改底层数据结构’,他听不懂,自然不理解为什么要花时间;第二,忽略‘对方立场’,产品急着上线,可能是因为运营活动有窗口期,你没看到他的压力,他也看不到你的风险;第三,急于反驳,一听到‘不可能的时间’就炸毛,没给对方解释的机会。”
陈默在笔记本上圈出这三个误区,每一条都对应着昨天的沟通:他说 “调整底层数据结构”,李薇可能没听懂这意味着什么;他没问 “为什么必须下周三上线”,不知道运营活动的窗口期;一听到 “3 天” 就反驳,没给李薇说 “能不能砍功能” 的机会。
“那怎么解决?” 有同事举手,林姐笑着翻到下一页:“沟通的底层逻辑 —— 先‘听懂’,再‘说通’。你得先搞清楚对方的‘真实需求’‘压力来源’‘可妥协的点’,再用他能听懂的话,讲清你的技术逻辑和风险,这样才能找到平衡点。”
她紧接着讲了 “积极倾听的 3 个技巧”,每一个都配了具体场景:
-
第一个是 “复述确认”:比如产品说 “3 天上线”,你别直接反驳,先复述 “我理解你需要下周三前上线,是为了赶上运营的预热期,对吗?”—— 这样既能让对方知道你在听,也能确认你没误解需求;
-
第二个是 “追问细节”:确认后再追问 “这两个功能里,‘购物车过期提醒’和‘跨店铺满减’,哪个是必须上线的核心功能?如果砍一个,能把时间放宽到多少天?”—— 找到对方的优先级,才能谈妥协;
-
第三个是 “记录关键信息”:把对方说的 “运营预热期 10 号开始”“核心功能是满减”“最晚不能超过 12 号” 都记下来,避免后续沟通时 “你说过可以延”“我没说过” 的信息偏差。
“这三个技巧的核心,是‘让对方觉得你和他是一伙的’,而不是‘对立面’。” 林姐强调,“技术和业务不是敌人,你们的目标都是‘把事做成’—— 你听懂他的需求,他才会听你的技术建议。”
陈默突然想起张磊说的 “找到平衡点”:如果昨天他先复述确认李薇的需求,再追问细节,说不定就不会吵起来 —— 比如李薇可能愿意砍 “过期提醒”,把时间放宽到 7 天,这样技术也能稳,业务也能赶得上。
以下非正文