一、对于个人：技术与管理的权衡

个人来看，技术能力和管理能力的提升都是需要额外花精力学习和实践的过程，用一句老话来说就是：两手都要抓，两手都要硬，但是鉴于每个人优点和缺点的不均衡性，目标可以降低为技术最好的管理达人或者管理能力最强的技术达人。

管理和技术一样，都是要讲求知行合一的过程，通过大量的阅读或培训以及逐步实践，才能逐步实现管理能力的提升，个人以为重点在三方面进行提升：

培养个人魅力，提升领导力：在带领团队奋斗的过程中提升领导力；通过阅读相关书籍、参加培训等方式形成系统的知识体系，通过科学的方法论，提升自己的领导力。

具备持续打造优秀团队的能力，学会放权：平衡“极致”与“苟且”，不对他人能力做超前预设，而是通过实际情况考察，对架构及编码保持一定的容忍度。

根据实际情况判断，学会定方向：要具有融合企业目标和团队目标并可以贯彻执行的能力。

首先要明确定位，技术人员的成功属于个人，技术管理人员的成功大部分属于团队。身为团队管理者，应该以团队为服务对象，KPI来自团队，工作内容也要依靠团队成员共同完成，“放权”是必要的。

其次，技术与管理的关系不是非此即彼，而是相辅相成，两者都是为业务服务。技术人员拥有优秀的技术能力并愿意分担精力做管理，从而成为了技术管理者，技术管理者是意愿的产物，并非是年龄与资历的叠加。有了管理意愿后，通过学习相关的管理课程，并结合实践形成一套可行的管理方法论，带领团队向前。

团队工作的交付速度与质量，如何衡量？

业界其实都有成熟的定义和衡量方法，尤其是如今70%的公司都开展DevOps建设后，基本就只剩细节上的差别了：

交付速度，可以用单位时间内的需求交付数量，即需求交付的吞吐量，但是需求实际上存在评估风险，功能的简单升级和新功能研发其实都是需求，但是耗费时长实际上可能存在千差万别，所以要有一套需求的折算公式，例如一个新系统建设到底会产生多少个小的需求线，从而进行折算，才能对团队工作的交付速度进行较为准确的衡量。

质量一般用交付后缺陷密度和过程缺陷密度来衡量，从业界来看，交付后缺陷密度的折算比高于过程缺陷密度。除此以外，我做技术管理时还建立了五维质量评价模型并申请了专利，涉及可测性、可维护性、可靠性、安全性和代码重复度，这样就可以包含对技术栈的处理，对程序质量进行更好的评价，同时也可以预估技术风险，为修补风险做准备。

五维质量评价模型：我们有多套工具将数据利用起来，例如DevOps，我们通过Sonar、pmd等一系列工具对数据进行处理。对于可靠性，我们是将被认为是bug的东西通过单元以及代码折算比进行处理。除此之外，我们还会通过RNN学习模型对参数进行调优，保证实现应用每个维度的横向对比，同时实现自身趋势的提升，根据趋势变化情况决定其优劣情况，其他维度与该维度类似，不再做过多赘述。

我从DBA团队角度谈一下交付质量和交付速度的问题。根据我个人的理解，交付效率的提升建立在交付质量较为良好的基础上。对于我们数据库运维团队，我们交付的线上数据库的一些产品或功能点，会对线上业务的稳定性产生很大影响。所以我们交付业务需求时，更加注重交付质量，速度可以慢一点，但是质量一定要保证。所以对于交付质量，有一个重要衡量指标，即一次性成功率。在质量满足要求的前提下，我们主要通过工具和平台来提升我们的效率，而不是让每个人更加熟练线上操作。

多数创业公司迫于流量和收入，只能以交付效率为先，交付质量为次，两位老师如何看待这一问题？

创业团队更加局限于快速迭代满足用户需求，这一点可以理解。但过了这一阶段后，技术负债可能会越来越长，以至于到某一天我们不得不停下新业务，重构我们现有的代码，我们的技术管理者在哪一阶段介入，做好效率和质量的平衡，这一点需要我们持续思考。

根据个人理解，这两方面并不冲突。如果创业团队学过敏捷就会发现，Scrum就是在敏捷迭代过程中持续演进的管理方法。我认为创业团队应该先根据需求做出一个“行走骨骼”也就是最小的需求集，再通过最小需求级的不断迭代快速满足创业公司上线的需求，进一步快速得到投资。因此实际上这两方面并不是一个对立的过程。

如何降低团队人员的流失率？

团队成员在公司内的发展，我认为分两个方面：

一方面是公司能够为他提供什么，是否满足他的需求，这一方面主要体现在工资待遇上。在公司除了拿到符合个人能力的工资待遇之外，我觉得更重要的是通过快速吸收公司的业务或技术带来额外的个人能力的成长。

另一方面是技术氛围或团队氛围，这是需要管理者去持续创建的。在一个公司或一个团队内，如果大家的工作是比较和谐的，具有团队精神，团队协作能力较强，那么每个人都会工作得比较开心，可能离开的念头会比较少。

所以如何让团队成员能够持续地成长和持续地开心，是我们需要去考虑的两个方面。

银行人员的流动性是比较稳定的。

一方面虽然银行的收入比互联网低，但是银行人员工作的满足感实际上比互联网公司高，主要来源于业务成就感。我认为在物质基础一定的情况下，精神激励是非常有用的帮助。

另一方面强调团队氛围以及个人的成就感和满足感，这是团队稳定的重要因素。

其他的主要是金钱方面的问题，有了钱就会比较稳定。

严格与宽松，如何设定团队考核和奖惩机制？

工行目前采用OKR，即除常规工作正常完成以外，根据制定的亮点性和挑战性工作的完成情况在考核层面进行倾斜，交付质量等制度因素都会作为惩罚依据，有理有据，不要挫伤积极性，避免多做多错和不做不错的陷阱。同时做好教练式辅导，与团队成员进行面谈，通过信息的传达确保大家不会产生抵触，并在未来进一步提升和改善自身。

首先明确基本原则，哪些事是被认可的，哪些事是不能触碰的红线，限定做事空间的上限和下限；其次在工作过程中树立榜样，具象化我们的要求，给其他成员具象化的信息参考；在考核时重奖励轻处罚，给团队成员试错的空间，使其积极发挥主观能动性。

“管小团队适合从严，管大团队不能太严”，如何看待这一说法？

我个人认为这个说法是不合适的。我们首先必须有一套红线准则，无论大团队还是小团队都应该在线范围内，也就是大家的活动空间内进行处理。其次如果管理小团队太严了，团队成员都跑了，小团队存在不下去了，那么管理毫无意义。因此管理应该合理合法，让团队成员开心，做事有成就感，才是带领团队最好的方式。

如果技术管理者不事无巨细地管理，如何保证团队成员的执行力？

从个人精益的角度说很难事无巨细地进行管理。首先应该树立结果导向，结果完成是最优先级的，然后将每一过程划分成多个阶段，每个阶段我们有一个里程碑的销务和一个时间表，这个工作可以由项目经理帮你管理和完成。因此我们要善于任用专业的人，而不是自己一个人包揽所有工作。

其实我们在安排任务和定OKR阶段就已经确定了每个人身上的指标和任务。同时我们团队是每一个人去做自己的OKR，在年初的时候我们就会制定月度计划等，并在年终进行回顾总结，在目标制定完之后，我们基本上每一个月会做一次过程的跟踪，比如我们的指标现在已经到达什么程度了，原来我们计划5月份到哪个点，实际上它是否到达，在这个过程中遇到了什么问题等。当我们与团队成员对我们的OCR进展时，这些信息是同事能够反馈出来的，也是我们能够掌握的。通过这种方式，我们能够及时了解到当前各项事务的进展以及团队成员遇到的问题，及时介入和为团队成员提供帮助，这是我们现在任务的一个管理方式。

如何安排团队做日报、周报、月报等形式的工作汇报？

我们做得比较少。首先知识工作者并不是计量的流水线的工作，有些工作短期内无法出结果；其次这种工作会影响团队成员的工作感受。我们团队会有周报，但是周报的目的也并不是考核或者了解成员一周的工作情况，我们更多的是每个月进行一对一的沟通，了解OKR的进展并跟进具体的事项。

我们没有日报、周报的说法，只有月报的汇报材料，但月报也是属于基层管理者的汇报工作。平时我们主要从四个方面做工作管理：

第一，通过纪要对团队成员的工作进行跟踪，每一条纪要规定了大概的工作量。

第二，每周会开一次例会，一方面是将上层的思维进行向下的传递，另一方面查看团队成员是否在工作中遇到问题，进行改进和分享解决方案，避免出现更多纰漏。

第三，月报主要是希望把一些工作的亮点进行展示和汇报。

最后，在合适的时机进行合适的汇报。如果一项工作完成的成果非常好，并且对业务非常有价值，通过汇报可以将自己做的事情充分展示出来，使领导对其有更好的认识。

如何应对团队内的“程序员35岁危机”，引导员工做好职业规划？

我认为正确的应对之道是持续完善和展示自己的能力，使自己更独特，比如专利数量、领导力强、设计能力强、问题解决能力强、主动承担更多的工作等，用现在流行的话说就是卷自己。我面试时面过一些35岁的高级程序员，对技术不做深究，对架构不做总结，仅仅保持安排什么做什么的工作习惯，那么就很有可能被社会淘汰，因此需要加强自身的危机意识。

个人来看最适合的还是教练式辅导，通过富有技巧性的提问和结构清晰的流程帮助被辅导者释放潜能，增加认识，承担责任，使其持续做好职业规划。我喜欢和团队成员开诚布公，透传不对称的信息，诱导其思考自身优缺点和后续改进方向，以及未来的成长目标，从而做好职业规划。

在我看来，如果自身不成长，那么任何时间点都是有危机的。以之前看到的新闻为例，高速收费站36岁员工因为被裁大哭，称找不到新工作，他们的危机在什么时间出现，取决于收费站什么时候撤。所以对于这个问题我的看法是，在年龄更大的情况下，每个人需要具备更强的差异化的能力，以应付和解决更复杂的问题，给团队带来更多的价值。如果当我们35岁时，还在做25岁就能解决的事情，那么35岁一定是个危机。

我们团队也有35岁以上的成员，我们会根据每个人的特长或业务工作诉求，给他们安排更加有挑战性的工作，让他们能够在这个岗位上发挥出自身独特的优势。

还不到35岁就面临被裁危机，且目前就业难度高，如何进行调整？

如果自身优秀，那么无论哪个岗位都适合就业。从现在来看主要有三类：

一是从大厂出来的，如果愿意承受降薪的处理，也可以享受一个较为轻松的工作。

二是小厂出来的，需要看自身的技术能力是否过硬。如果自身技术能力过硬的话，也能够找到不错的工作。

三是高不成低不就，如果自身工作能力不强，但是预期较高，那么建议调整一下预期或者使自身成长为与预期相匹配的程度，也能够解决就业危机。

高不成低不就时则很容易产生焦虑，我期望很高，但是个人能力没达到。首先需要了解当前的就业形式，比如可以通过找几个猎头聊一聊了解岗位的工作情况，需要具备什么工作能力，再与自身进行对比，了解自身不足并改善，从而解决就业问题。

作为管理者反向思考，基层人员应该如何向上管理？

第一，做好工作，展示亮点；

第二，做好备份，保护自己；

第三，做好总结，改善自己；

第四，积极学习，提升自己。

做好以上四点，无论是向上还是向下都是相通的。

每个技术管理者能够做到这个岗位上，基本上都有一双火眼金睛，能够看到团队成员的工作程度或工作亮点。因此基层人员不需要刻意地进行向上管理，比如不需要刻意地通过写好PPT使老板了解其工作内容。

如何进行高效的跨团队或跨职能协作？

我认为可以通过四方面进行提升：

确定共赢愿景和目标：使彼此目的一致，在共赢的情况下团队成员才愿意积极地配合。

落实协作工具和技术：比如通过腾讯会议开会，快速解决问题，当出现问题偏差时，需要快速将其扭转回来，避免会议冗长，同时需要一些其它的技术支撑。具体的协作工具有用Sourcegraph建的知识库、Wiki工具Confluence、共享DOC，便于共同编辑，促进理解；交流工具有钉钉、微信以及我们自己的沟通系统。从沟通层面到知识共享层面有一个完整的底层支撑，那么对于大家进行协作是非常有积极作用的。

鼓励知识共享创新：不同的团队之间可能会遇到相同的问题，通过共享能够避免犯相同的错误。

做到有效沟通：比如有些人喜欢发邮件，但是可能邮件来回六七次还没有把一个问题说清楚，这种情况下我建议直接打电话，或者面对面解决问题，最后再写一个会议纪要，把落实情况发给大家，提升沟通效率。沟通不要流于纸上，为了达成共赢的目的才是我们沟通的本质。

将以上四方面做好之后，跨团队或跨职能协助其实并不是问题，因为大家都愿意把工作做好。

如Confluence、共享DOC等工具我们团队也在使用，而且团队越大，对这些工具的依赖则会越重。由于我们的分公司位于多个城市，因此我们公司的电话视频会议是做得比较完善的。

首先两个团队或者多个团队内，如果有一个共同的利益点，那么是最容易达成一致的，因为大家的目标很清晰。另一种情况是彼此的目标可能不一致，或者我的目标是需要你的团队支撑的，但是并没有排在你的计划里，这种情况一般是我们在最开始定目标的时候没有互通信息。

其次，在遇到上述情况时，我们仍然需要站在更高的维度思考问题，用“没人牵头我牵头，有人牵头我协助”的思维牵引我们进行跨团队或跨职能的协作。

如果往更深入的角度思考，我认为每个企业都会有企业文化，遇事不决时可以代入企业文化，很多问题就能迎刃而解。比如我们做事的方式是否符合公司的价值观，它能够给我们团队或者公司的业务带来什么帮助，整理好这些问题档案，推动彼此达成一致，才能够更好地推动团队协作。

领导力和管理是什么关系，是否有冲突？

领导力是管理必须具备的一个品质，决定的是个人的魅力，通过自身能力的提升带动团队成员的工作即领导力。

而管理实际上是在提升自身的同时通过一些方法论对团队进行领导和组织，相当于方法论的执行。

个人理解两者并不矛盾，而是一个包含的关系。

我认为领导力其实可以等同于非职权影响力，也就是在不需要使用行政手段的情况下带领身边的同事达成一些业务目标，这是领导力的体现。对于管理而言，更多的是职权影响力，也就是站在管理的岗位上，利用一些公司赋予的权利把团队带到某一个水平上。

特别鸣谢