5.1. 用户的经理

在开发一个供内部使用的项目是，组织可能不愿意让你完全不受限制的接触一个或多个用户，却可能让你接触用户的经理。

如果用户的经理不是软件的实际用户，这其实就是偷梁换柱。即使用户的经理的确是软件的用户，但是他使用软件的模式肯定也与典型用户不同。

例如：

在一个呼叫中心的应用程序项目中，开发团队获准接触呼叫中心的轮班主管。 虽然轮班主管确实在使用这个软件，但他们在新版本中想要的功能主要集中于管理呼叫队列和在坐席之间的呼叫转移上。

这些功能对于轮班主管手下的人来说，重要性却很低，但这些人才是该软件的主要用户。如果开发人员不能接触更多典型的用户，他们就会过分关注轮班主管需要的功能，但这些功能很少使用。

有些时候，用户的经理会从中干预，并且出于自负，想在项目中充当用户的角色。他可能承认自己不是典型用户，但他固执己见，认为自己比用户更知道他们需要什么。

在这种情况下，务必小心，不要得罪用户的经理，但是为了项目的成功，在部分围绕他的同事，也要想办法接触终端用户。针对这种情况，我们会在后续的“5.10 与用户代理合作时，做些什么？”专门聊聊如何来处理。

5分钟不等于1分钟

我们下面用一个故事来说明一下，有时候用户的经理是错误信息的来源。

有个内部项目的“用户”是副总裁，他从来没用过这个软件。在他和终端用户之间，还隔着经理层。

在为下一个迭代的故事安排优先级是，他希望开发人员专注于提高数据库查询的速度。开发团队也注意到了这个高优先级的故事，但他们有些困惑。

他们知道应用程序的性能十分重要，所以已经在软件里建立了一个监测的机制：每次执行数据库查询时，它的运行参数、执行查询花的视觉以及用户的名字都会保存在数据库里。每天至少会监测一次这种信息，没有迹象表明性能问题。可是，他们的“用户”仍旧告诉他们，有些查询需要花“多达5分钟”的时间。

在与副总裁会晤之后，开发小组研究了一下查询的历史记录。他们发现：有两个用户执行的查询操作只花了一分钟就完成了。这虽然比所期待的时间要长，但考虑到他们查询的数据、数据库的大小以及执行这种类型的查询操作并不频繁，这种性能是符合预期的。

但是用户已经将这件事情汇报给他们的经理了。之后经理有汇报给副总裁；可是为了让副总裁注意到这个问题，经理却故意说查询花了2分钟时间。然后副总裁又将这个问题反馈给开发人员，为了让开发人员足够重视这个问题，他将这个问题说成了花了“多达5分钟”的时间。

所以，只要有可能，就要通过与实际用户交流来求证我们从用户的经理那儿获得的信息。