V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
labex.io
通过在线实验与 50 万用户一起学 Linux、DevOps 和网络安全技术,付款时输入 V2EX30 限时 30% 专属折扣
Promoted by JamesZHH
iheeleme
V2EX  ›  职场话题

目前工作情况下的一点困扰和问题探讨

  •  
  •   iheeleme · 2024-07-06 14:30:48 +08:00 · 6366 次点击
    这是一个创建于 369 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 背景:10 人左右小团队,前端,公司产品主要为 toG 产品,可能挺适合养老
    • 问题:团队内基本没有协作和开发的规范
    1. 产品端原型非常粗糙,日常变动修改需求且不通知研发
    2. 后端层面无研发规范,同一个模块下相同的字段命名不统一,开发前无接口定义文档,api 定义不规范(有用驼峰的,有用短横线的),代码质量非常低(各种报错异常)
    3. 前端层面,低质量代码比例过多(很多该抽组件的没抽,有使用拼音的命名的),风格各异,历史遗留问题较多
    4. 管理层面,没有一个规范的管理体系,且几乎没有复盘过问题,拒绝流程的规范化
    • 困扰: 因为上述相关的问题,前端在整个团队中很被动,自己做出了一系列努力如:搭建了代码仓库,多分支代码管理发布体系,Jenkins 自动构建流水线,私有化镜像仓库,前端代码规范检测( eslint ,prettier 等——手动狗头,应对写拼音命名的),多次提出建议团队需要规范化

    结果:研发流程一直无法规范化,前端沦为后端的接口验证工具,10 个接口有 8 个是有问题的,需要前端帮助定位问题,遇到稍微复杂的问题就需要等个半天,研发规范流程被 leader 多次以敏捷开发,项目交付周期紧张为由拒绝(敏捷开发,却连一个需求池都没有,也没有相关的需求研讨评审,原型评审也是走个过场,结果每次项目交付都延期,且项目质量非常差),每次原型评审简单的放一下原型,当场提出的问题可能后续也不会修改,反而后续进行一些优化的变动,且不告知开发人员

    • 最近一次提出能否先让后端把接口这块规范化一下,leader 回复说我们这种小团队没必要去弄那些规范化的流程,弄了反而影响写代码的时间,现阶段更适合对个眼神,口头传述一下就好

    目前感觉没有必要再待下去的样子,困扰的问题挺多

    36 条回复    2024-08-10 15:14:03 +08:00
    k9990009
        1
    k9990009  
       2024-07-06 14:50:11 +08:00 via Android
    在小公司干过,一样的问题,一年受不了,团队建设不起来,跑路了。我有想过你这些问题。打字太多了,加我绿泡泡 eXg5Njkx 可以一起交流下
    yuanmomo
        2
    yuanmomo  
       2024-07-06 14:54:35 +08:00 via iPhone
    这个就是事物的两面性,在国内稳定的工作,可以养老,肯定又不好的一面。就看自己怎么去平衡了。
    losephsky
        3
    losephsky  
       2024-07-06 14:57:18 +08:00
    你在这团队中是什么角色?流程规范化如果没有 Leader 的支持或者权限不够确实推不动,敏捷开发不代表不需要制定规则和遵守约定,建议请一个高维度的第三方去影响整体团队和 BOSS ,让他意识到问题的严重性
    Donahue
        4
    Donahue  
       2024-07-06 15:15:30 +08:00   ❤️ 1
    “研发规范流程被 leader 多次拒绝”
    感觉这个 leader 没什么水平,项目弄得乱七八糟的
    kxg3030
        5
    kxg3030  
       2024-07-06 15:21:25 +08:00
    以前我会说没有规范化流程的公司直接走人 但是工作几年反而心态好了一些 因为熵增是无法避免的 能跑就行了
    9c04C5dO01Sw5DNL
        6
    9c04C5dO01Sw5DNL  
       2024-07-06 15:40:57 +08:00
    想要养老呆下去就把这份工作当糊口别逞强,凑合能过得去就行了,至少在目前这个领导在的时候。把时间留出来做自己想做的事情,能发挥自己能力的事情。

    要么就换工作换领导。
    meetalpha
        7
    meetalpha  
       2024-07-06 15:57:04 +08:00
    要不试试 Claude 3.5 Sonnet ?据说在代码故障排除和重构能力上有很大提升,不知实际效果如何。

    在团队考察 AI 能否根据文字需求改进代码的内部编程测试中,Claude 3.5 Sonnet 成功解决了 64%的问题,而 Claude 3 Opus 只解决了 38%。研究人员发现,只要给 Claude 3.5 Sonnet 清晰的指令和必要工具, 它就能独立编写、编辑和执行代码,并具备复杂推理和故障排除能力。并能轻松处理代码翻译,特别适合更新遗留应用程序和迁移代码库。

    Anthropic 开发者关系工程师 Alex Albert 表示,Claude 在编写代码和自主修复 pull requests 方面变得非常出色。“显然,一年之后,大部分代码将由大语言模型编写。”

    他在日常工作中发现,代码测试和修复通常比编写本身更花时间。此时 Cloud 3.5 Sonnet 可以充当一个成熟的编程代理。Albert 在视频中展示了如何在最少输入和没有互联网访问的沙盒环境下,借助 Claude 将一个裁切圆形头像的 bug 函数修复,并转变为一个包括单元测试在内的功能齐全的实现。
    lucasj
        8
    lucasj  
       2024-07-06 17:18:36 +08:00
    你是什么岗位都没说怎么探讨?
    seedhk
        9
    seedhk  
       2024-07-06 17:19:37 +08:00
    好家伙,我觉得我们是同事啊。
    lucasj
        10
    lucasj  
       2024-07-06 17:29:05 +08:00
    看得糊里糊涂的,重复看了一遍,好像看明白了。OP 是在一个小团队,是前端成员,整个前后端研发都是一个 leader ,OP 想要规范化,但领导不同意。目前团队表现出的问题:开发混乱、低效、质量差。

    我的建议:六字真言。

    我给出建议的理由:1 )规范化无意是需要付出额外成本的,而且存在风险。2 )研发地位低,其次领导觉得能跑就行,不想折腾。
    iheeleme
        11
    iheeleme  
    OP
       2024-07-06 19:01:57 +08:00
    @k9990009 的确就是初创团队
    iheeleme
        12
    iheeleme  
    OP
       2024-07-06 19:03:44 +08:00
    @yuanmomo 的确如此,暂时看来很稳定,就是待着挺难受的
    iheeleme
        13
    iheeleme  
    OP
       2024-07-06 19:04:36 +08:00
    @Donahue 不是很好评价这个问题,只能说可能追求平稳,毕竟改起来也有风险
    iheeleme
        14
    iheeleme  
    OP
       2024-07-06 19:05:20 +08:00
    @raviscioniemeche 才出来没两年,可能心态还没到那个程度,哈哈哈
    iheeleme
        15
    iheeleme  
    OP
       2024-07-06 19:08:23 +08:00
    @giiiiiithub 的确如此,目前这段时间也是在这样实施的,就是目前最大的问题在于,平常的工作协同效率过于低下,特别影响自己的时间了,经常被拖着加班,但是又没有自己的事情,只能干等
    iheeleme
        16
    iheeleme  
    OP
       2024-07-06 19:16:13 +08:00
    @losephsky 目前是前端组长,其实也只是想推动一下基本的协作约定,奈何无人支持,只做到了前端组内的规范执行(意义并不大,更多的压力来自外部,像目前的前后端开发分离情况,未提供接口定义的情况下,前端都无法 mock 数据与后端并行开发,导致每次出现需要等待后端接口基本完成才开始对接,且后端的接口大多数情况都是异常的,需要前端联调)
    iheeleme
        17
    iheeleme  
    OP
       2024-07-06 19:20:25 +08:00
    @lucasj 可能写的有点多,也没写的太清晰,可以举个例子,目前团队内经常出现如 A 接口正常定义值为 0 ,B 接口正常定义值为 1 的情况,而且字段名也可能不同的情况,可能站在领导的角度考虑的问题不同
    iheeleme
        18
    iheeleme  
    OP
       2024-07-06 19:21:09 +08:00
    @seedhk 哈哈哈,看来遇到这种问题的不止我一个
    minze
        19
    minze  
       2024-07-06 20:07:45 +08:00
    @iheeleme #17 接口定义值在正常情况下,是否是需要有定稿的接口文档供前后端参考进行编码呢?在接口和设计文档完成后再进行编码。
    9c04C5dO01Sw5DNL
        20
    9c04C5dO01Sw5DNL  
       2024-07-06 20:33:33 +08:00 via Android
    @meetalpha 他这个不是技术问题,是领导问题,团队问题。要是打算待下去,漠不关心勉强凑合完成工作是最好的解决办法
    iheeleme
        21
    iheeleme  
    OP
       2024-07-06 20:39:09 +08:00
    @minze 目前我们团队并没有一个相关的接口文档供参考,纯靠一个各自理解,加上编码过程中,原型的各种修改优化,最后联调就出现各种情况
    k9990009
        22
    k9990009  
       2024-07-06 21:53:13 +08:00
    团队在没有规范流程,一般来讲高级开发,自驱和能力才达标,我觉得人均高级才搞得下去。
    leader 是后端组长,还是项目经理,还是部门经理?这个还是管理问题,事前没规范,事中瞎搞,事后没复盘。
    自下而上很难搞。这个情况,我也不知道怎么把问题上升,领导思维固化,难以改变。
    我有个简单的想法,不谈 PMP 、执行力这些东西。就把功能质量标准、时间都定下来,责任边界划分清除,
    到底是产品、后端、前端、测试的问题。一个事不管多少人参与,就定一个责任人,让这个人去拉通。
    搞不定就辞退,搞定优先考虑晋升,就这样靠个人能力硬搞。当每个人都会被定为责任人,
    逼着每个人提高个人能力和协作。
    你们估计也没绩效,要么绩效只是按加班考核。
    tangkikodo
        23
    tangkikodo  
       2024-07-06 22:10:49 +08:00
    后端接口质量不过关,并且 leader 不重视, 前端只能遭罪了。

    我们 team 也不大, 但是 service 层功能的 testcase 非常重视,单测,mock 数据的集成测试, 这是这两点就让接口质量稳定了许多。
    iheeleme
        24
    iheeleme  
    OP
       2024-07-06 22:21:07 +08:00
    @k9990009 说的太中肯了,目前就是事前不规范,事中没有任何逻辑的干,事后不复盘,可惜目前本人在团队话语权不够,基本属于自下而上去驱动,无法改变现状,
    iheeleme
        25
    iheeleme  
    OP
       2024-07-06 22:24:49 +08:00
    @tangkikodo 确实遭罪,日常被拉着加班,加班也是等,基本没有任何产出
    v2Geeker
        26
    v2Geeker  
       2024-07-07 00:11:02 +08:00 via iPhone
    价值导向呀,能赚钱吗?你要把这事往你领导的目标上靠,或者,你把收益、执行路径跟你领导讲清楚?好好给他规划一番,说得他无法反驳。如果这些都做了还不同意,那个时候才决定走不走呀!
    kandaakihito
        27
    kandaakihito  
       2024-07-07 01:08:34 +08:00
    天呐这简直就是我.jpeg (请自行脑补那张图)

    无解,大领导怎么可能不知道团队下面啥情况,无非是觉得以公司的水平,在场的技术团队不重要所以不想做出改变罢了。大概率你们公司也是明面上产品、项目与开发平级,实际上开发的重要性垫底。
    taine
        28
    taine  
       2024-07-07 08:51:58 +08:00
    只看第一条,如果是事实,尽量离开。
    Xrall
        29
    Xrall  
       2024-07-07 09:06:54 +08:00
    不知道其他,反正自己所在的也是这样。其次就是比这个更糟糕。需求变更会给你讲,加量不加价。
    其次提需求的人你问具体的需求,他就回你不知道,我也不晓得。
    非得他说个轮廓然后你自己想,想到了不合理在和他扯皮。
    想跑,但是自己一没强劲的技术,二没学历,市场也难顶。一言难尽。
    jianghu52
        30
    jianghu52  
       2024-07-07 10:17:51 +08:00   ❤️ 1
    如果你真的想彻底改变这一现状。那么首先,你要做下面 3 件事儿。
    1.看明白整个团队谁的话语权最大。是项目经理,还是前端销售,还是财务主管。是哪个能能拍板让你试错。能承担试错的后果。
    2.找出一个最具收益的修改方向。并给出具体的评估数据。
    3.做出风险评估以及失败后的补救计划。


    看到这里下面可以不用看了,下面只是我的一点偏见

    作为老板有时候会很讨厌“精英”式的队员。因为他们本身能力强,然后就理所当然的认为其他人应该跟他们一样强,然后就开始各种看其他人不顺眼。偏偏呢,他们说的不少东西是对的。但是对的又怎么样,错的东西就已经能赚钱了,对的东西能帮老板赚更多的钱么,不能的话,那为什么要改,仅仅是为了让你们这些牛马少加班么?
    是的,我这么说很资本家,但是这就是现实。我在楼主的描述中,看到了交付质量差,项目延期,但是我没见到甲方的态度,没看到甲方的要求。在这种情况下,作为乙方的老板,有什么动力去重构整个项目的流程,中间的风险谁来承担?
    我听一个前辈讲过一段话,很有启发。他说,一个项目里面,能有 20%靠谱的人,就谢天谢地了。剩下 80%里面,通常会有 30%的草包,和 50%的混子。20%的骨干的能力的强弱,影响着项目的上限,但是项目的下限,根据木桶原理,往往取决于那 30%的草包。而一个项目实际的结果,其实最终取决于 50%的混子的用心程度。
    所以我现在做项目,首先问自己的是,这个项目的下限要什么样,然后去看草包的能力够不够。然后再看项目客户预期什么样,随之看我鞭策混子的强度有多大。至于希望项目有多优秀,我基本上都随缘了。
    caomu
        31
    caomu  
       2024-07-07 10:56:11 +08:00 via Android
    看起来像是给 G 做外包的,按我们平时用起来的体验,反正就像一坨,但是至少能用就行,而且都支持现代浏览器了,不像以前老业务还得用 ie 。只要能跑,支持现代浏览器,过了等保不出安全问题被爆库注入啥的就好。
    chendl111
        32
    chendl111  
       2024-07-07 11:37:41 +08:00
    @iheeleme #16 从自己负责的部分入手,将其规范化,统计规范化前后的开发效率/时长/代码量/步骤,做成 ppt 反映给大领导,争取管理层的认可
    如果领导不在意,做好自己的事情,等待时机即可
    shawnsh
        33
    shawnsh  
       2024-07-07 13:55:56 +08:00 via Android
    规范化不是一天搞成的,项目中出现的各种问题重复多次出现总要有接地气的解决方案吧
    ninjaJ
        34
    ninjaJ  
       2024-07-07 21:34:15 +08:00
    这个话题我可能有一点发言权,因为我曾经也在这样一个团队,后来通过一些策略在团队内推动了这些东西,最后成了大团队 leader 。。。

    1. 你看到的这些问题,别人有没有看到,leader 有没有看到?
    这些东西他很大可能是知道的,只是疲于应付或者他有他的 KPI 或者掣肘的地方。简而言之,这对他来说是一个取舍问题,而不是对错问题。有句话怎么说,成年人的世界没有对错。所以问题的本质是你和他的屁股不一样,屁股决定脑袋。

    2. 基于 1 ,那么就有 2 种方式去推动,第一种是让他不得不转变思路,损失大于收益的时候他自己就会主动改变了;第二种是让他的 leader 认识到必须改变。

    3. 千万别急功近利,现状不是一天形成的,也不是一天能改变的,可以先推动一点点,然后长期维持形成习惯。再推动一点点。但是不能默默无闻,要会汇报工作,每次都将成效总结出来,指出你在推动团队规范化方面的努力和成效的因果关系。

    4. 最后一点给你泼一盆冷水。以上 3 点大概率没啥用,因为企业文化是老板的个人选择,公司风气形成的原因基本上都可以从老板身上找到。一个销售驱动的老板是不会尊重工程师文化,不会尊重标准化的,很简单,你哼哧哼哧大刀阔斧的改革,搞得鸡飞狗跳,不如人家一晚上自罚三杯收益大。

    如果你想锻炼一下自己的管理能力,这个地方可太适合你了。如果你想做好技术,赶紧跑吧。
    yangzzzzzz
        35
    yangzzzzzz  
       2024-07-08 17:22:00 +08:00
    之前公司和你说的差不多,然后来了一个比较有能力的老哥 搞了全套流程 还经常写文档、周报、总结等。但是领导需求经常变 最后累的还是自己。前段时间私下和我说事情越来越多 不想干了。这种情况,领导层不变 是没用的。其实最主要原因还是 需求变动频繁 人员不够,老板想省钱 又着急给客户看成果
    lsyAndroid
        36
    lsyAndroid  
       334 天前
    伙计,能干就行,能跑就行,至于其他的对小公司来说真的不重要。重要的是能活下去,发得出工资,交得起社保!
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5027 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 08:16 · PVG 16:16 · LAX 01:16 · JFK 04:16
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.