大多数谈论经管类的文章，作者都是企业高管，或者社会名人、公知。视角往往都是自上而下，先从战略规划，再到具体实践，高屋建瓴，视角宏远。作为一个长期一线的程序员，大多数情况下都是被管理者，我在想是不是也能从另外一个视角发出自己的声音，对我们日常团队协作有些许帮助。

手机配件送货员的故事

我比较幸运，无论是读书时期的兼职零工，还是毕业后的正式工作，和老板（直属领导）关系都还行，没有发生一些不愉快的事情。不过对身边发生的一些见闻感触很多。

高中毕业的时候在老家的小城市找了一份暑期兼职，工作的内容就是在手机零配件批发部给手机维修师傅送货。那个时候还是功能机时代，手机维修的需求很多，手机维修需要一些屏幕、听筒、排线等配件。城市不大，骑个自行车市区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 环境，发现每个人建有自己的流水线，部署方式各不相同。

最终这个项目做的非常头疼，技术经理没有打通整个工作流，整理相关的文档、规范、部署方法，让开发把主要力气用在开发上。每个人都需要摸索一套自己的做事方法，做东西很难说高效和”规范“ 。

优秀的管理者，应是治水人，像都江堰的鱼嘴、堤堰，疏、堵相适宜。设计流、协作体系，制定规范。

一线工作者和领导有一些不同点，也有相同点。

不同点是一线工作者的诉求和领导的诉求不同。一线工作者的诉求主要有两个，干的开不开心，还有钱够不够。领导的诉求是，能不能出活儿，是不是能服从安排。

相同点是，他们都不希望对方老是来事儿。

一个软件项目是否成功，不仅取决于工程师和技术挑战之间的矛盾，还有团队协作的流畅性和项目经理的管理手段之间的矛盾。

治大国如烹小鲜，被管理者也不喜欢被天天折腾。