IT 角色：生产力与可用性

作为 IT 管理者，我们面临着需要应对两类截然不同的技术专业人员。区分这两类专业人员的，不是他们的性格类型或工作方式，而是他们工作角色的本质属性。理解这两种工作类型各自独特的需求，对于有效管理技术工作者至关重要，但鲜有 IT 部门真正花时间去理解和体会这两种不同工作角色所固有的细微差别。

第一类，也是目前为止被理解得最透彻的一类，我将称之为“工程师”。这个工程类角色涵盖了极其广泛的工作职能，从软件开发人员和设计人员、架构师、系统工程师、网络工程师，到任何其主要职能是创造性地设计或实现各类新系统的人。“工程师”这个术语含义宽泛，但相对而言是有意义的。

第二类技术工作者角色可以笼统地称为“支持”角色。支持类职业可能包括服务台、系统管理、桌面支持、网络监控、指挥中心等等。将支持类专业人员与工程类专业人员区分开来的是，他们的任务并非涉及新设计或新实现的创造性流程，而是与现有系统打交道，确保这些系统正常运行，并在出问题时迅速修复。

不言而喻，现实世界中不太可能有哪个真人会完全只属于其中某一类，但 IT 中几乎所有工作职能都极为偏重于其中一类或另一类。可以相当有把握地假设，几乎任何角色都会异常侧重于某一类角色。一个单一职位在这两种角色之间被均匀对半划分的情况非常罕见。

这种角色识别派上用场之处，在于懂得如何衡量和管理技术人员。从很高的层面来看，衡量和管理工程师是相当被人理解透彻的。生产力这一概念对于工程类角色而言非常简单且有意义。管理一名工程人员或一个工程团队的目标，是允许并鼓励该角色尽可能多地产出创造性的设计或实现。当然，质量这一概念同样存在，但我们仍然可以用相对具体的术语来大致思考工程类角色，例如所编写的功能数量、所产出的部署包数量、所设计网络的规模等等。指标是一种模糊的东西，但我们至少对于工程师而言效率意味着什么有一个不错的概念，即便我们未必能够准确地衡量它。

支持类角色并没有这种相同的概念。当然，你可以使用诸如“关闭工单数”这样的人为指标来衡量支持角色的生产力，但那会极具误导性。一张工单可能微不足道，而下一张可能是一项庞大的研究难题。在许多情况下，可能很长时间都没有工单，然后许多工单同时涌来，却无法被同时处理。生产力很可能是零星的、不可持续的，并且归根结底，衡量它毫无意义。

工程类职位是通过在相当长的一段时间内有效地产出成果来体现其价值的，对于大型项目而言这段时间甚至往往延续数月乃至数年。因此，对于工程类职位，目标是提供一个能够鼓励可持续生产力的环境。众所周知，工程师往往会通过缩短或采用替代的工作时间、定期休假等方式来提升生产力。这不仅常常能提高生产力，往往还能大大提升产出的质量。

支持类职位则是靠在需要时“守在那里”来挣得自己那份口粮的。如果一名支持人员试图以最高效率工作，那么其中自然隐含着这样的意味：始终有一批源源不断、积压待办的支持问题等待着支持团队去处理，并且有许多需要支持的人不得不排队等候，从而形成一个队列。由于始终存在一个队列，这也意味着支持人员是在不断地从这堆积压中取下工作，而不是在解决实时事项——要么忽视高优先级事项，要么不断被打断——从而导致持续的上下文切换，这显著降低了高效处理队列的能力——而这个队列存在的全部目的，本来就是为了在一开始制造出一种人为生产力的假象。

支持类角色是“事件驱动”的。我喜欢这个说法，因为我认为它最准确地描述了几乎所有支持专业人员工作所处的模式。无论一个事件是由一通电话、一条即时消息、一封电子邮件还是一张工单所引发，它都是一个“事件”，启动了支持人员从空闲到行动的转变，或者在某些情况下，从一个低优先级事项到一个高优先级事项的转变。无论以何种方式，一个事件对于支持专业人员而言都代表着一次“上下文切换”。没有事件，支持专业人员就无事可做。即便这个“事件”是以工单队列或电子邮件积压的形式呈现的，它仍然是事件的一种形式。

要拥有一个真正高效的支持台，需要对事件流程进行细致的管理。让支持问题排成一个永无止境的队列，对支持专业人员而言是令人精疲力竭的，而且这也意味着，再多的人手也永远不会处于“空闲”状态以待命处理高优先级事项。正因如此，要么高优先级事项没有得到本应有的迅速处理，要么处理中的事项遭到搁置。

理解支持人员事件驱动的本质，对于理解如何着手管理这些团队至关重要。这里没有简单的答案，而支持人员的指标往往比工程人员的指标还要更加没有意义——所以请极其谨慎地使用，但通过体会支持角色，我们可以开始看清，我们作为支持管理者的角色，是如何融入支持和促进支持团队成员这一更大图景之中的。

根据我的经验，最重要的概念，是为流向支持团队的中断提供一个良好的流量调控。支持团队往往要处理若干不同的支持渠道，比如电子邮件和电话。对事件加以限制并将其导向适当的渠道，至关重要。

电话的问题在于，它们咄咄逼人，要求立即进行一次上下文切换，无论接听者是处于空闲状态，还是正在处理公司史上最严重的生产中断。打电话的人是在假定，他们当下的需求压倒了支持人员当前正在支持的对象的需求。无论在何处被使用，电话都会引发这个问题。

想一想你上一次在比萨店柜台点单时的情形。你耐心地排着队，看着每个人依次被服务。你做了正确的事。你来到了队伍的最前面。你正要开始点单，这时，电话响了。为你点单的人把你“晾在一边”，尽管你就站在那里，他拿起电话，接了那个订单，挂断，然后回过头来招呼你。这传递出的信息是：打电话的那个人，作为那只“吱吱作响、会哭闹的轮子”，对这家店而言比真正身处店内的人更重要。这种同样的效应在许多支持台上演——处理中的工作被打到群组线路或直接打给支持人员的来电所打断。这种做法往最好里说也是低效的，往最坏里说则可能扰乱针对极其紧要问题的关键支持流程。

所以，当思考如何管理 IT 专业人员时，请想一想他们角色的目的。工程师的目标是生产力。支持专业人员的目标是可用性。