唐巧：技术人如何成为管理者

前不久趣直播举办了一场技术人成长交流会。邀请了小猿搜题产品技术负责人唐巧来分享。我也有幸参加了此次的交流会

以下是文字版：

我大概自我介绍一下，我叫唐巧，是小猿搜题的产品技术负责人。我之前在网易做过 2 年服务器的开发。后来和网易的同事一起参与一个之前叫做『猿题库』，现在叫做『猿辅导』的公司的创业。做 iOS 开发，现在做了有 5 年了。

大概 3 年前，2014 年 7 月份的时候我们打算做小猿搜题这个产品，当时没有人负责这款产品，我的老大就说让我来负责，所以从那个时候开始，我就慢慢的从一个纯 iOS 开发者，慢慢开始一边写 iOS 代码，一边管理团队，慢慢到后面这个团队越来越大，现在产品和技术加起来大概有三十多人，也没有时间写代码了。

所以说经历了一个纯的技术人员转变到一个技术管理者的历程，大概 2 年的多的时间，所以说给大家分享一下，技术人如何成长成为一个管理者这样一个话题。这个话题之前我自己也深有感触，写过不少笔记，所以正好借这个机会把自己的心得分享给大家。

我们是讲技术人如何成为管理者，主要是讲如何，How 这个话题的。但是我自己觉得在讨论如何成长为管理者之前我们应该先想明白技术人为什么要成为管理者。就是 Why 这个问题。只有我们搞清楚为什么成为管理者，我们才能去成为管理者，成为管理者更偏向于执行，偏具体的工作，而想清楚 Why 是更难的。

技术人术人成长为管理者的理由

就我自己来看，我觉得技术人成长为管理者有这样一些理由。

突破个人贡献的天花板

第一个是突破个人贡献的天花板，释放更大的贡献。为什么这么说，大家都知道。每个公司都有自己的职位划分，比如说百度的技术T级别，管理可能是 M，产品是 P。阿里的技术是 P 级别，管理是 M 级别，产品经理是什么字母开头的记不清了。但是一次有机会和苹果的人聊，在苹果他们只有两种类型的级别。一种是叫做 IC，另一种是 M。IC 是 Individual Contributor 就是个人贡献者，另外 M 就是 Manager。

在苹果他把一个人的类型分为个人贡献者和非个人贡献者，我认为他就代表着一个职位很大的特征。一个个人贡献者他的所有的贡献产出都来自他自己的，很少依赖别人，比如写代码我的产出就是我的一行行代码所构成的最终的产品，我做设计我的产出就是我的设计稿，我做产品我的产出就是原型图和需求文档。这些都是依赖个人能力贡献出来的。

但是如果你是一个管理者的话，你的产出很多时候是很难说清楚的，你会发现，产品稿不是你做的，设计稿不是你做的，代码也不是你写的，但是你在做什么呢？你做的可能是协助他们把这些给做出来，还有组织这些的沟通和相互协调。是另外一种工作方式，我觉得当你尝试管理工作，他会突破你个人能力的天花板，一个个人能力贡献者，可能他的上限就是每天 24 小时不停的工作也就那样了。他就算是不休息，一周也就是工作 7 天那个样子。

但是一个好的管理者的话，他可以发动身边的团队的人，大家朝着一个目标努力，他的贡献可能是释放了十倍百倍的。我觉得这里一个成为管理让人激动人心的地方。他能驱动更多人朝着一个方向努力。做出一个有更大贡献的一个产品。

你终究需要面对管理

有些人说我就不喜欢做管理者，我就喜欢做技术，在国内其实也是这样，有些技术人他往上的职业阶梯很美好，比如说我们老讲的阿里的多隆，他成为了阿里的 11 个合伙人之一，他的级别是 P11。成为每个人的偶像。

就算大家从一个基础的技术者，往后做，做的架构师，做到多隆这样的职位，你终究要面对一个事情，就是你需要管理几个人，或者几十个人，在技术上达到一个目标。那个时候你多多少少是需要和别人协调，你除了自己攻坚那些最难的问题之外，你还需要指导你下面的几个可能几十个技术人，大家一起朝一个方向努力。从那个角度讲其实技术人，即便是做技术也需要一些领导技能的

即使你是一个架构师，你也需要 Lead 一个技术团队。其实对大家来说，你的未来成长不管是走纯技术路线还是走非技术路线，你都需要增长自己的管理技能。因为到最后你总归是需要管理沟通的，很难出现你级别非常非常的高，但是你还不跟任何人打交道，完全靠自己的个人能力来贡献，我几乎没有见到这样的情况。所以这是我觉得一个技术人为什么要成为管理者的原因。

为为什么要成为管理者的误区

讲完原因我觉得还有一个误区大家需要特别关注的。我会见到一些技术人他们想做管理者，但是问这些技术人他们为什么要成为管理者，我觉得他们的理由是不对的。这里我列给大家。

期望拿更高的薪水

总有人觉得管理就应该高人一等，拿的比别人多，其实不是的。很多公司技术岗和管理岗都有相应的薪资。做纯技术做到架构师你的工资是很高的。

在很多公司，高级的技术，他的 Manager 的工资是比他低的。就是他技术很牛逼，在业界就那几个人能做到。所以说你要是想拿很高的工资的话，这不是一个很好的理由，因为做纯技术也能够找到很高的回报，之后的一步步的技术提升也很高。所以说不是一个很好的理由。

期望指使别人

很多人觉得做管理就是指使别人做事情，你做这个，你做那个，其实不是的。很多时候领导都是，负责背锅，负责给大家抗压力，负责擦屁股，负责端茶倒水的伺候大家的人。我印象最深的时候就是我们刚刚创业的时候，我们做一个网站叫做粉笔网，但是这个网站挂了，当时这个网站有一个功能就是PDF预览功能。我们调研了一下市场上的技术，PDF 只能用 FLASH 来完成，大家知道 FLASH 技术已经是一个日落西山的技术了。

当时我们创业大家都觉得这个技术学了过几年会完全没人用的。所以我们当时所有人都不想做这个东西，都不想学，那怎么办呢，我们 CTO 去学，我们 CTO 当时就是完成我们网站上的 PDF 预览功能。这就是一个很好的例子，他就是负责去擦屁股，去做最脏的活，最累的活，大家都不愿意去做的活。

指望更轻松的工作

很多人觉得程序员很累对吧，刚刚听说比 996 还辛苦，我知道整个业界，整个中国互联网大家的压力都很大，有些公司 996 是常态，我们公司还好，但是有时候比如上线的时候，改 BUG 会改到很晚，熬夜加班，大家就会觉得程序员太苦了，是不是我做管理就不用加班了呢？我也不用写代码了。我之前有时候也是这么想的。后来我自己现在转管理了。我发现完全这个想法是错的。

就拿我自己来说，我在之前做 iOS 开发，我下班之后就完全可以去做别的事情，我周末只有工作的事情做完了我就可以自己看看博客，自己写点东西，或者玩些别的事情，但是我发现我做管理之后我发现我的事情做不完。总会有一堆事情堆着。每件事情也没有一个完成的定义。所以我上班也要想着这些事，下班也得想着这些事，周末也得想着这些事。

大家发现我现在写博客的实际比以前更短了，这就是一个很好的例子，做管理其实并不是一个轻松的事情。有人说技术是累体力，管理是累心的工作。我觉得真的是这样。技术你就单单和电脑打交道对吧，代码写好，没有 BUG 你就算是做的很好。但是做管理你需要和人沟通，你需要反复的和别人去交流去解决他的问题。很多时候做法没有标准的，目标也没有最明确的，这个过程你需要非常的劳心劳力去把事情做好，非常的累。

指望更容易换工作

刚刚我们说到技术人是一个 Individual Contributor 个人贡献者，个人贡献者就有好处就是这家公司垮了，第二天你就能找到一份好工作，只要你的能力是足够强的，比如你代码写的特别好，没关系啊，这家公司不好，你第二天就能找到一个更满意的公司上班，很容易，前提还是你技术是厉害的。但是一个管理者换工作的难度是相对高的，因为很多时候你的管理能力是取决于你对这个团队和业务的了解。

对于我来说我能管理小猿搜题团队，其实是因为我持续在这个团队工作，我熟悉团队中每一个人的性格特点，他们的擅长的，不擅长的，那些人做得好，那些人是温和的，那些人是激进的，和每个人打交道要用他喜欢的方式，我也非常的了解我们产品的用户特点。我们的用户场景是什么，用户行为是什么样子的，我们为什么要做哪些功能，我们未来的产品发展方向。

大家明白嘛？这些全都是和小猿搜题这团队和产品相关的，如果我要换一个工作，在新工作里面我如果面对不一样的人，不一样的产品，我的整个管理方式可能完全都不一样了。所以说我很难去管理一个新的团队。我想说大家都知道空降一个高官其实是非常难的，管理者大多数时候都是从这个团队里培养出来的，而不是空降到那里的。

对我来说除非我把整个团队带走，这样其实是非常奇怪的。正常情况下你离职，那你很难去融入一个新的团队。价值也很难发挥出来。其实会面临一问题。一个管理者是更不容易换工作的，相对于个人贡献者来说。

所以说基于期望拿高薪，期望指使别人，期望更轻松的工作，或者更容易换工作，基于这些理由找工作的话是非常不合适的。管理者根本就不是这样子的。讲完误区我们来看一下技术人如何成为管理者。

　　　　如何管理

01

时间管理

我觉得技术人转管理的第一课就是时间管理。为什么这么说，当我们做程序员的时候，我们每天的工作其实都是有人给你安排好的。可能是产品经理也可能是项目经理，他可能会告诉你这周你要完成一个什么样的产品开发目标。他会把产品稿和设计稿都给你。你会给他估计一个时间，这段时间你要做一个什么事情就已经定了，你每天做这个安排好的工作就完了。这个工作做完之后又会有新的工作过来。

对于一个纯程序员来说他的时间管理是非常简单的。他甚至不需要时间管理，他只需要每天完成别人给他的工作就好了。但是它可能会遇到一些技术挑战，可能会遇到一些延期，他顶多是通过加班，或者项目延期的方式来解决，他不涉及很强的自我时间管理。

但是一个管理者完全不一样，等你管理一个团队的时候你会发现，没人过来说今天你要做什么，明天你要做什么，这个星期你要做什么。所有的事情是你自己来安排，如果你去列下来你会发现你有一堆的 TO DO LIST，还有一堆人在找你，那你就需要做时间管理了。

因为你管理不好的话。你会发现你一天工作下来感觉自己累的要死。但是好像什么事情都没做一样。或者做的东西并不是你想做的。所以时间管理是技术人转管理所遇到的第一个挑战。因为他在之前的工作中并没有得到锻炼。

我在这上面也遇到了很大的困难。我怎么办呢，我就去看各种技术转管理的书，看了这几本书《管理的实践》，《卓有成效的管理者》，《成为技术领导者-掌握全面解决问题的方法》，《格鲁夫给经理人的第一课》，我感觉这是管理者第一个需要学习的。

每本书讲的角度都不一样，但是我发现他们讲的套路都是一样的，就是换着方式在说一件事情，套路就是这四点。怎么做时间管理呢？

你先记录，然后分析，然后改进，然后回顾。

具体怎么做，就是你先拿笔记录下来，你每天的时间花费到底在哪里。比如说，你早上几点到几点做了那些事情全部记录下来。记完之后比如说周末下来你看这一周到底时间花在哪里了。到底是花在和别人沟通上还是花在项目的推进上，还是花在招人上面，还是花在别的事情上面，你把它列出了之后你就知道你每块的占比是多少，然后你就可以做分析了。

我天天盯他们进度或许是不必要的，大家可能很自觉，是不是这块时间我可以减，你和他说你遇到问题了再来找我，如果说进度是正常的话就不用来找我了。那你的这块时间可能会减少。但是还是取决于你的同事的工作方式是不是让你信赖的过。

通过思考你会想到一些改进的方式来优化你的时间，最终会得到一个结果，你的改进可能是让你的时间变得更好了，或者你发现这么改不行，然后你会去从新的调整，经过这样的一个反复迭代，就能最终的找到一个让自己舒服的工作节奏和工作方式

这个就是我 2015 年底某一天写的时间花费，那段时间我经常觉得自己时间很乱，然后我就专门花时间记下来，然后去分析自己的时间花费，做着做着我就发现，确实要好很多了。最终我会把我的时间分成两部分。

一部分是被动时间，一部分是主动时间。被动时间就是别人主动来找我的时间，比如说有些会议需要我去参加，有些产品稿或者设计稿需要我去评审，我会把我的时间专门在软件上记下来。剩下以外就是我的主动时间，主动时间我就回去想，未来三个月对于我来说最重要的事情是什么，然后我就会把我的主动时间全部花在这个上面。其他的事情我觉得不重要的我就把它忽略掉，或者交给别人来做。

接下来就会有人问了。我现在每天就是写代码，没有机会做时间管理啊。我的工作都已经被别人安排好了，怎么办呢？ 这里我有一个办法，就是可以尝试从规划你的个人时间开始，什么是你的个人时间呢？就是你工作之外的时间，比如说下班之后、周末这些时间你可以尝试规划一下。

有人说想写博客平时没有时间，或者是不知道怎么写。你可以周末的时间来总结下来写篇博客。或者你规划学习一些技术或者总结一些技术。你自己主动的尝试去做一些时间规划或者时间安排，看看自己执行的好不好。这就是一种自我的时间管理的尝试。这种事情做多了，能管理好自己的时间安排了，等你工作上从技术转管理了再工作中也可以做好这一点。

所以我觉得大家可以从管理好个人时间开始。

学会表达

说完个人时间我觉得第二个就是学会表达。这个为什么要提呢。其实我会觉得如果是一个非程序员转管理的话可能都不用说。比如说产品经理转管理就不会需要这一点，因为他的工作每天都是需要和别人去讲的。他需要说服别人去认同他的产品稿。还有和用户交流，他天天都在沟通。

但是有时候我就觉得程序员做的就是一个翻译的工作。就是把产品经理的产品稿翻译成电脑能懂的东西。翻译成一行行代码，电脑能听懂，能够正确的执行。大多数情况下面对电脑做就行了他不涉及到人与人的交流技巧，所以说大部分的程序员都会比较闷，然后不善于表达、不善于沟通。这其实是和他的工作环境有关，因为他的工作就是对着电脑，所以说这方面锻炼的少了自然就弱了。

我刚工作的时候我就特别的恐惧，我这么工作天天从早到晚都对着电脑，会不会就是以后见人都不会说话了，我就有这样的恐惧。然后我就会刻意的去想办法提高自己。所以说我觉得大家如果感觉到自己在表达沟通上能力还有欠缺的话，也可以试着去弥补这方面的能力。

怎么做呢我觉得可以尝试着去写作，写点博客，做个演讲，如果觉得演讲这个事情是比较恐惧的你可以先试着做你们公司内部的技术分享，甚至是不用很大的，就做你们组内的技术分享，大家很熟三五个人还是可以锻炼自己的表达能力的。

指导新人是一个很好的机会，有些人总觉得带新人是一个很累的事情，我觉得是不对的，指导新人是一个非常好的去锻炼自己的表达能力的。每个新人的特点都不一样，你需要针对每个人的个人特点，来定制针对他的个人学习和成长计划，并且和他刻意的去沟通。这个过程就是锻炼自己的表达能力和沟通能力。

比如我之前带一个 iOS 新人，他就很内向，那我怎么办呢，因为他很内向他就不会主动找我过来问问题，我就对他说，每天下午的 5 点到 6 点就过来找我，就是我们讨论问题的时间，我不做别的事情你就向我提问题。就变成我主动和他构建了一个时间来交流。他就会觉得 5 点的时间本来就是向我提问的。他就会把当天遇到的问题主动向我沟通。这就是我自己想出来的，怎么去带比较内向的遇到问题不好意思去提问的新人。你在认真的带新人的过程中也会成长，会学到一些新的东西。

还有一点心得就是把你自己最熟悉的东西给他做，为什么这么说，因为你在写一遍其实非常没有成就感了，一样的代码再写一遍就像是一样的日子再过一遍一样的感觉，你没有任何的挑战，你交给他做，他肯定会出各种问题对吧，你心里会想哎呀还没有我自己做的快。你不要这么想，你指导他成长，这个指导过程对于你来说是很有意义的。

所以说你自己很擅长的事情就不做了交给他做。然后你去想他在这个过程中会遇到什么问题，你提前帮他想好了，他遇到的你跟他讲，讲清楚。对于他来说，在做的新的东西，还有人知道，不会出太大的叉子，他很放心，他很开心。然后对于你来说呢，你会做的事情已经不用自己做了，去给别人做，你也很开心对吧。你学会了新的东西，怎么去指导别人。这是很好的技巧。

还有的话，交朋友也是一个很好的办法，如果单身的话，试着去追一个女朋友也是很好的方式。你能把自己的心爱的女朋友追到手，顺便你的交友技能也得到了提高，表达和沟通的技能也得到了提高。

刻意练习

特别要说一点就是以上这些都需要可以练习。不能说巧哥说写博客好，那周末就花两个小时写博客吧。然后每次写都敷衍了事，把博客写出来，如果你每次都是不求精，不求越做越好的话，你在这件事情上就很难有成长。

比如你写博客刚开始你写的很烂没关系，大家可以看我五年前写的非常烂，我还专门看过 bang，就是那个写 JSPatch  热更新的作者。你去看他 10 年前开始写博客的，我去翻了一下写的非常烂，就是说没关系的。

只要你坚持的写，努力的去提高自己的技能，坚持几年下来肯定就很厉害了。bang 现在的博客写的非常厉害，排版整个表达，写了 10 年了肯定厉害了，什么事情做 10 年做不好呢。所以说你只要是刻意练习那肯定是没有问题的。

所以说在表达上不管是写作还是做演讲还是带新人或者是交友，你只要是刻意的在想怎么做是做的更好的。老在想这个事，老在尝试去改进做一些不同的尝试，这件事情肯定是能做好的。我去看我5年前的博客也是写的非常糟糕，我现在觉得我的博客还是不错的。这就是刻意练习带来的成效。

下一个需要做的其实就是偏执行的事了。管理上面的事情其实很多人都已经遇到了。有人也有总结，市面上有很多很多的书，就是需要你去花时间翻一翻那些书，看看这些人他是怎么讲他遇到的问题的。其实和做技术一样，遇到问题了就去网上搜一下。GitChat 上有没有别人解决的，去看看书上是这么说的。很多的时候别人也遇到了一样的问题，并且解决的很好，你去看书上讲的然后自己再实践一遍，然后自己有所体会和收获。

这里面有些需要注意的。第一点就是看书，但是不能照搬。因为管理这个东西不像是技术，技术一就是一，二就是二，但是管理很多的时候都是偏实践的。每个团队都有不用的文化，沟通方式，书上讲的不一定是适合你的团队和你个人的

我个人推荐两本书，第一本是《格鲁夫给经理人的一课》，第二本书是《成为技术领导者》。第一本书的格鲁夫是因特尔的总裁，他代理因特尔从半导体时代转型做CPU。

大家知道嘛？因特尔最早不是做 CPU 的，他是做内存芯片的。大家知道日本在做内存芯片基本上是处于垄断地位的，他们被日本厂商搞的快要倒闭了。然后格鲁夫带领因特尔转型从内存芯片转型做 CPU，后来的故事大家都知道了，因特尔成为芯片行业的霸主。

格鲁夫带领因特尔做了一次成功的转型。格鲁夫也是一个技术人员，他最早的时候就是一个程序员。所以看他的书会非常的亲切，他会用程序员的语言给大家讲，给你列各种管理学的公式，还有各种例子，文字都非常的有条理。一眼就能看明白他在讲什么，不会绕来绕去的，非常适合大家去看。

第二本书的作者也是一个技术人员，都是从程序员的角度来写的如何管理。我觉得是非常好的两本书。即便是你不做管理你也可以看一看。你可以看看你部门的领导是不是按着这样的方式来管理的。

下一步就是我刚刚说的实践了。我觉得管理就有点像是学游泳，你在岸上是怎么都学不会的。那些理论都是你实践之后才能够体会的。对于你来说就是一个个的知识点，你没办法深有感触。所以说最好的学习方式就是实践。当你真正的开始带一个新人，指导一个技术团队，慢慢的这个团队你管的越来越大，慢慢的你就会有各种的体会了。那才是被你吸收的一些管理能力。书上讲的都是别人的。

我推荐这些书。我自己看过这六本书都很好。《管理的实践》、《卓有成效的管理者》、《格鲁夫给经理人的第一课》、《管理3.0：培养和提升敏捷领导力》、《领导梯队》、《成为技术领导者》前两本是德鲁克的，第三本是刚刚说的格鲁夫的，每本书的讲法都不太一样，总会学到一些不一样的见解，其中有些东西就会成为你自己的。

　　心得

最后讲一讲我的心得。说是心得其实就是遇到的坑，所以我弄了一个很大的坑在这里，掉了不少坑，这里给大家做一些分享

01

不写代码

第一个坑就是你会发现没有时间写代码了。我开始的时候讲了我是2014年底开始转管理的，开始我还有一点时间写代码，但是到后面很快就没有时间写代码了。那个时候我还是幻想应该要写点代码，不能把技术丢了，我就给他们说，还是给我分点活吧，我少做点。后来我发现完全做不了，因为做管理的很多时候是做协调，做协调工作就会发现别人老是过来找你，需要和你沟通，但是程序员又是需要很长时间安静的思考的。

有个理论就是说程序员被打的一次需要 15 分钟才能接上上次的思路，我觉得是有道理的。比如你刚刚想好一个逻辑，刚刚开始写了，啪被别人打断了，那个时候就想杀人，所以大家都说程序员大家不要轻易打扰他。程序员的工作方式是需要尽量安静的思考。管理的工作特点是频繁的和人沟通。所以我那段时间就频繁的被人打断，我就只能用晚上或者周末的时间来写代码，那样又会影响整个项目的进度，后来我就完全不写代码了。

但是我还是很喜欢的写代码的， 我就用周末的时间写点 demo，看一些新技术做一些研究或者做一些分享，通过这种方式来学习。但是公司的项目代码我是完全写不了的。这是我遇到的第一个坑，尝试编写代码边做管理工作。我发现这样是不行的。

02

怀疑自己的价值

第二个坑就是迷茫，我是谁，我要做什么。管理很多时候给大家带来的价值，或者给团队带来的价值会有点虚。好像自己什么都没做，事情都是别人做的，有一段时间我有这样的担心，但是后来我发现不是这样的。因为一个团队每个人要过的开心，会遇到各种各样的问题，可能是人际关系的问题，可能是沟通方式的问题，可能是和别的组协作的问题，各种各样的问题，你能帮助他把这样的问题全部解决，让每个人都工作的很好，很开心这是很难的。

刚才我提到的《成为技术领导者》的那本书，给管理的定义就是所谓的领导者就是要创造一个环境，让每个人都开心的舒服的工作，发挥它最大的价值。所谓的管理其实就是这个样子，你看起来什么都不做。但是你一旦构建出一个团队，每个人都很舒服，很开心很高兴工作没有遇到各种问题，这其实就是你的成功，和价值。我花了很长的时间来扭转自己的观点。可能大家在刚刚开始管理的时候也会有这样的问题或者困惑。看上去你每天只是动动嘴皮子，但是里面是要花很多心思的。

03

懂向上管理

最后一个坑就是不懂的向上管理。这也是程序员本身这个职业带来的。很多时候作为一个程序员你只需要写代码，把代码写好，你不需要去和你的老大去提什么要求。涨工资有时候会提的，或者也不用提，你干的好他就给你涨了。但是当你管一个团队的时候，除非你是 CEO，就算是 CEO 也会和董事会汇报，你总是会有一个向上的管理过程，你需要像你的老大去沟通，他希望整个团队在未来主要去解决什么问题这就是一个向上管理的过程。

通过和老大的沟通，获得他对整个团队的期望和目标。也通过沟通提出你遇到的困难的和挑战，让他给你相应的资源和帮助，这个过程其实是很重要的。刚开始带一个团队很可能会忽视这样的一个过程，你可能会觉得不好意思，或者不重要，其实这是非常重要的。

在德鲁克的那本书里举过这样一个例子。他人主管写下一个目标，然后让上司写下他对主管的工作目标和期望。会发现大部人写的都是不一样的有90%不一样，这就是缺乏沟通的一个问题。如果没有一个这样向上管理的话，你可能把整个团队都给带偏了，最后老大会说我要的其实不是这个。我要的是另外一个东西。所以说一定要做好向上管理。

每隔三个月我就会找老大聊一聊未来三个月的工作目标是什么，让他看看有没有问题。最近一次沟通下来我确实发现他想的和我的不一样。然后和他聊，最终我接受了他的观点，这是一个很重要的过程。

最后我大概总结一下今天分享。开始的时候讲了成为管理者的一些好处和误区。我分享了成为管理者的三个非常基础的方法。一个是时间管理，一个是强化表达，最后一个是看一些方法论的书。如果你去看书的话还会发现各种各样的技巧和方法，我觉得那些不重要，你只要记住这几个基本的那些东西都能学会。最后我介绍了一些我遇到的一些坑期望能够指导大家，我觉得这件事情值得每一个程序员去尝试去积累自己的管理能力。

我觉得不管你最终是一个架构师还是说整个团队的管理者你都会需要这样的能力。我真心的希望在座的每个人都能在这个方面有所成长。以上就是我的分享，谢谢大家！

Q     &A时间

Q您好，首先我先谢谢巧哥的分享，感觉这三百块钱花的值了。我有两个问题，一个就是现在我处的状态可能是和您5年前是一样的。在一个技术转型期。自己的技术达到了一定的程度。公司放心我去带一个小的团队，我现在手下面大概7个人。三个前端四个后端。我的问题是您是怎么放心的把工作交给其他人的呢。有些时候公司会有一些很重要的工作交给你。比如说你要跑一些运维的脚本或者是公司要一些什么的数据，但是呢，这些我熟，但是我没时间。我做的话可能2个小时能做出来。但是别人的话，可能一天都做不出来。你想把自己的工作交给别人，但是你不放心，因为涉及的东西太多了。

A怎么样把工作交给别人这个问题是很好的问题。我自己也深有感触就像我刚刚说的。别人花一天时间其实还不如你写两个小时写得好，你还需要指导别人 2 天 3 天的时间最后这个事情才能完成。

这两者有一个很大的差别，你在指导别人他是在成长的。如果你确定这个人还靠谱的话。他最终达到你的水平只是一个时间的问题。在这个过程中你需要注意怎么指导他，并且确定他不会把问题搞糟。最终大家还是要为结果负责。如果把事情搞砸肯定是不行的。指导上面我觉得还是需要尽心尽力的。尽量的让他感觉到你是期望他成长起来的。能够做的像你一样好的，他会觉得你这么放心他会有压力。

你心里还是应该有一个判断，你把事情交给他，他能不能搞定，你心里一定要由这个判读，不能说我很相信你，但是最后事情搞砸了，其实是你自己没有做好判断。就是要判读这个人到底只是需要时间指导还是说他可能就不是一个认真的人，不够负责的人的。如果他靠谱的话就只是一下技巧的问题。如果你不放心，在他最终做完的时候你去帮他做 review，还有在一些关键的问题上和他讨论。

我怎么指导一个人去做一个很难的事情。一个很难的事情我之前做过。我说这个事情交给你，你先想一想，等你有思路了过来找我，他想了有思路过来找我。有些地方想的不对的我给他指出来这些地方可能会有问题你在想想，和他都通完，我说没问题你去写吧。写完我再看一眼，看看有没有问题，有问题再改。其中的关键步骤你都加入了自己的检查，所以说他搞高不乱的，最坏的情况就是你最后看的还是发现有问题。 最后不上就行了，延期不上不会对线上有太多影响。

你指导一个新人心里一定要有把握，并且在一些关键的地方加上自己的检查。这件事情就能够放心的交给别人的了，只是说你需要再花点时间。这样的事情做几次之后就会发现，这人能行呢。后来再有困难的问题你就让他去想，然后告诉你，你就会发现该想的都想到了呢。然后说写完给我看一看，你一看写的很好没什么问题。再后来你说有思路给我讲讲就行了不用给我看代码了。再后来你就可以说遇到问题再来找我。没问题就不用找我了。慢慢的这是一个渐进的过程不是一个突然的，扔给别人，什么事情都不用管了。

Q所以说有一个问题的时候不会把解决方案告诉他。而是让他去想?

A是的不会告诉，解决问题的能力是很重要的，你要让他自己的去想，不然你交不出去的。

Q如何应对突然的打断?

A首先我回去做时间记录。我会去看看那些时间是被别人打断的。你会发现有些打断是避免不了的，比如确实是突发的必须去处理的。有些你会发现打断是可以避免的，比如说产品写完产品稿说你来看一看，你可以定一个时间就是每天的下午 5 点钟是产品的过稿时间，或者 2 周过一次。如果发现一些打断不是那么重要的话。你可以制定一些规则约束，大家知道你的规则就会按照你的规则来，毕竟你还是负责人。

Q巧哥你好我是做 iOS 开发的，我想问一下你们公司的 APP 是如何避免在开发过程中越来越大的呢。

A首先分析 APP 大的地方在哪里，我们就会把我们的程序拆解开，比如资源文件多大，程序逻辑多大，还有一些别的多大。比如说程序逻辑过大，就去看看是哪里的问题，比如打进去的无用的库，或者无用代码，再去看资源文件，图片压缩，用矢量图。比如说猿题库我们有一个公式的渲染引擎需要资源。我们就安装之后再下载。就是要根据具体看消耗在哪里，然后去对应的解决问题。完了之后再看体积缩下来多少。

Q我也是技术转管理的，就是管理上我年纪比较小我是 96 年的。有些人他感觉自己的经验很丰富，怎么和他沟通会比较好一点。我是做前端的，我说一个方案，那个同事就会按照自己的方案来。我是知道这里有坑的。

A这样我的建议是让他去尝试，遇到问了几次出现问题，发现你说的对，会对你的技术产生尊重。虽然中间可能会浪费一些实际，管理就是大家建立默契相互信任他其实就是花时间的，他当前没有对你建立信任，这就是一个管理成本。我的建议就是让他错几次。我们老大是怎么管理我们的呢，他说犯错没关系，一定要总结。我并不担心浪费一点时间。我更多的是期望团队搭建好了，之后的团队管理就会舒服很多了，所以说我会愿意花这个成本。

Q我们公司现在 10 个人。我经常发现我只能给 2，3 个人派事情。我自己也有事情做。就是这么多人我管不过来。

A核心就是我刚才讲的。你自己在写代码一样。就是你已经是 10 个人的团队了，自己的工作应该压缩一些尽量少一些。尽量交给别人来做。你团队 10 个人中间协调和沟通的工作应该会很多。你在这个上面不花时间就没人花时间了。你不沟通有些人就真的闲杂哪里了。他们就真的不知道干什么。他们也不敢过来找你，看到你很忙。对于组织来说就浪费这个资源了。管理的层级应该尽量的少。层级多了会带来沟通的效率损失 10 个人的团队应该是最舒服的，这 10 个人应该每个人都非常清楚别人做的事。都知道大家的努力方向如果你引入中间的架构效率会损失。所以就需要多沟通，给每个人派活。把你的事情分出来。

Q我怎么能确保我想要的和下面人做出来的最后的是一样的。

A程序员有些时候会误会一些产品稿，实现错了还有一些比较麻烦或者漏掉了。我们会有每天打包，程序员写完了就让产品马上下下来用用，看看有没有什么问题，如果有问题马上去找他，通过更早的发现问题来解决问题。在最终上线前设计产品和技术都会在看一遍。看看哪里有问题。并不是测试，而是简单的测试。

Q如何让团队的人知道我想要做的事情

A我主要是用 WIKI，给大家做协培训，然后录像。来了一个新人我就会让他看WIKI 和录像，在他看完之后我再和他沟通看看再这个过程中有什么问题。

Q巧哥你好。我就是前一两年看您的博客各种技术文章认识到您的。我目前是个 iOS 也是干了 2，3 年了，现在遇到的问题就是对技术特别的喜欢，但是产品也比较喜欢，但公司的产品和我的想法就比较大的冲突。因为我是从技术出发的。现在的情况就是有想法，但是他们不采纳。

A你要明白技术人转管理和技术人转产品这是两个事情。主要的产品还有由他们决策。产品对产品负责，技术对技术负责。这样才是正确的工作方式。大家相互尊重，信任对方。

微信扫一扫

关注该公众号