|
|
# 第179讲 | 张矗：技术管理者必经的几个思维转变
|
|
|
|
|
|
你好，我是马蜂窝技术副总裁张矗，在互联网这一行摸爬滚打了十余年，也参与了两个创业项目。一路从一个普通工程师走向技术团队的管理岗位，经历了多少挫折和错误，可能也只有自己才清楚。我回顾自己在这个过程中的成长，发现每一次蜕变都是思维的转变。今天总结一些经验分享给你，希望对你也有一些帮助。
|
|
|
|
|
|
## 一、去管理，而不是找人协助你
|
|
|
|
|
|
刚开始带团队时，团队成员大概在7-8人左右，通过有效地辅导，任务分解，沟通协调，团队成员的工作也能有条不紊地推进。但问题在后期逐渐都凸显出来了，其中一个问题就是主要的核心代码还必须由我完成，一些长期来看重要，但是短期无法校验结果的事情，我也无法安排给其他同学来完成。
|
|
|
|
|
|
今天回头看这个转型阶段，一方面是长期单兵作战形成的一些"技术洁癖"局限了自己的思维转换，"技术洁癖"并不是缺点，不过"技术洁癖"会让自己更多的关注在代码层面，而我们需要让自己的关注点转移到解决方案、产品交付、质量控制等其他层面。这些领域对于一个新手技术管理者来说，很可能都是需要重新学习的内容，因此出现问题就成为了必然。
|
|
|
|
|
|
另一方面是没有找到对任务完成情况进行跟踪和衡量的办法，导致自己无法和团队建立信任，无法将任务的复杂性有效地封装和管理起来，任务封装可能更多的在于能力问题，但任务管理就是思维问题。比如如何了解任务的执行进度？如何监控可能的风险？如何在任务中进行资源的协调？如何阶段性的衡量任务的执行情况？等等。
|
|
|
|
|
|
只有转化思维，了解这些问题，才能从根本上理解管理的意义。而这个过程中，在单兵作战期间能力非常突出的成员，可能要花费更多的时间来完成思维的转变。在我看来，管理不是找一些人来协助你的工作，而是让你带领一帮人来完成指定的目标。而现实情况是问题多种多样，问题的解决办法也是多种多样，对于这种多样性，我并没有固定的解决办法，只能具体问题具体分析，在这里我不再展开来谈，我想强调的是思维转化是这一切的前提。
|
|
|
|
|
|
## 二、技术视野从深耕到全局
|
|
|
|
|
|
今天互联网领域用到的技术非常广泛，一个人要对所有主流的技术栈有一个全面且深入的了解，只从时间这个维度来看，已经几乎是不可能的了。
|
|
|
|
|
|
人们总是习惯于用自己擅长的技术来解决问题，这无可厚非。但是随着我们管理的范围越来越宽泛，如何管理其他技术栈领域的团队是一个不可回避的问题。举个例子，不同的技术栈适合解决的问题不同，在协同工作的时候，经常会出现重复造轮子、统计口径不一致等现象。
|
|
|
|
|
|
在移动互联网爆发的这些年，我看到很多客户端团队和服务端团队的互相不理解，WEB开发团队和大数据团队的互相不理解。这个时候往往是需要工程师能够互相换位思考，可是一般的工程师并不具备这样的能力，这就需要我们技术管理者能够从一个宏观的视野来进行协调和规划。
|
|
|
|
|
|
而要做到这一点，就需要我们具备足够的技术敏感度，同时要保持一个开放的心态，保持对新技术的追踪与学习，不需要了解具体的技术细节，但要能够了解不同技术栈适合用于什么场合，这是非常重要的。
|
|
|
|
|
|
我自己早期更多的偏向WEB开发领域，那个时候大数据生态刚开始在国内萌芽，但是需求一直存在，我自己还使用PHP实现了一个简单的分布式计算方案，一开始也迅速解决了问题，但是随着时间推移，维护成本越来越高。等到阅读了谷歌关于大数据的三篇论文，回头再看，直接采用Hadoop的方案应该会少走很多弯路。
|
|
|
|
|
|
当然，这个过程需要我们不断提升快速学习、总结归纳和英语沟通的能力，同时，对于其他技术的学习，也要关注在它在成熟度、应用领域、人才状况等方面的情况。
|
|
|
|
|
|
## 三、该不该停止写代码？
|
|
|
|
|
|
写代码应该是一个给技术人员带来成就感的行为，我认为也是一个技术人员要毕生追求的行为。
|
|
|
|
|
|
但是作为技术管理者，随着管理任务越来越重，在写代码上的时间投入一定是在减少的。当出现下面几个迹象的时候，也许就是时候停止了：
|
|
|
|
|
|
1. 项目的推进开始等待你的代码完成，可是你的时间花在会议、招聘等管理事务上，无暇顾及；
|
|
|
2. 你写的BUG，别人修复起来消耗的成本很高；
|
|
|
3. 你写的代码无人可以维护。
|
|
|
|
|
|
这几点说的都是一个意思，即在这个阶段虽然你的代码质量可能依然优秀，但是它已经成为了整个团队的瓶颈。
|
|
|
|
|
|
当然，我并不建议这个阶段的技术管理者完全停止写代码，少量写一些不重要的代码，持续保持自己的技术敏感度也是很重要的，这个时候，一些胶水语言也许就非常适合了。
|
|
|
|
|
|
## 四、不要时刻冲在最前线
|
|
|
|
|
|
亲自带领团队完成一个又一个的项目，当然是技术管理者的责任。但是随着团队越来越大，要做的事情越来越复杂，你不得不认识到，时刻冲在第一线，对你和团队来说都不再是一个好的选择了。这会让你无法关注最重要的事情。这时候，需要让团队中更多的优秀人才来带队，辅助你完成项目，而你要用服务的心态做好帮助的角色。
|
|
|
|
|
|
从带领团队到服务团队的转变，具体表现在几个方面：
|
|
|
|
|
|
1. 从简单的辅导培训，走向搭建平台。辅导培训更多的是一个单向输出，而搭建平台是创建规则、环境与生态，让大家能够在更大的空间中自由发挥才能，施展创意。
|
|
|
2. 从统一管理到多元治理。在小团队阶段，统一固然能够保证效率最大化，可是多元化才能让你的团队长期发展。而这需要管理者保持开放的心态，在不同时期做好统一和多元间的平衡。比如在团队初创阶段，统一的开发语言、CI/CD流程会让整个迭代过程非常高效，但是团队规模变大之后，支持多种开发语言的微服务解决方案就变得非常重要。
|
|
|
3. 更多的要成就他人。团队的成功一定不是一个人的成功，应该是团队整体的成功，并让团队成员与团队获得共同成长。这就需要我们作为技术管理者赋予团队成员更多的责任与权力，并在一个个项目攻坚中，帮助他们完成自己的蜕变。这样相辅相成，相互成就，团队才能持续正向的发展。
|
|
|
|
|
|
还记得电视剧《兄弟连》里面有一个经典的场景：温斯特晋升营长之后，下面的连长带领E连冲锋遇到了阻碍，温斯特控制不住要自己上去带领E连冲锋，却被他的团长叫住。作为营长必须坚守在指挥阵地，完成更重要的任务，为整个团队负责。
|
|
|
|
|
|
## 五、技术思维到产品思维的转变
|
|
|
|
|
|
技术的最终目的还是要创造价值，同时技术的价值也必须通过产品来呈现，因此，技术管理者的关注点不能仅仅停留在技术架构与团队建设上，更应该建立你的产品思维。具体该怎么做呢，我有以下四点建议：
|
|
|
|
|
|
第一，关注客户的反馈，不光是内部客户，也应该关注外部客户；
|
|
|
第二，需要对业务有更深地理解和洞察；
|
|
|
第三，关注财务状况，要思考如何让技术团队从一个成本中心转化为利润中心；
|
|
|
第四，让其他岗位能够通过产品充分利用技术，将技术的价值最大化。
|
|
|
|
|
|
这并不是要让技术管理者转型成为产品经理，产品经理也是专业活，也需要时间的积累，而是让技术管理者能够具备同理心，站在产品经理的角度思考产品价值。研发工程师和产品经理常常在各种段子里面被描述成相爱相杀的冤家，其实用技术的手段打造出改变这个世界的产品，应该是每一个互联网技术管理者的梦想终局。
|
|
|
|
|
|
因此，我建议技术管理者们，要时常转变思维，换一个角度来看待技术对产品产生的价值，网络上流传乔布斯1秒变小白，马化腾3秒，张小龙5秒。那么你转换思维需要几秒呢？
|
|
|
|
|
|
## 作者简介
|
|
|
|
|
|
张矗，马蜂窝技术副总裁。TGO鲲鹏会会员，曾任新浪网研发经理，开心网联合创始人。2012年加入马蜂窝，负责技术研发团队管理工作。目前，马蜂窝技术研发团队已发展至600人。
|
|
|
|