V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
IvanCrancy
V2EX  ›  职场话题

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

  •  1
     
  •   IvanCrancy · 13 天前 · 3641 次点击

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

    业务在大群里,反馈了个 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 分钟后交了作业,同时花了十来分钟写下来这篇小作文。

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

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

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

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

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

    4-本质问题是流程和规范问题,你为什么不去推动建立这种机制?为什么没有一个接口人清单列明什么模块出了问题的时候应该是哪个开发负责跟进?
    确实是这样的,我很认同。不过呢··很多事情,并不是一个产品能决定和推动的,很多厂子里边会有复杂的利益关系和派系竞争;很难协调的,什么? 您说难办那就别办? 事实上我已经决定年后跑路了哈哈哈哈哈,so ,世界卫生组织关心您.jpg
    66 条回复    2025-01-23 18:08:06 +08:00
    ignore
        1
    ignore  
       13 天前
    你出发点就是错的,直接找技术负责人就完事了
    IvanCrancy
        2
    IvanCrancy  
    OP
       13 天前
    发出来才发现格式变了,V 站迷一样的 markdown 兼容···随便了,反正也是随便吐槽,各位老爷凑合看吧
    arron2022
        3
    arron2022  
       13 天前
    太卑微了吧 我们这产品一般就直接群里把问题抛出来。没人认领响应,就马上 at 项目负责人 at 部门经理
    ho121
        4
    ho121  
       13 天前 via Android
    看到很多问题:
    1. 上游接口返回格式变化,没有通知下游。
    2. 修改代码逻辑没有经过评估和测试直接上生产。
    3. 改动逻辑直接在生产环境做验证,而不是先在测试环境验证。
    4. 问题确实是闭环了,但没有复盘,没有考虑下次如何避免类似的问题。
    crazyzzm
        5
    crazyzzm  
       13 天前
    这个和团队文化、个人意识有关。
    个人意识方面,不怕背锅,主动跟进,但很“个人”。而团队文化,是可以作为兜底弥补个人的不足的,平时团队多宣讲强调,必要时纳入绩效,团队整体还是能有所改变的。

    只不过绝大多数人没这个意识,而团队中管理的也没这个意识的话,团队也就那样了。
    asdhak
        6
    asdhak  
       13 天前
    @ignore #1 这是对的,直接找开发人员,能理他就不错了。还他以为这是哪个模块的问题,然后找具体人
    kisick
        7
    kisick  
       13 天前 via iPhone
    应该直接找领导
    buruliu
        8
    buruliu  
       13 天前   ❤️ 4
    最后还是外包干了活。
    hi2hi
        9
    hi2hi  
       13 天前
    外包才是干活的苦力
    null2error
        10
    null2error  
       13 天前   ❤️ 4
    不太理解是什么场景下,要产品去做定位梳理的事情,于情于理,我们狗产品可以做,但是不能这么卑微的做吧~
    如果是非正式的需求推进,最好还是确定 一下对方和你关系 有没有这么好,人家要做多余的事情,何必呢?

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

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

    作为一个产品,摇人才是第一生产力 [狗头] ~
    gopher404
        11
    gopher404  
       13 天前
    个人建议,如果不清楚该项目的任务分工范围,应该优先找知晓该项目分工的负责人比如项目经理,而不是直接丢到群里。再一个,如果经常有这种情况,应该优化自己内部处理这种问题的机制和流程,以便团队更好的定位和协作。
    dfdd1811
        12
    dfdd1811  
       13 天前   ❤️ 2
    外包更可怜…我从不为沟通的事生气着急,找小兵能解决解决,解决不了就找对方领导,再不行找自己领导跟对方对接。我各方都通知了,不接锅
    gxt92
        13
    gxt92  
       13 天前
    全程测试竟然不吭声?我觉得测试负责人应该开掉
    akakidz
        14
    akakidz  
       13 天前
    我司会有专门的开发负责人对接问题,不过问题下来之后 开发内部还是会有这个场景🤣
    LuXiaoR
        15
    LuXiaoR  
       13 天前
    不会技术的产品不是好产品,哈哈哈,产品好好学习技术,不求人,还给自己加分🤣
    SmartTom
        16
    SmartTom  
       13 天前
    为何不换个角度思考问题的本质呢?
    keyfunc
        17
    keyfunc  
       13 天前
    我觉得直接 at 测试负责人就行了,测试有时候比开发更懂代码~
    GuLuDaDuiZhang
        18
    GuLuDaDuiZhang  
       13 天前
    一开始就不应该自己私聊找开发的,要让开发负责人来处理。直接在开发或者业务的大群里 @开发负责人呗,让他排人来看,业务催你你就崔开发负责人。
    freak118
        19
    freak118  
       13 天前
    什么意思?外包直接修改代码逻辑还上线了? 你们公司流程这样随便吗
    raydied
        20
    raydied  
       13 天前 via Android
    恩恩,我以为这里没产品
    Vegetable
        21
    Vegetable  
       13 天前
    为什么外包能迅速更新生产环境啊,这不是早晚爆炸吗
    blur1119
        22
    blur1119  
       13 天前
    @LuXiaoR 扯呢,学了你又不用,给你贴代码你也看不懂
    courtier
        23
    courtier  
       13 天前
    哈哈,别说产品了,我一个开发去找那些负责搞内部工具的部门帮忙处理个线上问题,也能在他们部门里遇到 ABC 三个组互相踢皮球,明明都坐一块非要我去传话,后面火了把他们直接拉到一个人的座位上让他们自己面对面来扯皮

    再后面回来后直接跟我们部门的技术负责人吐槽了,最后可能他们几个组也被他们的技术负责人拉去讲了,反正过了几天后在大群里发了个对接的流程:找到谁的就让谁来全程跟进下去直到处理完成(但我觉得不可能可以执行得下去,都是话术)
    LuXiaoR
        24
    LuXiaoR  
       13 天前
    @blur1119 那就怪自己笨吧 看不懂学个叼毛
    xz410236056
        25
    xz410236056  
       13 天前
    @Vegetable 没外包这团队早完了。
    iphantom
        26
    iphantom  
       13 天前
    我说下我的处理流程。发现问题后,1 、先拉上测试,和测试同事一起测试环境复现问题; 2 、确认问题模块后,即使知道是具体那个开发负责的(比如 B ),那么会同时拉上开发负责人 A 和 B (不知道就不拉),把问题及现象告知; 3 、然后及时跟进 A ,让他反馈问题原因和修复方案~
    jydeng
        27
    jydeng  
       13 天前
    外包能直接上线,分享你刚编的故事
    daimon1
        28
    daimon1  
       13 天前
    一楼正解。我是 pmo 部门的,团队询问这种情况时,我都引导找技术负责人沟通
    SuperDaniel313
        29
    SuperDaniel313  
       13 天前
    客户催业务
    业务催产品
    产品催测试
    测试催研发
    研发修复
    测试验收
    产品验收
    业务验收
    客户验收

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

    流程和规范、制度的缺失,不可能靠爱和责任能弥补的
    daimon1
        30
    daimon1  
       13 天前
    @daimon1 其实想想我司的流程,岗位职责也是蛮清晰的。这种情况就是要找团队的技术负责人来沟通,包括后续怎么安排修复上线,这些流程都是有的
    sky3hao
        31
    sky3hao  
       13 天前
    产品狗你好, 产品狗再见
    tim9527
        32
    tim9527  
       13 天前
    都是甩锅大师
    DonaldY
        33
    DonaldY  
       13 天前
    你们需要一个工单群。
    可以指定技术处理
    THESDZ
        34
    THESDZ  
       13 天前
    @ho121 #4 关于 1 的问题,我之前想过,上游下游有个兼容列表的检查逻辑,举个例子:比如上游会有一个接口,提供版本兼容列表,下游启动(或者每天轮询一次)时,检查本地 sdk 的版本是否在上游的兼容版本列表里面,当然最好的是,上游兼容性变更。
    我始终认为,人和人(团队和团队)的沟通成本非常高,而且越来越高,如果有一种机制(标准,规范之类的),解决沟通的问题,可能更合适。
    bravecarrot
        35
    bravecarrot  
       13 天前   ❤️ 1
    不知道楼主想吐槽的问题是什么, 是没有人热心帮助你吗?
    职场上大家干活儿拿钱,做好自己的职责,一点问题没有。
    至于说评价, 你的评价对面老板不一定在意, 甚至对面老板的评价 员工都不在意。

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

    建设流程 无非就是找到能解决问题 又必须归他负责不能甩锅。
    Meld
        36
    Meld  
       13 天前
    不要只找具体技术,拉技术的时候也要给+1 拉进去,如果+1 是虚线的话,直接给实线+1 拉进去,你就知道技术们有多负责多认真了
    timeance
        37
    timeance  
       13 天前
    学到了,感谢 OP 和 10 楼
    lambdaq
        38
    lambdaq  
       13 天前
    三个和尚没水喝
    IvanCrancy
        39
    IvanCrancy  
    OP
       13 天前
    @null2error 是的 ,我认为老哥这个是标准做法;一般可以通用应对 90%以上的情况
    IvanCrancy
        40
    IvanCrancy  
    OP
       13 天前
    @SuperDaniel313 “流程和规范、制度的缺失,不可能靠爱和责任能弥补的”----您说的很对,认同
    HumbertHumbert
        41
    HumbertHumbert  
       13 天前   ❤️ 1
    工作流程觉得吃力,那就是存在规则缺失,各领域没有达成共识。
    所以 PM 或者项目经理首先要做的,明确目标、明确干系人、共同制定、建立规则:
    1 、建立问题处理规则:拉着各开发测试运维等责任干系人,共同建立的问题定位流程等,固化成结论并实际执行。
    2 、建立沟通矩阵:日常各部件、各领域的接口人、上升求助人、重大问题通报规则等,固化成表格,共享发出。找人方便,求助通常,重大问题快速通报集中资源解决。
    grantonzhuang
        42
    grantonzhuang  
       13 天前 via Android
    上游这个改动是他们出 bug 了还是真的改动了?别他们修好了 bug 你们又挂了。
    blur1119
        43
    blur1119  
       13 天前
    @LuXiaoR 你以为你学了就看懂了?装什么逼呢,学了业务逻辑是你写的吗,你懂上下文吗,
    blur1119
        44
    blur1119  
       13 天前
    @LuXiaoR 我就问你一句话,你自己是产品经理吗?不是别逼逼
    woshihgs
        45
    woshihgs  
       13 天前
    上游改了数据格式,上游开发人员竟然不考虑会产生什么影响的吗?
    veightz
        46
    veightz  
       13 天前
    找直接的责任人吧, 出了什么问题,造成什么影响,需要谁/哪个团队的问题来负责。
    大家杂事儿太多了,只在意确定和自己有关的事儿。


    > 最终大家在欢声笑语中打出 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
        47
    zy0829  
       13 天前
    上线有问题难道不应该先找测试负责人吗?
    gaocc
        48
    gaocc  
       13 天前
    @ignore @IvanCrancy
    确实,凭经验直接找人大概率出错。哪个项目谁是技术负责人,让他协调。然后产品给个 deadline ,或者有相关制度的,比如 15 分钟未解决,3 级 bug ,扣个人绩效。涉及金额的按金额数量给 2 级,1 级 bug 。
    分分钟给你解决,即使确实难解决,也会有更高层技术领导来沟通,陈述。
    panfenglai
        49
    panfenglai  
       13 天前
    只能说是日常吧。不过我司研发会主动一些,会主动拉人进群。我拉 A ,A 拉 B ,B 拉 C ,C 拉 D…
    问题解决还好,解决不了开始踢皮球是最烦的。只能拉会,让这群人在会上撕。
    bestkxt
        50
    bestkxt  
       13 天前
    其实拉群把 tl 拉进去就很快乐
    Jove7
        51
    Jove7  
       13 天前
    @ignore too young too naive. 技术负责人根本是找不到的, 基本都在开会定方案. 除了领导 下面的人根本拉不到他
    Jove7
        52
    Jove7  
       13 天前
    @Vegetable 应该是 od 吧 菊厂的外包确实权限比较全的. 但是都是通过了培训和考试的 牛皮的 od 有可能还是 B 的位置呢. 学历低了不代表能力不行
    Jove7
        53
    Jove7  
       13 天前
    @woshihgs 估计是考虑了 也写了产品说明的. 但是就这个团队的吊样 通知他们了估计也不会看不会改
    Jove7
        54
    Jove7  
       13 天前
    @bestkxt 我们 tl 拉进去了 @了 也不会看的
    除非是领导拉的领导 @了
    h1298841903
        55
    h1298841903  
       13 天前   ❤️ 1
    我个人感觉,A 工、B 工 没啥问题,又不是自己模块,他们肯定不知道具体逻辑,要怎么修。想修都不知道怎么修
    tonytonychopper
        56
    tonytonychopper  
       12 天前
    这种时候应该直接先找 TL ,找我们这种 dev 一直跟往好了最多说这个 dev 比较负责,往坏一点 dev 会被说是没有边界浪费时间
    LuXiaoR
        57
    LuXiaoR  
       11 天前
    @blur1119 我是你爹就完事了
    LuXiaoR
        58
    LuXiaoR  
       11 天前
    @blur1119 我当产品经理 你还没出生呢
    LuXiaoR
        59
    LuXiaoR  
       11 天前
    @blur1119 先好好找到工作再说吧 16k 下次找个 10k 的
    blur1119
        60
    blur1119  
       11 天前
    @LuXiaoR 知道你是弱智了 哈哈哈哈 还翻我主页,像条狗
    blur1119
        61
    blur1119  
       11 天前
    @LuXiaoR 什么弱智产品,你能做,就你这低能样子
    blur1119
        62
    blur1119  
       11 天前
    @LuXiaoR 创业了多少次了,还一直失败,你还不清自己什么能力?创业是你这种低能儿做的东西吗?你能做的明白吗
    wqhui
        63
    wqhui  
       11 天前
    庞大的系统拆太细了哈哈,所以要跟着链路一个个团队找过去,其实问题就是他们没有帮你递归到下一个人直到出现答案,而是返回下一个人的地址让你问下去,需要个工单流转之类的东西
    huangshaokun
        64
    huangshaokun  
       11 天前
    我感觉之前的我就像那个外包老哥,后续就是啥问题都来我这了,最恐怖的时候我就像游戏里面的新手村长(业务人员遇到问题找我,啥问题都找我,逼得我都直接在公司大群公开吐槽,我一个开发整天带你们业务部门新来的人员理业务...)。ps. 我的职位是 后端开发
    huangshaokun
        65
    huangshaokun  
       11 天前
    不过也成就现在的我产品设计会一些(因为和业务人员沟通中经常会有他们用这个产品遇到问题的地方,ps. 我们公司是铁打的后端,流水的产品和前端和其他人员)
    huangshaokun
        66
    huangshaokun  
       11 天前
    前端也懂,测试也懂,运维也懂
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   971 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 17:48 · PVG 01:48 · LAX 09:48 · JFK 12:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.