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

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

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

预测业务

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

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

预测行业

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

又是一年春天，招聘跳槽的黄金季节。没事多看看，了解一下现在其他公司的招聘要求，工作内容，细心一点你就能看出当前行业缺少的技术是什么；多跟你的上级聊一聊，打听一下公司的下一步大的战略方向是什么，你就又能提前准备一些事情。
很多时候，之所以能够做到预测未来，无非是你掌握的信息比别人要多而已。

预测团队和项目

如何找到自己团队或者项目的不足？
其中一个方法是直接问你的用户。就像我在文章开头时候提到的那个 CMS 系统的例子，如果你不是切实去做 CMS 系统的人，你根本不可能知道完成一个 CMS 组件有多复杂。
预测团队是个很有意思的事情。他的有意思在于你很容易先入为主，去猜测某些可能会发生的事情，然后某个机缘巧合，这件事情发生了，会让你觉得，其实你早就知道这件事会发生了。比如你想知道自己团队的不足，你去找团队的人聊天，大概率会得到的答案是那个你心中已经有的答案。而这背后，并不仅仅是大家的想法都一样，事实上更多的是因为你很容易只听到那些你想听到的事。 所以得出的结论经常是前端说的后端技术太差，返回的东西乱七八糟，有用的数据没有，没用的数据一堆；后端说前端水平太差，几个字段自己拼一下就能知道数据了，什么都让我返回，这个逻辑我没法写。
之前在沪江的时候，我们 team 里有一句话叫：当一个事情发生第一次的时候，他就有可能发生第二次，当他发生了第二次的时候，就一定会发生第三次。
像这种推脱，很难直接去解决，因为前端没发理解后端的难点，后端也不知道前端的复杂。但一个常常被忽略的重点是，他们至少能表达出自己觉得差的地方。当多个人都觉得某个东西很差的时候，那可能真的是他有问题了，需要考虑如何解决掉这个问题或者避免下次继续发生。

team 的成长，才是 Leader 的绩效

之前看过一部电视剧，叫《大江大河》。讲的是文化大革命刚结束的时候，男主是个大学生被分配到国企化工厂上班，因为能力出众，当上了小组长，带两个厂子弟一起做事。
当时他就跟上级说了一句话：他们两个做事效率实在太低，与其让他们两个人去做，还不如我一个人直接做完了。
我相信这是很多人刚当上 leader 的第一感受，我当时也是这样，很多事情还不如自己加个班去解决掉，也比交给别人拖两三天才完成要好。
但事实上这样的后果就是：现在你只带两个人，有些事可以帮他们完成，将来将一个厂的人都交给你的时候，你要如何去帮他们完成呢？

我们 CTO 每次都说 Leader 要懂得将自己的能力复制给组员。让 Leader 的能力变得可复制，这才是公司最大的财富。
而懂得将预测未来的能力交给组员，这才是提升的最快办法，比很多傻逼公司强制996要好太多倍了。
当然，懂得跟上级形成定期的汇报机制，小事用钉钉微信，重要决策或进展当面或者日报。掌握足够的信息才是预测未来的重要依据，同时也是向上管理的必要条件，这也是我们CTO教我的。

你看，我们CTO自己也需要向上管理。