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

标签: 重生 技术 管理 | 发表时间:2015-12-18 21: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

相关 [重生 技术 管理] 推荐:

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

- - 唐巧的技术博客
我从高中就开始接触计算机并开始编程,我非常喜欢编程,我一直以为我会写一辈子代码. 我从毕业就一直做技术,开始一年是做 Java 语言的服务器开发,开发过网易邮箱和微博的后台,后来转而做 iOS 开发. 因为喜欢,我几乎把我所有的非工作时间也投入到技术中去. 当然,并非是把工作带回家,而是专研技术或者从事技术写作.

技术、管理与30岁的槛~

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

技术管理者标准管理模板

- - 后端技术杂谈 | 飒然Hang
对于公司技术团队新晋升的一些研发Leader、主管等管理人员,即使在大公司具有完善的培训机制,大多数人在一开始还是会手足无措,不能很好地做到从个人贡献者到团队贡献者角色的转变. 于是根据自己以及公司内部很多技术管理者的工作经验梳理出了一些技术管理者的管理模板,可以作为管理工作的实践参考. 基于职责确定团队的使命、目标.

有关技术管理的一些思考

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

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

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

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

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

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

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

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

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

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

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