千万不要被 Leader 的鬼话影响

[zzhbbdbbd]

千万不要被 Leader 的鬼话影响 刚出来工作不久，感触很深的一件事情，很多时候对于一件事情的解决方法有很多种，当你突然想到一种很好的解决方法的时候，Leader 突然拿出一个烂方法说这个好，总是在朝自己灌输一系列他的想法，但是通常这个阶段的自己没有太大的说服力，再有力的理由也会打半折，你知道，代码这东西，只要能解决问题，他能扯 100 种理由来说他的观点，最后将你的方案丢掉，理由就是他觉得，他的方案更好，最后代码是越写越糟糕。

这样的团队不能提升自己，反而在走倒退的路，我觉得团队低于我的期望了，有时候真的想把公司的产品当作自己的产品来做，但是后来发现真的很难。

[codermagefox]

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

[janxin]

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

[win7pro]

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

[JsonTu]

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

[bellchu]

“刚出来工作不久”

[vjnjc]

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

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

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

[dvaknheo]

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

[ChenStyle]

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

[switch100]

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

[leafShimple]

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

[fhsan]

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

[Just1n]

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

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

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

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

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

[fvckDaybyte2]

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

[imycc]

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

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

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

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

[2kCS5c0b0ITXE5k2]

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

[hhhsuan]

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

[laike9m]

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

[HuHui]

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

[orqzsf1]

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

[hantsy]

@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 自己认领。