17611538698
webmaster@21cto.com

谈成熟技术团队的管理

资讯 0 1903 2020-08-31 01:02:21

 

1347512602-xianzaikezai-microsoft-azure-shangshiyong-elasticsearch-service-elastic-cloud.jpg


对于非创业阶段的公司,业务相对稳定,公司发展的目标、计划也比较明确,公司一般很重视产品技术团队的建设;在这样的环境下,研发团队应该如何发展呢?笔者准备从以下几个角度,来探讨技术团队的综合管理。
 
 1、招聘
 2、人员培养
 3、团队文化、氛围
 4、技术栈、技术架构
 5、项目管理
 6、晋升
 
技术栈、技术架构
 
很多公司都经历过技术栈、技术架构统一的过程,形成公司内研发组织统一的选型和强制标准。这是一个非常有利的事情,能带来以下好处:
 
    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有责任、有义务通过更客观的数据、评价,提交给评审组,对他的晋升进行支持。
 
晋升是需要有比例限制的;一方面大部分公司的晋升和调薪都是挂钩的,出于成本的控制,有限制晋升比例的动力;另一方面,各团队都希望自己部门晋升的人多一些,如果没有限制,会出现职级晋升放水。
 
晋升政策上,还需要关注一个问题,部分员工做的贡献很大,但是技术(专业能力)并不是很强,或者因为所做的项目,是需求复杂性、行业知识难的项目,而不是技术有挑战的项目。这方面笔者倾向于支持行业知识要求高的候选人晋升、需求复杂度高的不晋升(主要专业能力体现在产品经理身上);但是在绩效奖金、调薪上,应该对贡献大予以支持。不能因为晋升不成功,影响这些贡献比较大的人的调薪空间(目前很多公司在这两方面,是进行了绑定),从而影响这些人的稳定性,形成谁都不愿意做的“黑暗系统”。
 

作者:方正柱。贝壳技术负责人。本文由作者向21CTO社区供稿,欢迎各位技术人投稿。

 

 

评论