BA的广度和深度

作者:ThoughtWorks – 亢江妹。未经允许,请勿私自转载。

BA,或者称业务分析师,是企业数字能力和业务能力之间的沟通桥梁。随着企业数字转型的进一步深化,相信对BA这样的技能需求会越来越多,只是未必都用“BA/业务分析师”这样的Title。

ThoughtWorks在创建之初,就有BA这样一个职位。Lupi Messenger是我的一个同事,她是ThoughtWorks的第一批BA,到现在为止做了18年,孙女都已经上小学了,我很仰慕。这二十年间变化很大,需求分析方法从最初的敏捷用户故事,演进到现在精益为基础的需求分析方法,BA的技能要求也在不断变化。整理出一个大家都认可的BA技能图谱,几乎是个不可能的任务——即使仅限ThoughtWorks所要求的BA技能(我在ThoughtWorks是所见的不同时期的BA技能图谱要超过10个)。但所有的表达都是为了交流和学习,不是为了“证明自己是对的”,所以斗胆结合自己的经历,谈谈我心目中ThoughtWorks版的BA技能图谱,并分享一些学习提升的方法。

BA的广度和深度

“在ThoughtWorks做BA是怎样一种体验”中提到,BA的职责是把业务和用户需求转换为软件需求。即使是这样一个单一职责,也会有不同的场景:

  • 8人以下的团队 vs. 40个人的团队;
  • 单一的Stakeholder vs. 跨不同业务部门,庞杂的多个Stakeholder;
  • 面对的需求是简单的工具(如订单自动化上传) vs. 一个复杂的产品平台(如一个新的互联网金融平台);
  • 客户/用户对自己的需求有清楚的认知,并能清楚表达 vs. 客户/用户并不知道自己需要什么,或者知道但表达不清楚;
  • 在一个创业团队上线一个产品 vs. 在一个大型企业里推动产品体系改变

能在左边的场景里做到优秀,是否就意味着在右边的场景下就同样能做到优秀呢?相信大家有了自己的答案。在ThoughtWorks这样的专业服务公司里,我这样看BA的技能广度和深度:

01

图1: 我眼中的ThoughtWorks BA——广度和深度

BA的技能广度(图中绿轴部分)

  • BA所涉猎的行业和领域,比如银行、保险、电信、医药、能源、农业、教育等等;
  • 这里“涉猎”的含义,不是指简单地知道某个行业是什么;而是指如果突然有一个这个行业的项目,规模大概在8人X3月时,能担负起“把客户/用户需求转换成软件需求的”责任。

BA的技能深度:

  • 在某个行业/领域的视野和眼界(图中蓝轴部分),从小到大,依次是应用/系统, 到产品和流程,到企业战略和愿景,再到行业发展趋势和愿景,反映了在行业领域能够把控的深度。
  • 专业上的杠杆领导力(图中橙轴部分):从个人自己的技能胜任,到使能自己所在团队、所在客户、内部实践社区、甚至外部职业社区的杠杆领导力。举个例子,作为BA可能是软件团队里面最多开会的人——“会议王”,会议引导能力很强。那当所处的场景是,40个不同角色不同背景的人要开会做出重大决策和计划的时候,是否能有效识别、激发其中的一些人作为“协助者”,发挥协力在这个场景下把会议引导地很高效呢?这就体现了杠杆领导力。

BA的“生存圈”和“生长圈”

02

图2: 我眼中的ThoughtWorks BA——“生存圈”和“生长圈”

当我们刚入门BA时,相当于是在上图中的原点。图中最内红色的圈是我们的“生存圈”。在“生存圈”中,

  • 我们聚焦的是要交付的应用和系统
  • 我们的核心职责是需求沟通和澄清
  • 我们扮演的“是业务和技术之间的翻译官、解释器”,我们并不被要求去挖掘业务痛点和需求、系统思考全盘分析识别业务优先级,而只是把需求能翻译、解释成技术更理解的语言,帮助需求被实现成为软件功能。

换句话说,在“生存圈”里,是在前面举例的5个左边的场景里,能胜任:

  • 8人以下的团队里,能很好地收集、分解、表达、澄清、验收需求;
  • 单一的Stakeholder的情况下,能很好地与之沟通,把他/她的想法能清晰、准确、有效地传达给技术团队;
  • 面对的需求是做一个简单工具(如订单自动化上传),能清楚地勾勒、描绘用户与之的交互过程、步骤、每一步的输入输出、业务规则,并提供简单的交互设计建议;
  • 客户/用户认知并能清楚表达自己的需求,能有效地捕捉、梳理、表达、管理好他们的需求;
  • 在一个创业团队从0到1开发一个产品,能做用户访谈、理解用户的想法、把软件需求表达给技术团队、并能向用户演示、做用户测试。

跨越生存圈之后,就要在前述的广度和深度上继续拓展、深钻:

  • 拓展行业领域的广度。比如如果已经是熟悉零售,又有银行工作背景,是否可以去拓展下互联网金融领域?
  • 拓展行业领域的深度。比如在保险行业,只是能看到所做的在线自助服务应用;那可不可以拉长视野,在保险企业层面去看如何提升客户体验呢?是否能把自己在线自助保险服务业务上的知识,让全团队各个角色的人、全社区各个角色的人都清楚了解并掌握呢?

BA的技能图谱

BA从“生存圈”到“生长圈”,做到有广度、有深度,成为真正职业的“业务分析师”,我总结有五个方面的关键技能:需求、战略、产品、数据和流程。

关键技能1:需求 – “需求沟通和澄清”

也就是BA在“生存圈”的必备技能,分解开来:

  • 收集业务系统需求
  • 业务系统的流程的As-is和To-be分析
  • 识别需求顺序和依赖关系,构建需求全景图
  • 分析和沟通非功能性需求
  • 需求分解,把大的特性(Feature)拆分成粒度合适的用户故事(User Story)
  • 能应用INVEST原则,细化用户故事(User Story)的详细需求
  • 低保真界面原型以沟通和澄清需求
  • 能做功能演示和验收测试

关键技能2:战略 – “业务洞察和方案”

这是走出“生存圈”之外的一个重要能力,即有战略视野,真正连接业务、用户和技术,在企业级提供咨询建议。这意味着:

  • 能快速进行行业研究,并提供有价值的行业洞察报告
  • 能和CxO对话,建议和销售战略计划
  • 能完成售前解决方案建议书,或提供战略性的建议
  • 能驱动完成大客户发展规划
  • 能帮助客户规划愿景、目标和路线图
  • 能完成市场、用户、和竞品分析
  • 能规划执行的方案、范围、优先级
  • 能发现、提炼案例并分享给客户和外界

关键技能3:产品 – “产品定位和规划”

战略建议到落地层面,往往在于产品的开发和管理——产品机会的发现、启动、从0到1上线、运营增长、并不断演化的过程。具有“产品定位和规划”能力意味着:

  • 能带领完成用户、市场研究
  • 能完成业务模式的提炼和设计
  • 能带领完成产品路线图的规划
  • 能清楚描述用户体验和产品需求全景
  • 能管理产品需求列表及其优先级
  • 能确定并管理产品需求的优先级
  • 能制定产品交付计划、确定阶段性目标及需求
  • 能确定关键需要跟踪的运营数据、并指导如何用数据验证假设
  • 能跟踪和管理产品交付进度
  • 能管理产品上线
  • 能提供运营建议

关键技能4:数据 – “数据分析和建议”

对数据的洞察力,将是未来企业的核心竞争力。如果要能为业务提供建议、做产品规划,其基础之一就是要能做数据分析,“懂”数据:

  • 能帮助企业进行数据的采集、存储的战略和方案设计
  • 能帮助完成数据如何清洗、规整、质量监控和提升的方案
  • 能指导业务场景的KPI指标设计和跟踪框架
  • 能结合业务场景,指导数据分析的模型,如数据的属性、数据来源、统计角度、频度等
  • 能指导数据的可视化和解释呈现
  • 能使用工具进行数据分析,提供洞察,比如进行探索性分析、预测性分析、假设验证分析等

关键技能5:流程 – “决策引导和沟通”

在我前面举例的场景中,如果去思考右边的5个场景,会发现其中需要的不仅是个人的远见卓识,而是能多大程度上有谋有略地引导一个复杂的团队和组织有效进行决策和沟通,这意味着:

  • 有效连接业务、用户、和技术,建立一致的沟通语言,填补沟通漏洞
  • 能指导业务需求管理的流程
  • 能进行Stakeholder管理、提升合作关系
  • 能进行范围和优先级管理
  • 能进行关键流程的设计、引导其解决问题流程、决策流程、冲突流程、需求管理流程等
  • 能高效驱动决策形成
  • 能培训和指导团队的问题解决流程和实践

除了以上所说的5个关键能力,系统思考、沟通表达、研究分析和总结、以及敏捷和精益这些软性的技能则是这些技能的基础。综合以上,BA“化繁就简”的技能树如下:

03

图3: 我眼中的ThoughtWorks BA——“技能树”

这是一个开放的能力框架。时代在变化,BA的能力框架也应该不停地演进,所以我选取了“树”这种表达方式,期望它“开放”的,可以不断生长的。(或许我明天的想法就会与这个不同?)

BA技能如何生长?

虽然说,没有一个完美的能力模型,但如果想提升整个组织的BA能力,还是建议组织里要有一个能力框架基线。那么,学习途径就是:

  • 首先,通过组织的BA能力模型,识别自己的重点发展方向和若干项能力短板;
  • 从0-4提升、有计划地提升自己的能力。

04

图4: 能力水平的评估和学习曲线

技能提升的方法

对一块技能的掌握程度,有下面几个层次:

  • 0 – 没有相关知识
  • 1 – 知道相关知识(常规套路和工具)
  • 2 – 能按常规套路和工具解决问题
  • 3 – 能创造新方法和新工具解决问题
  • 4 – 能教他人方法和工具来解决问题

从0-1这个层次,是太需要外力的,自己通过搜索相应的资料,能够很快总结出来常规套路和工具。拿梳理需求优先级为例:

  • 阅读5篇以上关于这个主题的比较经典的文章 (如果不知道,可以请别人推荐来源)
  • 自己总结出一些常规的套路和工具 (能从最基本的角度讲清楚What, Why, Who, When, Where, How)。

从1-2这个层次,必须要靠实践,需要通过项目机会来尝试运用所学的基本套路和工具,可能在一开始会走很多弯路,犯错误,但这是学习的必经过程。

从2-3这个层次,则需要很多个项目的经验积累,融会贯通,灵活运用,乃至创造出新的方法和工具。这外力上需要机会,内力上需要持续总结。

从3-4这个层次,则是需要有很强的“发现总结模式”的能力,即使自己没法亲身经历过100个不同的项目,但还是能总结出10种套路和工具,覆盖到其中99个项目,从而能够教会其他人如何解决问题。这个层次更多的是靠内力,持续思考和总结了。

我的一些学习体会

  • 自我驱动 over 外力指导或培训。如果某些时候,觉得自己必须依靠外力培训才能提高,可以问自己这个问题:
    “请问我自己看过关于XX的10篇文章吗?请问我自己看过关于XX的3本书吗?请问我自己从这些文章或书中总结除了一些常用方法和工具吗?我可以从翻译一些文章开始来积累知识吗?”
  • 最有效的学习途径是教他人学习。有项目机会固然可喜,没有项目机会的时候,我也会通过给团队同事做分享、组织内部培训、去给外部社区做工作坊、去实地公益组织探访、尝试去给客户做咨询等,来自己挖掘“问题场景”体验式学习,这些都是非常有效的学习方法。前年在公司做的”团队引导培训“就完全是自己学习、自己开发课程、自己去试讲,然后就得到机会到不同办公室、软件园、客户那里讲,做完之后完全感觉不一样了。
  • 刻意练习。作为BA,我们至少每天可能要开1-2次会,这么多次会,我有没有在每个会议中都总结我可以准备得更好、表达得更好、节奏控制得更好、总结更精准的地方?如果坚持把每次会议都当成会议引导技能提升的练兵场,相信收获会更大。大家可能觉得回顾会议没什么特别,一直使用Well/Less Well/Puzzles这一种方式来做,但是否知道同事Patrick Kua单就回顾会议的方式写了一本书Paulo Caroli 则专门开了博客专栏来写回顾实践。单一个敏捷回顾就能造就专家,何况我们引导那么多会呢……
  • 思考和总结的习惯。同事王健说过,“不把信息当知识,不把收藏当学习,不把阅读当思考,不把储存当掌握”。做过一次工作坊,就总结下自己做的流程;做过一次售前,就总结下售前的得失;看过几篇银行业务的文章,就写个读书笔记。花多少时间和思考,决定了自己学习的加速度。
  • 提升学习速度。不知道大家是否也有这种感觉,就是时间变化快,几年前学习的一个方法可能现在就不适用了,或者已经演进成新的了。如果读一本书要半年,写个总结要花两个月,我觉得完全满足不了市场变化对我们知识和能力的需求。至少,应该要提升三倍以上的学习速度吧。

以上仅是我的个人观点,10个ThoughtWorker心目中可能有10个不同的理想BA画像。“观点就是用来批判的”,所以欢迎大家的各种批评,以及赞扬(如果有的话)。最后,学习快乐! 祝大家都能早日点亮技能图谱上的各颗星星,有广度,有深度!

Share

在ThoughtWorks做BA是怎样一种体验?

BA,英文全称Business Analyst,也称业务分析师,或需求分析师。Linkedin上BA相关的职位不到产品经理或项目经理的四分之一。到本土的拉勾网、智联招聘等网站上,BA的职位就更少了。那么,

  • BA究竟做什么,有没有必要设置BA这一岗位呢?
  • BA具体会做哪些工作?一天会是什么样?
  • BA有哪些能力要求?BA的职业发展如何?

下面我仅就个人在ThoughtWorks的经历做些分享,可能不能代表所有BA,给大家一点参考。

 

BA做什么?为什么需要BA?

BA顾名思义,就是做业务分析。具体说来,就是能够把业务需求和用户需求转化为软件需求,保证最终的软件能满足用户需求,并带来业务价值。举个例子,

01

在软件开发过程中,大家都知道,需求信息要在很多角色中流转。没有BA的团队,需求大概是这样传递的:

02

大家知道,信息每传递一次就会衰减;况且在图上的每一个节点上,往往不是一个人,多人参与更容易失真。根据《组织行为学》中的相关数据,这样跨五层的传递,大约60%左右的信息能被完整无误地传递了。

而有BA的团队,需求则是这样传递的:

03

BA和每个角色都保持无缝的沟通,尽量在每一个节点向前验证需求,保证沟通的每个环节都是闭环,最大程度地减少需求失真。

目前在ThoughtWorks,90%的团队都会配置专职的BA, 只有少量规模很小的团队(如人数<=5个人),则会由其他角色兼任。

 

BA的一天,大概什么样?

如前所说,BA的工作主要围绕需求来展开。在ThoughtWorks的敏捷团队里,使用User Story(用户故事)来表达需求,所以具体的工作就是用户故事的发现、捕捉、拆分、设计、定义、Kick-off、预验收、演示和验收、上线及反馈等,这个过程中会与客户、用户、设计师、开发和测试沟通协作,确保大家做的是有价值的需求,并且对需求的细节有一致的理解。比如我现在的一天:

  1. 早上8:50到公司,看邮件,理一下今天的todo-list, 可能包括如下项(我当前这个组很特殊,会同时负责2个项目
  • 准备项目A在下周一的Showcase
  • 项目B下个迭代的故事卡 – 需要与另外一个BA再过一遍,确保卡上的细节准确无误
  • 项目A的两个故事卡Kick-off
  • 到客服中心去做用户访谈
  • 跟踪下昨天测试报告的外部服务接口好没好
  • 需要与设计师碰一下,把项目B涉及的UI改版的需求再梳理一下
  • ……
  1. 9:15和客户、团队一起站会
  • 更新自己负责的项目需求状态和变更信息
  • 认真听其他人的更新,及时发现有没有需要自己要澄清或跟踪的需求问题
  1. 9:30-9:45 给组里的新同事解答业务相关的疑问
  2. 9:45-10:15 处理一下紧急的客户邮件
  3. 10:15-11:00 与其他BA过项目B下个迭代的卡;
  4. 11:00-12:00 主持迭代计划会议 (怎么做,昨天已准备好)
  5. 12:00-13:00  午饭+休息,刷朋友圈
  6. 13:00-13:40  约到开发、测试,一起kick-off项目A的两张卡
  7. 13:40-16:00  出发去客服中心,用户观察和访谈
  8. 16:00-17:30  准备项目A的showcase讲稿,拉测试做一遍演练、检查外部服务接口是否好了
  9. 17:30 迭代计划会时发现了两个需求问题,发邮件跟客户确认一下
  10. 18:00 查看早上整理的todo-list,还好高优先级已经处理完

 

在ThoughtWorks做BA,跟在其他公司做BA有什么区别呢?

04

我之前也在一家通信企业工作过,属于PM兼BA的角色,对比下来,觉得区别主要在下面几个方面吧:

  • 在TW,我最常用到的工具是白板,PPT,卡片,便利贴;以前最常用的是Word和Visio。
  • 在TW,墙上贴得花花绿绿的,各种需求相关信息,开发测试问到需求,我也是随时随地都能解释;以前都是要翻出需求规格明书,对照着看,才能知道到底做什么。
  • 以前,基本上是做系统分析,到我手上的都是功能需求,有时候明知道做好了没有用户真正用这个功能,还是硬着头皮对照需求规格说明书逐条实现;现在在TW,会真正关注业务问题,用户场景,基本每一条在我手上经过的需求,知道它为什么要做,有什么价值。
  • 以前,几乎从来看不到客户,也不知道用户行为是什么样的;现在几乎天天跟客户打交道(只不过有时是在视频里),还有机会做真正的用户观摩和访谈、用户测试。
  • 以前,一年几乎只能看到1-2次产品上线;现在在这个组,每月都要有很多次产品上线,时不时能得到客户发的巧克力,T恤衫,还是挺受鼓舞的。

 

BA的职业发展怎么样?目前ThoughtWorks中的BA是不是仅能在内部发展?

以我自己的经验来看,BA是个综合技能要求很高的岗位,需求大局到细节的把控、提供业务方案建议、引导决策等等,尤其是大型的产品团队中,更需要综合的影响力和领导力。

之前的BA同事离开ThoughtWorks之后, 有的去做了产品经理,有的去做了数据分析,到其他大型公司里面做BA教练,还有的去创业等等。

在ThoughtWorks内部,有的BA想精专在某一产品领域,比如O2O, P2P还有金数据,实际上承担产品经理的职责,做需求分析的同时,还做售前、看市场和运营;有的则深钻某一个行业,去更多地做业务咨询、解决方案设计、数据分析师等。也有一部分,因为综合影响力和领导力得到了极大的锻炼,横向发展成为管理人员,比如目前我们的全球CEO办公室负责人,我所在组的大客户经理等。

ThoughtWorks是一个人才观非常开放的公司,在内部会鼓励大家“不设限”,主动去尝试很多不同的工作,创造新的“岗位”。

 

在ThoughtWorks做BA,觉得最好的一面和最坏的一面是什么?

最好的一面,是可以接触到各种类型、各种行业的客户,每次都能发现新鲜东西去学习去尝试;最差的一面,其实也是这个,因为有时候要短时间学习很多技能,压力很大。当客户老板说“五分钟之内把图画好”,我们说“好”的那一刻,万分紧张和忐忑;最终把事搞定之后,又是酣畅淋漓,痛与乐并存吧。

 

去TW做BA有什么具体要求呢?

还真没有硬要求,不讲专业,不需资历,也不需软件背景。大致说来,有这四点:

  • 有需求转换的能力
  • 逻辑思维好,清晰有条理
  • 沟通好,复杂的事情也能三言两语说清楚
  • 爱挑战,爱学习

还有的一些不是必须的,但如果能做到,就是加分项了:

  • 喜欢琢磨研究行业市场
  • 善于图形化表达信息
  • 懂敏捷和精益

 

以前没做过BA,但想试试,有书推荐吗

 

最后,以我们内部训练营的BA宣言结尾:

“Skill-set over Role; BA is Business Analysis rather than Business Analyst

角色不重要,真正有两把刷子才重要。大家共同学习,多多增长技能,才是重点。

Share

优秀离岸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