技术管理杂谈

人非机器。

我们可以编写一段程序，让机器严格按照我们的预期运行，程序写得好的机器够牛逼的话，能保它跑个几十年无需干预。

但是人不行。

人有别于机器在于他的感性以及模糊的理性。

人会懒惰，会自私；也会追求，会奉献——但这不是无条件的，需要诱因。

人们汇聚到一起，形成了一个截然不同的实体：群众。管理本质是对群众的组织——有组织的群众才叫团队。

未经组织的群众如一盘散沙，虽持有满腔热情，也不过是昙花一现。

就如流水总是落向地面，人在本能上趋于惰性（可能是出于机体的节能诉求），在处理问题上趋向于”活在当下，避重就轻”。想想自己团队中有多少问题是重复出现的，大家黑着眼圈在那日复一日地解决同一个问题。

在团体沟通中，人总是倾向于自我为中心，往往从自身的利益和视角看待问题，加之语言这种天生的模糊理性工具，使得团体的沟通效率是总是那么低下，有时会严重阻碍项目进展。想想自己团队中有多少会议是超过两小时的。

人天生健忘，团体甚是如此。 团体进行的项目除非有专人/组织持续推进，否则总会一筹莫展。团体的热情总是超不过三分钟。今天日本首相去祭鬼，我们气得砸丰田车，明天就忘了；这次会议我们说要对X系统重构，明天便再没人提起。

管理主要解决团队的效率问题： 当前的效率和未来的效率。

技术管理真正的挑战在于，虽然”人非机器”是管理的因，但管理的果却不是把人变成机器（流水线生产）。在技术管理领域，机器化管理或许能提升当前的效能，却不利于未来的产出。

我们要不要做 KPI 考核？

之所以问这个问题的原因在于软件技术管理的 KPI 考核很难做。

就目前而言，软件仍然是个”非标准化”产品——它的每次产出都是创造而非复制，无法像螺丝钉那样通过标准化的生产和检测机制来衡量效益。

进一步说，软件的效益是置后的。软件刚上线的时候并不能体现其价值，其价值是在使用过程中逐渐兑现的。

所以我们无法简单地通过当期产品的产出速度来衡量效益：有可能这个所谓的”高效”是用牺牲未来的稳定性和可扩展性换来的，就像一些公司的”繁荣”是建立在巨额债务上的。

一些公司采用代码行数、千行 bug 率、单元测试覆盖率、线上 bug 数等数据来作为KPI指标。不是不行，但不理想，容易被形式化，而且很容易被钻空子。

KPI 考核的目的是什么？末位淘汰？升职加薪？是，但不全是。

Leader 脑袋里面不能只有”考核”——这是懒政的表现。

最好是将”考核”二字彻底从你的脑海里去掉。然后将 KPI 换成 OKR。 OKR 关键是他这里强调了个 O，也就是目标——这是关键。

很多团队没有目标。

“怎么可能？我们每个月都加班加点做了那么多需求啊！”

那是任务，不是目标。

任务是公司或上级下达的刚性需求，是对公司业务的支撑要素，完成这些任务是每个团队的本分——但这是公司的目标，不能算是你这个技术团队的目标。

比如公司（或事业部）今年一季度的目标是开发一个大客户，且大客户开发属于今年的战略目标。那具体到你这个技术团队，一个硬性任务就是为至少一个大客户完成私有化服务部署和定制开发——但这只能算你这个技术团队的任务（放入KPI中）——作为一个技术团队，不能将这个作为目标。

技术团队的目标要从技术角度去制定——这不是说技术团队的目标就能不顾公司目标而异想天开地定，相反， 技术团队的目标要从技术的角度去支撑公司的目标。

比如公司做大客户开发在技术上有什么难题、有什么提高效能的地方，这是技术团队需要着重考虑的东西。大客户需要做私有化部署甚至要使用他们自己的私有云，那我们能否在技术上支持一键私有化？大客户都有很强的定制化诉求，那我们的基础平台能否支持快速定制化？

这些目标看似跟具体某个月的任务无关，但对于项目的成功以及长久效能提升是关键。

从技术的角度支撑公司的业务，提升工作效能，这才是技术团队存在的价值。

然而，理想很丰满，现实很骨感。大部分中小型公司，迫于生存压力，不得不疯狂地开拓和迭代产品，却又没有足够的资金养活庞大的技术团队，结果是寥寥的几个技术人员所有的时间都被刚性任务占据，除了搬砖，一无是处——但这也不排除另一种情况，即技术团队自己（团队 Leader）把自己定位在搬砖工的角色上了，主动放弃思考。

团队从 KPI 转向 OKR 需要勇气——特别在小型公司人力资源不足的情况下。目标的制定本身就是一项挑战，需要经过深入的思考，对团队、系统以及未来业务的综合考量，还可能涉及到其他团队的配合，需要说服上级以及其它团队支持你的工作（对于不善沟通技巧的技术管理者来说是个不小的挑战），以及承担不确定性带来的失败——相较于这些挑战，上级说 1 就做 1 的策略明显舒服得多。

技术性目标的另一个挑战是其实现过程是探索式的。比如我们的目标是让服务 X 达到 4 个 9 的可用性，为此我们需要实现自动化部署与自我恢复、负载均衡、熔断、限流、健康检测（也就是现在火热的云原生里面的一大箩筐东西）等，这些技术好像都已经有标准化实现方案了，但在实际项目使用中仍然会挫折不断（而不像生产螺丝钉那样让生产十字槽就绝不会生产出一字槽的）。那么在这种探索过程中，如果你用”考核”的思维来管理团队，你会发现要么 KPI 没法设置，要么贡献最大的人却得了最低分。探索的性质决定了 KPI 本身的主观性。

主观的 KPI 会带来一系列问题，如不公平、缺乏说服力、钻空子。

不过，主观不确定性确是人类天生特质。人因理性而别于其它动物，因感性（主观性）而别于机器。

我们一心想用理性框架去框定团队的行为，殊不知 真正让团队保有战斗力的却是感性。真正让红军战士忘我拼命的是对他们眼前黑暗社会的仇恨和对那个他们自己看不到的光明未来的向往。

OKR 的目的在于让团队清楚自己的目标（O）以及届时如何评估该目标是否达成（KR）。

一些管理者挂在嘴边的一句话是：”我不要看你加班的过程，我只要看结果！”虽然这句话有几份道理，却不能作为中层管理者的座右铭——如果一个团队只有过程却没有结果，那要么是过程和目标南辕北辙了，要么是遇到重大阻碍却得不到支援，这是重大的管理事故。

技术管理的主观性可以通过诸如计分卡的形式作为 KPI 补充，计分卡的设计主要记录考察成员的主观能动性方面的表现（需要有事件支撑），作为后面绩效评估的一种补充。另外如果做KPI考核，建议时间维度在季度或半年度，而不是每个月或者一年——季度或者半年一般能完成若干个中小型项目，一些大型项目也能达成阶段目标，比较容易对成员作出较全面的评估。

如果必须进行 KPI 考核，建议考核粒度只到团队不到个人，个人层面由团队 Leader 自主把握。

技术团队的 KPI 考核不但很难做，而且讨论之多、争议之广在传统行业也是不多见的。每个公司有自己的文化和价值观（对于中小型公司往往就是老版自己的价值观），技术团队做不做 KPI 考核（甚至怎样做）往往不是技术团队自己说了算的。就个人观点来说， KPI 并不能给团队带来多大的效率和质量提升。就技术团队的效能和质量来说，有两点最为关键：

过于严苛和死板的 KPI 往往适得其反，特别是跟当月工资挂钩的做法最让技术人员反感，很可能造成人员离职。一些高层管理者（非技术部门）可能觉得这正是他们想要的：通过跟工资挂钩的做法激励那些骨干人员，并淘汰混日子的。实践中这会导致三个严重问题：

一个高效团队的管理者需要进行一定程度的专制。

大家都喜欢谈”民主”，反感”专制”——但这不过是语言的把戏，是为了满足大众的心理需求。

中国自古至今都是专制政体。今天我们叫”人民民主专政”，这是多数人对少数人的专制——如果没了这层专制政体，就会立马变成少数人对多数人的专制。

适当的专制能提高团队的协同性和生产效率，只谈民主没有专制的团队几乎什么事也做不成（印度式的民主）。

但是反过来， 过度的专制会导致团队僵化，Leader 说一，没人敢说二，成员的极度无权感会导致其没有归属感——团队是 Leader 的，不是他们的。

比如团队要有规章制度，这些规章制度一般是 Leader 起草的。

如果 Leader 自己默默写了一份规范，丢给团队说，以后我们就这么办；或者丢给团队去讨论，结果讨论来讨论去，不同的声音全部被 Leader 一一驳回，最终还是按照 Leader 一心想出来的制度执行，这就属于过度专制。这种军事化管理风格并不适合技术管理这种创造型劳动组织。

经过大家讨论认同并定稿后，规范就成了团队的规范，是必须以专制的态度去执行的。假如规范要求需求上线必须经过几道测试流程，并经过哪些人审批，结果张三的某个小需求没有经过必要的测试环节就上线了，这种对规范的破坏必须得到相应惩罚（如通报批评），否则规范就会逐渐被所有人无视，团队也就进入了碌碌无为的民主态。

架构师也要进行一定程度的专制，否则其架构设计便很难得到实现。不过在很多公司架构师并没有足够的权利要求各系统严格实现其架构设计（特别是跨团队时），所以一般只有个性较强势且执着的架构师才能完成其夙愿（或者该架构师善于向上管理，利用上级的权利来行事）。

优秀的Leader能够较好地把握专制与民主的尺度，即让团队保持较高的执行效率，又不扼杀成员的主观能动性。”人民民主专政”是个伟大的制度创新，是一种在民主和专制之间寻求平衡的政体，在做团队管理上应多多借鉴。

团队间也存在民主与专制的问题。我们现在讲敏捷，喜欢搞一个个”自管理”的敏捷团队，但现实中的一个问题是这些团队过于强调团队自身的独立性，不但不服其他团队管，也不服上级管（往往是这些团队的上级也不怎么管他们），这就导致团队间的沟通协作成本过高，过高的沟通成本反过来导致团队间不愿意沟通，所以你往往发现这些团队间大家都做了许多一样的基础功能。

我曾经呆过的一家公司曾组建了一个专门的架构组（或者叫基础设施组）来解决该问题，但失败了。问题出在这个架构组成员和其他敏捷团队之间没有任何有效交集，他们也没有什么权利去管辖其他团队，这个架构组做出来的架构设计有些团队遵守了，有些没有；做出来的基础设施也鲜有其他团队用——因为这帮人只是为了做基础设施而做基础设施，做出来的东西往往不符合业务需求。

一个更可取的方式是从各团队抽调一些技术骨干（或者技术经理，抽调的人要在其团队内部有相当的话语权）组建一个虚拟的架构师团队，这些人在技术上代表了公司的核心，在利益上代表了各个业务团队。这个虚拟团队需由这些团队的直接上级领导。这样一个团队既拥有相当的权利，也代表了实际业务团队的利益，他们做出来的架构设计和基础设施能更符合实际需要。

想想你所在公司的团队间，是不是在实行希腊城邦式的民主？

团队之间存在沟通壁垒。

如果你参与过跨团队项目，就会发现团队之间的沟通协调是件多么麻烦的事情，特别当几个团队不在一个办公地点时。

往往的情况是，团队 A 的张三需要和团队 B 的李四联调某个功能，但李四却被调去做别的事情了，无奈，张三这块得等着李四，而王五又得等着张三。

团队 A 的张三做了个功能模块，而团队 B 的李四也做了个差不多的功能模块。

团队 A 的张三对某数值四舍五入取小数后两位，而团队 B 的李四则是取的后四位，最终导致报表出了一分钱的误差。

……

对于跨多个团队的大型项目，需要成立 专题项目组，从各团队抽调人员组成临时的、项目制的虚拟团队——否则这个项目往往会变成无头项目，没有全程跟进的总负责人。

虚拟团队由 项目经理负责（可能不是全职的，比如由技术负责人或产品负责人兼职，但他需要对整个项目负全责）。另外两个重要的角色是 产品经理和 架构师（架构师也不一定是全职的，比如可能有某个主模块的主程兼职）——这两个角色需要对项目的业务和技术正确性负责。

由于虚拟团队是临时组建的，里面一些角色是兼职的，有些人意识不到自己所承担的角色（比如产品经理承担项目经理角色却意识不到自己应及时复盘项目进度以及潜在的资源配置问题），同样会导致无头项目风险。没有清晰角色定位的团体不叫团队，团队组建者（一般是上级领导或上级领导授权的某人）在组建团队时一定要公开声明里面关键角色人选以及（更重要的）其职责范围。

正是因这些全局性的关键角色存在，虚拟团队才能打破团队沟通壁垒，使得项目组成员之间达成整体的认知和一致的步调。

虚拟团队中的成员处于不稳定态：一方面需要关注本项目组的事项，另一方面又要关注原物理团队的事项，经常会出现工作穿插（在人力资源紧张的小公司尤其如此），这种穿插经常让人无所适从，使得团队成员怨声怨气。另外由于在归属感上虚拟团队存在先天劣势，这使得虚拟团队的管理人员必须更加强势才能维持这个团队的团结态。为了使虚拟团队”实体化”，也为了有意让成员从原物理团队隔离开，虚拟团队经常会闭关到”小黑屋”里（特别是在项目冲刺阶段）——这种隔离使得虚拟团队成员间的沟通成本降到最低，也使得他们和原团队间的沟通成本大大提高。

有那么一群技术管理者，他们总是团队中”最忙”的那位，每天加班到最晚，线上出问题永远是他们在处理，每个月的任务项也是他们最多——总之，事无巨细，能他们自己干的就绝不让其他人干。奇怪的是，他们的团队总给人杂乱无章感，事故频出，每次绩效也并不高。

很多技术管理者并没有完成身份转换，所有的时间都花在具体任务执行上而缺乏思考，对团队缺乏组织，团队的各项事务也没有人去跟进，团队成员遇到了阻碍也没人去协调，系统的顽固性 bug 也没人去思考去重构。

他们认为只有敲代码才是实在的工作，其他都是虚的。

有两件事情值得我们去思考：重要而不紧急的事和紧急而不重要的事。 团队 Leader 一定要花很大一部分时间去思考和处理重要而不紧急的事情，而不是整天在那救火。

其他人关注当前的效率，Leader 要更关注未来的效率。

团队中每个人的特性是什么，需要将哪些人培养成团队骨干和接班人？

当前的系统存在什么样的问题，为什么会存在这些问题，得安排在什么时间怎么处理这些问题？

之前的迭代暴露了什么样的问题，当前的流程规范是否要做改进，怎么改进？

就未来公司发展来说，我们团队需要提前做哪些准备？

上午张三抱怨说团队 A 的那个李四负责的模块毫无进展，他推不动了，我是不是得去看看？

王五的代码水平怎么样，是不是要去瞅瞅他写的项目？

这周带大伙去哪里浪？

……

技术团队的灵魂是技术性——技术本身就是点燃团队热情的星星之火。

有人谈论团队文化，更多是从”道德”层面（公司层面）去思考某某团队应该要有什么文化，比如”客户为先”、”奋斗青年”。

文化是自内生发的，而不是自外加冕的。

诸如”客户为先”可以作为技术团队的行事规范，但不能作为技术团队的文化内核——除非他们是技术支持团队。强加外部属性作为其文化内核，会让团队成员觉得受到了忽视（甚至是歧视）——想想让销售团队天天喊”我们是一群技术极客”，他们会是什么反应？

文化一定是来自团体众人的自有属性。技术人员的自有属性就是技术。对技术的热爱使得他们进入这行（至少起初是这样），技术性的产出会让他们获得至高成就感。

缺乏技术氛围的技术团队没有灵魂。没有灵魂的团队很难做出优秀的东西，他们日复一日上演着一出出悲剧。

技术 Leader 的一个职责就是想方设法打造团队的 技术氛围。

技术分享会应该作为团队日常事项的一部分。分享会的目的并非是让大家掌握到什么高深的东西——一两个小时能讲个啥——而是调动大家的技术热情，以及开放分享的心态，同时也能作为日常繁忙事务中的一杯调节剂。

分享会可定期或不定期举行，最好不要限制范围（有些公司会软性限制需和公司业务或技术栈相关，这会让人感觉功利性太强而失去兴趣）。

分享会一般在全公司范围举行（当然也可以团队内部进行，因为有些人觉得自己分享的内容平平，不想在大范围内表现）。

为了鼓励大家参与，可以有些奖励机制，如可以为考核或升职加分。

另外 Leader 要对团队提出较高的技术要求，比如代码审核，对代码的质量作出要求；压力测试、渗透测试等，对系统质量作出要求。

在每个月的任务项中，要安排一定比例的技术性任务（如系统重构、基础设施建设、顽固 bug 处理），这些任务相较于日常业务型任务具有更大的挑战，更能锻炼人，也更能调起大家的兴趣。

有了技术氛围这个火种，才有可能去追求第二种特质： 业务氛围。

大部分的技术团队都属于业务团队，大部分的开发工作也是在开发业务系统，但并不是每个人都对自己团队负责的业务非常熟悉。有些人可能常年只负责某个模块，连完整的业务闭环都摸不清楚。

业务型技术团队对业务的漠不关心是团队的另一个悲剧。由于对业务缺乏进一步探索的热情，很多人一直呆在一项业务的某一个环节上，对业务流程只见树木不见森林，在做系统设计时便无法顾全大局——这种情况在按功能（而非项目）组织的团队上尤为明显。比如储值卡业务，涉及到制卡、储值、消费、车队卡、家庭卡等，制卡、储值和消费还涉及到不同的入口（如手机、POS 机），这些环节可能都是由不同的人维护的，如果他们对储值卡业务根本不感兴趣，便没有动力去了解整个业务闭环的每一处细节。

对业务漠不关心的原因多方面，比如该业务并不赚钱，属于公司的边缘业务；又或者这个业务系统是历史遗留下来的，不是亲儿子，而且 bug 超多；还有可能是大家压根不知道有多少人在用这套业务系统。

Leader 需要让大家知道团队负责的业务的价值，比如某业务上个月赚了多少钱，某 App 这周下载量上升了多少等。人们不会对没有价值的东西感兴趣。

对于历史遗留系统，团队应有较明晰的计划去解决其遗留的顽固问题（当然如果这些问题不影响使用，不给大家的日常生活造成困扰（无休止的bug），则另当别论）。

只有当团队对业务感兴趣了，才有可能追求第三种特质： 服务氛围——只有大家有面向客户的意识时，”客户为先”才不会仅是一句空话。

技术氛围、业务氛围和服务氛围是递进关系，越在前面的越基础也越重要，技术团队可以没有服务氛围，甚至可以没有业务氛围，但唯独不能没有技术氛围。

注意这个顺序和公司层面的追求是相反的，公司层面一定是服务（客户） -> 业务 -> 技术。正是出于这方面原因，很多公司不能理解技术团队的特质，无视技术团队的现状，强行要求技术团队和公司层面保持一致，在技术团队中大力推行诸如”客户为先”，让技术人员觉得公司压根就不关心技术团队的死活。

Original: https://www.cnblogs.com/mq0036/p/16545494.html
Author: jack_Meng
Title: 技术管理杂谈