读《用户故事与敏捷方法》有感(三)

　　对于一个项目来说，客户团队里包括一个或多个真是用户是及其重要的。虽然其他人可以猜想用户如何使用软件，但事实上，关键往往还在于实际用户。遗憾的是，我们很难有机会与实际用户一起工作。例如，我们在开发一个广泛通用的产品，用户编辑全国各地，但我们没法也不适宜把一个(或多个)用户带到现场，与我们一起编写故事。或者我们正在开发一个给公司内部使用的软件，但被告知我们不能与用户一起讨论。我们期望与尽可能多的用户接触，这些yoghurt代表了产品的不同角度，当我们无法接触到他们时，我们就需要求助于用户代理，但他们在项目里代表着用户。

　　选择合适的用户代理对于项目的成功至关重要。我们要考虑潜在用户代理的背景和动机。有营销背景的用户代理识别故事的方法，不同于由领域专家担心的用户代理。重要的是要认识到这些差异。接下来，我们会探讨有时代替实际用户、不同类型的用户代理。

　　在开发一个供内部使用的项目时，组织可能不愿意让你完全不受限制地接触一或多个用户，却可能让你接触用户的经理。如果用户的经理不是软件的实际用户，这事实就是偷梁换柱。即便用户的经理的确是软件的用户，但使他使用软件的模式肯定也与典型的用户不同。例如，在一个呼叫中心的应用程序项目中，开发团队获准接触呼叫中心的轮班主管。虽然轮班主确实在使用这个软件，但他们在新版本中想要的功能主要集中于管理呼叫队列和坐席之间转移呼叫上。这些功能对于一个轮班主管手下的人来说，重要性却很低，但这些人才是该软件的只要用户。若开发人员不能接触到更多典型的用户，他们会过分关注轮班主管需要的功能，但这些功能很少使用。

　　有时候，用户的经理会从中干预，并且处于字符，想在项目中充当用户的角色。她可能承认自己不是什么典型的用户，但她固执己见，认为自己比她的用户更知道他们需要什么。当然，在这种情况下，务必小心，不要得罪用户的经理。但是为了项目的成功，在部分围绕她的同时，也要想办法接触终端用户。针对这种情况，我们要知道，在产品公司里，客户团队来自市场团队。来自市场团队的人经常是不错的用户代理，但他们通常关注于软件的功能数目，而不是质量，这点必须要客服。而且领域专家可以成为优秀的用户代理，但必须避免一点：在为产品编写故事时，将产品开发成只适合那些与他们水平有相同水平的人使用。