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

227 天前
iheeleme  iheeleme
  1. 产品端原型非常粗糙,日常变动修改需求且不通知研发
  2. 后端层面无研发规范,同一个模块下相同的字段命名不统一,开发前无接口定义文档,api 定义不规范(有用驼峰的,有用短横线的),代码质量非常低(各种报错异常)
  3. 前端层面,低质量代码比例过多(很多该抽组件的没抽,有使用拼音的命名的),风格各异,历史遗留问题较多
  4. 管理层面,没有一个规范的管理体系,且几乎没有复盘过问题,拒绝流程的规范化

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


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

5645 次点击
所在节点   职场话题  职场话题
36 条回复
iheeleme
iheeleme
227 天前
@minze 目前我们团队并没有一个相关的接口文档供参考,纯靠一个各自理解,加上编码过程中,原型的各种修改优化,最后联调就出现各种情况
k9990009
k9990009
227 天前
团队在没有规范流程,一般来讲高级开发,自驱和能力才达标,我觉得人均高级才搞得下去。
leader 是后端组长,还是项目经理,还是部门经理?这个还是管理问题,事前没规范,事中瞎搞,事后没复盘。
自下而上很难搞。这个情况,我也不知道怎么把问题上升,领导思维固化,难以改变。
我有个简单的想法,不谈 PMP 、执行力这些东西。就把功能质量标准、时间都定下来,责任边界划分清除,
到底是产品、后端、前端、测试的问题。一个事不管多少人参与,就定一个责任人,让这个人去拉通。
搞不定就辞退,搞定优先考虑晋升,就这样靠个人能力硬搞。当每个人都会被定为责任人,
逼着每个人提高个人能力和协作。
你们估计也没绩效,要么绩效只是按加班考核。
tangkikodo
tangkikodo
227 天前
后端接口质量不过关,并且 leader 不重视, 前端只能遭罪了。

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

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


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

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

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

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

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

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

如果你想锻炼一下自己的管理能力,这个地方可太适合你了。如果你想做好技术,赶紧跑吧。
yangzzzzzz
225 天前
之前公司和你说的差不多,然后来了一个比较有能力的老哥 搞了全套流程 还经常写文档、周报、总结等。但是领导需求经常变 最后累的还是自己。前段时间私下和我说事情越来越多 不想干了。这种情况,领导层不变 是没用的。其实最主要原因还是 需求变动频繁 人员不够,老板想省钱 又着急给客户看成果
lsyAndroid
192 天前
伙计,能干就行,能跑就行,至于其他的对小公司来说真的不重要。重要的是能活下去,发得出工资,交得起社保!

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1055292

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX