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

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

  •  
  •   iheeleme · 119 天前 · 4733 次点击
    这是一个创建于 119 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 背景: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  
       119 天前 via Android
    在小公司干过,一样的问题,一年受不了,团队建设不起来,跑路了。我有想过你这些问题。打字太多了,加我绿泡泡 eXg5Njkx 可以一起交流下
    yuanmomo
        2
    yuanmomo  
       119 天前 via iPhone
    这个就是事物的两面性,在国内稳定的工作,可以养老,肯定又不好的一面。就看自己怎么去平衡了。
    losephsky
        3
    losephsky  
       119 天前
    你在这团队中是什么角色?流程规范化如果没有 Leader 的支持或者权限不够确实推不动,敏捷开发不代表不需要制定规则和遵守约定,建议请一个高维度的第三方去影响整体团队和 BOSS ,让他意识到问题的严重性
    Donahue
        4
    Donahue  
       119 天前   ❤️ 1
    “研发规范流程被 leader 多次拒绝”
    感觉这个 leader 没什么水平,项目弄得乱七八糟的
    kxg3030
        5
    kxg3030  
       119 天前
    以前我会说没有规范化流程的公司直接走人 但是工作几年反而心态好了一些 因为熵增是无法避免的 能跑就行了
    9c04C5dO01Sw5DNL
        6
    9c04C5dO01Sw5DNL  
       119 天前
    想要养老呆下去就把这份工作当糊口别逞强,凑合能过得去就行了,至少在目前这个领导在的时候。把时间留出来做自己想做的事情,能发挥自己能力的事情。

    要么就换工作换领导。
    meetalpha
        7
    meetalpha  
       119 天前
    要不试试 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  
       119 天前
    你是什么岗位都没说怎么探讨?
    seedhk
        9
    seedhk  
       119 天前
    好家伙,我觉得我们是同事啊。
    lucasj
        10
    lucasj  
       119 天前
    看得糊里糊涂的,重复看了一遍,好像看明白了。OP 是在一个小团队,是前端成员,整个前后端研发都是一个 leader ,OP 想要规范化,但领导不同意。目前团队表现出的问题:开发混乱、低效、质量差。

    我的建议:六字真言。

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

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

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


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

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

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

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

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

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

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