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

标签: 技术 管理 | 发表时间:2015-12-18 13:32 | 作者:
出处:http://blog.devtang.com/

一个程序员的理想

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

我从毕业就一直做技术,开始一年是做 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。

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

适合一对一沟通的内容有很多,包括:

  1. 不成熟的看法
  2. 迫在眉睫的问题
  3. 精彩的想法
  4. 倾诉焦虑
  5. 抱怨

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

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 版本)的时间点。产品经理需要努力在时间点内保证产出,这样其实反倒使得大家会关注产品设计的主要问题,在细节上不过分纠结。

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

总结

小猿搜题从 2014 年 7 月 17 日立项,到 10 月上线,再到元旦正式对外推广,到现在在不到一年的推广时间内,已经积累了超过 5000 万的用户。而我,也随着小猿搜题,从一个纯技术的 iOS 程序员,成长成为它的产品技术负责人,虽然也犯了一些错误,我感觉自己的进步还是很快的。

我也希望我的故事能够激励其他的技术同行,能够勇敢地接受新的挑战。在快速变化的移动互联网时代,快速迭代演进的不止有 App,也包括我们自己,愿大家都能活得精彩!

Posted by 唐巧 Dec 18th, 2015 summary

关注我的「iOS开发」微信公众号,每天获得精选的 iOS 开发文章和创业心得:

原创文章,版权声明:自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0

相关 [技术 管理] 推荐:

技术、管理与30岁的槛~

- Amom - 高春辉的 BLOG
原发表在新浪微博: @高春辉 (1)我相信在技术圈里,30 岁以后是不是去做管理的纠结,一定是每个做开发的人都会有的,包括我在内,也和很多人讨论过,但是我还是选择了自己喜欢.

有关技术管理的一些思考

- zhangyijun - 博客园-首页原创精华区
这些天里工作的环境发生了一些微小的变化,可能以后对基层开发的程序员也会有更加具体的影响. 上周参加 Open Party 时,重点听了《那些失败的项目们》,分析了一个项目的提出、实施,直到最后失败的过程. 我也在想一个技术团队究竟应该用怎样的一种管理方式,才能让技术团队的效率达到更优. 我分了几个小主题,下面一一讲来.

技术管理者应不应该写代码?

- - 灰色的灵魂
我相信所有新晋的技术经理,都做过Team的工期紧张,自己加班动手写Code的事情,这种事情我自己也没少干过,事实上,偶尔我自己仍然会在critical的项目上写一些代码. 相信不少同志们还引以为荣,并且不少技术管理的书上,对于技术管理人员是否应该去写代码也有不同的观点,有些认为不应该写,有些认为一定要写一点避免脱离群众外行指挥内行.

如何更好完成从技术到管理的转变?

- - TECH2IPO创见
编者按:这篇来自《程序员》杂志的文章是写给那些IT公司的内部人员,但同样适用于互联网的创业者们. 这篇文章可以告诉你,技术创业者如何完成从执行者到管理者的角色转变,作者梁景波. IT公司研发部门的管理人员大多是从公司内部的技术人员中提拔的. 在快速发展的公司里,这样的机会更多. 然而这种“半路出家”的转型也给我们带来了很多挑战,其中最关键的部分在于思维方式的转变.

Facebook技术总监:如何管理10亿用户的数据?

- - 互联网的那点事
2012年1月28日消息,Facebook用户数量,已经突破10亿大关. Facebook在发展期间,所实现的技术成就,成为了IT行业工程师关注的话题. 究竟Facebook取得了哪些技术成就呢. Facebook前工程部门总监,在问答网站Quora上,对这一问题作出回答. 无论对于IT行业的投资者还是使用者,这些回答都有着指导意义.

如何做好基层技术管理工作?

- - CSDN博客研发管理推荐文章
最近有朋友与我探讨了软件基层技术管理工作方面的话题,借此从动机和方法两方面谈谈我的看法. 要做好基层技术管理工作,首先要确保自己有良好的动机,即明白自己为何要走上技术管理岗位. 做管理的根本是为了获得权力,但获得权力的动机却存在很大的差别. 有相当数量的人往技术管理岗位“挤”,是为了获得以后在工作中可以少做或挑做工作内容的权力;也有的人是为了更快、更多地获得公司动向的资讯,以体现“领导”的“与众不同”;还有人是为了更高的薪资.

关于技术团队管理的胡言乱语

- - 博客园_知识库
  临近年底,接到《程序员》杂志的邀请,希望我能写一篇与团队管理有关的年终盘点文章,盘点2013年业界与团队管理相关的大事. 试想,揪出各个公司在2013年的各种“大事”,指点江山,激扬文字,那种众人皆醉我独醒的感觉是相当的妙不可言. 可细细一想,2013年可以归纳为团队管理大事的事件倒是不少,例如Yahoo!美女CEO宣布取消在家办公制度,最近又按照绩效评估结果排名开始裁员;最近知乎上好事者提出的“你问什么离开xx公司”系列,各种回答纷至沓来,为2013的团队管理大事记提供了不少素材.

如何管理飞扬跋扈的技术人员

- - 创业邦
  在互联网项目当中,相信每一个项目经理或者制作人,最头疼的就是技术部的管理. 因为技术工作看起来是那么的棘手,一般人难以理解,而且技术人员大多数都似乎情商不高. 管理人员既不能轻易了解技术工作的内涵,技术人员也觉得很难和管理人员沟通. 特别是技术工作,难以在不同人之间交接,很多技术人员都声称无法继续别人做过的项目.

从技术到管理:思维转变是关键

- - 博客园_知识库
  IT公司研发部门的管理人员大多是从公司内部的技术人员中提拔的. 在快速发展的公司里,这样的机会更多. 然而这种“半路出家”的转型也给我们带来了很多挑战,其中最关键的部分在于思维方式的转变.    从个人成就到团队成就.   无论是做管理还是做技术,成就导向意识是优秀员工的基本素质. 只有具备很强的成就导向意识,才能把事情做得超预期,才能追求卓越.