离岸BA顾名思义就是工作在离岸项目(offshore) 上的需求分析师（business analyst)。离岸交付面临的挑战是很多的，比如语言，沟通，客户关系，客户业务等等方面。作为offshore项目的BA，要把握好以下的10要。
第一: 要和客户建立良好的沟通方式和节奏
离岸最大的问题往往就是沟通问题，有许多offshore项目都有时差问题，比如我所在的美国项目，和客户时差长达16个小时，沟通成了我们的主要问题之一。作为项目的BA兼IM(iteration manager)的角色，和客户保持紧密沟通成为关键。通过沟通澄清需求，汇报项目进度，风险管理等等。只有和客户建立良好的沟通方式和节奏，才能建立客户和团队间的信任，从而保证项目顺利进行。
沟通的方式有很多种，比如邮件，会议，各种即时聊天工具 (skype, slack, asana）等等。不论采用哪种工具，最终目标就是希望能够高效沟通。有了这些工具还不够，要真正和客户保持紧密沟通就需要时间灵活，比如美国项目，和客户时差有12-16小时，有时需要早上7点开会，有时需要晚上11点和客户开会。当然，为了提高沟通效率，我们要尽量避免邮件沟通的方式。对于简单的需要确认的问题，就直接和客户用聊天工具完成。如果复杂问题，尽量book一个时间统一解决。
沟通的节奏需要和客户协商，尽可能在项目之初排出每个迭代的会议计划。比如站会，story kickoff，showcase, story review 都在每个迭代的什么时间进行。如果客户时间允许，和客户的站会最好每日一次，风险评估会议最好每周一次。story review次数尽可能多，如果客户比较忙，那么就固定时间进行批量story review。
第二：要高效利用和客户每次开会的时间
由于时差问题，和客户开会的次数是比较有限的，所以需要提前做好充分的准备，高效利用每次的沟通机会去澄清需求，汇报进度，风险管理，分享反馈等等。
比如站会（standup) 不能采用传统的方式，客户并不关心我们每个人每天具体做了什么，而是关心每个迭代完成程度和我们遇到的困难或提出的问题/风险。我们可以利用站会的时间确认优先级，反馈问题，预报风险，甚至可以就关键的需求问题在站会上讨论。
第三: 要尽早分析需求和讨论设计方案
在敏捷开发中，BA的最终输出是story。在写story之前，要经过需求分析和详细设计，这中间需要多次和客户沟通才能完成。而且由于在讨论设计方案时往往会出现不同意见，需要经过几次修改或者讨论才能最终和客户达成一致。所以从分析需求到输出story，这中间可能要经历好几天，甚至几周的时间。为了不影响团队的开发进度，一般需要提前至少两个迭代周期开始分析需求和提供设计方案。
如果跟客户时差比较小，并且一天之内有多个机会和客户沟通的话，那么需求分析和设计的周期会短一点。但如果时差有16个小时（客户在洛杉矶），那么每天能够沟通的时间很可能只有一次。所以建议沟通细节需求之前，先根据大的需求画出线框图（wireframe)，这个线框图体现了你的设计思路（包括对需求的理解），用这个线框图去跟客户聊会效率高很多。
第四：要及时确认以防止沟通失真
在沟通需求的过程中，需求信息通常要经过用户代表，产品经理，需求分析人员，设计人员再到开发人员，在这个信息传递的过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。为防止沟通失真，要进行及时确认。
比如当客户阐述了需求之后，BA当场再用自己的语言重述一遍。如果和客户讨论的要点比较多，会议之后要发邮件总结确认的需求，进行再一次的确认。
第五：要有效控制需求变更
需求变更频繁是困扰无数软件开发团队的恶魔之首。从需求变更的根源来看，一是因为BA在捕获需求时信息不全面，二是确实是业务变化了。我们应该尽可能避免犯错误，同时加强对需求变更的预测。尽管需求变更是不能避免的，我们还是要想办法控制变更，控制变更的的目的是减少变更对开发工作的影响。可以从以下两个方面来有效控制需求变更：
- 在进行需求捕获时，对于客户提到的未来可能的变化要引起重视，并且把这个重要信息记录在story里面供开发参考。如果忽略这个可能的变化，有可能会造成返工甚至要推翻整个技术框架来重做。
- 对变更进行集中处理，选择正确的评估者对变更进行评估，分析变更对技术，项目带来的影响，并且确定优先级。比如如果客户说让我们改一个功能，我们不能立刻就去改。首先应该新建一张story卡，然后评估一下需要几天完成，跟客户确定优先级，最后把这张新卡排在某个迭代计划中。
第六：要善于借助团队成员的力量
在遇到比较强硬，难说服的客户时，要善于借助团队其他成员的力量来解决问题。
比如客户坚持某一个设计方案，但是这个方案的开发代价比较大。这个时候就需要拉上技术骨干和客户一起谈，帮助客户理解技术难度，同时给客户提供其他几个effort小的备选方案。
再比如，客户提到的方案技术实现没有问题，但是用户体验明显不好，这个时候BA除了自己propose几个方案以外，还可以和团队一起进行一次头脑风暴，争取找到最佳解决方案。
第七：要深入理解客户的业务
对于Offshore项目我们往往拿到的都是客户加工分析过的需求，根据这些需求，我们负责拆分story，完成详细设计。BA对于客户提出的需求要多思考，理解用户需求背后的业务场景，这样才能设计出对用户有价值的产品。不仅如此，平时还要注意积累客户的行业知识，深入研究客户的业务，这样才能给出客户更加有建设性的建议。
举个例子，在我们设计一个Tag功能时，很多网站的实现都是不区分大小写的，也就是说当用户输入一个大写ABC的tag时会自动转存为小写的abc。但是由于客户是医疗行业，有很多大写缩略词汇作为tag，这个时候如果自动变为小写显然不合适了。
第八：要定期和客户要反馈
我们常说要“知己知彼”，那么客户“对项目进展、产品质量是否满意”，“客户有没有其他期望或者是担忧” 诸如此类问题，我们都要定期地和客户进行沟通，了解客户的态度，识别潜在的风险，做到随时和客户保持一致。
有些客户如果你不问反馈，他几乎是不会主动给你说的，但是客户心里可能对某些事情已经有些不满了。为了避免未来可能的发生的冲突，也为了未来更好地合作，需要定期和客户开个小会聊一聊，我建议一个月至少一次。
第九：要管理好客户的期望
判断项目是否成功，是由客户说了算，要看是否满足的客户的期望值。而客户的期望是可以管理的，这里有几个小技巧：
- 要知道我们能做什么
- 要了解客户的期望，并且将这个期望分享给团队成员
- 不要轻易给客户许诺
- 定期汇报进度，预报风险
第十：要善于利用技术为客户创造全新体验
客户对技术解决方案永远都不是最擅长的，因此他们无法构想出对其工作产生变革性的解决方案。这就需要BA在对客户需求深入理解的基础上，选择合适的技术方案，创造出客户未梦想到的功能，从来带来全新的用户体验。
