管理者，不必是一个专家，但一定能带领团队找到方向；不必时时和蔼可亲，但是需要客观公正；不必是事必躬亲，但需要人尽其用，才尽其专。
     
    我比较幸运，无论是读书时期的兼职零工，还是毕业后的正式工作，和老板（直属领导）关系都还行，没有发生一些不愉快的事情。不过对身边发生的一些见闻感触很多，对一个优秀的管理者的样子有一点自己的思考和理解。这里写几个亲历的故事，大家不妨看个热闹。

小老板的故事

    高中毕业的时候在老家的小城市找了一份暑期兼职，工作的内容就是在手机零配件批发部给手机维修师傅送货。那个时候还是功能机时代，手机维修的需求很多，手机维修需要一些屏幕、听筒、排线等配件。城市不大，骑个自行车市区10 -20 分钟内大部分地方可以送到，所以老板喜欢招一些年轻小伙儿送货，人力便宜还身手敏捷。当然也有中年人做这个，临时混口饭吃。

    我们店的老板姓陈，每天坐在店里接电话出货。大家都叫他老陈，为人很和气，不管是客户还是员工遇到的问题都尽力帮忙解决，跟他干还是比较开心。手机和配件这个行业在当时的小城市属于暴利行业，一块商务电池进价 20 元，给维修师傅的价格是 60 元，最终顾客需要支付 100 - 200 元不等。

    隔壁陆陆续续开过几家新的批发铺子，都不太长久。有一次中午吃饭认识了一个隔壁的送货小哥，我叫他黄哥，给我说干啥都不容易，他们那个老板很烦，经常数落他们。客户(维修师傅)有时候摸不清需要更换什么配件，往往弄错，于是他们就来回跑。浪费时间不说，空跑也不挣钱，老板就责怪他们为啥不问清楚再送，如果维修师傅经常这样，就加钱或者不送了。

    我感到很惊讶，这算啥事儿啊。我们之前也遇到这些问题，就给老陈吐槽这事儿。老陈说你们来回跑怪累的，我这就去买一些包，下次你就把常用的都带上，有个包放收据啥的也方便。工作中这样的例子很多，有啥事儿就给老陈说，一起想想如何改进也就解决了。优秀的管理者，应是挖渠人。利用自己的位置和资源帮助解决问题，让员工工作流畅，就像春耕时期引水灌溉一样，及时疏通水渠中的石头和杂草，而不是怪水流的太慢。

    Thoughtworks 的一个同事刚到 Thoughtworks 的时候被分配到国内某项目，负责前端开发，构建一个报表页面。我们组就两个人，一个前端，也就是我，还有一个后端。项目比较简单，我很快构建好了 React 的前端页面，因此在 Interview ++(内部的一种绩效评价机制)中的评价还行。后端那个兄弟使用 Spring Boot 构建 API ，并需要连接 LDAP 获取公司的员工信息。他的工作并不顺利，花了大概两周才完成了 API 构建而且质量不佳。

    后来我参加他的 Interview ++，得知他有10 年以上的工作经验，之前一直都是写 C++ ，因为没有合适的项目来这个项目上写 Java。他的 Interview ++ 评价很不好，“技术能力一般，和工作经验不匹配” “不主动交流” “接受反馈的能力不好” 等。因为项目上只有两个人，我们私下关系比较好，他虽然不是很健谈的人，但是具有非常好的沟通能力，理性和独立思考。我能理解他被给负面反馈的原因，无非是他工作在一个不适合他的位置，当技术能力无法满足项目需要时。在团队眼里，优点就会被弱化，缺点被放大。

    很多人可能会说，写得好 C++ 的人写 Java 也会很快上手。但是客观事实是，计算机语言虽然很容易跨越，但是领域很难。长期从事嵌入式工作的人在没有人指导的情况下，在两周内上手 Spring Boot 这种 “低级“ 技术很困难，因为需要很多服务器编程的背景知识。在某个平行宇宙，他会不会上了一个他擅长的项目，被当做大神膜拜。“不主动交流” “接受反馈的能力不好” 这些反馈还算不算缺点呢？优秀的管理者，应是引水人，把员工放到合适的地方，用合适的期望评价工作产出。需要遵从科学发展观，再好的水也不能逆势倒流。

一个客户的故事

”我说过好多次了，提交代码前需要本地跑通，现在流水线又挂了“

”我昨天就强调，没用的代码要删除，不要留在项目里面“

”你这个代码能不能写的规范一点，这么乱“

    晨会开了半个小时后，我无奈的放下耳机。在国内的一个项目上，我被派到一个团队和客户一起工作，这几乎是每天早上的状态。每天主持晨会的人是客户一个工作了很久的人，他似乎很恼怒，责备负责管理供应商的人为什么招聘了这么多能力差的人。我入场后，分配的第一个工作是改造一个旧项目，这个项目因为某些设计遗留问题，遇到了性能瓶颈，需要优化。一个负责相关业务的人来给我讲了一下背景，然后给我开通了一个代码仓库的权限，我就这么开始工作了。

    当我开始下载好代码后，头皮发麻，这个项目没有任何文档介绍如何启动。甚至我不知道这个项目在整个系统中处于哪个位置，我开始四处求助。我找遍了整个办公室的人，得到了很多收获。

● 想要把项目跑起来，本地需要安装 Redis、数据库等依赖，不过需要从同事那里先拷贝一些特别的配置，并注释几行代码。

● 想要了解整个项目的背景，找了同事 A、B、C 终于拼凑出了这个项目的概况。

● 项目没有任何规范，全凭自己发挥，至少有三种加解密的工具类，多种序列化方法。

● 想要部署到 Dev 环境，发现每个人建有自己的流水线，部署方式各不相同。

    最终这个项目做的非常头疼，技术经理没有打通整个工作流，整理相关的文档、规范、部署方法，让开发把主要力气用在开发上。每个人都需要摸索一套自己的做事方法，做东西很难说高效和”规范“ 。优秀的管理者，应是治水人，像都江堰的鱼嘴、堤堰，疏、堵相适宜。设计工作流、协作体系，制定规范。

总结

    站在员工的视角，看待一个优秀的领导者，可能有不同的看法。不过，可能有几个共同点，大体是差不多的。管理者，不必是一个专家，但一定能带领团队找到方向；不必时时和蔼可亲，但是需要客观公正；不必是事必躬亲，但需要人尽其用，才尽其专。“太上，不知有之；其次，亲而誉之；其次，畏之；其次，侮之。” 最高境界的领导，会让团队认为工作产出都是他们自己努力的结果。制度和流程自然运转，深入每个人的工作习惯中了。