千万不要被 Leader 的鬼话影响

Leader

鬼话

理由

代码

80 条回复 • 2019-08-14 10:34:36 +08:00

1

ly4572615

2019-08-12 17:29:45 +08:00

1

我不一样，我碰见的都是些好久不在一线的“领导”碰见影响业务的问题，带着一堆人靠开会连猜带蒙去解决问题，我们这里也没有 Leader 一说，都是自己处理解决自己的问题

2

lixiangzaizheli

2019-08-12 17:32:33 +08:00

1

不知道我这个 leader 的鬼话如何

3

lixiangzaizheli

2019-08-12 17:32:37 +08:00

1

https://imgchr.com/i/mSwmSf

4

zzhbbdbbd

OP

2019-08-12 17:32:46 +08:00

1

@ly4572615 这样太好了，我们是一个部门有一个 Leader，这个 Leader 是技术，方案，拍板的，有的时候，Leader 真的就是整个团队的短板，什么都是他说了算

5

also24

2019-08-12 17:48:04 +08:00

18

转述一下我在之前的帖子里的态度
https://www.v2ex.com/t/546096

我做组员的时候，我会详细说明这么做的理由，以及主管的方案的问题，然后由主管告诉我最终结果：
“那就改掉吧” 或者 “别 BB，按我说的做”

我做主管的时候，了解一下组员想这样做的原因，陈述一下自己的想法，然后给出最终方案：
“那就改掉吧” 或者 “别 BB，按我说的做”

总而言之：
组员只要确保自己讲清楚理由，主管只需要确保收集足够的信息。
至于决策？你以为 “主管” 两个字是什么意思？

6

also24

2019-08-12 17:50:43 +08:00

之所以这么做，主要是因为：
当主管干涉你的方案时，主管要对他作出的决策负责

当然，如果你遇到了一个，干涉你方案还不为这个决策负责的主管，那确实是个糟糕的情况。

7

betulac

2019-08-12 17:54:44 +08:00

领导不是应该只关心你什么时候干完吗

8

liangkang1436

2019-08-12 17:54:59 +08:00 via Android

@also24 说的清清楚楚明明白白，令人信服！

9

zzhbbdbbd

OP

2019-08-12 17:57:27 +08:00

@also24 看你这么一说，我觉得挺有道理的，但是有的时候他的决策虽然不会引发业务上的问题，这意味着他并不需要负责，因为没出问题，但是，代码却很难看，整个团队的代码水平是被限制住了

10

zjsxwc

2019-08-12 18:00:59 +08:00 via Android

碰到的技术领导水平和经验都比我高，code review 时是学习的时候，

碰到产品出身的领导确实有楼主这些问题，但是他们是老大他们说了算，不用多想造做就行，留下聊天证据，出问题不是我背锅就行。

11

scofieldpeng

2019-08-12 18:01:42 +08:00

给你一个小 tip 吧：觉得有更好的办法，带上你的理由给更好的方案。如果 leader 不认同，反驳你并且不执行，没关系。如果出事的时候，因为老方案的原因，并且领导愿意承担责任，跟你没啥关系。不愿意，你至少认清了这个 leader 可以说是不负责的 leader 了。
还是那句话，拿钱办事，要么忍要么滚。
最后，这就是为什么我家里有一个高可用集群的原因之一。如果环境给不了你想要的，那就自己主动创造一个适合你的环境。

12

zzhbbdbbd

OP

2019-08-12 18:02:28 +08:00

@zjsxwc 是技术出身的，每次 code review 就是在把他那些糟糕的观念灌输给我，接受不了，拗不过，常常只有妥协

13

zzhbbdbbd

OP

2019-08-12 18:03:46 +08:00

@scofieldpeng 谢谢，可能我对公司有所误解，我一直以为团队是能够帮助我提升的，发现缺了“好的团队”这个形容词

14

virus94

2019-08-12 18:03:50 +08:00

@zzhbbdbbd +1 部门里就所谓的 leader 最散漫,思想落后,大大小小的事都要插一嘴,跟村头的长舌妇似的.
可怕的是,公司居然可以一直容忍这种人存在.

15

zzhbbdbbd

OP

2019-08-12 18:08:23 +08:00

@virus94 有的时候我挺理解他要考虑很多，其实有的时候他确实对他的烂 idea 很固执，很惊奇产品还可以活，现在项目里都是各种 patch，全局滥用，有的时候安慰自己这不是自己的项目。leader 真的是团队的短板啊，code review 的时候照做就行了

16

scofieldpeng

2019-08-12 18:11:04 +08:00

@zzhbbdbbd #13 好的公司是能在一定程度上帮助你成长，但是不要认为公司能帮你很多，最根本的还是靠你自己。

17

also24

2019-08-12 18:17:25 +08:00

代码难看这个事儿，因为没有具体接触，我不太好猜测具体情况。

有时我也会刻意要求组员写某些 “冗余” 的代码，乍一看有些过度解耦的嫌疑。
这种情况有时是因为我这边和产品 /业务交流的会更多，会预测到一些后期需求，不太复杂的预先准备工作，就在前期顺手做了。

这个只能说有利有弊，短期来看会增长工期，长期来看也有预测不准的风险在里面。
但是还是那句话，这部分责任，我会来承担，短期工期我来争取，长期风险我尽量降低。

另，如果我遇到有人写了有风险的代码，又不听我的意见的情况，时间充裕的情况下我不会太强求，而是会构造一个对应的特殊 Case 要求他处理，他就明白我的意思了。

18

zzhbbdbbd

OP

2019-08-12 18:25:37 +08:00

@also24 赞同这种情况，但是在两种方案都可以解决问题的情况下，并且我的方案更能适应多种场景，他会以没有这种场景来反驳，然后采用他的烂点子。上面的你会出一个 case，他出不出来，也没必要出，拍板就行了...

19

also24

2019-08-12 18:27:52 +08:00

@zzhbbdbbd #15
“代码好看” 是要付出很大的成本的，老项目丑一些是常态。

代码不是艺术品，重心最后其实还是在业务需求方面。
有预见到风险的时候，及时告知就好了，个中权衡，让具体负责的人来做。

除非 leader 是无理取闹，否则还是以负责人说的为准吧。

组员：我觉得这样写，在高并发场景下，如果有两个请求连续操作 xxx，会出现问题。
组长：你想太多了，我们这个系统没多少人用，真出了问题那部分数据也不重要，别管啦。

组员：我觉得我们应该把 xx 拆分出去，方便下个项目复用
组长：你妹的这个项目工期还有 3 天了，你给下个项目省时间有个鬼用，别管啦。

20

zzhbbdbbd

OP

2019-08-12 18:29:50 +08:00

@also24 可能我觉得代码是艺术品...

21

codermagefox

2019-08-12 18:35:52 +08:00

@zzhbbdbbd #20 那我觉得你 Leader 可能段位真的比你高...

22

janxin

2019-08-12 18:36:10 +08:00

主管和成员两个人出现方案分歧的时候，不一定是哪个人傻逼

23

win7pro

2019-08-12 18:36:36 +08:00

1、你可以坚持你的信仰，你的判断，但你最终还是应该按 leader 的决策来执行。
2、无法评价你 leader 的“鬼话”是否在理，但是如果组员们都和你一样觉得自己有更好的方案并且都希望按自己的那套去执行，那肯定是个灾难，leader 这个角色的作用这时候就有用了，他拍板的未必是你认可的，但是可以保证大家的方向是一致的。
3、有时候，最好的技术方案未必是最合适的技术方案，作为组员更多想到的是技术实现方案，作为 leader 还要看到项目上线风险，产品上下游配合，开发周期，代码维护交接难度，人员可替代等因素，这些因素综合起来做出的决定，可能就不那么好理解。
4、leader 做出决策同时也是要为他的决策负责任，某个角度上来说，这个 leader 能坚持他的选择说明他起码也是个基本及格的 leader，可能是沟通能力和影响力上欠缺没法让组员信服，但是比起那些一幅“你自己决定”然后出了问题就往你身上推责任的 leader 来说，已经算不错了。

24

JsonTu

2019-08-12 18:47:41 +08:00 via iPhone

如果你有能力证明你的解决方案更好，你迟早会把他干掉。反之亦然。
我目前就是这个样子，组员说的我基本上都否了，那是因为确实渣，做事不动脑子，这里改好了那里坏了，还得帮着擦屁股，真 TM 心烦

25

bellchu

2019-08-12 18:51:42 +08:00 via Android

“刚出来工作不久”

26

vjnjc

2019-08-12 18:51:59 +08:00

跟楼上 also24 的看法一致，业务代码不可能写的很简洁很艺术的，因为业务需求不可控。

而领导让你改方案主要是方便管理。不知道你们团队人多不多，要是每个人写出的代码风格都不一样的话，em，至少我是不想维护的，丑也要丑得尽量风格一致。

对代码的精益求精是很好的习惯，但工作上的代码还是尽量满足需求(包括老大的需求)。想要爽就写 side project 鸭

27

dvaknheo

2019-08-12 18:57:07 +08:00

@also24
组员：我觉得我们应该把 xx 拆分出去，方便下个项目复用
组长：你妹的这个项目工期还有 3 天了，你给下个项目省时间有个鬼用，别管啦。
组员：项目完工了，我们可以拆分了吧？
组长：得，跑得好好的，改出问题来你负责啊？

28

ChenStyle

2019-08-12 22:23:06 +08:00

解决方案这种东西肯定有好几种，关键是工作量和随之而来的问题。你不妨问清楚你不想采用的理由，或者问如果在什么情况下出现什么问题如何解决。如果你问不出来，只是觉得这个解决方案有问题，那是你的问题。

29

switch100

2019-08-12 22:40:44 +08:00

1

有一种主管，就是什么都不管你，做好了没表扬，做坏了压力巨大，我真的觉得很没意思

30

leafShimple

2019-08-12 22:46:04 +08:00

我把他熬走,然后我照着自己喜欢的样子改项目.改了一年.各种舒服,兄弟.哈哈哈... 现在我参与的项目都是怎么舒服怎么来,因为大家观点都差不多.他说公司规定 1.6,走了我就 1.8.- - 不合理的通通改掉.

31

fhsan

2019-08-12 22:59:46 +08:00

我们一个团队，三年都没人撕逼主管，每次撕逼都有 100 个理由证明他是对的，后来走个形式，最后按照他说的做。

32

Just1n

2019-08-12 23:04:22 +08:00

5

我觉得当前帖子下，楼主说的这些都是楼主自己的主观感受，没有实际的案例。
楼主说 Leader 的方法烂，但是没有说出烂在哪里，如果能举出一个例子，也好让大家知道到底是谁的方法更优。而且很多时候方法的优劣，并不好通过一个人的单方面说辞去判断，要放在一个具体的产品的样本中去判断。

当一个产品足够大的时候，Leader 必然是对产品的了解比你更多的，他在做一个决定的时候，必然是从全局去考虑。

举个简单例子（只是例子），你深谙 SOLID 之道，在做一个简单的 issue fixing 的 work item 的时候，你觉得有几个文件的代码看着非常的繁冗，完全背离了 SOLID 原则，你想去做一下重构。如果是我，我可能不会允许你在当前这个 work item 下去做这个事情，而会建议你新建一个 WI，专门去搞这个重构。
你可能不会同意，觉得是顺带手的事情，但是从大局来看，每一个 WI 拆分得越细，目标越单一，出错的概率就越小, Reviewer 审查代码的时候也越容易。
Fix Issue 就是 Fix Issue, 重构就是重构，New Feature 就是 New Feature.

综上来看，我无法判断你和你的 Leader 两个人的方法和观点谁对谁错，但是有一点他没有做好，就是他否决你的方案的时候，没有给你一个非常合理的解释，也没有照顾到你的情绪，所以才会让你觉得他的方法烂，和觉得他固执。

以上是我作为 Leader 的一些感觉和判断，不一定对，但是希望可以给楼主一个从另外一个角度去看待这个问题的可能性。

33

fvckDaybyte2

2019-08-12 23:22:51 +08:00 via iPhone

没有 code review，leader 只看结果，不问过程，不知道是好是坏

34

imycc

2019-08-12 23:29:59 +08:00

首先必须肯定的是，leader 的决策并非都是对的。

除非是难度特别大的模块，通常业务代码用 A 方式行得通，用 B 方式也可以。不单是看功能是否能被实现，还需要考虑测试、运维、拓展性、时间成本、人力成本等等方面。leader 是决策者，最后出了问题他自己也是要负责的。

这个贴下面很多人在反驳你的话，我觉得问题不是出在“要不要用 leader 的方案”，而是你的描述中没有说清楚，你跟 leader 具体的矛盾在哪里。leader 觉得你的方案不好，不好在哪里，是时间成本大？是容错性差？是无法实现 KPI ？还是运维成本高？

如果你的 leader 讲不清楚方案差在哪里，那是他的水平不行。如果他讲清楚了，你能基于他的观点进行反驳，那才是大家更愿意看到的讨论~

35

2kCS5c0b0ITXE5k2

2019-08-13 00:28:39 +08:00

事实上有 leader 出错了就是他负责你照着他思路走出错了就是他问题

36

hhhsuan

2019-08-13 00:35:31 +08:00 via Android

作为 leader，我一般不接受别人不用我的方案

37

laike9m

2019-08-13 08:08:42 +08:00

举个例子咯，看看到底谁的方案好？不然空口无凭啊

38

HuHui

2019-08-13 08:23:32 +08:00 via Android

对于一个团队而言，对错好坏不是那么重要，重要的是方向的一致性。

39

orqzsf1

2019-08-13 09:19:17 +08:00

楼主可以收藏这个贴，几年后自己来回贴

40

hantsy

2019-08-13 09:34:05 +08:00

2

@Just1n 很多习惯了抱怨，而不是正确的去看待问题本身。作为技术决策者，可能要考虑太多的是应用整体设计层面上的问题。

曾经在 V 站看到几个这样类似的帖子“后端太菜了，开发 API 太慢，影响到我前端开发怎么办”，或者相反。以我的经验，你做前端为什么要等后端 API 提供再开发？为了消磨时间吗？从技术角度很容易来解决，比如引入 Consumer Driven Contracts。如果做技术 Lead，强制加入一些新东西，必然会引起一些习惯打酱油的人自然反弹。必然有些人会抱怨，这个 Lead 太不人道，把自己的想法强加到别人头上。

在自由职业这几年时间，我也尝试过加入一些创业公司，希望有机会能够用上自己技术栈，结果算是栽了跟头。推过敏捷，XP，TDD，结果没一个人愿意写测试。推行过 Github Flow，结果大部分人还是习惯 SVN 式的使用。推行过 CI 测试，部署自动化。。。结果都是不理想。有些人习惯把自己的无知或懒惰当成合情合理，不愿意去接受一些新东西，他们喜欢把时间浪费在一些重复无聊的事情，而不是用在创造性的工作上，还经常抱怨别人，什么“领导不好”，“同事太菜影响到自己”。

@hhhsuan 从大体上讲，完全不接受也不妥，任何方案在实施之前，听取各方面的意见，三思而行，Think twice before you act. 敏捷开发也讲 Brainstorming。以前的经验中，即使是一个小的 Task，在没指派前，都是希望大家发表意见。把要考虑的东西全部摆到台面说出来，然后再指派，或者由 Team Member 自己认领。

41

viazure

2019-08-13 09:36:36 +08:00

「真的想把公司的产品当作自己的产品来做，但是后来发现真的很难。」感同身受。

42

pluepapya

2019-08-13 09:37:54 +08:00

那怎么办啊。

43

raysonlu

2019-08-13 09:39:30 +08:00

一句总结，楼主还是太年轻了

44

phpcxy

2019-08-13 09:49:18 +08:00

只给建议，能实现出来管他用什么方法

45

Takamine

2019-08-13 09:55:14 +08:00

很现实的问题，你不是那个做决策的人。
你要做的是把属于自己要做的这一块做好就够了，剩下的时间提升自己。
不是每个地方招人都是为了希望一起成长共同打造一个好的东西的。
甚至整体业务的成败说难听一点，和你的关系并不大。
有时候他只需要一个泥瓦匠，你却想干建筑师的活，他反倒觉得是你不自知。
这说明你和这个公司这个岗位不匹配，剩下的六字真言不用我多说了吧。:doge:

46

sucai

2019-08-13 09:59:38 +08:00

看来我遇到的 leader 普遍较好，能听进去话，还愿意抗事

47

yggdrasilqh

2019-08-13 10:00:35 +08:00

顶！！支持浩大王

48

Keyes

2019-08-13 10:38:27 +08:00

我们研发团队就是这个鬼样子

Python+PHP 都写不好，非要说 P+P 语言垃圾
MySQL 好好用着，嫌安装包大，功能太多太重，硬生生换成 SQLite
天天喊着重构，重构了三年一点屁动作都没有
我做的功能，人家说你这根本不算功能，太小了太简单了，结果我转岗时候让找人接，说没人接得了，硬生生拖了三年

过完年，最后我留下一句话，老子这次铁了心去做产品了，你爱 TM 怎么折腾怎么折腾吧，不服请把我开掉谢谢

然后丫怂逼了，怂逼我也不给你面子了，再见！

49

luozic

2019-08-13 10:57:06 +08:00 via iPhone

静态和老旧才可控啊；都是新的虽然原理一样，但是本身就没有好好明白原理，换了新东西，他咋能控制呢，表现自己的权威呢。

50

smallpython

2019-08-13 11:52:15 +08:00

公司的代码是公司的财产,不是你的
你要是有好的想法,可以自己写自己的项目
把公司的代码和自己的代码区分开来

51

b0644170fc

2019-08-13 12:01:10 +08:00

@also24 +10086

52

lk920724

2019-08-13 12:13:48 +08:00

代码是你意志的产物，但也是你领导意志的产物。
换位思考领导怎么想的呗，当然领导不一定全对。及时反馈是最重要的吧。跟着他的思路走错了也是他的问题。别把锅一直往身上背吧~（简称甩锅 23333 ）

53

mars0prince

2019-08-13 12:15:52 +08:00

@also24 要是主管肯背锅，估计楼主也不会发帖了

54

winglight2016

2019-08-13 12:18:21 +08:00

我还以为 lz 遭遇工作 /生活态度不端的领导，原来只是技术问题的争执，这种问题还真是不值一提。有时候技术选择在组员的层面和 leader 层面看来是不一样的，lz 可以尝试一下换个角度思考。

55

chnhyg

2019-08-13 12:35:40 +08:00

谁决策，谁背锅。

56

wly19960911

2019-08-13 14:03:41 +08:00

不要和主管争论，你表达自己观点就行，锅不是你背，如果甩锅过来你有理有据就行。

只要你背这个锅你就能做，但是公司不让你背。

57

1239305697

2019-08-13 14:17:01 +08:00

leader 最烦的就是你这种刚出来工作，班没上几天，觉得自己很厉害的组员，自己写到一半写不下去了，出了问题自己拍拍屁股走人了，让 leader 加班帮你擦屁股

58

1239305697

2019-08-13 14:18:23 +08:00

方案好不好什么时候跟代码写的好不好挂钩了？代码写的跟狗屎一样，方案再好有什么用？

59

ibufu

2019-08-13 14:33:45 +08:00

那你倒是把 argue 的点贴出来啊，让大家给你看看到底是谁的问题。
Talk is cheap, show me the code.

60

Sapp

2019-08-13 14:44:38 +08:00

按照你说的办，出事情你负责吗？最后还不是他负责，那么为什么他不按照他的想法搞呢？他选这个方案应该就是有过往经验，哪怕是个垃圾方案，他也能负责的起来，你呢？

61

8355

2019-08-13 14:48:57 +08:00

从语言上来看工作经验小于 3 年

62

wupher

2019-08-13 14:49:01 +08:00

这是你们 leader 差啊。

一般只提建议，最终上线结果由测试和产品经理决定。俗话说的好，让听得见炮火的人来指挥战斗。

我作为 leader 如果强烈反对这样实现，一般是由于这么做会坑到“我的代码”，否则我只建议。否则，自己拉的屎，自己捡干净。

63

IamUNICODE

2019-08-13 15:13:53 +08:00

@1239305697 这位+1
以前有个同事也是这样，一定要按照自己的想法写，结果 bug 超多，最后还得别人帮他洗地，然后他还嫌领导技术不好领导能力不行，emmmmmmmmm

64

snappyone

2019-08-13 15:19:33 +08:00

举个例子说明下，不然我也认同楼上几位的说法

65

mrzx

2019-08-13 15:29:14 +08:00

很简单，我工作中遇到这种事情，我直接跟领导说，如果按照你这种做法，会出现“ xxxxxx"之类的问题，还影响这项工作的进度。如果你命令我这么做，可以，发封正式邮件给我，阐述你要求我必须这么做的合理理由，抄送给我们相关最大的相关领导。
我就照你说的做，怎么样？

通常说完这句话后，领导都会缩成一条虫，立刻态度 180 度大转变，不会在对你指手画脚了，因为他怕担责任啊～～～～～

最关键是你自己不要怂，因为如果坚信你自己是对的，或者说领导说的方法的确比你好，你也不用着说这些话。反之，遇到那种傻逼领导，该怼就怼，最坏结果能怎样？丢了工作在找呗，又能力你害怕找不到工作？而且你不在他底下干反而是好事。。。

66

mrzx

2019-08-13 15:34:22 +08:00

总之，如果是自己做的事情，自己要担责任，如果是领导逼着你这样做，那么就让你的领导写一封邮件抄送给所有人，如果出事了，你不用承担这个责任。

67

Flourite

2019-08-13 15:36:09 +08:00

不用在意，出来工作 4/5 年，其实大部分程序员都很水，做自己的事情就好

68

dsnake1984

2019-08-13 15:38:42 +08:00

别瞎折腾听领导的否则季末 C

69

IamUNICODE

2019-08-13 15:51:50 +08:00

@also24 那帖子笑喷了，这都能吵一天

70

xaoduer

2019-08-13 16:00:49 +08:00

一般来讲我能留下来继续干肯定是认可领导的能力的，领导的考虑层面跟我们不一样，他要顾全局，所以领导说，我们来做就好了。因此你可以把你的想法和考虑告诉 leader，如果他坚持自己的，那就照他的干，不管你认为自己的方案有多好。如果你不认可他的能力,或者你认为 leader 技术烂的一比还爱瞎搞搞，不辞职留着干嘛？

71

luzhh

2019-08-13 16:16:02 +08:00

上一个项目，方案我不是很认同，而且逻辑会比较复杂。但是没办法，所以我只是尽力把代码写的更优雅更简洁一些。

72

Breadykid

2019-08-13 16:20:07 +08:00

@zzhbbdbbd 我也觉得写得好看的代码是艺术品呢

73

lqw3030

2019-08-13 16:21:15 +08:00

你是来赚钱，还是来拯救世界

74

yalin

2019-08-13 16:23:32 +08:00

一言难尽

75

miniwade514

2019-08-13 16:25:38 +08:00 via iPhone

2

有没有这样的主管？
要求你用他的方式做事，尽管你不认同，但他很固执。
由于客观上这个方式是有问题的，导致过程很不顺利。
你内心抵触，但也很痛苦地坚持，最终还是把事情做到了。
最后主管拿着成果去晋升了。
而你，因为过程中推进得不太顺利，导致他觉得你能力有问题，绩效给你打了差。
有没有这样的主管？
真 tm 有。