posts - 309, comments - 6940, trackbacks - 0, articles - 3
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

[转载]Business Analyst - 职业的新方向

Posted on 2008-02-03 15:04 诗特林 阅读(5830) 评论(2)  编辑  收藏 所属分类: Java与外企
       [转载]Business Analyst - 职业的新方向

如果你在北美IT行业工作过一段时间,一定有可能听说过 Business Analyst,中文叫做业务分析师这个职业。(以下简称BA)。其实BA这个工作在IT行业已存在多年,并且正逐渐获得更多的认可和关注。记得几年前笔者向别人介绍自己的BA工作时,着实要费一番口舌,因为在华人圈里的确不是有很多人听说过。如果您对BA这个工作不是很了解,那么在看完此篇文章之后,您将会有一个初步的认识。希望以下介绍的信息能对想找工作的新移民或者是想换工作的朋友们的职业选择会多少有些帮助。
随着数字化、虚拟化和自动化技术的高度发达,全球境外经营越来越普及。全球生产业务向中国的集中,以及服务业务向印度的集中,说明了一个看似遥远其实已残酷地摆在面前的事实:发达国家的技术开发、生产和服务环节的工作机会已经减少,并且这个趋势会越来越快。我们作为技术移民,大多数都是技术背景,很多人都工作在一线的研发、生产和服务领域,是属于最容易被这种全球化冲击的群体。那么,在这种经济全球化的变革中,什么样的工作职位才能更稳定和有发展前途呢?Business Analyst(BA)就是最好的选择之一。
Business Analyst是个什么样的职业呢?
如果你在 www.workopolis.com 或者 www.monster.com 的网站上敲进 Business Analyst进行关键字搜索,你会发现有上百个相关职位。其中涉及的行业从金融、电讯到医疗、保险不等。首先澄清一下,我们这里提及的BA,是IT相关的BA,有时也称做 Business System Analyst,Business Specialist, Business Consultant or Business System Consultant。
虽然称呼上略有不同,但其实工作性质都是非常接近的。简单而言,BA是一种介于客户和IT团队之间的角色,BA在IT项目中负责发掘、分析、传达和确认客户需求。BA需要了解有关业务上的各种问题并发现新的机会,搭建业务和IT人员之间的沟通桥梁,并推荐问题的解决方案以实现组织的目标。这其中还包括参与系统的设计和测试,以及各种协调工作。
BA的具体职责大体有如下几种:
业务需求分析,建立相关文档和分析、建立业务模型
协助project manager的项目管理工作,如项目scoping,planning
调查、分析现有的系统和业务流程
组织各种会议和workshop
准备External Design文档和进行可行性调查
准备和实施Test Plans
参与IT系统的安装和培训
为什么要在客户和开发人员之间加上一道程序,让他们直接对话岂不更好吗?我个人认为有以下几个原因:首先就是分工细化的要求。IT项目越来越庞大,客户需求也愈加复杂,IT开发人员已无更多精力,这样就要有专门的人员来担当此任。其次,BA的需求分析工作不是简单地坐在那里听客户讲,然后记录下来并组织成文档。在业务分析中会有许多的挑战,需要BA应用特殊的技巧来将客户脑中潜在的需求挖掘出来。BA要做系统的分析,如业务流程分析,要了解客户及其他相关人员和组织。这期间需要付出大量的精力和时间,而不是开几个会再用Word记录下来那样简单。用一个流行的话讲,BA的工作要add value。
BA在项目各阶段中起何作用,他们和团队中的其他成员是如何互动的呢?
BA在项目的初始阶段,要参与到项目目标设定、项目范围的界定、和stakeholder分析等工作中。在项目的需求分析阶段,主要负责分析、开发,了解和记录客户的需求。这其中还涉及到了业务流程分析,建立各种业务模型。这些需求文档和业务模型将成为日后开发人员进行系统分析和设计的重要参考依据。在项目的设计与开发阶段,BA主要是负责联络和沟通,起到桥梁的作用。有时还要参与到系统外观设计中,确保系统设计符合客户的需求。在测试阶段,BA要参与测试计划的编写和实施,审核测试文件的有效性并确保客户所有的需求达到测试标准。在项目的最后实施阶段,BA要参与实施方案的制定与监督计划的实施。有时还涉及到客户培训和项目最后的评估。
要找到BA工作,需要具备那些条件呢?哪个行业又最需要BA呢?
目前来讲,BA的工作机会还是很多的,因为在各行各业中,只要它需要开发信息系统,就得有人来分析记录客户需求,这也就离不开BA这个角色。整体来讲,金融、医疗、电讯、政府等行业和机构都需要大量的BA。而且BA这一职业的特点是在一个行业的时间越久就越吃香,价值也不断增加。目前各公司也越来越重视BA的开发和培养,BA这个职业也越来越受到社会的认可和重视。
笔者本人的经验,找BA工作需要几大法宝。第一就是相关的行业经验。其次是BA的流程技巧。第三是较强的沟通能力。这其中必然包括较流利的英文口语及书面表达能力。
BA的工作前景如何?薪水如何?今后的职业发展又如何呢?
应当说BA的薪水是相当不错的。Junior BA与类似经验的 Developer的收入持平或略高一些。一两年经验的BA 年薪一般能达到五万元,高级 BA 和 Consultant 能拿到7到9万元不等。如果做Contract的话,收入就会更高一些。
从职业发展上看,BA可以向Business Consultant或者Project Manager等方向发展,都是不错的选择。当然也有些BA向Business方向转换的,比如做Financial Analyst或者Process Analyst。
BA工作的挑战是什么?尤其是对中国人,门槛是不是很高呢?
BA这个工作,和其他职业一样面对许多困难和挑战。就笔者本人的经验来讲,主要有以下几点:首先你要对一个新接触的行业和客户在最短的时间内进行了解,熟悉客户专业名词和业务流程。这往往对我们英语非母语和初来乍到的移民来讲是一个不小的挑战。其次就是英语。口音倒不是最大的障碍,很多时候是我们不知如何用恰当的词和句子来表达,结果说了半天别人也听不懂。再有就是许多人对BA的工作流程不是很了解,感觉找工作无从下手。
至于门槛呢,我个人认为应该说不低,尤其是对交流能力的要求。但也没有想象中的那么难。我想只要平时注意学习英语,以积极的态度对待工作中的人与事,经过一段时间的积累和锻炼,工作上就会驾轻就熟。同时,交流能力的提高也有助于今后向其他方向发展。
BA工作的好处是什么呢?
首先BA工作不乏味。通过做不同的项目,你会接触到许多新鲜的东西,最起码你不会厌烦反复做同样的事情。其次,BA工作使你能接触到公司中许多不同的人和各种业务,既有助于发展人际关系,也有助你了解了公司是如何运转的。最后,在当今 IT外包势不可挡的情况下,BA这个职业也显示了其特有的优势。由于BA的工作性质是同客户打交道,必须要贴近业务和客户,因此所受影响就微乎其微。

Many organizations have an IT role called analyst, and will often differentiate between various types:

  • Requirements analysts who are responsible for requirements elicitation
  • Systems analysts who are responsible for analyzing the requirements to determine the system needs to fulfill those requirements
  • Business analysts who are responsible for understanding the business and making recommendations for improvement
  • Business system analysts whose responsibilities are a combination of those of a requirements analyst, business analyst, and a system analyst.
 

The focus of this discussion is on business system analysts (BSAs) even though many of the issues (or flavors thereof) are pertinent to the other analyst types. BSAs typically have experience in a wide range of techniques, including interviewing, structured meeting approaches such as Joint Application Development (JAD), modeling sessions, and model reviews. Good BSAs have a good understanding of the business domain and are typically 損eople persons?  This article covers:

  1. Why Have BSAs?
  2. The Traditional Activities of an Analyst
  3. Business Analysts Gone Awry
  4. Towards Agile Analysts
  5. BSA as Product Owner?

1. Why Have BSAs?

Why have many traditional organizations adopted the idea of having BSAs on staff?  There are three general reasons, all of which I believe are misguided:

  1. Developers can't elicit requirements.  The common stereotype is that developers don抰 have the communication and modeling skills necessary to elicit requirements effectively, and sometimes they don抰 even have the inclination to do so.  At best this is a self-fulfilling prophecy: if you believe that developers can't do this sort of work then you won't give them the training nor the opportunities to gain the skills on the job.

  2. Stakeholders can't model and document their own requirements.  In one respect this is true, particularly when stakeholders aren't given any sort of training or support.  With the use of inclusive tools and techniques, and with a bit of training, stakeholders can become active participants in the development efforts.  Yes, project stakeholders still need someone to guide and facilitate their efforts, but they can do the majority of the work. 

  3. You need analysis experts. You definitely need to do analysis, but whether you need someone who just does that is a really big assumption.  Agile developers are generalizing specialists, people with one or more specialties, a general understanding of the software process, and a knowledge of the domain.  One of their specialties might be in analysis, or then again it might not.  It is unreasonable to expect everyone to be an expert at every aspect of software development, but it is reasonable to expect IT professionals to have some analysis skills and for some people to have deep skill in this activity (amongst many of their skills).

 

You need to do analysis, but that doesn't imply that you need analysts.

2. The Traditional Activities of an Analyst

A BSA on a traditional software development project will perform one or more of the following activities:

  1. Scope the system. During the initial phase of a project, often called 搃teration zero?or simply the inception phase, BSAs may be the only 揹evelopment staff? assigned to the project. At this point they will work with key project stakeholders to formulate and communicate the business vision, to envision initial requirements, and to scope the project. Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic. They may also help to identify potential areas of automation and even to aid in reengineering the underlying business process. 

  2. Translate business needs. A major responsibility of BSAs is to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand. This is an iterative process throughout the project. An important part of this is to the distillation of the differing messages of various project stakeholders into a single, consistent vision. This task often includes significant negotiation and political maneuvering. In this respect a BSA will act as a knowledge integrator. Furthermore, BSAs often find themselves spending significant time in meetings, thereby saving the rest of the development team from this inefficient use of their time. 

  3. Translate technical issues. BSAs will also explain technical/architectural complexities to project stakeholders, such as why your HTML-based application can抰 have as slick of a user interface as a Visual Basic application.   BSAs often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates.

  4. Model and document. BSAs will often work with project stakeholders to identify, model, and then document their requirements and business domain details. 

  5. Act as a communication broker. BSAs typically have very good connections within the business community and therefore are in a position to help development teams find the right people to work with. 

  6. Political mentor. BSAs often help project teams through the political minefields within their organizations, particularly when the BSA has worked within the same organization for several years.

  7. Test and validation. BSAs will work with project stakeholders to validate their requirements and analysis models via techniques such as reviews, walkthroughs, and play acting. BSAs will often aid in writing user acceptance test (UAT) cases and will be a liaison between project stakeholders and your testing organization during UAT.

  8. Represent stakeholders. When project teams don抰 have direct access to their project stakeholders, clearly not a good situation, BSAs will act as 搒takeholder surrogates? Typically developers will treat a BSA as the 揷ustomer?from which requirements, domain information, and business priorities are provided. The BSA in turn will work with the stakeholders to obtain information and to verify decisions.  

3. Business Analysts Gone Awry

In theory the idea of having traditional BSAs involved with a project should work quite well, and in practice it often does. The best analysts are organized and great communicators, having the ability to distill the critical information from your project stakeholders out of the 搃nformation noise?that they provide ? often through a wide range of modeling techniques. For many organizations the addition of BSAs clearly improved the quality of the requirements elicitation and analysis modeling. It also opened up communication between the 搕ech weenies?in IT and the 揵usiness morons?that the system was being built for. 

Clearly this was a step in the right direction. However, some very common problems have been known to occur: 

  1. BSAs often lack the right skills. Many organizations have difficulties hiring the right people and/or nurturing the right skills in people. The end result is that people are often thrust into the role of BSA but do not have the skills to fulfill that role, nor do they have an opportunity to gain those skills.   

  2. BSAs can have undue project influence. A strong-willed BSA may inadvertently influence a project, perhaps by playing down requirements that they don抰 agree with or even influencing architecture decisions by being biased towards one type of analysis technique (such as focusing just on use cases or just on data models). This is particularly dangerous when BSAs act as stakeholder surrogates AND the developers and stakeholders have little interaction other than via the BSA.

  3. BSAs can be out of date. Having previous development experience is critical for a BSA because it grounds them in reality. However, it may also lead them astray. For example someone with a data-intensive background may struggle when working with a development team that is using object technology (and vice versa) because they don抰 know which issues they need to focus on.

  4. BSAs can act as a communication barrier. Although BSAs can act as a communication bridge between the two groups they also act as a communication barrier. On the Agile Modeling (AM) mailing list Ron Jeffries depicted the communication approach of traditional BSAs to look like 搒takeholder => BSA => developer => BSA => stakeholder? This looks a lot like the game of telephone tag, doesn抰 it? When you play this game you quickly discover that the signal degrades between hops, decreasing the chance that the actual message gets through successfully. Although a highly skilled BSA, one with excellent communication skills, will reduce this problem it will never go away completely.

  5. BSAs can reduce stakeholder influence. An interesting implication is that your project stakeholders don抰 have as much influence over the software as they may think. They抮e influencing the traditional BSA, and the models and documentation that the BSA creates, but have no direct influence over what the developers are creating. This can even be said of user interface prototyping efforts, particularly when those efforts are led by a traditional BSA.

  6. BSAs often over analyze.   Another inherent problem with traditional BSAs is their tendency to actually do their perceived jobs. What? When you specialize in something you will naturally focus on that task. The implication is that the task of business analysis will be stretched out, instead of Iterating to Another Artifact as AM suggests, such as a design model or even source code, a BSA will likely focus on expanding the artifacts that they specialize in. Not only is your development effort likely to devolve into a more serial process, instead of an evolutionary approach, the BSAs are likely to develop more documentation than is required.  Your goal should be to create models and documents which are just barely good enough.

  7. BSAs can reduce feedback. When analysts are only responsible for analysis efforts, for creating models and documents that are meant to be handed off to developers, there is less opportunity for feedback. There is the danger that they will create theoretically sound models, and make unrealistic promises based on those models to your project stakeholders, that don抰 work in practice. The feedback of people working with software is critical, feedback that you can抰 get from models and documents. The BSA quickly learns what actually works, and from the resulting changes requested by stakeholders quickly improves their analyst skills because they recognize mistakes they made.

  8. BSAs can reduce opportunities for developers to gain communication skills. With traditional BSAs in place developers aren抰 given as many opportunities to improve their own communication skills, skills that are critical to success in today抯 environment. Nor are they given the opportunity to work closely with business experts, opportunities that would allow them to learn about the nuances of the business environment and thus increase the chance of them building a system that actually meets their users needs. Nor are they given the chance to discover that the 揵usiness morons?are actually pretty smart after all, with interesting knowledge worth learning. Similarly, project stakeholders miss the opportunity to learn about how software is developed, arguably a good thing in some organizations, and to discover that the 搕ech weenies?are actually very interesting people. Houston, we have a problem.

 

The role of BSA makes sense when barriers to communication (such as time, distance, or lack of communication skills among developers) have been erected between stakeholders and developers.  BSAs compensate for these barriers.

4. Towards Agile Analysts

Fundamentally the activities performed by traditional BSAs are varied, but a crucial goal was always to improve the communication between developers and project stakeholders.  In many 搕raditional?organizations that meant that BSAs formed a bridge between the two groups, a definite improvement in many situations, although at the same time erected barriers.  Now is the time to take the next step, to become more agile and have BSAs become the communication mentors/coaches on project teams.  This isn抰 to say that every existing BSA is qualified to become a communication mentor, but chances are that your pool of BSAs is a good place to start looking for likely candidates.

How can BSAs become more effective?  AM suggests that development teams follows the practice Active Stakeholder Participation, that they work closely with their project stakeholders.  The goal of this practice is to reduce the feedback loop and thereby improve communication.  However, the way that you work with your stakeholders will in part be determined by your team抯 organization.  An interesting implication is that the role that a BSA takes on changes dramatically based on the communication options available to your team.  There are three categories of team organization that need to be considered with respect to how an 揂gile BSA?will act on a project team:

4.1 One Room ?Developers and Stakeholders are Co-Located

First, let抯 assume that you are able to co-locate your development team with your project stakeholders, an ideal situation that you should always strive to achieve. In this situation an agile BSA should be just another one of the developers on the team, likely leading requirements and analysis modeling efforts as needed. They would actively work to facilitate communication within the team, mentoring developers in BSA skills and perhaps even mentor project stakeholders in development skills. Ron Jeffries says it well in his article ?a href="http://www.xprogramming.com/xpmag/BizAnalysis.htm">Business Analysis in Extreme Programming?

This begins with a simple change of focus, from "We'll go out and find out what the customers want and bring it back", to "We'll go help the customers figure out what they want, so they can tell us". This change of focus leaves control in the hands of the customers, and makes all the difference.  

A critical skill that an agile BSA brings to the table is the ability to investigate and understand how the business actually works, as opposed to how developers think it works or want it to work, an ability that they should be able to mentor developers in. When co-located, Agile BSAs would also perform non-BSA activities as well, perhaps pair programming with one of the developers on some of the business code or working with users to develop acceptance tests.  This way the agile BSA would grow his or her own skill set over time and would help others to do so as well. 

An implication of this approach is that the 搕raditional BSA?is getting dropped in favor of a developer with very good communication skills. This reflects AM抯 philosophy that good developers are generalizing specialists, people who have a general understanding of the complete software development lifecycle and one or more specialties: in this case business system analysis. The danger of this approach is that the BSA can抰 be in the role of 揷onflict arbiter?when developers and stakeholders don抰 see eye to eye ?the BSA is a developer and therefore is likely to be seen as biased in such situations. Conflicts would need to be resolved by the project manager/coach or one or more senior project stakeholders.

 

A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.

Remember, BA is also the abbreviation for band-aid.

4.2 Over the Wall ?Single Location But Not Co-Located

A common situation is for project teams and project stakeholders to be located in the same building but not together ?perhaps the project team is one floor and the stakeholders are on different floors. Furthermore, the project stakeholders are typically not available on a full time basis to the project team. Common scenarios include stakeholders that can co-locate one or two days a week and be available as needed on other days; stakeholders that can be available for physical and teleconference meetings several times a week; and stakeholders whose availability is severely limited and often can only give you an hour or two a week. Clearly none of these scenarios are ideal, but unfortunately they are all too common.

In these situations the agile BSA takes on some of the aspects of a traditional BSA. In particular, in situations where the stakeholders are not able to partially co-locate with the development team the BSA will need to work with them in their own environment. This will likely entail modeling sessions and interviews with the project stakeholders. The Agile BSA will typically bring one or two other developers with them to these sessions, that way the developers can not only learn the business knowledge that they need they can also gain BSA skills in the process. This will also help to build bonds between the developers and stakeholders.

The agile BSA will also model a bit ahead of the team, gathering the information which they need a few days or weeks before it's actually needed: too much modeling ahead may result in the sort of wastage seen with a big requirements up front (BRUF) approach.

4.3 Across the Network ?Dispersed/Distributed Development

In this scenario the project team is located in a different location than their project stakeholders, and in the extreme the project team itself is in several locations as are the project stakeholders. Large organizations, consortiums of organizations, and organizations that outsource development to other companies (often overseas) often find themselves in this situation. I highly suggest that you avoid distributed development situations such as this because of the increased communication risk inherent in this approach. When a team is dispersed/distributed the opportunities for face-to-face discussion, the most effective way to communicate, are reduced. Instead you are forced to rely on less productive communication strategies ?such as video conferencing, telephone conversations, and written documentation ? and thereby dramatically increase project risk. Rich communication between developers and project stakeholders is a fundamental aspect of agile software development. It is possible to take an agile approach in these situations, as Alan Wills describes in Dispersed Agile Software Development and Dispersed eXtreme Programming, but it抯 very hard.

In this situation the role of an Agile BSA devolves into something closer to that of a traditional BSA, that of trying to bridge the gulf between developers and project stakeholders. They would realize that this situation is not in the best interest of the project, that they really want to have the project stakeholders working with the developers and therefore should try to get these people together as often as possible. Perhaps they抣l facilitate conference calls, video conferences, and online meetings between the two groups. Perhaps they抣l help to arrange periodic co-locations where some project stakeholders travel to the developers, or vice versa, to enable some direct interaction between the groups.

   

5. BSA as Product Owner?

A business analyst make take on the role of "product owner" on a Scrum project.  In Scrum the product owner is the single person whom is responsible for prioritizing the team抯 requirements.  Yet, as Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.  Although the role of product owner is close in some ways to that of the traditional business analyst what they produce is often significantly different.  Product owners facilitate communication, which means they will be actively involved in modeling and will inevitably produce some documentation, but they will do so agilely. Product owners clearly need to be skilled in agile business analysis in order to identify stakeholder needs, negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively. 

Figure 1. Scaling the role of Product Owner.

Although a traditional business analyst could fill the role of product owner, particularly those from the business side of your organization, there is a significant risk that they will fall into their old habits of communicating via documentation.  The traditional software development community has significant cultural barriers to overcome when it comes to modeling and documentation, and as a result experienced business analysts often struggle to fit into agile teams.  Like I said, we need to do business analysis on agile projects but that doesn抰 imply that we need specialized business analysts.

6. Recommended Resources

The Object Primer 3rd Edition: Agile Model Driven Development (AMDD) with UML 2   The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
Agile Modeling   Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
Elements of UML 2.0 Style   The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

 

7. Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here

You may be interested in my two-day Agile Requirements Workshop: Something Old, Something New, Something Borrowed, Nothing Blue.


Canadian Flag

Copyright 2002-2007 Scott W. Ambler

Last updated: March 3, 2007
This site owned by
Ambysoft Inc.

|| 
Agile Data (AD)  |  Agile Unified Process (AUP)  |  Enterprise Unified Process (EUP)  |  My Writings  ||


评论

# re: [转载]Business Analyst - 职业的新方向  回复  更多评论   

2008-02-13 15:26 by nazzy
看了您的文章,之前做了几年相关的业务分析工作,很想朝BA方向发展。希望能够到专业从事该方面工作、经验丰富、公司实力雄厚的大型公司工作,不知有何推荐?

# re: [转载]Business Analyst - 职业的新方向  回复  更多评论   

2008-04-12 10:39 by 豆抓搜索
好长呀...http://www.douzhua.com

只有注册用户登录后才能发表评论。


网站导航: