阿久被逼做前端,40岁老程序员重操旧业
王福强
阿久是极少数跟我同岁还奋斗在一线写代码的CTO,今天在朋友圈看到一条他的“自黑”:
挖坟,心酸史,我又要做前端了。
这是我埋葬了15年的技能[流泪]
2004年,老爷子让我做一个大气的界面。
从那时起,我就发誓,只做牛逼的后端。
虽然期间技痒,写了4个A9系列的工具。
我就很好奇发生了什么,遂回头问了下, 从发来的聊天记录上看, 我觉得可能他犯了技术管理的一个忌讳,而我之前在做顾问和咨询的过程中也经常看到这样的案例,所以,为了坚持做damn few, 我觉得有必要再好好说说这个话题,即不要不分场合的做细节管理和使用命令式管理。
事情的经过我就不详细介绍了, 大意是阿久团队的某个前端队友没有使用阿久之前指定的前端技术选型(可能更没有拿到阿久要的结果),从而导致阿久质问的过程, 此中唇枪舌战就不说了, 我觉得那个前端队友肯定是有问题,但我今天不想说他,我想说的是,作为一个团队的负责人,你用指责的方式其实是拿不到你想要的结果的,“为什么没用vue-element-admin,这个是我指定的
”, 首先这句质问就说明阿久在技术管理层面的不成熟,一个是过度陷入了细节管理,另外一个就是过度粗暴地使用了命令式管理来处理这种管理场景。
其实,能力是随人走的,你可能vue-element-admin很熟,也能拿来用很快地拿结果,但不是所有人都是这样, 有的人可能更喜欢其它Admin Dashboard方案,比如当事人可能antd更熟或者更喜欢自己动手造轮子(我猜的), 这就好比计算机语言一样, 一个人一个胃口,你或许有权力可以强制别人用什么方式做什么事情,但绝对不会收获最高的组织协同效能, 因为人不是机器,谁都有控制欲,所以很多管理者很容易陷入到命令式管理的模式中,因为这种管理模式最直觉性、对自己也更“舒服”。
但是, 不要忘了, 命令式管理是有适用场景的,不是所有的人所有的场景都适合用命令式管理, 除非这个人是你带出来的,跟你有感情,认同你的做事方式和理念,否则,任何一个外部招聘来的专业人士,稍微有点儿专业资历还有点儿想法的技术人员,你是很难命令的。人都有情绪,包括我也是, 如果有人指责我,那我第一反应肯定怼回去(当然,有些时候是刻意怼回去), 大家都是人, 或许有层级之分,但没有人格上的差异。
所以,最好的选择应该是, 不要苛责别人的能力与自己一样, 而应该允许不同能力的人使用自己的能力拿到同样的结果。
我刚接手巧房技术团队之后不久,因为前端资源缺乏,所以做了一个组织调整决策,把公司所有的前端技术同学都压到了核心业务线,但这需要说服平台技术部的负责人,因为前端架构师原来都是他部门的,这相当于“削弱”了他部门的力量。
这个过程其实也没有那么顺利,因为要改变一个人的想法或者认知其实是很难的,好在我们最终还是收获了共识。
很多大平台出来的人都喜欢兵种齐备才能打仗,但是对于一些纯管理后台类项目,根本不需要精美绝伦级的UI/UE, 所以,我建议公司内部大部分技术类产品或者后台使用类似Bootstrap之类的前端框架搞搞就好,当然,不强制,我只是说没有专职的前端, 事情还是可以做的,一开始平台技术部的负责人还是很抵触和为难的,毕竟,体感和手感可能之前都没有过,觉得与自己的认知相悖吧, 时间上也是纠结了一个来月吧,某天的技术例会上, 突然跟我说,“我们发现一个前端框架, 开发后台管理应用老爽了,像xx这样的应用,两三个小时就可以搞定…”(如果有人好奇要问是啥,其实是iview ui), 我终于会心的笑了, 大家皆大欢喜。
只要达成目的,做事情的人又高兴, 这不挺好吗? 干嘛非要逼着别人用自己熟悉的能力去做事呢? 在很多时候, 作为一名技术管理者,你要做的只是定目标、控过程,不要去过多干涉细节,尤其是对那些不是自己带出来的,还自己有想法有执念的技术人。
非要别人按照自己的思路走,是一种“病”,得治。我过去也有这毛病,哈哈哈哈哈哈
实际上, 什么叫“求同存异”? 放在技术管理上就是“同一目标,不同的人,不同的路径”, 条条大路通罗马, 你干嘛非要逼着别人跟你走同一条路去罗马呢? (◐‿◑)
既然说到了这个话题, 也给自己打打广告, 欢迎各位看官购买和阅读我的《极简管理课》 (https://afoo.me/books.html)
「福强私学」来一个?
「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。
开天窗,拉认知,订阅「福报」,即刻拥有自己的全模态人工智能。