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

[iheeleme]

• 背景：10 人左右小团队，前端，公司产品主要为 toG 产品，可能挺适合养老
• 问题：团队内基本没有协作和开发的规范

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

• 困扰： 因为上述相关的问题，前端在整个团队中很被动，自己做出了一系列努力如：搭建了代码仓库，多分支代码管理发布体系，Jenkins 自动构建流水线，私有化镜像仓库，前端代码规范检测（ eslint ，prettier 等——手动狗头，应对写拼音命名的），多次提出建议团队需要规范化

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

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

---

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

[k9990009]

在小公司干过，一样的问题，一年受不了，团队建设不起来，跑路了。我有想过你这些问题。打字太多了，加我绿泡泡 eXg5Njkx 可以一起交流下

[yuanmomo]

这个就是事物的两面性，在国内稳定的工作，可以养老，肯定又不好的一面。就看自己怎么去平衡了。

[losephsky]

你在这团队中是什么角色？流程规范化如果没有 Leader 的支持或者权限不够确实推不动，敏捷开发不代表不需要制定规则和遵守约定，建议请一个高维度的第三方去影响整体团队和 BOSS ，让他意识到问题的严重性

[Donahue]

“研发规范流程被 leader 多次拒绝”
感觉这个 leader 没什么水平，项目弄得乱七八糟的

[raviscioniemeche]

以前我会说没有规范化流程的公司直接走人 但是工作几年反而心态好了一些 因为熵增是无法避免的 能跑就行了

[9c04C5dO01Sw5DNL]

想要养老呆下去就把这份工作当糊口别逞强，凑合能过得去就行了，至少在目前这个领导在的时候。把时间留出来做自己想做的事情，能发挥自己能力的事情。

要么就换工作换领导。

[meetalpha]

要不试试 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]

你是什么岗位都没说怎么探讨？

[seedhk]

好家伙，我觉得我们是同事啊。

[lucasj]

看得糊里糊涂的，重复看了一遍，好像看明白了。OP 是在一个小团队，是前端成员，整个前后端研发都是一个 leader ，OP 想要规范化，但领导不同意。目前团队表现出的问题：开发混乱、低效、质量差。

我的建议：六字真言。

我给出建议的理由：1 ）规范化无意是需要付出额外成本的，而且存在风险。2 ）研发地位低，其次领导觉得能跑就行，不想折腾。

[iheeleme]

@k9990009 的确就是初创团队

[iheeleme]

@yuanmomo 的确如此，暂时看来很稳定，就是待着挺难受的

[iheeleme]

@Donahue 不是很好评价这个问题，只能说可能追求平稳，毕竟改起来也有风险

[iheeleme]

@raviscioniemeche 才出来没两年，可能心态还没到那个程度，哈哈哈

[iheeleme]

@giiiiiithub 的确如此，目前这段时间也是在这样实施的，就是目前最大的问题在于，平常的工作协同效率过于低下，特别影响自己的时间了，经常被拖着加班，但是又没有自己的事情，只能干等

[iheeleme]

@losephsky 目前是前端组长，其实也只是想推动一下基本的协作约定，奈何无人支持，只做到了前端组内的规范执行（意义并不大，更多的压力来自外部，像目前的前后端开发分离情况，未提供接口定义的情况下，前端都无法 mock 数据与后端并行开发，导致每次出现需要等待后端接口基本完成才开始对接，且后端的接口大多数情况都是异常的，需要前端联调）

[iheeleme]

@lucasj 可能写的有点多，也没写的太清晰，可以举个例子，目前团队内经常出现如 A 接口正常定义值为 0 ，B 接口正常定义值为 1 的情况，而且字段名也可能不同的情况，可能站在领导的角度考虑的问题不同

[iheeleme]

@seedhk 哈哈哈，看来遇到这种问题的不止我一个

[minze]

@iheeleme #17 接口定义值在正常情况下，是否是需要有定稿的接口文档供前后端参考进行编码呢？在接口和设计文档完成后再进行编码。

[9c04C5dO01Sw5DNL]

@meetalpha 他这个不是技术问题，是领导问题，团队问题。要是打算待下去，漠不关心勉强凑合完成工作是最好的解决办法

[iheeleme]

@minze 目前我们团队并没有一个相关的接口文档供参考，纯靠一个各自理解，加上编码过程中，原型的各种修改优化，最后联调就出现各种情况

[k9990009]

团队在没有规范流程，一般来讲高级开发，自驱和能力才达标，我觉得人均高级才搞得下去。
leader 是后端组长，还是项目经理，还是部门经理？这个还是管理问题，事前没规范，事中瞎搞，事后没复盘。
自下而上很难搞。这个情况，我也不知道怎么把问题上升，领导思维固化，难以改变。
我有个简单的想法，不谈 PMP 、执行力这些东西。就把功能质量标准、时间都定下来，责任边界划分清除，
到底是产品、后端、前端、测试的问题。一个事不管多少人参与，就定一个责任人，让这个人去拉通。
搞不定就辞退，搞定优先考虑晋升，就这样靠个人能力硬搞。当每个人都会被定为责任人，
逼着每个人提高个人能力和协作。
你们估计也没绩效，要么绩效只是按加班考核。

[tangkikodo]

后端接口质量不过关，并且 leader 不重视， 前端只能遭罪了。

我们 team 也不大， 但是 service 层功能的 testcase 非常重视，单测，mock 数据的集成测试， 这是这两点就让接口质量稳定了许多。

[iheeleme]

@k9990009 说的太中肯了，目前就是事前不规范，事中没有任何逻辑的干，事后不复盘，可惜目前本人在团队话语权不够，基本属于自下而上去驱动，无法改变现状，

[iheeleme]

@tangkikodo 确实遭罪，日常被拉着加班，加班也是等，基本没有任何产出

[v2Geeker]

价值导向呀，能赚钱吗？你要把这事往你领导的目标上靠，或者，你把收益、执行路径跟你领导讲清楚？好好给他规划一番，说得他无法反驳。如果这些都做了还不同意，那个时候才决定走不走呀！

[kandaakihito]

天呐这简直就是我.jpeg （请自行脑补那张图）

无解，大领导怎么可能不知道团队下面啥情况，无非是觉得以公司的水平，在场的技术团队不重要所以不想做出改变罢了。大概率你们公司也是明面上产品、项目与开发平级，实际上开发的重要性垫底。

[taine]

只看第一条，如果是事实，尽量离开。

[Xrall]

不知道其他，反正自己所在的也是这样。其次就是比这个更糟糕。需求变更会给你讲，加量不加价。
其次提需求的人你问具体的需求，他就回你不知道，我也不晓得。
非得他说个轮廓然后你自己想，想到了不合理在和他扯皮。
想跑，但是自己一没强劲的技术，二没学历，市场也难顶。一言难尽。

[jianghu52]

如果你真的想彻底改变这一现状。那么首先，你要做下面 3 件事儿。
1.看明白整个团队谁的话语权最大。是项目经理，还是前端销售，还是财务主管。是哪个能能拍板让你试错。能承担试错的后果。
2.找出一个最具收益的修改方向。并给出具体的评估数据。
3.做出风险评估以及失败后的补救计划。


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

作为老板有时候会很讨厌“精英”式的队员。因为他们本身能力强，然后就理所当然的认为其他人应该跟他们一样强，然后就开始各种看其他人不顺眼。偏偏呢，他们说的不少东西是对的。但是对的又怎么样，错的东西就已经能赚钱了，对的东西能帮老板赚更多的钱么，不能的话，那为什么要改，仅仅是为了让你们这些牛马少加班么？
是的，我这么说很资本家，但是这就是现实。我在楼主的描述中，看到了交付质量差，项目延期，但是我没见到甲方的态度，没看到甲方的要求。在这种情况下，作为乙方的老板，有什么动力去重构整个项目的流程，中间的风险谁来承担？
我听一个前辈讲过一段话，很有启发。他说，一个项目里面，能有 20%靠谱的人，就谢天谢地了。剩下 80%里面，通常会有 30%的草包，和 50%的混子。20%的骨干的能力的强弱，影响着项目的上限，但是项目的下限，根据木桶原理，往往取决于那 30%的草包。而一个项目实际的结果，其实最终取决于 50%的混子的用心程度。
所以我现在做项目，首先问自己的是，这个项目的下限要什么样，然后去看草包的能力够不够。然后再看项目客户预期什么样，随之看我鞭策混子的强度有多大。至于希望项目有多优秀，我基本上都随缘了。

[caomu]

看起来像是给 G 做外包的，按我们平时用起来的体验，反正就像一坨，但是至少能用就行，而且都支持现代浏览器了，不像以前老业务还得用 ie 。只要能跑，支持现代浏览器，过了等保不出安全问题被爆库注入啥的就好。

[chendl111]

@iheeleme #16 从自己负责的部分入手，将其规范化，统计规范化前后的开发效率/时长/代码量/步骤，做成 ppt 反映给大领导，争取管理层的认可
如果领导不在意，做好自己的事情，等待时机即可

[shawnsh]

规范化不是一天搞成的，项目中出现的各种问题重复多次出现总要有接地气的解决方案吧

[ninjaJ]

这个话题我可能有一点发言权，因为我曾经也在这样一个团队，后来通过一些策略在团队内推动了这些东西，最后成了大团队 leader 。。。

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

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

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

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

如果你想锻炼一下自己的管理能力，这个地方可太适合你了。如果你想做好技术，赶紧跑吧。

[yangzzzzzz]

之前公司和你说的差不多，然后来了一个比较有能力的老哥 搞了全套流程 还经常写文档、周报、总结等。但是领导需求经常变 最后累的还是自己。前段时间私下和我说事情越来越多 不想干了。这种情况，领导层不变 是没用的。其实最主要原因还是 需求变动频繁 人员不够，老板想省钱 又着急给客户看成果

[lsyAndroid]

伙计，能干就行，能跑就行，至于其他的对小公司来说真的不重要。重要的是能活下去，发得出工资，交得起社保！