涅槃重生:我的技术转管理之路

字数统计: 5k阅读时长: 16 min

 2015/12/18 

一个程序员的理想

我从高中就开始接触计算机并开始编程，我非常喜欢编程，我一直以为我会写一辈子代码。

我从毕业就一直做技术，开始一年是做 Java 语言的服务器开发，开发过网易邮箱和微博的后台，后来转而做 iOS 开发。

因为喜欢，我几乎把我所有的非工作时间也投入到技术中去。当然，并非是把工作带回家，而是专研技术或者从事技术写作。

于是这几年，我积累了超过 150 篇原创技术文章，在 iOS 技术圈子里面也小有名气，也出版了一本《iOS 开发进阶》的书，微博和微信公众号的粉丝数也都超过了 3 万。

我做得很开心。

我一直以为，我会是一个好码农，我会一直在技术上深入下去。

但是，改变有些时候就是来得那么突然。

涅槃重生

我还记得那一天，2014 年 7 月 17 日，我当时受到邀请，在广州的微信分享 iOS 开发技术。当天晚上，我接到郭常圳（我们的 CTO）的电话，知道要做小猿搜题这个项目，并且这个项目「由我负责」。

于是，我开始了技术转管理之路。

通过从以前的项目组中抽调人手，小猿搜题这个产品技术团队很快组建出来了。我在开发 iOS 版的小猿搜题客户端的同时，也开始了我的管理工作。

现在经过了一年半，我们不但组建成了一支充满战斗力的团队，成收获了不小的成绩：

小猿搜题产品一年时间获得了 5000 万的用户。
我们团队在开发上做到了每周一次迭代，两周一次版本发布。

技术管理的总结

在我的工作中，我慢慢总结出在创业公司中做技术管理工作的「方法论」。我把我的技术管理工作分成以下几个部分：管理业务，管理团队，管理技术。

管理业务

做为互联网公司，我们奉行简单直接的沟通，所以我很多时候并不需要涉及人员的管理工作，更多的时候是业务的管理工作。业务的管理工作主要是围绕着一个具体要做的技术开发功能点展开。具体包括：

任务分解和分配
制定大概的开发排期
每天了解开发进度
讨论和跟进各种具体的技术问题
协调一些产品需求变更
响应一些市场同事的需求
跟进相关功能上线

在这方面，我们主要是采用 Scrum 的开发方式，见《适合码农工作时玩的游戏：Scrum》。

我们在整个迭代（Sprint）过程中引入四个会议：计划会议，每日站会，评审会议和回顾会议。通过事先简单的计划，再加上这四个会议中的详细讨论，我基本能够做到：

通过计划会议：比较合理的安排开发排期、分配任务。
通过每日站会：每天了解开发进度，会后讨论和跟进各种具体的技术问题

对于产品需求变更和市场同事需求的响应，我主要利用自己在 Sprint 执行过程中的时间来展开。我会根据当前需求的大小和紧迫程度，来决定是否插入到当前的 Sprint 中。如果插入到当前的 Sprint 工作量太大，我会适当做一些 Sprint 内容的调整。

跟进相关功能的上线主要是开发快要结束的时期，我会和产品同事一起试用最新的功能，了解 Bug 修复的进度，上线的风险情况。在大部分出现风险的情况下，我们都希望用适度加班的方式解决，所以我们上线当晚有时候会工作得比较晚。在无论如何都搞不定的情况下，我们可能会调整上线时间。

在业务涉及跨部门合作的时候，相关的进度管理会更麻烦一些。因为各部门自己的进度安排不一致，所以就会存在「等着联调」的情况。另外联调时出现问题也容易出现没人主动出来解决的情况。这些都需要负责人更频繁地沟通和推进，以保证按时上线。

在每周的工作中，我的管理业务的工作大概花费是 2 天左右。

管理团队

刚刚也说到，互联网公司不怎么需要管人，那么管理团队主要是做什么事情呢？我认为主要是两件事情：招人和带人，所谓的搭班子和带队伍。

招人

招聘这事情实在太重要了，所以必须要团队负责人参与。人才的招聘除了从公开的渠道收取简历、从猎头或同事那里得到推荐以外，还包括定向的找一些自己熟悉的前同事或某个领域的知名大牛，这些工作都是非常花费时间的。

在招人上，我们主要用到了找前同事，内部推荐发伯乐奖，以及进行技术分享和开源代码来获得社区影响力的方式。

值得一提的是，我们对于开源社区的贡献也得到了肯定，我们的基础架构组负责人陈恒因为多次为 Hbase 贡献代码，所以成为了 Hbase 的 Committer，而全中国拥有 Hbase 的 Committer 的公司在此之前只有三家，而且中国的 Hbase 的 Committer 不到 10 人。

在每周的工作中，招聘大概会占用我半天到一天的时间。

带人

人才招进来了，能否顺利融入团队，团队负责人以及这个人的导师（mentor）非常重要。需要做的事情包括：

平时多交流沟通。
在新人遇到问题时，热心地解答。
引导新人熟悉公司的工作方式。

一对一沟通来源于 Intel 公司，在最近很火的一本书《创业维艰》中里面也提到过。《创业维艰》的作者本·霍洛维茨是被誉为「硅谷最牛的 50 个天使投资人」之一，先后在初期投资了 Facebook、Twitter、Groupon、Skype。

他在书中对一对一沟通介绍到，一对一沟通最主要的意义是：可以使得信息从下而上地传递。从而获得在其它渠道不易获得的信息，保证透明。

适合一对一沟通的内容有很多，包括：

不成熟的看法
迫在眉睫的问题
精彩的想法
倾诉焦虑
抱怨

这些内容都不适合在别的场景中出现，比如：不成熟的看法，如果在部门的正常会议或邮件中提出，会让人觉得未经过深思熟虑。又比如一些焦虑或抱怨，如果通过一些渠道宣泄给其他同事，其实也是不好的。一对一沟通让这些内容有了一个不错的出口。

5 年前我刚毕业加入网易有道的时候，我的老大，也是我现在创业公司的 CTO 郭常圳就开始和我做一对一沟通。我非常享受每次沟通的过程。现在我也开始和别人做一对一沟通，我也开始关注一对一沟通的技巧。我们认为最大的技巧是：作为管理者，要多听少说，让员工成为沟通的中心。郭常圳有一个特别「老土」的办法，就是：不主动说话。通过这种方式，强迫让员工选择他们想聊的话题。

在《创业维艰》一书中，也介绍了一些适合用来引导的问题：

当前产品还有哪些可以提高的地方？
我们部门的最大问题是什么，为什么？
如果有，你觉得工作中有哪一点令你感觉不舒服？
你觉得谁的工作最优秀，为什么？
我们的产品哪方面不尽如人意？
我们错失的最大机遇是什么？
哪些是我们应该做而没有做的？
你自己希望未来在哪些方面能有提高？
有什么我能为你做的事情？

我大概保持每个月和每个组内同事都有一次一对一沟通，有很多时候，我是通过「请他们吃饭」来完成的。一对一沟通需要一个舒适的环境，所以在咖啡厅或饭桌上，可能都比在办公室的效果要好一些。

一对一沟通的另一个核心要素是要坦诚，这就像 Scrum 指南中用「游戏规则」来描述内容一样，如果管理者做不到坦诚，那么同事就不会把这当作是一次有效的沟通机会。坦诚的沟通方式是：所有问题都真诚的回答，不掩饰问题，也不回避问题。如果沟通双方能够做到坦诚，即使是一个棘手的问题，那么双方也会从「解决问题」的角度，尽量寻找可能的办法。

除此之外，定期组织一些团队活动，让团队每个人之间建立友谊，也是我努力在做的。这在很多大公司是 HR 部门做的事情，在我们创业公司里面，也变成团队负责人的工作之一了。

什么是领导力

关于管理团队，我也特别喜欢《成为技术领导者》一书中的观点，关于本书，更多的请见《成为技术领导者》读书心得》。书中是这么说的：

所谓领导力，就是创造这样一个环境，每个人都能在其中发挥出更多的能力。

我想：在强调平等、创新、自由的互联网公司里面，这可能就是领导力最好的定义吧。

管理技术

作为一个技术负责人，产品在技术上的架构是否合理？随着用户量的增长，现有架构能否胜任？当运营活动发生时，突发的流量会有多少，服务器是否能够承受住压力？未来技术上的架构应该如何演进？除了服务器端，客户端应该在哪些技术方案上投入研究力量？这些都是技术负责人需要考虑和决策的。

我同时做过服务器端和移动端的开发工作，不过由于最近几年都是做移动端的开发，所以服务器端的架构技术细节我其实并不是专家。所以我在这方面做得算不上很好。可能是运气好吧，有几次服务器的压力问题，我们都及时发现并且解决了，但是时间都挺紧迫的。现在，我会花时间把服务器端的架构图画出来，然后一块一块考虑，看看有没有更优的方案，并且和服务器端的同学讨论。

在客户端上，我只是对 iOS 开发比较熟悉，对 Android 了解得并不深入。所以我会让技术同学自己提一些技术改进方案，我参与 Review，我想他如果能说得有理有据，还是可以授权他在技术上深入的。

其实每个平台的技术管理可能都需要更多的「授权」，因为具体做事情的人，会比技术管理者更清楚地了解细节。而对细节的深入了解，才是改进技术架构的方案来源。所以，尽量招靠谱的人，那么在管理技术上的工作就只需要遵守「尽量授权」的原则来就可以了。

管理技术还包括公司技术氛围的建立，我主要在以下这些方面下了一些工夫：

推进技术 wiki 的使用
推进 iOS 端每周一次的技术分享
推进 Code Review 以及代码质量

Wiki 是一个非常好用的知识管理工具，前提是每个同事都参与贡献内容。所以作为一个管理者需要用言行来指导新同事学会用 Wiki。我会主动将重要内容记录在 wiki 上，对于一些同事发的邮件内容，我也会要求他整理到 wiki 上。

iOS 端的技术分享也是需要管理者推进的。我之前在网易有道的时候，这方面的活动基本上是大家自愿的方式来进行。这其实对分享者要求很高，一般的人很难达到这种意识，所以当时有道 iOS 端的技术分享很少。因此，我还是认为「半强制」的分享方式更适合当前团队。

「半强制」的分享规则需要大家认同，在一个相对轻松的环境下达成一致，为此我专门组织了一次交流会，大家相互认识一下，一顿吃喝之后，再约定分享规则。现在看起来，大家其实有很多想分享的内容，在 Wiki 上，很多一两个月才轮到他的人，都已经把分享的主题确定了。

Code Review 也是一个需要推动的事情，我们使用 Git 和 Gerrit，做到了所有的提交必须 review 通过之后，才能 merge 进代码仓库。另外我们也在 wiki 上规定了详细的代码风格要求。Code Review 如果做得好，不但可以在代码风格上达成一致，还能让新同事从中学习到一些良好的编程习惯，一些潜在的 Bug 也可能在 Code Review 中被发现，实在是值得坚持的事情。

产品负责人

除了技术负责人的管理业务，管理团队，管理技术工作外，我另外还是小猿搜题的产品负责人，所以我还承担着技术负责人之外的一些工作。这些工作最主要的就是对产品的管理工作。

产品工作看似简单，实则复杂，而我作为一个工作多年的程序员，在这方面的经验非常少。所以我在参与产品讨论时，一开始都比较惶恐。后来我慢慢发现，产品经理的思维还是有章可循，便开始总结和学习，我看了不少产品经理的书，而郭常圳的多次指导也对我的帮忙意义巨大。其实做产品的原则就那么多，重要的还是多思考和体会，把那些原则融入自己的理解。

「场景化思维」是我学到的第一点，我还记得郭常圳带着我们学习乔布斯推出第一代 iPhone 时的演讲，乔布斯非常会讲故事，在用户具体的场景中介绍自己的产品。好的产品经理会将自己「代入」目标用户的使用场景中，解决用户的主要痛点和问题。做为技术人员，我常常陷入产品逻辑完备的泥潭中，但是「场景化思维」使得我能够重新跳出细节，关注主要功能设计是否合理。

「关注数据」是我学到的第二点，产品经理在打磨细节方面，如果能够关注产品数据，那么就很容易找到改进的方向，并且在后期验证自己的想法。关于这个，详细的请看：数据的秘密（上）- 为什么要关注数据和数据的秘密（下）- 如何分析数据。

我曾经犹豫自己是否应该学习写产品稿，郭常圳说不用，他说你只需要多看产品经理的产品稿，多思考和比较，慢慢就会有产品的感觉。我发现这一点还是管用的。以前用一个新的 App，作为开发者，我会关注它的功能在技术上如何实现，而我现在，不光会关注技术实现，还会想它的产品设计思路。打开了这扇窗户后，我就能在日常生活的每一天里，通过思考来提升自己的产品能力。

作为产品负责人，我主要的工作是参与产品稿的评审和美术稿的评审，同时会参与决定未来要做的功能，将其安排到产品工作中。另外，我也会关注产品的各项指标数据，保证重要的产品数据都是看过的。

我每周花在产品评审和美术评审大概是半天到一天，每周花在关注产品各项指标数据上的时间大概是半天到一天。

我做得不好的地方

做为一个技术转管理的新人，我觉得我的工作还是有挺多问题。

首先，我刚开始还是太迷恋技术了，有一些开发工作我仍然主动参与。但是实践之后发现，因为我的事情太多太杂，使得我很难保证自己承担的开发工作的进度。所以我现在学会主动把任务交给别人做，如果一件事情不是必须我才能做的，我就交给别人。所以现在技术上，我只参与 iOS 端的 Code Review 工作了。我将更多的精力，放在一些不得不由我做的沟通和项目推进方面的工作上。

接着，我有很长一段时间没能很好地安排好产品计划和研发的进度。好的产品计划应该要领先开发一个以上的迭代周期，这样在技术开发当前版本时，下一个版本功能就在设计和评审当中，使得大家的工作都不受影响。而小猿搜题的产品计划有一阵一直没能很舒服地领先技术，这让很多时候开发同事并不舒服。

解决的办法是我们让产品文档的完成时间点也尽量精准，对于一个大的产品功能设计，我们会定好初版（我们内部叫做 1 版本）、详细版（我们内部叫 5 版本）、完善版（我们内部叫 9 版本）的时间点。产品经理需要努力在时间点内保证产出，这样其实反倒使得大家会关注产品设计的主要问题，在细节上不过分纠结。

最后，我在招聘上的成绩也比较一般，没有能够为团队招来很多有经验的人，所以小猿搜题现有团队还是新人居多。新人的好处是容易和团队文化保持一致，但是在经验上，还是需要更多的锻炼。