分类: 敏捷

优秀离岸BA的“十要”,你做到了几条?

离岸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在对客户需求深入理解的基础上,选择合适的技术方案,创造出客户未梦想到的功能,从来带来全新的用户体验。

Share

发表评论

评论