结果:研发流程一直无法规范化,前端沦为后端的接口验证工具,10 个接口有 8 个是有问题的,需要前端帮助定位问题,遇到稍微复杂的问题就需要等个半天,研发规范流程被 leader 多次以敏捷开发,项目交付周期紧张为由拒绝(敏捷开发,却连一个需求池都没有,也没有相关的需求研讨评审,原型评审也是走个过场,结果每次项目交付都延期,且项目质量非常差),每次原型评审简单的放一下原型,当场提出的问题可能后续也不会修改,反而后续进行一些优化的变动,且不告知开发人员
目前感觉没有必要再待下去的样子,困扰的问题挺多
1
k9990009 119 天前 via Android
在小公司干过,一样的问题,一年受不了,团队建设不起来,跑路了。我有想过你这些问题。打字太多了,加我绿泡泡 eXg5Njkx 可以一起交流下
|
2
yuanmomo 119 天前 via iPhone
这个就是事物的两面性,在国内稳定的工作,可以养老,肯定又不好的一面。就看自己怎么去平衡了。
|
3
losephsky 119 天前
你在这团队中是什么角色?流程规范化如果没有 Leader 的支持或者权限不够确实推不动,敏捷开发不代表不需要制定规则和遵守约定,建议请一个高维度的第三方去影响整体团队和 BOSS ,让他意识到问题的严重性
|
4
Donahue 119 天前 1
“研发规范流程被 leader 多次拒绝”
感觉这个 leader 没什么水平,项目弄得乱七八糟的 |
5
kxg3030 119 天前
以前我会说没有规范化流程的公司直接走人 但是工作几年反而心态好了一些 因为熵增是无法避免的 能跑就行了
|
6
9c04C5dO01Sw5DNL 119 天前
想要养老呆下去就把这份工作当糊口别逞强,凑合能过得去就行了,至少在目前这个领导在的时候。把时间留出来做自己想做的事情,能发挥自己能力的事情。
要么就换工作换领导。 |
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 函数修复,并转变为一个包括单元测试在内的功能齐全的实现。 |
8
lucasj 119 天前
你是什么岗位都没说怎么探讨?
|
9
seedhk 119 天前
好家伙,我觉得我们是同事啊。
|
10
lucasj 119 天前
看得糊里糊涂的,重复看了一遍,好像看明白了。OP 是在一个小团队,是前端成员,整个前后端研发都是一个 leader ,OP 想要规范化,但领导不同意。目前团队表现出的问题:开发混乱、低效、质量差。
我的建议:六字真言。 我给出建议的理由:1 )规范化无意是需要付出额外成本的,而且存在风险。2 )研发地位低,其次领导觉得能跑就行,不想折腾。 |
14
iheeleme OP @raviscioniemeche 才出来没两年,可能心态还没到那个程度,哈哈哈
|
15
iheeleme OP @giiiiiithub 的确如此,目前这段时间也是在这样实施的,就是目前最大的问题在于,平常的工作协同效率过于低下,特别影响自己的时间了,经常被拖着加班,但是又没有自己的事情,只能干等
|
16
iheeleme OP @losephsky 目前是前端组长,其实也只是想推动一下基本的协作约定,奈何无人支持,只做到了前端组内的规范执行(意义并不大,更多的压力来自外部,像目前的前后端开发分离情况,未提供接口定义的情况下,前端都无法 mock 数据与后端并行开发,导致每次出现需要等待后端接口基本完成才开始对接,且后端的接口大多数情况都是异常的,需要前端联调)
|
17
iheeleme OP @lucasj 可能写的有点多,也没写的太清晰,可以举个例子,目前团队内经常出现如 A 接口正常定义值为 0 ,B 接口正常定义值为 1 的情况,而且字段名也可能不同的情况,可能站在领导的角度考虑的问题不同
|
20
9c04C5dO01Sw5DNL 119 天前 via Android
@meetalpha 他这个不是技术问题,是领导问题,团队问题。要是打算待下去,漠不关心勉强凑合完成工作是最好的解决办法
|
22
k9990009 119 天前
团队在没有规范流程,一般来讲高级开发,自驱和能力才达标,我觉得人均高级才搞得下去。
leader 是后端组长,还是项目经理,还是部门经理?这个还是管理问题,事前没规范,事中瞎搞,事后没复盘。 自下而上很难搞。这个情况,我也不知道怎么把问题上升,领导思维固化,难以改变。 我有个简单的想法,不谈 PMP 、执行力这些东西。就把功能质量标准、时间都定下来,责任边界划分清除, 到底是产品、后端、前端、测试的问题。一个事不管多少人参与,就定一个责任人,让这个人去拉通。 搞不定就辞退,搞定优先考虑晋升,就这样靠个人能力硬搞。当每个人都会被定为责任人, 逼着每个人提高个人能力和协作。 你们估计也没绩效,要么绩效只是按加班考核。 |
23
tangkikodo 119 天前
后端接口质量不过关,并且 leader 不重视, 前端只能遭罪了。
我们 team 也不大, 但是 service 层功能的 testcase 非常重视,单测,mock 数据的集成测试, 这是这两点就让接口质量稳定了许多。 |
24
iheeleme OP @k9990009 说的太中肯了,目前就是事前不规范,事中没有任何逻辑的干,事后不复盘,可惜目前本人在团队话语权不够,基本属于自下而上去驱动,无法改变现状,
|
25
iheeleme OP @tangkikodo 确实遭罪,日常被拉着加班,加班也是等,基本没有任何产出
|
26
v2Geeker 118 天前 via iPhone
价值导向呀,能赚钱吗?你要把这事往你领导的目标上靠,或者,你把收益、执行路径跟你领导讲清楚?好好给他规划一番,说得他无法反驳。如果这些都做了还不同意,那个时候才决定走不走呀!
|
27
kandaakihito 118 天前
天呐这简直就是我.jpeg (请自行脑补那张图)
无解,大领导怎么可能不知道团队下面啥情况,无非是觉得以公司的水平,在场的技术团队不重要所以不想做出改变罢了。大概率你们公司也是明面上产品、项目与开发平级,实际上开发的重要性垫底。 |
28
taine 118 天前
只看第一条,如果是事实,尽量离开。
|
29
Xrall 118 天前
不知道其他,反正自己所在的也是这样。其次就是比这个更糟糕。需求变更会给你讲,加量不加价。
其次提需求的人你问具体的需求,他就回你不知道,我也不晓得。 非得他说个轮廓然后你自己想,想到了不合理在和他扯皮。 想跑,但是自己一没强劲的技术,二没学历,市场也难顶。一言难尽。 |
30
jianghu52 118 天前 1
如果你真的想彻底改变这一现状。那么首先,你要做下面 3 件事儿。
1.看明白整个团队谁的话语权最大。是项目经理,还是前端销售,还是财务主管。是哪个能能拍板让你试错。能承担试错的后果。 2.找出一个最具收益的修改方向。并给出具体的评估数据。 3.做出风险评估以及失败后的补救计划。 看到这里下面可以不用看了,下面只是我的一点偏见 作为老板有时候会很讨厌“精英”式的队员。因为他们本身能力强,然后就理所当然的认为其他人应该跟他们一样强,然后就开始各种看其他人不顺眼。偏偏呢,他们说的不少东西是对的。但是对的又怎么样,错的东西就已经能赚钱了,对的东西能帮老板赚更多的钱么,不能的话,那为什么要改,仅仅是为了让你们这些牛马少加班么? 是的,我这么说很资本家,但是这就是现实。我在楼主的描述中,看到了交付质量差,项目延期,但是我没见到甲方的态度,没看到甲方的要求。在这种情况下,作为乙方的老板,有什么动力去重构整个项目的流程,中间的风险谁来承担? 我听一个前辈讲过一段话,很有启发。他说,一个项目里面,能有 20%靠谱的人,就谢天谢地了。剩下 80%里面,通常会有 30%的草包,和 50%的混子。20%的骨干的能力的强弱,影响着项目的上限,但是项目的下限,根据木桶原理,往往取决于那 30%的草包。而一个项目实际的结果,其实最终取决于 50%的混子的用心程度。 所以我现在做项目,首先问自己的是,这个项目的下限要什么样,然后去看草包的能力够不够。然后再看项目客户预期什么样,随之看我鞭策混子的强度有多大。至于希望项目有多优秀,我基本上都随缘了。 |
31
caomu 118 天前 via Android
看起来像是给 G 做外包的,按我们平时用起来的体验,反正就像一坨,但是至少能用就行,而且都支持现代浏览器了,不像以前老业务还得用 ie 。只要能跑,支持现代浏览器,过了等保不出安全问题被爆库注入啥的就好。
|
32
chendl111 118 天前
@iheeleme #16 从自己负责的部分入手,将其规范化,统计规范化前后的开发效率/时长/代码量/步骤,做成 ppt 反映给大领导,争取管理层的认可
如果领导不在意,做好自己的事情,等待时机即可 |
33
shawnsh 118 天前 via Android
规范化不是一天搞成的,项目中出现的各种问题重复多次出现总要有接地气的解决方案吧
|
34
ninjaJ 118 天前
这个话题我可能有一点发言权,因为我曾经也在这样一个团队,后来通过一些策略在团队内推动了这些东西,最后成了大团队 leader 。。。
1. 你看到的这些问题,别人有没有看到,leader 有没有看到? 这些东西他很大可能是知道的,只是疲于应付或者他有他的 KPI 或者掣肘的地方。简而言之,这对他来说是一个取舍问题,而不是对错问题。有句话怎么说,成年人的世界没有对错。所以问题的本质是你和他的屁股不一样,屁股决定脑袋。 2. 基于 1 ,那么就有 2 种方式去推动,第一种是让他不得不转变思路,损失大于收益的时候他自己就会主动改变了;第二种是让他的 leader 认识到必须改变。 3. 千万别急功近利,现状不是一天形成的,也不是一天能改变的,可以先推动一点点,然后长期维持形成习惯。再推动一点点。但是不能默默无闻,要会汇报工作,每次都将成效总结出来,指出你在推动团队规范化方面的努力和成效的因果关系。 4. 最后一点给你泼一盆冷水。以上 3 点大概率没啥用,因为企业文化是老板的个人选择,公司风气形成的原因基本上都可以从老板身上找到。一个销售驱动的老板是不会尊重工程师文化,不会尊重标准化的,很简单,你哼哧哼哧大刀阔斧的改革,搞得鸡飞狗跳,不如人家一晚上自罚三杯收益大。 如果你想锻炼一下自己的管理能力,这个地方可太适合你了。如果你想做好技术,赶紧跑吧。 |
35
yangzzzzzz 117 天前
之前公司和你说的差不多,然后来了一个比较有能力的老哥 搞了全套流程 还经常写文档、周报、总结等。但是领导需求经常变 最后累的还是自己。前段时间私下和我说事情越来越多 不想干了。这种情况,领导层不变 是没用的。其实最主要原因还是 需求变动频繁 人员不够,老板想省钱 又着急给客户看成果
|
36
lsyAndroid 84 天前
伙计,能干就行,能跑就行,至于其他的对小公司来说真的不重要。重要的是能活下去,发得出工资,交得起社保!
|