一、主题分享：高杠杆率技术团队管理

大家好，我是XX公司负责理财业务的技术负责人，今天主要跟大家聊一聊高杠杆率技术团队管理。

首先需要回答一个问题， 对于团队的经理人来说，他的产出是什么？
引用格鲁夫的原话：一个经理人的产出，等于他直接管辖和影响力所及的组织产出和总和。
那么一个经理人该如何才能增加他的产出？

重要的核心是增加团队管理的“杠杆率”。

古希腊科学家阿基米德有这样一句流传千古的名言：“加入给我一个支点，我就能把地球挪动！”

我们可以用以下公式计算经理人的每项管理活动对组织的影响

···javascript 经理人的产出=组织产出的总和=杠杠率A管理活动A+杠杠率B管理杠杠率B……. ···
为了有较高的产出，经理人应该把经理放在杠杠率较高的活动上，也就是提高每个单位时间的产出。为了提高管理活动的杠杠率，经理人要把工作重点放在“时效”性上面。
接下来我将从团队组织结构，团队目标管理、高杠杆率技术团队管理具体措施几方面介绍一下我们的团队管理活动。

第一部分：团队组织结构

图一：团队组织结构
图一：团队组织结构

图二：业务线
图二：业务线

  1. 业务线团队：纵向是业务线团队，也就是任务型团队组织，业务线团队由各职能线团队组成，业务线团队有共同的业务目标，根据公司业务发展规划组建不同的业务线团队，同时具备一定的灵活性，能够根据一些短期目标需要临时组建虚拟业务线团队。
  2. 职能团队：横向是各职能团队，主要负责各职能的标准规范、技能提升，重点是专业方向制定引导，职能型团队由各职能线部门经理负责，比如产品部经理、技术部经理。

技术线面是业务线的组织结构，同样我们在技术线上也是按照“矩阵式团队”的模式打造“混血型”技术团队：
图三：技术线
图三：技术线

  1. 任务型技术团队: 任务型技术团队的共同目标是以业务目标为驱动，主要是与业务线垂直维度相匹配，完成业务线技术目标。
  2. 功能型技术团队: 功能型技术团队除了基础架构组之外，其他是由各团队自发组织的虚拟委员会组成，以更好的加强技术团队在技术专业方向上的标准监督与跨团队专业交流，促进团队技术融合。
  3. 矩阵式“混血”技术团队，任务型团队以项目业务目标为主，功能型团队以完成特殊职能目标为主，“业务目标”+“专业目标”由团队共建

第二部分：团队目标管理和团队目标制定

各个业务线每半年制定中长期的方向规划，然后拆分到每个季度、月的目标分解。

目标的执行监督
团队的目标具体执行采取按周分解、周汇报、一周一版的方式，进度监督采取双向汇报制度：业务线汇报，技术线汇报。

业务线汇报
每日清晨站会：固定时间、固定地点、固定问题（昨天干了什么、今天计划干什么、遇到什么阻碍）进行Scrum看板会议，每日站会是团队的脉搏，能够尽快发现团队中存在的风险与阻碍。

周汇报制度
每周五各业务线会对本业务线各职能节点、整体的周进度目标完成情况、版本情况、遇到的阻碍进行汇报，并对下周的目标进行分解与规划。

季度总结规划
季度目标完成情况、季度规划是业务线管理非常重要的考核点，公司上线会对各个环节的产出情况进行非常详细的评估与总结提高，并对下个季度的目标进行规划分解。

技术线汇报
技术线汇报大部分的内容为任务型团队的完成情况与质量情况，以及技术架构目标的完成情况。技术汇报主要包括：经理人周计划、经理人周例会、经理人月度目标总结、项目组季度总结规划、部门季度总结规划。

第三部分：高杠杆率技术团队管理

团队的组织结构是确保高杠杆率的基础，目标管理、目标监督为团队产出的核心，接下来我将介绍一下职能线技术团队的部分内容。

要提高职能团队的产出主要包括两块内容：
1.是增强团队的工作动力，使团队具备自驱动力把工作做好；
2.增强团队的工作能力。

知识库标准化

培根说：知识就是力量。对企业来说，如果每个人、每个项目的经验和知识可以转化为更多人、更多项目的能力，为公司业务的改进发挥价值，那知识的力量将成倍数地被放大。知识管理，就是这样的转化器、放大器，通过这个工具，经验得以传承，成功得以复制。
大家应该都听说过华为的知识库非常的健全，我们根据团队的情况建立起一套完善的知识库体系，达到团队经验知识力量成倍数地被放大的目标。

图四：知识库标准化
图四：知识库标准化

1.行政办事流程指引
团队工作中重点需要关注的行政办事流程、公司制度，减轻日常工作中行政部分的口头指引成本。
图五：行政边是流程指引
图五：行政边是流程指引

2.公共服务
团队办公区公共设施、团建、办公软件相关的指引，降低办公环境的口头指引成本。
图六：公共服务
图六：公共服务

3.新员工指引
新员工导师、实习生、新员工系统性的指引，为新员工导师、新员工明确清晰的工作框架，提高新员工快速投产的效率
图七：新员工指引
图七：新员工指引

4.团队制度与流程规范
团队的技术规范、管理流程规范、技术团队素质模型指引，提高团队工作标准制度化成熟度。
图八：团队制度和流程规范
图八：团队制度和流程规范

5.技术协会
各委员会的团队宗旨、评议活动、分享活动、培训活动等指引，提高团队在专业性方向的能力。
图九：技术协会
图九：技术协会

6.技术指引
各种团队技术相关手册指引与技术研究、坑的总结，为团队技术方向的标准化与技术经验的传承提供指引。
图九：技术指引
图九：技术指引

7.业务团队文档指引
各任务型技术团队的业务文档指引，为业务经验的传承提供指引。

8.招聘管理
挑选一个与工作岗位相匹配、具备潜力的人需要付出非常大的努力，招聘本身就像一场婚姻，是一个双向选择的过程。招聘管理的核心原则是宁缺毋滥，招聘方式上我们团队建立了一套标准的考核指标，综合个人的专业技能、求知欲、总结抽象能力、沟通能力以及抗压能力做出评价。
对于应聘者潜力判断的一个重要指标是正确的动机，一个高潜力的人，血液中流淌着强大的动力与驱动力，需要与公司的价值观相匹配，对个人的职业规划有长远的愿景。
同样与面试者沟通中需要让对方更多的了解公司的情况，阐述团队的价值观，并对岗位的定位与对方进行深入沟通，避免入职后造成双方期望不一致。

9.新员工试用期管理
图十：新员工管理
图十：新员工管理

新员工在面试阶段就已经明确过了岗位职责，入职后由项目经理确定试用期的目标承诺并双方签字确认，通过标准化的导师制、新员工指引、新员工培训，每个月进行标准化的月度总结考核，及时指正试用期间的工作问题，将新员工往团队期望的方向引导，学习公司的文化价值观、目标以及行事准则。可以看出培训新员工具有极高的管理杠杆率，能够不断激发新同事的最佳表现，同时为转正后的绩效评审做好铺垫
这里非常关键的是每个月的一对一面谈有巨大的杠杆率，通常要求导师、项目经理、测试经理以及工作中配合的同事在面谈前向经理人汇总表现情况，然后再进行一对一面谈，经理人通过与新员工的面谈建立了共同的信息基础，以达成近似的处事方式。

11. 老员工能力提升
图十一：老员工能力提升
图十一：老员工能力提升

12. 季度绩效评估
绩效评估最重要的目的是给下属的工作反馈，我们从员工试用期开始就持续在员工的工作反馈，绩效评估的目的主要有两个：

  1. 检视下属的技能，指出下属哪些技能需要增强；
  2. 加强激励力度，让已经达到阶段性预期的下属挑战更高的绩效。

同样绩效评估也需要综合项目经理、测试经理以及工作中配合的同事的评价，绩效评估结果确定后，要求部门经理与下属进行一对一面谈，且当面讲绩效结果告知下属。对于与预期差别太大的同事，长期跟不上团队的发展速度，则只能选择分手。所有的经理人都必须做到客观公正的运用其自身判断力对下属进行绩效评价，每次绩效评估要求经理人搞清楚他对下属的期望，然后再以此来判断下属的绩效是否合乎期望，评估最大的问题主要是由于经理人并没有列明对下属的期望，造成双方期望不一致。由此可以看出绩效评估也成为经理人最具高管理杆杠率的活动。

13. 团队培训
长期坚持团队分享与培训对于业务压力非常大的团队来说非常不容易，但是长期来说培训是提高团队能力的最佳实践，也有助于跨团队之间的专业交流，提高团队的技术创造力。我们团队的培训主要由培训委员会组织，每周固定时间、固定地点举行，风雨无阻。
培训具有极高的管理杠杆率，能够极大的帮助提高团队的工作能力，培训的有效方式是培训内容一定要和团队的行事方式紧密结合。

14. 梯队进阶
公司制定了详细的团队梯队模型，模型从专业技能、综合素质各个指标进行了详细的要求，对于不同梯队往上一个梯队进阶提供了具体的参照指标，对员工在能力方面的提升明确了清晰的标准。

15.质量管理
图十二：质量管理
图十二：质量管理

  1. 统一标准规范：对技术方案、架构分层规范、代码规范、数据库规范、安全规范等都有非常明确统一的要求，每个员工在试用期的头半个月都需要认真研读相关规范，建立统一的设计风格，并通过开发工具进行自动化检验。
  2. 方案评审:在产品业务需求输出后，开发团队的具体组长需要组织技术方案的设计，通过组内评审后提交技术方案评审委员会进行公开会评，并将会评意见提交给项目经理要求修改，对于问题较大的方案要求进行复评。方案评审直接带来的效益是在开发成本最低的时候控制住，避免因为方案缺陷导致上线后更大的风险。且让新老同事能够快速提升技术方案设计水平，加强跨团队业务知识交流，并通过思想碰撞带来技术创新。
  3. 代码评审:开发人员在特性分支开发完成自测后，统一提交给特性组长代码审核，组内审核通过后合并到开发主分支，并申请代码评审委员会进行代码会评，上会评审后对于代码缺陷较大的代码将要求项目经理安排重构，避免上线后造成业务损失或客户体验问题。代码评审让新老同事能够快速提升程序设计水平，加强跨团队技术能力提升与技术创新。
  4. 慢SQL审查: DBA会每周对各个项目的慢SQL进行汇总，并提供改进意见，及时将DB瓶颈控制住，避免造成更大的系统故障。

16. 自动化
技术团队的自动化程度能够极大的提高团队的工作效率，具有非常高的杆杠率，直接影响团队的持续交付情况，在这一块我们技术团队与运维团队、测试团队携手在自动化代码扫描、自动化接口测试、自动化集成部署、自动化预警、自动化故障转移等方面取得了不少战绩，同样也得益于团队在业务不断推进过程中在微服务化重构方面所做出的巨大努力。

二、专题 Q&A

Q1： 技术方案和技术架构怎么分？技术方案和架构评审不是两个委员会么，他们按什么区？
A1： 相辅相成的，我们架构分业务架构、基础架构。评审都归到技术方案评审，人员有交叉的，架构委员会会成立一些虚拟小组负责技术研究
Q2： 如何能保证一个组织的沟通畅通（技术内部线）？
A1： 委员会的工作其实没这么复杂，组织成立后，比如方案评审，每周负责轮值的委员负责与各项目经理沟通，是否有需要评审的项目，或者部门经理指定某些关键的项目要评审，委员负责安排人、时间、地点，准备好资料，到时间，大家准时参加。需要类似评审项目的不同委员会成员大部分不冲突，所以可以错开。评审的前提是统一的标准，统一的意识。
A2： 所以整个团队的职业成熟度还是比较高
A1： 这个过程才是重点
A2： 一开始是方案，然后到代码，后面人越来越多，逐步成立培训。核心是在成本最低的时候控制住。
Q3： 研发后自动化测试先跑，还是人工测试后再跑？
A1： 自己单元测试先跑，集成的时候对老业务进行回归跑自动化
A2： 所以只能是上线后再完美自动化测试，下一版跑上一版的全流程
A1： 对，不可能做到完美，上线时间也不允许，平衡吧
Q4： 自动化测试怎么保证信息同步，可能涉及多个部门上线，我现在就怕一跑起来然后报错邮件就出来了？
A1： 主要是看业务间的服务化隔离吧，磕磕碰碰肯定也正常，一般要求底层先灰度发好
A2： 一涉及人就麻烦，人要自觉主动推不得，核心岗位对人保证可靠就行了
A1： 我们的集成系统、研发系统是自研的，靠人对因素不稳定

三、非专题问答

Q1： 求个助，有没有熟悉单用途预付卡业务的朋友？单用途预付卡在用户购买的时候，支付渠道要收手续费吗；如果单用途预付卡是可以让商家提前把资金提现的，那么，在用户使用单用途预付进行交易的时候，平台要收交易手续费吗？单用途预付卡是一种营销工具还是支付方式呢？
暂无回答

Q2： 有个问题和各位探讨一下，商户给第三方发了一个代付请求，之后商户主动轮询查询该订单状态，极端情况下，订单数据还没落地，查询请求已经到了，这样就会返回订单不存在，一般商户会认为该状态为支付失败。
A1： 商户加个缓冲时间，过了缓冲时间还是查无此订单，再做相应处理；可以定时查，但在缓冲时间内查无订单，忽略，下个定时继续查
A2： 设置订单状态层级，比如未支付，支付确认中，支付已确认，支付成功
A3： 这个问题需要商户兼容，很多第三方实现方式不同，返回订单不存在是不对的。
A2： 要求商户也做类似层级，比如发起请求时商户订单变成了查询中，这时从你方服务获取的状态是未支付，需要告知商户应该保留查询中状态，因为查询中的状态高于未支付
A4： 多次查询补偿呢
A5： 这种时效性不高，隔几分钟后查，把这种当成处理中状态，多次查询。
A6： 依赖于设置超时间隔时间，在极端情况下还是会出现问题，目前我们就发生一次这种情况。还依赖于第三方和后端的渠道约定的时间，感觉就是个循环依赖；目前在考虑状态层级
A1： 根本原因在于你的订单落地性能问题上，订单落不了地，查询又依赖于库，肯定是查无此订单了；比如当你有两个RAC时，下单请求落在了A上，查询请求落在了B上，如果A无法及时落地，B节点查询是查不出来的。
A7： 另外，做好幂等性，让商户原订单号重发交易。
A1： 幂等是一个方案，幂等的本质就是以C代Q

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。