小猿搜题的工程师总结技术转管理之道

26点 林涛 7803℃ 0评论

把技术管理工作分成以下几个部分:管理业务,管理团队,管理技术。

管理业务

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

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

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

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

 

如需转载请注明: 转载自26点的博客

本文链接地址: 小猿搜题的工程师总结技术转管理之道

转载请注明:26点的博客 » 小猿搜题的工程师总结技术转管理之道

喜欢 (0)
发表我的评论
取消评论

表情