了解你的干系人

这个系列是我对《七步掌握业务分析》的读书笔记，作者本人是极为资深的专家，也是IIBA协会的创立者之一。对业务分析领域感兴趣的人，如果不急着去考IIBA认证的话，强烈推荐大家先阅读本书。

第2章 了解你的听众

了解你的干系人要比理解一整套高大上厚而全的需求和分析技术要重要得多。深层次的原因是BA是一个以沟通为生的工作，一旦脱离良好的沟通基础，你的技术再精湛也无法无中生有，满足项目上各个干系人的需求。
另外，本章中有一个非常重要的观点，就是如有必要，针对每个对象单独准备沟通方法和内容形式，以提高沟通效率。说白了就是“见人说人话，见鬼说鬼话”，因为项目做多了，你会发现不是每个人都是懂得理解，倾听和尊重的。
下面会详细介绍，作为一个BA，在项目中，究竟如何沟通，与谁沟通。

1. 与你的干系人建立信任关系
2. 业务分析师与谁一起工作？
3. 平衡干系人的需求

1. 与你的干系人建立信任关系

我一直坚信，在工作中，无论你与对方间有无上下级关系，职权从来不是获取良好合作和信任的重要工具。建立信任关系才是，对待下属，对待同事，对待管理人员同样如是，而信任管理的秘诀则在于：

• 真诚对待对方，不管是正式和非正式的工作场合，都信守承诺，坦诚率直
• 恰当使用信息，保护信息源，不对其产生危害
• 懂得对敏感信息保密

2. 业务分析师与谁一起工作？

大部分的项目里，干系人大多数量不少且扮演的角色不同。而不同角色的干系人，会要求业务分析师采取不同的沟通技巧，沟通不同的内容，以达成完整的需求收集确认的目标。这些干系人角色大部分有以下这些（括号中是敏捷项目中对应的一些角色）：

• 项目决策人或发起人（BO）
• 项目经理
• 其他业务分析人士
• 专家和用户（BO or User)
• 质量保证分析师 (Q&A, Test)
• 可用性专业人士 (UI/UX）
• IT架构师（大规模敏捷框架中：System architecture/Engineer）
• IT开发人员（Development Team）
• 数据管理员/架构师/分析师
• 数据库设计师/管理员
• 供应商

业务分析角色体系

其实在敏捷开发流中，干系人的沟通会变得更加简单一些，因为Scrum在实践敏捷开发时，将各色干系人浓缩成为PO,BO,开发团队以及其他stakeholder，而PO又是需求的代言人，所以不会有传统开发中错综复杂的需求关系。
然而，了解敏捷实践的人会发现，业务分析师在一个理想的Scrum团队中压根不存在，那么又为什么会有业务分析师在敏捷团队中实践干系人沟通技巧这个话题呢？
这个话题可以讲很多，一般我们可以将此种情形下的业务分析师视为代理PO，因为很可能真正的PO来自跨国团队，而这位业务分析师在做本地化的工作；又或者团队中有PO职衔的人，同时参与到了2-3个敏捷团队中，那么这样的一位PO则无法再完整履行敏捷团队中PO的职能，这时候，业务分析师自然而然的成了做PO工作的人。
对哪些干系人，沟通哪些内容，需注意哪些沟通技巧，达到何种目的，以下是整理的一些摘要：

• 项目决策人或发起人

与业务分析师的关系：或许是汇报关系，可以对你的职业生涯产生影响
沟通哪些问题：为什么要完成这个项目？成功的标准是什么？
沟通技巧：过项目摘要直奔主题，沟通时说要点，时刻关注问题——项目是否还会达到增加利润或者减少成本的预期目标？
沟通目的：理解项目的起因和范围，如成本控制或财务目标。

• 项目经理

与业务析师的关系：项目经理管理资源，业务分析师管理需求。很遗憾，大很多时候业务分析师也在扮演项目经理的角色，完成大部分工作。当然，这在小的项目里也是合理恰当的安排。
项目经理推进项目前进，业务分析师在项目前进前需要收集足够多的信息以辅助决策。项目经理创建分解工作包（Work Package），业务分析师完成工作包的特点任务。
沟通哪些问题：项目进度如何？有无缺失的关键信息？是否存在需求的重大变更？
沟通技巧：与项目经理一起站在项目蓝图的角度看待分析问题，提供信息辅助做出决策。
沟通目的：减少因需求不完整或有遗漏导致的返工或需求的重大变更。及时提出并求助项目经理扫除项目前进的障碍。

• 专家和用户

与业务析师的关系： 对分析的业务提供重要和关键信息。
沟通哪些问题：为什么做，如何做，结果会怎么样？业务的关键成功流程，以及为什么有些流程无法奏效。
沟通技巧：如何说服或者引导专家认为——你是和他站在一边的？如何认识这个专家，采取合适的方法引导需求收集？也许你可以试试以下几点：

• 路过他的办公室，观察其工作环境，是井井有条还是凌乱？这会给你这个人的工作的印象。
• 他很受欢迎还是看上去比较孤独？这会告诉你这个人是否容易与人交谈。
• 办公室墙上的证书或奖状？表面专家的工作经验如何。
• 专家以什么样的面貌出现在工作场合中？是否准时出席会议？是否会对参加会议需要的信息提前准备？是否会主动联络同事沟通，跟进问题？他是否在业务领域足够专业，是否乐意接受变革？
• 有没有显示专家的兴趣爱好或者家庭合影的照片？找出共同兴趣和话题，尽力与其建立良好的友谊关系。

沟通目的：尽可能多地获取业务领域的专业知识，业务模式和需求
各种各样的专家：不同的专家类型，要求有不同的沟通方法：
1. 一个不理解员工工作的经理：这样的专家并不具备真正的业务领域的专业知识和经验。这个时候，需要尽快确认谁知道什么？需要知道谁才是真正的专业知识？大多数情况下，开明和诚实的经理会推荐你去找经验丰富的员工引导需求；
如经理不主动告知，则使用不同的方式对同一个问题进行发问，看是否得到相同的答案，或询问例外情况。使用封闭提问，观察他的肢体语言是否有犹豫，或者有大量不准确和模糊的回答。

2. 专家不是真正的专家：如果一个经理将没有太多经验的人分配至了业务领域里，作为专家与业务分析师合作。先别急，安排一个访谈，就像你对其他专家做的一样，评估是否收集到了相关和准确的需求。
有些人会告诉你我不知道，这很好，但很多人会不懂装懂，我们可以使用分析技术来确认这个人真正的知识等级。如观察、查阅他提供的需求文档是否存在漏洞；使用不同方式询问同一个问题，对每个需求通过两个不同的来源来确认等。
一个基于不准确的需求的解决方案不可能产生正确的解决方案，不要怕冲突，只要时机方便，就需要即可将此种情形通过客观陈述事实和细节的方式指出来。也要把担忧告知项目经理，一同着手解决这个问题。

3. 当专家确实是专家：从一个真正的专家那里引导需求的方法，就是准备和重复。不断提醒对方，他们才是真正的专家，而你只是在学习。

4. 痛恨他工作或不愿开口分享的专家：回避负面情绪，重点放在问题上，引导专家理解正式有这些问题，所以项目本身就是在帮助他优化业务。

• 供应商

业务分析师与供应商接触的时间可能在任何阶段，这取决于采购发起人对这个项目的理解。但最好的情况下，是在制定RFP时，业务分析师就参与进来。
通常情况下，人们认为购买软件就意味着更快上线，运行更好，比内部开发更省钱，产品更成熟。然而这些仅仅只是假设， 业务分析师应彻底了解分析业务和解决方案，才能评估购买的产品的真正价值。

3. 平衡干系人的需求

当业务分析师面临多个干系人的需求时，这些需求需要进行平衡，这往往是业务分析师工作中充满挑战并且一定会面临的。只需要业务分析师成为一位很强的沟通协调人，以及共识双赢的建立者。
如何做？如何成为这样的人？
首先，业务分析师必须理解组织的目标和战略，拥有大局观；
其次，业务分析师必须首先明白哪个具体的干系人，或团队，在资助这个项目？也就是说，这个项目的预算是哪个部门出的？谁来签字发起和审阅这个项目预算？
最后，业务分析师需要透彻的理解项目的特定目标，以及项目与企业战略间的关系。

即使不同的干系人在对待项目目标，企业目标的理解上一致，也会有不同的做法和路径。当干系人间的意见不一致，甚至与你的理解不一致时，这个时候，业务分析师一定要完全理解他们的需求，在这之前不要试图改变他们的想法或说服他们，而是使用双赢策略，找寻不同方的共同点和共识领域，以此入手推进解决方案的实施。

当然，也会存在不可能达成共识的情况，这个时候，项目发起人时最终的决策人，其他所有干系人需要理解并接收这个事实。