谈成熟技术团队的管理

对于非创业阶段的公司，业务相对稳定，公司发展的目标、计划也比较明确，公司一般很重视产品技术团队的建设；在这样的环境下，研发团队应该如何发展呢？笔者准备从以下几个角度，来探讨技术团队的综合管理。
 
 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社区供稿，欢迎各位技术人投稿。