产品狗视角下的“协同作战”

[IvanCrancy]

此故事纯属虚构，如有雷同，那就是你不走运。

业务在大群里，反馈了个 bug ，看着像是 A 工平时负责的模块，遂私聊以求快速定位解决问题

我：

业务反馈了有个问题 XXXX ，A 工你看下是不是你那边的问题哈！

A 半天后回复：

看了下，我这里处理的逻辑没涉及这个方面，不是我的问题，可能是 xxx 模块的。

我：

那这个 xx ，要找谁？

A：

不清楚，你问问 B ？

我拉群。喊上 B ，截图聊天背景 并 @B

B 半天后群里抛了个代码截图，上边没有任何注释，不知道是哪个业务功能的实现代码，2 分钟后，补充了个文字回复：

这个也不是我这边的问题，这个异常不是我这里抛出的。

我（强忍火气）：

那请问是哪里的问题？业务催的急麻烦看下。

B：

感觉是 XXX 中台返回的数据格式不对。

我：

… 那这个中台的接口人是谁，帮忙拉下哈～

十来分钟后，B 在聊天框里，贴了个中台干系人 C 的工号，此外没有一丝多余动作，出招极其干净利索，看来是个高手。

无奈，我只能自己拉了 C 进来，重复一波截图和背景描述；并 @C 协助定位 bug 。

过了半天，大概是师出同门，C 同样抛了个代码截图，不过明显 C 修炼功力更强，他还额外配了个日志记录，说：

“我的代码运行正常，应该不是我这块的问题。”

一气呵成无懈可击，看来是高手中的高手。

我（爆炸边缘）：

那么请问这个还可以找谁排查呢？

一整天没人理。沉默，是今晚的康桥。

业务持续催我屁股，无奈，怒拉多方领导进群，又又又说明了一波问题和截图背景。

领导说了一套套话，下达指示： 你们几个，要及时解决，不要影响业务。

半饷，C 拉了个外包同事 D 进来，指示他看看翻下群聊天记录，并定位具体情况。

十分钟后，D 回复，这是 xx 模块的上游接口返回的信息突然变了格式，我刚刚加了个逻辑转译了下，现在应该 ok 了，你生产环境看下。

我验证了下。数据无阻碍了，群里回复 “OK 了谢谢”

其他人也回复 “辛苦了！” 还有各种👍 👌🤝emoji ，中间穿插着些拉通、对齐、闭环、协同作战、事成人爽 …这类看不懂的名词，==空气中充满了快活的气息。==

最终大家在欢声笑语中打出 gg 之后，我把工单状态改为了“已闭环”，群被我解散了。

过了两天，对方领导私聊我，说他们部门年底参与评选优秀团队，想让我写两段业务评价，帮忙写点好话发个表扬邮件。

我打开 ChatGPT ，2 分钟后交了作业，同时花了十来分钟写下来这篇小作文。

看来大家春节前都在摸鱼刷 V 站 我发这个帖子，并不是为了批判那几个开发老哥，相反我其实蛮能理解他们的；我只是嘲讽说我厂的风气，明明各种机制和流程不健全还整天把团队、协作之流的名词挂在嘴边，最后解决问题靠外包老哥罢了 ，大伙儿就当放假前看个小故事，看个乐得了。

很多大佬给了建议和分析，都很有道理：那我就姑且补充下：

1- 应该一开始就直接 it 负责人或者项目老大可能会更快解决问题，不要自己一个个问，如果不是自己的模块，毕竟程序是没义务帮你的。
按道理说确实也应该是这样，然而大公司里大佬各种会议，所以一般都是已读不回的，顶多会牵引让你找某某组长，而那个组长，就是里边的 B 君；至于程序有没有义务帮你，鄙人觉得，看每个人的视角和性格吧，可能程序角色是这么觉得的；但也像其他朋友建议那样，产品也大可以直接找测试提单，群里喊一下给测试和开发组长，给自己留痕证明自己有主动推动过就行了，至于后续进度大可以不管，反正 bug 解决时效也不是产品的 kpi ，但是问题还在那，业务还是在受影响，总得有人去踢一踢，对吧；

2-测试在吃干饭的？出了问题一声不吭？
嘛 ，这个是有的，只是我没写的很详尽，我的锅；大概故事是，测试也提 bug 单了，但是总得找到相关方去定位和修复，然而他找人的结果也基本跟我一样碰壁，结合第一条，很多时候这种情况为了尽快解决问题，只能死马当活马医，摇人定位，至于为啥不上升反馈，参考上一条；

3-外包直接修改生产环境？你们这迟早爆炸的；
是的，你没看错；敝司里外包只是编制待遇不同，实际上为了“开发效率”，git 仓库和数据库等等的 access 是一个不少；没过测试就直接修改生产环境的情况，正式工其实干的更多···至于你问炸没炸过，那肯定是有炸的···但是为啥还没收回口子，那得问运维和开发老大了，或许是觉得炸的不严重吧（笑）；世界都是个巨大的草台班子，并不是所有单位都有严格的运维流程，有了流程也未必都会严格执行；我甚至见过直接将接口的私钥直接明文放在群聊里的。 什么？你说我是编的？ 好的那就当我是编的吧，也顺便真心预祝各位以后永远不会碰到这种事情。

4-本质问题是流程和规范问题，你为什么不去推动建立这种机制？为什么没有一个接口人清单列明什么模块出了问题的时候应该是哪个开发负责跟进？
确实是这样的，我很认同。不过呢··很多事情，并不是一个产品能决定和推动的，很多厂子里边会有复杂的利益关系和派系竞争；很难协调的，什么？ 您说难办那就别办？ 事实上我已经决定年后跑路了哈哈哈哈哈，so ，世界卫生组织关心您.jpg

[ignore]

你出发点就是错的,直接找技术负责人就完事了

[IvanCrancy]

发出来才发现格式变了，V 站迷一样的 markdown 兼容···随便了，反正也是随便吐槽，各位老爷凑合看吧

[arron2022]

太卑微了吧 我们这产品一般就直接群里把问题抛出来。没人认领响应，就马上 at 项目负责人 at 部门经理

[ho121]

看到很多问题：
1. 上游接口返回格式变化，没有通知下游。
2. 修改代码逻辑没有经过评估和测试直接上生产。
3. 改动逻辑直接在生产环境做验证，而不是先在测试环境验证。
4. 问题确实是闭环了，但没有复盘，没有考虑下次如何避免类似的问题。

[crazyzzm]

这个和团队文化、个人意识有关。
个人意识方面，不怕背锅，主动跟进，但很“个人”。而团队文化，是可以作为兜底弥补个人的不足的，平时团队多宣讲强调，必要时纳入绩效，团队整体还是能有所改变的。

只不过绝大多数人没这个意识，而团队中管理的也没这个意识的话，团队也就那样了。

[asdhak]

@ignore #1 这是对的，直接找开发人员，能理他就不错了。还他以为这是哪个模块的问题，然后找具体人

[kisick]

应该直接找领导

[buruliu]

最后还是外包干了活。

[hi2hi]

外包才是干活的苦力

[null2error]

不太理解是什么场景下，要产品去做定位梳理的事情，于情于理，我们狗产品可以做，但是不能这么卑微的做吧~
如果是非正式的需求推进，最好还是确定 一下对方和你关系 有没有这么好，人家要做多余的事情，何必呢？

至于实操层面，我自己是三级响应模式

lv3：我就能定位，且能明确这道这一坨是谁拉的（会辅助一个确认过程，总有关系好的开发吧~），直接过去叼 ta
lv2：不能定位或者不知道是谁拉的，找研发接口（我们这里是技术负责人），不能一眼看清楚的问题肯定会推三阻四，所以会辅助一个：我已经跟测试报备了，如果你这边短时间处理不了，我让测试报 bug ，省的回头忘记了。
lv1：lv2 找了人，大致看了，没回复或者没人认领，要么是很难搞要么就是有人要背锅，这种情况下轻声细语已经没用了，一定要出重拳！（拉会，产品老大，研发老大，测试老大，项目经理一起来（我拉会只拉这几个人，我自己组内只要叫上老大来给我撑腰就行了，其他组内要拉谁过来分锅，他们老大自己决定

作为一个产品，摇人才是第一生产力 [狗头] ~

[gopher404]

个人建议，如果不清楚该项目的任务分工范围，应该优先找知晓该项目分工的负责人比如项目经理，而不是直接丢到群里。再一个，如果经常有这种情况，应该优化自己内部处理这种问题的机制和流程，以便团队更好的定位和协作。

[dfdd1811]

外包更可怜…我从不为沟通的事生气着急，找小兵能解决解决，解决不了就找对方领导，再不行找自己领导跟对方对接。我各方都通知了，不接锅

[gxt92]

全程测试竟然不吭声？我觉得测试负责人应该开掉

[akakidz]

我司会有专门的开发负责人对接问题，不过问题下来之后 开发内部还是会有这个场景🤣

[LuXiaoR]

不会技术的产品不是好产品，哈哈哈，产品好好学习技术，不求人，还给自己加分🤣

[SmartTom]

为何不换个角度思考问题的本质呢？

[keyfunc]

我觉得直接 at 测试负责人就行了，测试有时候比开发更懂代码～

[GuLuDaDuiZhang]

一开始就不应该自己私聊找开发的，要让开发负责人来处理。直接在开发或者业务的大群里 @开发负责人呗，让他排人来看，业务催你你就崔开发负责人。

[freak118]

什么意思？外包直接修改代码逻辑还上线了？ 你们公司流程这样随便吗

[raydied]

恩恩，我以为这里没产品

[Vegetable]

为什么外包能迅速更新生产环境啊，这不是早晚爆炸吗

[blur1119]

@LuXiaoR 扯呢，学了你又不用，给你贴代码你也看不懂

[courtier]

哈哈，别说产品了，我一个开发去找那些负责搞内部工具的部门帮忙处理个线上问题，也能在他们部门里遇到 ABC 三个组互相踢皮球，明明都坐一块非要我去传话，后面火了把他们直接拉到一个人的座位上让他们自己面对面来扯皮

再后面回来后直接跟我们部门的技术负责人吐槽了，最后可能他们几个组也被他们的技术负责人拉去讲了，反正过了几天后在大群里发了个对接的流程：找到谁的就让谁来全程跟进下去直到处理完成（但我觉得不可能可以执行得下去，都是话术）

[LuXiaoR]

@blur1119 那就怪自己笨吧 看不懂学个叼毛

[xz410236056]

@Vegetable 没外包这团队早完了。

[iphantom]

我说下我的处理流程。发现问题后，1 、先拉上测试，和测试同事一起测试环境复现问题； 2 、确认问题模块后，即使知道是具体那个开发负责的（比如 B ），那么会同时拉上开发负责人 A 和 B （不知道就不拉），把问题及现象告知； 3 、然后及时跟进 A ，让他反馈问题原因和修复方案~

[jydeng]

外包能直接上线，分享你刚编的故事

[daimon1]

一楼正解。我是 pmo 部门的，团队询问这种情况时，我都引导找技术负责人沟通

[SuperDaniel313]

客户催业务
业务催产品
产品催测试
测试催研发
研发修复
测试验收
产品验收
业务验收
客户验收

不是吃饱了没事做，是官僚制更高效。当然，有时候更搞笑

流程和规范、制度的缺失，不可能靠爱和责任能弥补的

[daimon1]

@daimon1 其实想想我司的流程，岗位职责也是蛮清晰的。这种情况就是要找团队的技术负责人来沟通，包括后续怎么安排修复上线，这些流程都是有的

[sky3hao]

产品狗你好, 产品狗再见

[tim9527]

都是甩锅大师

[DonaldY]

你们需要一个工单群。
可以指定技术处理

[THESDZ]

@ho121 #4 关于 1 的问题，我之前想过，上游下游有个兼容列表的检查逻辑，举个例子：比如上游会有一个接口，提供版本兼容列表，下游启动（或者每天轮询一次）时，检查本地 sdk 的版本是否在上游的兼容版本列表里面，当然最好的是，上游兼容性变更。
我始终认为，人和人（团队和团队）的沟通成本非常高，而且越来越高，如果有一种机制（标准，规范之类的），解决沟通的问题，可能更合适。

[bravecarrot]

不知道楼主想吐槽的问题是什么， 是没有人热心帮助你吗？
职场上大家干活儿拿钱，做好自己的职责，一点问题没有。
至于说评价， 你的评价对面老板不一定在意， 甚至对面老板的评价 员工都不在意。

说回问题解决，相信每个人都看的出来，这个事情解决的不痛快是因为没有流程。
如果你第一次遇到， 那所有人都情有可原， 你应该推动流程建设；
如果不是， 那你之前为什么不建设流程？

建设流程 无非就是找到能解决问题 又必须归他负责不能甩锅。

[Meld]

不要只找具体技术，拉技术的时候也要给+1 拉进去，如果+1 是虚线的话，直接给实线+1 拉进去，你就知道技术们有多负责多认真了

[timeance]

学到了，感谢 OP 和 10 楼

[lambdaq]

三个和尚没水喝

[IvanCrancy]

@null2error 是的 ，我认为老哥这个是标准做法；一般可以通用应对 90%以上的情况

[IvanCrancy]

@SuperDaniel313 “流程和规范、制度的缺失，不可能靠爱和责任能弥补的”----您说的很对，认同

[HumbertHumbert]

工作流程觉得吃力，那就是存在规则缺失，各领域没有达成共识。
所以 PM 或者项目经理首先要做的，明确目标、明确干系人、共同制定、建立规则：
1 、建立问题处理规则：拉着各开发测试运维等责任干系人，共同建立的问题定位流程等，固化成结论并实际执行。
2 、建立沟通矩阵：日常各部件、各领域的接口人、上升求助人、重大问题通报规则等，固化成表格，共享发出。找人方便，求助通常，重大问题快速通报集中资源解决。

[grantonzhuang]

上游这个改动是他们出 bug 了还是真的改动了？别他们修好了 bug 你们又挂了。

[blur1119]

@LuXiaoR 你以为你学了就看懂了？装什么逼呢，学了业务逻辑是你写的吗，你懂上下文吗，

[blur1119]

@LuXiaoR 我就问你一句话，你自己是产品经理吗？不是别逼逼

[woshihgs]

上游改了数据格式，上游开发人员竟然不考虑会产生什么影响的吗？

[veightz]

找直接的责任人吧， 出了什么问题，造成什么影响，需要谁/哪个团队的问题来负责。
大家杂事儿太多了，只在意确定和自己有关的事儿。


> 最终大家在欢声笑语中打出 gg 之后，我把工单状态改为了“已闭环”，群被我解散了。
解决完问题， 我觉得至少你要出个结论吧。这个问题只是面上问题。。

进展同步：
XX 问题，线上出现多久，于 XX 已修复，不再新增。 感谢 XX ，XX ，XX 的定位和配合修复（踢球的也可以带上）
历史数据问题， 需要 xx 团队跟进修复。

业务影响面：
- 造成 xx 客诉，xx 咨询，目前已安抚/沟通资损和补偿方案中。

问题根因：
1. xx 变更 xx 引起。 艾特到人
2. 是 QA 没覆盖到， 还是 RD 自己发布没周知。 艾特到人，确定是 RD 问题还是 QA 问题，还是产品之前没提及这个细节。

后续处理：
如何避免下次再次出现：
1. RD 发布流程/沟通机制需要 xxx 。 艾特到人+DDL
2. QA 补充回归 case 。 艾特到人+DDL

[zy0829]

上线有问题难道不应该先找测试负责人吗？