Aa57adf99585cf7811e9e770a7e38a98
Leader 的自我修养 —— 学会预判

大概两个多月前的一次,跟朋友聊天,谈到了一些当 leader 的心路和历程,他说正好我很久没更新博客的,让我写下来,分享一波,我当时没放在心上,心想这种管理上的事情,各有各的方法,本身没有对和错,只有合适不合适,何况都是一些不成片的经历而已,适合互动交流,但很难提炼成文章。

无独有偶,今年过年因为疫情在家,跟一个年前离职的同事聊天,他之前在我团队是个很不错的研发,现在也是在一个一线公司带小团队。他当时问了我同样的事情,让我讲了讲带团队的成长经验。

我突然意识到,这些过往的经验如果稍微做一下抽象和总结,多少能给人一些启发。虽然我从很早开始做 Android 开发,真正带自己的团队也只是从两年前加入一条开始的。得益于职业生涯前几年的努力,自己技术累积了良好的口碑,恰好也是公司快速发展的需要,其实我相信,几乎全部的初当 leader 的同学一样,我们应该都算是 "码而优则仕",又恰巧碰到一个机会,就这样走上了这条路。这两年,我从刚入职做到技术经理又做到副总监,团队也从5个人到20个人,很大程度上归结与一些做事方法相关,主要就是三点预判。

预测业务

从技术研发初做 Leader,最大的变化就是工作内容的改变。以前需要重心放在代码上,思考怎样解决问题、了解实现原理,而现在变成了解业务,思考业务,预测业务。
这个过程是个非常痛苦的过程,甚至有点算一种悖论。不知道大家有没有发现,在最初我们做研发的时候,要去了解各种各样的框架,学习内部实现原理,再尝试自己去写一个类似的框架,再从这个过程中了解这项技术的本质。这其中最神奇的就是,大家都觉得做业务写需求是一件很傻的事,而做架构,搞技术预研则是一件很高大上的事,所以很多人觉得公司的架构组、基础组的人都很厉害,相对的垂直业务组的人则技术比较差。
但是作为 Leader 往往是需要对公司的业务和组织架构有着深入的理解,并且能够通过产品经理提出的需求,对应的猜到这项需求上线后会对将来的业务干系方产生怎样的影响。
所以这两类人在很多公司都是被分割开的,比如阿里的P职级跟M职级,虽然有对应的转换,但大部分都是P职级做技术,M职级做管理。

一条

举个我之前经历过的例子,我们是电商公司,APP 的首页对布局的灵活性要求非常高,上面这张图就是我们 APP 的首页。
公司有一套 CMS 系统,就是专门应对这样的场景的。核心技术就是后端返回一个 JSON,前端根据 JSON 展示对应的布局和内容,这其实是行业很通用的做法了,天猫之前开源过一个叫 Tangram 的解决方案,就是应对这种动态化首页的场景的。但是这种界面,如果是纯展示后端返回的数据还好,只要稍微插入一些特殊逻辑,代码马上会变得混乱不堪。最好的办法是客户端在请求接口的时候就将用户信息都传过去,然后服务端根据业务对应返回。但现实中往往是做不到的,要么是后端需要的参数非常非常多,要么是数据由不同的系统传出,可能同时涉及到VIP信息、订单、位置、推荐、广告等等。所以就变成了服务端返回一个占位符、客户端再根据占位符请求对应的子接口。
这种问题的解决就有两大思路,第一种技术层面的:就是通过良好的客户端架构设计,去充分考虑各种组件的情况,预留好应对方法。
第二种则是业务层面的:既然接口涉及到很多信息,那么能不能这些信息由一个专门去负责数据整合的中间层完成。
相比较而言,第一种改动点更小,只需要在自己工程代码中完成就可以了,第二种办法则需要充分了解公司的业务划分以及产品已定义的组件和将来可能的组件,找到相关的后端,再拉一个人或一个团队专门负责做接口整合的中间层,这时候第二种方案就对 Leader 的做事能力有着极大的挑战了。

预测行业

移动端开发没人要了。这种话作为段子我们不知道听到多少次了,事实上,每个公司都需要移动端的开发,只不过要求在不断变化而已。比如五年前,那时候创业的黄金时间,我们要的是能把业务快速做好上线的人;三年前,行业头部基本稳定,我们要的是能够把快速迭代那几年所欠下技术债还上的人;近几年,裁员不断,我们要的是能把公司成本降到最低,收益提到最高的人。理解了这一点,如何提高自己的价值,很简单,你能做公司需要而别人做不到的事,再帮助你的团队理解这一点,你就是公司最有价值的人。
比方说做 Android 的,近几年没有什么新技术,Kotlin、Flutter,没了。你要学吗?不一定!思考一下学完了以后对自己对公司有没有帮助,这才是重点。
想起来这样一个段子,说公司各种员工对老板的看法

员工 看法
普通员工 老板傻逼,什么都不懂
top Created with Sketch.