好领导,本来应是挖渠人

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

手机配件送货员的故事

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

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

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

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

评论已关闭