团队之困

去年写在印象笔记的一篇文章，忘了发布了。

在团队中推行一个新的事物（比如一个高效的工具、一个比现有更好的平台）比你想象的要难的更多。

尤其是非技术人，他们可能不了解利用技术和工具到底可以帮 TA 做多少事情，TA 每天重复性的花很长时间处理的数据，写个自动化脚本可能分分中就搞定了，并且可以自动化。

两个问题：

TA 们不知道有更好的办法，觉得现在处理的方式还挺好的，这些 "时间上的浪费" 是 TA 们工作的一部分，所以理所应当。
当你告诉他们这些你有更好的办法去用程序去解决，让 TA们提需求，我们帮他们解决这个问题时，他们通常是拒绝的，他们觉得现在处理方式能够满足他们的需求，所以似乎没有什么需求可以提。

习惯是个双刃剑，一旦习惯了某一件事物，就很难去提升自己。比如一开始用公司的系统做一个查询花了 5s，觉得很慢，但是你不了解这个系统的实现和优化难度，也不好说什么，就忍了。每个到公司的新人，基本上都是这个过程，久而久之，大家都习惯了这个速度。突然有个愣头青去抱怨这个问题时，甚至告诉他们这个问题可能很好解决，大家通常不是告诉他去尝试修改，而是觉得这个速度还可以。事实往往可能是从 5s 优化到 5ms 仅仅需要一行语句的调整。

一个拥有"历史原因"的项目组，这种问题更为严重。成员不愿意接受新的工具、新的技术、保守残缺，包括主管在内没有愿意承担无形的风险，即便是 0 风险。

当遇到问题时，大家都倾向于先能够解决问题的方法，而这个方法是否好当时可能没有时间和精力去评判，于是会信誓旦旦的说后续一定优化，事实上这个后续托了很久以至于相关模块负责人换了几波，这个问题的解决方法就成了 "历史原因"。

想起陈皓的一个微博：

这些东西，都是我 3-4 年前就讲过的事了，我在现公司也讲也实施，但效果不好。我现在越来越理解什么是"对牛谈琴"了。

看到有些同学想推动工程师文化，我只能对他们说，不要去推动，应该去寻找，和聪明的人在一起就完了，因为你不需要去解决不存在的问题。

我觉得说的太对了，在团队中想做一点改变都是很困难的。截至到 14 年 8 月份，我坚定的以为我只要耐心的做好技术就够了，个人能力足够强到哪儿都吃香。但是我后来开始质疑了：

一方面，虽说 "老子干的不爽就滚蛋" 这种观点就没有错的，但是更换工作环境并且熟悉它是一个很累的过程，并且你没有办法保证你的新环境是优于现在的环境（除了工资高一些，福利待遇都不能保证）;

另一方面，工作中大部分时候不需要那么好的技术，这又回到了上面的问题上，大部分问题只需要一个解决方案，并没有多少人关心这个解决方案足够好，尤其是站在公司的层面上，并不是说大家懒，而是优化通常费力不讨好，公司宁愿把你的精力花在其"更有价值"的事情上。当那个临时的解决方案出现了问题的时候，只需要一个人出来把这个坑给添了就可以了。对于这种流程你觉得不合理，但是想一想好像又他妈挺合理的.

这段日子，一直在想，我从事这个行业是我的兴趣所在，我喜欢工程、喜欢编码、喜欢那种把问题完美解决的感觉。可是我发现我所喜欢的感觉在一点一点的被磨灭，终究有一天会厌烦，那时我又将何去何从呢？又或者说现在应该尝试换个环境呢？