没有BA,用户需求转换为系统需求怎么搞

BA(Business Analyst)–业务分析师,在有的软件开发团队中有专人承担BA的角色,通常他是一个有技术背景又对客户需求和业务深入掌握的专家。在互联网软件开发的团队中,这个角色并不普遍,更为常见的是产品经理(产品策划或者运营人员)。BA存在的主要目的是承接起从用户需求到系统需求的桥梁,也承接起从业务需求到解决方案(通常是技术解决方案)的桥梁,缺失这样的角色实际上会带来很明显的问题。通常互联网企业对于产品经理的定位都在于产品的策划/设计/运营,产品经理往往不是技术开发出身,受制于兴趣和技术基础,对于系统的技术架构和处理过程一般理解的比较浅,加上公司对于产品经理的考核压力在于收入/用户数/在线访问数等指标,使得他们也没有太多的时间和精力投入到学习和更新与产品相关的技术知识。而技术开发团队也存在类似的问题,专注在自己的技术领域中缺乏产品意识。同时技术开发的工作压力一般都比较大,再加上技术本身的发展和更新很快,他们的时间就更加的捉襟见肘了。这样在产品和技术之间就形成了一个断层,甚至随着双方在沟通过程中的争论和摩擦,这个断层还在不断的加大。
在我们日常的迭代开发中就有一个常见的问题,技术团队抱怨产品经理的需求经常变,都没有想清楚,也没有规划好。而产品经理却觉得很简单的一个功能修改或者增加一个小功能,开发却需要这么长的时间。我们假设双方都是积极主动的希望把产品做好,都愿意协作和沟通,那为什么还会出现这样的常见问题呢。其中一个很重要的原因就是缺少了从用户需求到系统需求的桥梁,缺少了从业务需求到解决方案的桥梁。或者说缺少了能够承担起BA工作的人,如果有专职的BA,那么职责会很清晰,但是团队也可以没有一个人专职做BA,BA的工作可以分散在产品经理和开发人员上一起承担。
举个例子:产品经理Ellin提出一个需求:为了鼓励手机用户登录社区,对于每周登录超过2次的手机用户奖励一个装饰挂件。她觉得这个需求不复杂,开发团队应该能够
快速的实现,最好周末就要上线。可是没有想到在讨论需求时遇到了激烈的PK。Mark说:上次对于鼓励用户发微博的功能,就做的太赶,像统计、消息提醒、奖品的有效时间/是否可以赠送等等考虑的不周,结果收到用户的投诉。不应该急急忙忙地做这样的激励功能。
Steven说:以后还会有这样的激励需求吗?类似的用户激励功能涉及到多个系统模块,应该要统一设计,不要重复开发。
Jason说:目前的统计都是活动时临时发起的,不仅性能低,而且不能用于其他的活动中,因为每个活动的条件都不一样。需要修改为业务功能模块在完成一些关键动作,如:登录,发表时,异步的累加统计数据,这个的修改量还是比较大的…
结果争论了半天,1个小时的会议时间很快就过去了,大家不欢而散。
要搭建起从用户需求到系统需求的桥梁,从需求到技术方案的桥梁,如果我们没有专职的BA,要怎么搞呢?
首先:产品经理要着手了解系统的技术结构和处理过程,不要认为这个是开发团队的事情,和我没有关系,也不用害怕说我不懂开发,搞不懂这些技术知识。由开发团队组织对产品经理逐步的技术培训(培训的内容需要事先好好准备),再加上产品经理天天都与开发团队打交道,多问多听,通常可以比较快地建立对系统技术结构和处理过程的整体认识。
第二:产品经理和技术团队使用一种共同的沟通语言。这个非常重要,如果没有使用一种共同的语言就会出现鸡同鸭讲的情况。UML语言是一种可视化建模的模型语言,它适用于数据建模,业务建模,对象建模,组件建模。当然要用好它并不容易,整个团队可以选择对UML做一定的裁剪,然后定义出自己使用的图形语言,包括最常用的描述图(例如:组件图/时序图)以及它的使用方式。然后组织对产品经理和开发团队的培训,统一采用这种图形语言。
通常当开发团队和产品经理一起画出系统的各个模块,需求对模块的影响,以及需求在某个应用场景下的系统处理时序图时,双方就可以比较明确确定需求的范围,对系统的扩展性以应对不同的需求支撑也比较容易达成一致。
第三:技术团队需要帮助产品经理理解系统的技术结构和处理流程,同时也要深入的理解产品需求对系统的影响,向产品经理讲述系统如何更好的实现用户需求,提出技术方案,和产品经理讨论。这个过程就是从用户需求到系统需求,从需求到解决方案的过程。有的时候技术解决方案不一定是最好的选择,产品经理在理解了系统的局限以后,可能通过改变产品的设计或者引导用户采用不用的业务方案来达到一个更好的效果。
当产品经理和开发人员一起承担起BA的角色,那么产品经理和开发人员之间的断层就被沟通的桥梁给衔接起来。用户需求就可以比较顺畅的转换为系统需求,需求也可以比较顺畅的转换为解决方案。这个世界就会和谐很多。

发表评论

电子邮件地址不会被公开。 必填项已用*标注