IT 服务，根本在人

机器人、人工智能、增强现实，当然都很热门。媒体在报道，企业在投入预算，行业会议也在展示。

但我们不妨看看现实。任何技术背后，都有人在支撑：提出构想的人，设计系统的架构师，把想法变成产品的开发者，以及让这一切每天正常运转的服务工程师。

我想谈的，正是最后这一群人。他们很少成为报道的主角，这其实很可惜：服务运行良好时，人们往往意识不到它的存在；出了故障，才会注意到。

一百名工程师，还不等于服务能力

一个常见误区，是以为增加人数就能换来服务能力。签下大合同，再招聘一百、两百、五百个人，就觉得一定能做下来。

事实并非如此。大规模招聘并不能保证服务质量，有时甚至会适得其反。

服务工程师是一门独立的职业，和开发者、系统管理员一样，有自己的专业要求。他既要懂技术，也要能与处于焦虑中的用户沟通；既要迅速判断哪里出了问题，也要如实说明维修需要多久；既要遵循规程，也要判断什么时候现有规程并不适用。

这样的人，不是发一则招聘广告、一周之内就能找到的。即使招到一百名优秀工程师，也还没有形成服务能力——你拥有的，只是一百名优秀工程师。

要把他们组织成真正的服务力量，还需要三个条件。

第一：真正的团队，而不是人员编制

如今，“团队”这个词几乎可以用在任何地方：一个部门是团队，一个项目组是团队，二十个人在同一个群聊里，也被称为团队。

我说的是这个词真正意义上的团队。就像足球队，也像执行任务的特种作战小队：每个人都清楚自己的角色，了解身边的人在做什么，也能在必要时补位。失败由大家共同承担，胜利也属于所有人。

Jon Katzenbach 和 Douglas Smith 在《哈佛商业评论》的一篇经典文章中给出了一个准确的定义：团队由少数技能互补的人组成，他们拥有共同的目标、绩效目标和工作方法，并共同对结果负责（Harvard Business Review，1993年，英文）。关键就在“共同负责”。如果每个人只对自己的工单负责，那仍然是工作小组，而不是真正的团队。

在服务工作中，这种区别一眼就能看出来。工作小组里的工程师，关闭自己的工单就离开了；团队里的工程师，看到同事正在处理紧急的关键故障，会主动加入，而不是等上级下指令。

还有一点，我在实践中反复验证过：在好的团队里，工程师不害怕说“我犯了错”，也不害怕说“我不知道怎么修”。美国学者 Amy Edmondson 对一家制造企业的51个工作团队进行了研究，探讨了团队心理安全感、学习行为与绩效之间的关系（Edmondson，Administrative Science Quarterly，1999年，英文）。这里的心理安全感，是指成员能够坦诚提出问题、承认错误，而不必担心因此受到羞辱或惩罚。在服务实践中，这直接关系到恢复工作的推进。工程师如果不敢承认自己处理不了，就可能白白耗掉几个小时，而客户要为这些时间付出代价。

第二：像时钟一样精准运转的信息生态

再强的团队，如果只能摸黑工作，也会束手无策。

服务团队需要置身于真正运转的信息生态中。这里说的是各个环节相互连接、像原子钟一样精准配合的生态：

• ITSM 系统（IT 服务管理系统）：每一张工单从用户来电到最终关闭，都能在其中得到跟踪，并有明确的优先级、处理时限和流转路径。
• CMDB（配置管理数据库）：能够看清客户部署了什么、位于哪里、使用哪个版本，以及各配置项之间的关联。没有它，工程师赶到现场之前，甚至不知道自己会面对什么。
• 知识库：记录常见问题及其解决办法，避免夜班工程师重新摸索白班一个月前就已解决的问题。
• 通知机制：在需要的时刻，把消息送到应该接手的人那里，而不是无差别群发，更不是事件发生一小时后才通知。
• 监控：在用户发现之前识别问题。

这里最重要的词，是“真正运转”。部署系统，只完成了一半。我见过事后才补录工单的 ITSM 系统，也见过上线时更新过一次、此后再没维护的 CMDB，以及只有三篇文章的知识库。形式上，一样不缺；实际上，几乎什么都没有。

俄罗斯 IT 服务管理国家标准 ГОСТ Р ИСО/МЭК 20000-1-2021（俄罗斯联邦技术调节与计量署，俄文），强调服务管理体系中各环节的关联与持续改进。落实到实践，意思很简单：只要一个工具提供的信息不可靠，整条工作链就可能判断失误。这里引用的是管理思路，并不表示 ATRIMUT 获得了该标准的认证。

第三：敢于负责的管理者

第三个条件最难满足。遗憾的是，在我看来，这也是如今最难找到的一环。

团队需要看到一位真正的负责人，而不只是一个转发邮件的上司。他应当是这样的人：

• 工程师带着问题来找他时，不会把他们当作烦人的苍蝇，一挥手就打发走；
• 关键系统深夜宕机、不能等到早会再讨论时，能够迅速作出决定；
• 不会把责任推给其他部门、承包商，或者一句“事情就是这样”，而是自己承担起来。

我多次见过相反的情形。工程师对负责人说：“备用硬盘不够了，再过一个月就可能出问题。”负责人回答：“以后再讨论。”一个月后，问题真的发生了。到了复盘会上，被追责的却是工程师，因为他“没有按要求上报升级”。

经历两三次这样的事情，工程师就不再来反馈了。反正说了也没人听，又何必再来？负责人因此失去了了解真实情况最重要的信息来源。

Edmondson 的研究也讨论了领导者的辅导行为与团队心理安全感的关系（Edmondson，Administrative Science Quarterly，1999年，英文）。说得直白一些：团队会看管理者怎么做，然后判断哪些话可以说、哪些问题最好不要提。

三者缺一，最终受困的都是客户

只有同时具备这三个条件——真正的团队、有效运转的信息生态，以及敢于负责的管理者——才能建立起真正的服务团队。

拿掉任何一个，整个结构都会开始摇晃：

• 团队没有信息生态支撑，就只能靠个人拼命；原文说得尖锐：这样的热情，可能一年就耗尽。
• 有信息生态却没有团队，就只剩下一套套昂贵、却没人真正用好的系统。
• 有团队、有信息生态，却没有真正的负责人，优秀的人就会逐渐离开，去那些愿意倾听他们的地方。

最终受困的是客户。他付的是服务费，得到的却像抽签：碰上合适的值班工程师，很快就能修好；碰不上，就只能继续等。

好的服务，是客户不需要依靠运气。机器人和人工智能可以为此提供帮助，但能把这样的服务建立起来的，仍然只有人。