如何和关键/最终用户沟通以及如何应对不断更改的需求——我总结了这三点

今天想来谈谈如何和用户打交道。

在项目实施／需求开发过程中，我们始终都要打交道的一个角色就是业务，也就是使用系统的用户。

用户又可以分为两类，一类是关键用户(Key User)，通常由1～2名专门和IT打交道的业务人员组成，他们熟悉系统操作和业务知识，负责和IT团队沟通需求、需求开发完成后的验收（或组织最终用户验收）、项目上线后对最终用户的培训等。另一类是最终用户，是直接使用并最高频使用系统的用户，通常人数较多且进行执行层面的工作。

我们进行需求分析时，要借助关键用户去了解业务需求，他们的需求通常是经过内部沟通和优先级确认的，因此可信性较大。但如果你遇到的是一位对业务基础不了解、基本的系统操作也不会，因此对IT团队表述的需求一变再变且始终不符合业务场景的Key User，那么你就要“倒霉”了。

我在做上一个项目时，就遇到了这样一位Key Usr。她在各IT 团队风评极差，和我们合作的上一个项目因种种原因上线后也没能推广到业务。而我并没有很好地去适应和改变这种情况，因此那个项目进行得并不顺利。

这就是我想提的第一个问题，遇到不靠谱的“Key User“该怎么办？

我的观点是，找专业的人做专业的事，我们的目标是项目顺利上线而非个人做了多少辛苦活。能使巧力何必绕弯，能够智取何必直攻？

如果之后做项目再遇到这种情况，我会这么做：

1、一旦发现对方不能胜任，尽快找自己的领导让其协调更换，越换越好。首先你要向你的领导证明对方确实无法胜任工作，其次你的领导需要和对方领导沟通换人。如果大家的目标都是为了项目顺利上线，而非部门利益之争、个人功劳之显，这样的沟通我想是受欢迎的。

2、但由于各种原因（对方没有合适的人、我们无法拒绝需求）等，我们还是不得不狼狈地接下这个锅。人可以狼狈，但项目不能狼狈。因此作为IT团队的BA，你要承担起Key User无法胜任的那部分工作：协调各最终用户UAT、用户培训，甚至直接与最终用户确认需求细节。切记：不要把项目主导权交给用户，因为大多数时候用户是没有判断力的。

第二个问题：该不该听最终用户的话？

我的答案是：表面听，心里不听。

表面听。沟通需求时必有分歧，但BA若因为用户需求不断变更，而直接地表现出“抗拒”、“反感“等态度，用户也会被激发出“抵触”的情绪。而当情绪主导会议而非理性时，这个会议的走向就容易失控。同时，闭目塞听是停止进步的直接通道。作出愿意倾听、尊重他们的意见的姿态，以平等、合作、理性的态度进行沟通。我知道这很难，“杏仁核绑架”的力量过于强大，但你必须做到。

心里不听。最终用户是执行层面的角色，其所处的位置决定了其看问题的视角。是更聚焦于交互细节还是更关注项目顺利上线？是不断地抛出更改后的业务需求还是支持把主流程跑上线？

BA心里需要有杆称，不要被业务牵着鼻子走，但也不表示BA可以充耳不闻、阳奉阴违。作为需求接纳方，在管理需求时就需要按重要紧急程度分类，哪些是一期不上产线就会停工的，哪些是有Deadline的，哪些是并不紧急的优化类。

第三个问题：如何应对不断变化的业务需求？

现实世界远比代码世界更复杂。对于一个正处在疯狂生长期的公司而言，其业务的多变、复杂、难以梳理是必然的也是正向的。如果业务需求一成不变，这个公司就失去了生命力了。

但对IT团队、对BA而言，这就不是个好消息了。

我认为，首先要认同业务需求是多变的这个观点。我过去曾受一些影响，故而有个错误的观点，认为“业务提交给我们的需求，必须是明确清楚的、在开发完成前不会变化的。”

其实需求分析、沟通需求本就是个多次沟通的流程，而非业务一次提交，IT一锤定音这样粗犷的过程。BA需要在多轮沟通时，将一团乱麻的需求抽象成一个个用户故事、开发功能点。从多变到不变这个流程，应当截止在BA交付给开发需求文档之前（虽然实际情况很难如此理想）。

关于如何保证沟通的有效性，我建议我们人人都做到这一点：即在每一轮沟通需求结束后都要进行总结，不能浪费掉每次与用户沟通的机会。若双发达成一致，应明确指出（事后邮件）。若未达成一致，也应说明，制定待跟进事项、跟进人、截止日期。以便定期回顾事项完成情况。

今天就到这里，本周任务顺利完成没有Delay，读完了《原则》并整理了笔记，开始阅读《用户故事与敏捷方法》了。下周见。