原文地址:技术团队管理(上)技术团队管理(下)

对于非创业阶段的公司,业务相对稳定,公司发展的目标、计划也比较明确,公司一般很重视产品技术团队的建设;在这样的环境下,研发团队应该如何发展呢?笔者准备从以下几个角度,来探讨技术团队的综合管理。

  • 招聘
  • 人员培养
  • 团队文化、氛围
  • 技术栈、技术架构
  • 项目管理
  • 晋升

# 招聘

每个公司对引入合适的人才,都逐渐形成自己的人才观和人事方面的方法论。大部分团队的负责人和leader,也接受过公司关于人才招聘方面的培训。我们如何去寻找到合适的人才呢?请看下面这张图。【来自百度百科:人才冰山模型】

人才冰山模型

对一个候选人,我们的面试过程,也是从这几个方面进行考察。稍微和上面有一些差异。

知识: 在专业知识方面考察时,需要注意的是让至少高于候选人两个级别的人来面试,从而能准确的评价候选人的知识。如果让低P的人来面试,很可能会因为面试官没听懂候选人的回答,而早早误杀掉。

对于技术团队,在知识上,一般考察的是算法、数据结构、常用技术栈和数据库等方面的、有一致理解的“知识”。

经验: 在考察一个人的经验时,首先看的是他的简历,这样能快速的对一个人的经验做出判断。这个“速读”不能很深入的理解一个人的实际深度;做过一个项目、使用过一个技术,做的好不好、专业不专业,是看不出来的。

在面试过程中,可以挑一两个中型的项目,让候选人用十分钟来说一下当时做的情况,使用的主要的框架、部分难点攻关的细节。

素质: 这里是很容易发生误判的一个环节。不同的面试官面试同一个人,对一个人的素质判断可能会差异很大。这方面我使用的方法,是聚焦一下关键素质,包括:智商(逻辑思维能力、结构化思维能力)、情商(情绪控制能力、感染他人能力)。

动机: 一个人的动机判断,在面试阶段很难判断的出来,我自己在这方面也做的不好。我会去看一下这个人是不是比较善良,眼神里透露的是不是纯净,判断他的心态、工作和生活态度;以此来估计候选的动机是不是正能量。【这也许是个很差劲的方法】

以上说明了考察的几个主要方面。那么面试过程中,如何有效的和候选人沟通,获得这方面的信息,以做出对候选人素质的判断呢?我认为最重要的,是让候选人讲出实际的case,举例和讲解他在以往工作里做出的实际行动、项目、技术。从这些实际发生的客观事实里,联系到知识、经验、素质和动机上来,以做出比较好的判断。

作为技术团队,对候选人的智商考察,是很重要的。技术工作有一定的智商门槛。这里强调一下,做技术工作,不是智商越高越好,而是过了门槛就好。到了实际工作里,只要智商达到一定水平,具体的工作贡献,和个人的情商、动机关联更高。工作做的更好、发展更快的,往往是那些情商更高的人。

招聘过程中,还有一个现象,就是在招聘压力比较大的时候,面试官或部门负责人,会一定程度上放水,体现在对候选人的要求降低,或对候选的定级上放松。这方面比较有效的实践,是做跨事业部复试,对候选人的能力、级别进行公司层面的拉齐。

最后,在面试中和面试结束后,如果有好的建议给候选人,也可以跟候选人交流一下。我的实践是,候选人一般都会对真心的、客观的建议表示感激,在HR回访候选人时,也会体现出较高的面试过程满意度。

# 人员培养

人才是选出来的,不是培养出来的。这是人才的一个基本理念。人才选拔招聘这一环节,是非常重要的。但是,培训依然非常重要。

培训的内容,不仅仅有专业知识、业务知识的培训,还有公司文化、环境的培训,还有公司的价值观的培训,培训的内容分类,可以说是丰富多彩。我比较喜欢贝壳的领导力培训体系,覆盖了招聘、绩效考核、团队管理等一系列的课程。薪酬绩效部分的培训,是当时的CHO郑云端先生亲自上阵,让鄙人受益匪浅。

培训的价值,我认为是把各式各样背景的人才,通过培训的方式,在某些方面(比如管理、价值观),形成一致的认识,能够让完全不同的人,能够按一致的方式来思考、处理某类问题。比如在招聘的理解和实操上,能够把公司的招聘策略、方法和要求,一致性的传达给所有的部门负责人、面试官。这对公司整体的人才选拔,有很大的助力。

在研发团队内,培训主要分成这几个方向:

  • 专业技术培训
  • 行业知识培训
  • 技术分享
  • 价值观培训

专业技术培训,主要是对技术人员进行一些软件开发、系统架构方面的知识培训。比如对微服务架构、DDD领域设计、大数据分析方面的培训。团队内人才结构按梯度分布,不同梯度的人才,所接受的专业技术培训,也是不同的。我们一般是在公司内部寻找专业知识培训资源。

行业知识培训,主要是对团队所建设的领域,进行知识培训。比如我现在贝壳负责的人事、财务领域,在2019年组织了几场系列的人事、财务专业知识培训,请我们的HR、财务总监,来给我们讲课。这样的行业知识,能够让技术团队在后续的工作里,更快的理解业务需求,做项目的过程中,及时发现一些专业问题。

技术分享,主要是团队内的技术分享。团队成员完成了一个项目,作为一种知识扩散和团队互相交流的形式,给大家讲自己做项目过程的收获、体会,使用的方法、技术。技术分享主要的目的,是增进团队成员之间的互相了解,互通有无;其营造文化氛围方面的作用,超过技术传播方面的作用。

价值观培训,主要是团队内对文化价值观进行交流。价值观这个事情,就得一遍一遍的说,说到团队能记住了,不知不觉的影响了自己的行为即可。具体的方式,是一遍一遍的讲价值观的事例,对模范事情进行表彰,对不符合价值观实践进行刨析。价值观培训是个持续的过程,一个慢慢影响组织、渐渐发生物理变化的过程。

人员培养不止培训,还有另外一个维度,对潜在后继人员、潜在晋升人员进行培养。对于部门负责人来说这是很重要的事情,就是在团队里发现那些具备后继任潜力、晋升潜力的人,提前通过工作任务安排、项目安排和技术攻关,来让他们加速提高。这方面我们的研发团队做的很好,每个研发总监都有、而且在培养自己的后继任人。

# 团队文化、氛围

对于一个规模比较大的研发团队(50~200人),团队的文化、氛围,对团队的正向发展,变得非常重要。我分为以下几个方面,来探讨团队文化和氛围。

团队文化氛围
  • 技术民主的决策环境
  • 适度自由的工作氛围
  • 富有挑战的工作内容
  • 鼓励创新的文化
  • 积极互助的同事关系

技术民主的决策环境: 在技术栈选型、技术架构设计、技术方案评审方面,推崇技术民主的文化,支持任何人提出自己的观点、发表意见,并客观的评估提出的观点、意见,如果是更合适的、或是纠正现在的错误的,那就积极采用、支持落地,并对提出者给予公开的表扬。如果不采用,反馈不采用的原因,不得以批评、指责的方式打压提出观点、意见的人。

团队leader需要清楚的知道,在技术上,自己不一定是最强的人,甚至要引进技术比自己强的人,而和更强的人一起合作的方法,就是对对方意见和建议的尊重,采纳正确的方案。

即使是团队内技术不如自己的同事,因自己在设计上会有不完善或思考不周的地方,有纰漏和缺陷也很常见。审慎的对待每个提出的意见,尊重、感谢提出意见的同事,是避免出现线上大坑的有效方法。

民主的技术决策环境,体现的是对伙伴的尊重,对群体智慧的应用。

适度自由的工作氛围: 一般来讲,团队的成员请假,我基本都会批准。技术团队的加班加点是比较多的,在公司、团队的项目比较忙时,我们需要团队成员付出额外的时间是来投入工作;当员工遇到生活上的问题时,无论是生病、家中琐事、朋友来访还是亲人关怀,作为leader一样要给予方便。

有时部分同事为了安静的完成项目任务,提出在家“闭关”几天,我也会支持。项目的需求明确了,技术方案确定了,他自己的任务也清晰了,如果在家能够更安心高效的完成任务,减少上下班通勤时间,做到更好的交付,也是对公司、团队有益的。

当然,“自由”是适度的,是对那些平时工作积极、勤奋的同学才会是开始放的。这个自由,不能成为团队部分成员散漫的缺口,leader需要把握住。

富有挑战的工作内容: 对于做技术工作的同学来说,克服技术难题,实现以往自己做不到的事情,是个有莫大自豪感、成就感和快乐的事情。这种快乐,也许只有酒鬼遇到酒时,才能理解。【鄙人体会过前者,未体会过后者】。克服技术难题,做挑战性的项目,能激发起团队成员的斗志。

对于公司来说,对于能够完成挑战性任务的团队,自然也是另眼相看。但是做挑战性的项目,自然失败或延期交付的概率也高一些。团队的负责人在此时,需要及时的和公司沟通,同时积极鼓励团队加速攻关,而不是批评打压。

贝壳的UC系统,在 2019年上半年以前,稳定性只有2个9,A级故障频发。也被公司的技术委员会、合作团队多有诟病、评判。在我列入部门OKR、尚未安排启动时,我们部门的一个研发leader,已经自己组织了团队,每周六加班一天,用了2个月的时间,重构系统,把性能提高了10倍,稳定性达到4个9。

这样的创新、挑战行为,我是非常支持的,在年终的大会上,对这个项目和团队,给予了很高的评价。

一个没有挑战性工作的团队,是没有生命力的,优秀的人会逐渐流失。

鼓励创新的文化: 技术工程师团体一般比较年轻,思维活跃,敢于尝试,这是非常优秀的品质。对于他们在一些技术项目上,做一些“离经叛道”的尝试,应予以鼓励。但是对这样的创新的项目,团队的架构师和技术负责人,在确定能发布之前,必须严格的评审、review,防止给线上服务带来严重影响。

当前很多公司都在推统一的技术架构、统一的技术栈,以提高研发的效率。这是一个正确的事情,能够提高研发效率、交付质量、降低运维成本。但是同时也会带来相应的负面的影响,公司内对不同技术栈的研究不足,对日新月异的技术发展跟进不足。技术团队应该对新生事物保持好奇,保持探索的精神。

积极互助的同事关系: 作为技术团队,每天在公司的时间,一般都超过10个小时,也就是说,我们和同事相处的时间,大部分超过和我们的家人、朋友相处的时间。如果公司的同事之间,关系比较紧张,那么内心是很压抑的,在压抑的环境下,智力工作的效率是很低的。

作为团队的leader,需要主动去营造一个互助的氛围。积极和同事沟通,进行工作和非工作的交流,熟悉每个人的性格、特点、近况,做到即是工作上的leader,也是生活上的朋友。让团队内的气氛轻松,拉近团队的距离,让团队的沟通成本降低。

作为leader,尊重每个同事,欣赏每个同事,是和谐的团队关系的前提。曾经我一度误以为,严格的领导风格,对团队效率更高;对同事的缺点、项目的问题进行直接、严苛的批评,但是会逐渐发现,问题解决了,人心却散了。严格的批评、指责,是很容易滑向不尊重的,会非常伤害同事。后来我换了一个方法,在保持尊重和有礼的态度下,语气平和的指出问题和改进方法,团队成员表现出来的是更多的配合、感谢和持续提升。

# 技术栈、技术架构

很多公司都经历过技术栈、技术架构统一的过程,形成公司内研发组织统一的选型和强制标准。这是一个非常有利的事情,能带来以下好处:

  1. 在公司的不同团队、项目上,技术人员复用性更强
  2. 有利于公司在选定的技术栈和技术架构上,深入挖掘,形成自己的最佳实践
  3. 公司的运维体系统一,有效提高线上运维的一致性,降低运维成本
  4. 不同团队所研发的基础服务或组件,能够在公司内低成本复用
  5. 不同的系统之间,集成成本低,甚至相当“自然”

我曾经经历过一次合并收购的公司,使用的开发语言是PHP,而公司的主流开发语言是JAVA;引发了一系列的实际困难,最终用了一年的时间,才把技术栈切换过来。具体遇到的困难是:

  1. 收购的业务已经在线,已经有用户使用;因业务发展需要,新的需求和迭代,依然在不断发生。
  2. 对于新收购的业务,在人员扩充上,进入两难境地。一方面知道未来肯定要切换到JAVA语言,另一方面眼前只能招PHP的技术人员,来解决研发资源问题。当开发语言完成切换后,这些PHP工程师怎么办?
  3. 定级、晋升体系出现困难,由于PHP技术很少,在工程师定级、工程师晋升评审上,不好客观比较、匹配。
  4. 运维需要独立一套体系,不能融入现有的运维体系。导致线上故障的发现、处理效率,相对公司整体水平偏低。

对于这种困境,解决的过程也是很煎熬的,逐渐把新的服务开发向JAVA语言转换,过程中团队内PHP工程师安全感低,人员流失严重,团队文化氛围差;Leader需要做很多安抚和培训,对一部分价值观正、学习能力强的人,进行JAVA技术培训,以期以后能够转换到JAVA序列。

鉴于技术栈统一的优点,大部分公司发展到一定阶段,都会开始做技术栈的整合、统一,笔者认为此事非常正确。但是也需要正视带来的负面影响,采取一些行动,来降低负面影响。我认为负面的影响如下:

  1. 在人才招聘上,可能会因为候选人的技术栈不同,而错过一些优秀的人才。如果候选人的经验、学习能力很好,那么他是有能力用几个月的时间,掌握、切换到新的技术栈上;但是在面试时,因为面试官对于技术栈的偏好和熟悉度,很可能会降低候选人的表现和评价。
  2. 技术团队不能有效发现其他技术栈的优点; 团队对选定的技术栈钻研比较深,而对其它的技术栈、新的技术栈探索的比较浅,不能有效发现其他技术栈的优点,在当前技术栈逐渐衰老、退出行业舞台时,进行调整变化的节奏慢。
  3. 技术人员本身的技术视角的广度可能会受到限制,一些更有效、更优美的解决办法,会被错过。

鉴于这种情况,建议技术团队的负责人,在一些不关键的项目、工具上,允许甚至鼓励团队尝试一下新技术栈,但一定不要“传染”到公司的主要对外服务的线上系统里。保持团队的好奇心、创新性,留给技术人员接触、使用、和研究不同技术栈的“试验田”、“自留地”。

# 项目管理

自移动互联网爆发后,项目经理的岗位几乎在互联网里消失,项目经理的职责里,仅剩的项目进度跟进,被产品经理“兼职”了。2015年到2018年之间,项目经理的发展空间是大幅度萎缩的。以前高德CTO杨永琦说过,移动互联网就是要不断试错,不断把想法变成产品,推到用户那里,让用户投票,用户不用就下掉,用户喜欢就继续加码。

这样的背景下,产品迭代的速度,就成了各个互联网公司比拼的重要内功,甚至成为一种“竞争力”。能够让公司在还看不清楚的时候,就进行低成本的市场验证,进行“火力侦察”。用户的APP频繁升级,甚至成了提高用户活跃度的手段。这种背景下,重要的是产品经理又有了什么点子去让用户快速验证,只要撒对一个“idea”,用户就留存了,资本就欢喜了。

但是自2017年,王兴提出“互联网下半场”的节点后,“供给侧改革”为代表的B端服务兴起。项目逐渐变成需求复杂、交付周期长、质量要求高,产品经理的重心在需求的分析和理解上,在行业实践的探索上,而保障交付、保障质量的职责,重新回到了项目管理的维度上。B端服务的特征是专业知识门槛高、用户试错容忍度低、获客成本高,这些都为项目经理的重要性重新归来,奠定了前提条件。

我们团队自2019年重新建立了PMO团队,来跟进部门的项目,解决项目是否要做、参与项目各方的目标、资源、进度和交付问题。

项目管理第一个要解决的问题,是“项目值不值得做”的问题。 提出需求的部门、产品经理,必须能够讲的清楚,这个项目能给公司、用户带来什么价值,通过运营,最终实现什么样的结果。我们做了太多看似有用、实则可有可无的系统:有了没什么坏处,没有的话也没有什么痛。

项目管理第二个要解决的问题,是多部门、跨团队的协调问题。 大的组织里,每个部门都有自己的主攻方向和OKR(KPI),正常情况下各团队都以自己的部门OKR为重。这导致跨部门、跨团队的项目组织非常困难,由于目标、专业技能的不一致,项目的进展和实际结果,和开始的预期相差很远。项目经理必须能够清楚的理解项目的价值,并且传递给多个部门、团队的负责人,引导参与方对价值、优先级认知一致,在此基础上,制定出跨部门的整体计划来。

项目经理需要有足够的授权,如果项目经理只能是辅助角色,支持立项流程、跟进实施进度、协调各团队配合协作,那是体现不了项目经理的价值的。项目经理需要对项目的结果(业务结果)负责,以拿到业务结果为目标,组织公司的资源,实施项目过程。因此项目经理的人选,也是非常苛刻的,除了PMO外,项目经理大都是需求部门的负责人来兼任的角色。

# 晋升

为了给技术人员、除了管理这个“独木桥“外的晋升空间,大部分公司都建立了技术专业职级的制度,鼓励技术人员在专业能力上,持续发展、晋升。这满足了技术人员在职业上进行持续发展的需要,促进了技术团队的持续发展、稳定。

那么在技术人员晋升上,需要注意什么呢?笔者认为最重要的是公平性、公开性和看重直接领导意见。同时也要避开一个误区,那就是技术人员达到一个“级别标准”,即可晋级。(每次做晋升评审后,我在团队里进行晋升结果沟通时,都会遇到这样的情况,论实际的工作能力、掌握的技能,不比其他高级别的差,为啥有的人没有晋升成功呢?)

实际在各个公司的晋升评审中,可能每个评审官手里都一个职级能力标准;但是实际进行晋升评审时,往往只是作为“参考”。甚至到了最后阶段,是把大家打分的结果,拿出来“排序”,排序在前的几个人通过。这些情况反映了晋升评审的困难:到了一定级别,每个人的优点、个性都很明确,缺点也很明确,所做的工作内容可能差异也很大,不同领域的知识跨界很难,不同的人之间进行比较,要做到很客观是有困难的。

在这里,我需要重点提一下,晋升评审中,直接leader的意见很重要,每个人的能力、素质是不一样的,部分人就是不擅长言辞、临场发言(比如在下…),在晋升评审里,不能把自己的优点、做的东西讲出来。直接leader有责任、有义务通过更客观的数据、评价,提交给评审组,对他的晋升进行支持。

晋升是需要有比例限制的;一方面大部分公司的晋升和调薪都是挂钩的,出于成本的控制,有限制晋升比例的动力;另一方面,各团队都希望自己部门晋升的人多一些,如果没有限制,会出现职级晋升放水。

晋升政策上,还需要关注一个问题,部分员工做的贡献很大,但是技术(专业能力)并不是很强,或者因为所做的项目,是需求复杂性、行业知识难的项目,而不是技术有挑战的项目。这方面笔者倾向于支持行业知识要求高的候选人晋升、需求复杂度高的不晋升(主要专业能力体现在产品经理身上);但是在绩效奖金、调薪上,应该对贡献大予以支持。不能因为晋升不成功,影响这些贡献比较大的人的调薪空间(目前很多公司在这两方面,是进行了绑定),从而影响这些人的稳定性,形成谁都不愿意做的“黑暗系统”。