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

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

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

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

我做得很开心。

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

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

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

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

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

现在经过了一年半，我们不但组建成了一支充满战斗力的团队，成收获了不小的成绩:小猿搜题产品一年时间获得了 5000 万的用户。我们团队在开发上做到了每周一次迭代，两周一次版本发布。    技术管理的总结在我的工作中，我慢慢总结出在创业公司中做技术管理工作的「方法论」。我把我的技术管理工作分成以下几个部分:管理业务，管理团队，管理技术。

管理业务

作为互联网公司，我们奉行简单直接的沟通，所以我很多时候并不需要涉及人员的管理工作，更多的时候是业务的管理工作。业务的管理工作主要是围绕着一个具体要做的技术开发功能点展开。具体包括:任务分解和分配制定大概的开发排期每天了解开发进度讨论和跟进各种具体的技术问题协调一些产品需求变更响应一些市场同事的需求跟进相关功能上线在这方面，我们主要是采用 Scrum 的开发方式，见《适合码农工作时玩的游戏:Scrum》。

我们在整个迭代(Sprint)过程中引入四个会议:计划会议，每日站会，评审会议和回顾会议。通过事先简单的计划，再加上这四个会议中的详细讨论，我基本能够做到:通过计划会议:比较合理的安排开发排期、分配任务。通过每日站会:每天了解开发进度，会后讨论和跟进各种具体的技术问题。对于产品需求变更和市场同事需求的响应，我主要利用自己在 Sprint 执行过程中的时间来展开。我会根据当前需求的大小和紧迫程度，来决定是否插入到当前的 Sprint 中。如果插入到当前的 Sprint 工作量太大，我会适当做一些 Sprint 内容的调整。

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

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

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

管理团队

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

1.招人

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

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

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

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

2.带人

人才招进来了，能否顺利融入团队，团队负责人以及这个人的导师(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 版本)的时间点。产品经理需要努力在时间点内保证产出，这样其实反倒使得大家会关注产品设计的主要问题，在细节上不过分纠结。

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