第二章：Business Analysis Key Concepts

在正式介紹Business Analysis的六大知識領(lǐng)域之前氨肌，先就一些后面會用到的關(guān)鍵概念進行了介紹捂寿。

特別是這里面有些困惑大家已久的概念，對這些概念進行聲明魁瞪，便于達成共識后進行后續(xù)知識的學(xué)習(xí)穆律。

Business Analysis Core Concept Model

BACCM主要是對BA工作過程中的六個核心概念及其之間關(guān)系的描述。

這個模型可以用作：

在業(yè)務(wù)分析過程中导俘，對專業(yè)業(yè)務(wù)和領(lǐng)域進行描述峦耘。

對于業(yè)務(wù)分析過程中遇到的信息進行評估。

可以作為BA開展工作的思考框架旅薄。

變革Change

Change is the act of transformation in response to a need.

It works to improve the performance of an enterprise.

從這個概念我們不難看出辅髓，Change是一個高層級的動作，它會對整個enterprise產(chǎn)生改善績效的影響。

也可以說洛口，這個Change是需要與戰(zhàn)略矫付、目標(biāo)一致的。

需要Need

Need is a problem or opportunity to be addressed.

我們可以把Need理解為純業(yè)務(wù)的第焰，與技術(shù)技即、解決方案無關(guān)的。

甚至我更提倡直接將其理解為待解決的問題樟遣。

我們在做解決方案的時候而叼，一般都是從問題出發(fā)的。

之前我寫過“需求分析第一步：定義真正的問題”豹悬。

（可以點擊鏈接直接跳轉(zhuǎn)查看相應(yīng)的文章）

我們的日常工作中最經(jīng)常接觸到的是Need葵陵，對于Change一般是中高級領(lǐng)導(dǎo)會去思考的問題。

但是我們在分析Need的時候不能偏離Change瞻佛。

也是一種不忘初心脱篙。

當(dāng)然也不排除分析Need后，導(dǎo)致了Change的發(fā)生伤柄。

解決方案Solution

Solution is specific way of satisfying one or more needs in a context.

解決方案是用來解決問題绊困，滿足相應(yīng)環(huán)境下的需求的。

這點就不多說了适刀，沒有什么歧義秤朗。

干系人Stakeholder

Stakeholder is a group or individual with a relationship to the changes, the needs, or the solution.

基本上受到Change、Need笔喉、Solution影響的取视，或者影響它們的個人或團隊都可以視為干系人。

考過PMP的同學(xué)都知道常挚，基本上你想得到的人都屬于干系人作谭。

這里也不做過多說明了。

價值Value

Value is the worth, importance, or usefulness of something to a stakeholder within a context.

價值不是顯然是需要進行評估的奄毡，而且是對stakeholder有價值的折欠。

在這里，因為stakeholder的覆蓋面非常廣吼过，所以價值也會覆蓋得非常廣锐秦。

比如，不僅僅是對客戶有價值那先，對運維人員有價值农猬、對實施團隊有價值……

另外赡艰，有一點需要特別注意售淡。

在BABOK Guide3.0中，對于價值聲明了一點：

價值可以是帶來改進、收益等正面的揖闸，也可以是一些負面的揍堕。

就好像我們在PMBOK中可以看到對風(fēng)險管理的說明。

其認為風(fēng)險與機遇都是需要管理的汤纸，都屬于風(fēng)險管理的范疇衩茸。

在這里，Value也是一樣的贮泞，有正面的楞慈，很負面的。

這個概念對于后面去理解一些其他的信息很重要啃擦。

上下文Context

Context is the circumstances that influence, are influenced by, and provide understanding of the change.

這個概念在BABOK Guide 3.0里面被作為關(guān)鍵概念提出囊蓝，我深感其專業(yè)。

現(xiàn)在很多的教程令蛉、文章在說需求分析的時候聚霜，從來不提業(yè)務(wù)環(huán)境。

你看到中東富人們沒有羽絨服珠叔，于是去賣羽絨服蝎宇。

這就是無視環(huán)境。

還有在分析一些非功能需求時祷安，也從來不考慮環(huán)境姥芥。

另外，我一直覺得汇鞭，任何的需求都是基于業(yè)務(wù)場景的撇眯。

不管你這個需求的性質(zhì)是什么。

如果沒有合理的業(yè)務(wù)場景虱咧，并且假設(shè)太多熊榛，那么你憑什么說你的設(shè)計和解決方案是有價值的呢？

總結(jié)一下腕巡，當(dāng)你在進行分析的時候玄坦，從這六個問題分別去尋找答案：

What are the kinds of changes we are doing？

What are the needs we are trying to satisfy?

What are the solutions we are creating or changing?

Who are the stakeholders involved?

What do stakeholders consider to be of value?

What are the contexts that we and the solution are in?

Key Terms

本節(jié)主要介紹了再BA工作過程中會涉及到的一些關(guān)鍵信息绘沉。

這些信息大部分會反復(fù)出現(xiàn)在六大知識領(lǐng)域的任務(wù)中煎楣。

Business Analysis

關(guān)于這個概念，在第一章已經(jīng)進行了說明车伞。

此處不再說明择懂。

Business Analysis Information

這里需要注意的是分析的對象。

這個分析的對象是information另玖，而不是requirement和need困曙。

也就是說表伦，作為BA需要分析的對象是信息，并且這個信息可能是任何的種類慷丽、級別蹦哼、粒度渠退。

Design

Design is a usable representation of a solution.

由此可以看出來沦零，Design是針對Solution的。

Design聚焦在如何才能讓Solution實現(xiàn)其價值棚辽。

Enterprise

Enterprise is a system of one or more organizations and the solutions they use to pursue a shared set of common goals.

說實話我以前從未注意過Enterprise到底是什么意思锄俄。

從這里的定義看來局劲，Enterprise是一個比企業(yè)、組織更大的范圍奶赠。

我自作主張的將其理解為“圈子”容握，也就是為實現(xiàn)目標(biāo)的一個大圈子。

這個圈子里有所有的干系組織车柠，以及相關(guān)的解決方案剔氏。

這個圈子是虛擬的，沒有一個非常清晰的邊界竹祷，并且它的邊界是由業(yè)務(wù)定義的谈跛。

Organization

Organization is an auto group of people under the management of a single individual or board, that works towards common goals and objectives.

Organization顯然是我們常規(guī)意義上理解的組織、企業(yè)塑陵、單位感憾。

Plan

Plan is a proposal for doing or achieving something.

所有的工作在進行的時候，肯定都需要進行策劃令花。

以PMBOK為例阻桅，其中的過程組中就有不少在做規(guī)劃，也就是Plan的工作兼都。

Business Analysis也是如此嫂沉。

需要有一定的策劃和規(guī)劃去進行整體工作的指導(dǎo)。

Requirement

Requirement is a usable representation of a need.

這里我們可以看出這個定義和Design非常相似扮碧，只是Requirement是聚焦在Need上的趟章。

而在實際的工作過程中，我們很難去界定你在進行requirement的分析慎王，還是在做design蚓土。

并且因為各個公司對于BA的職責(zé)界定不同，大部分的（國內(nèi)的）BA不可避免的會涉及到一些Design的工作赖淤。

也許有的大公司界定的比較清晰蜀漆，會有專門輸出Requirement的BA，和專門做Design的SA咱旱。

但是至少BA需要參與到Design中确丢，以確保Solution可以實現(xiàn)Requirement绷耍，這也是BA評估的一個職責(zé)。

另外蠕嫁，現(xiàn)在越來越多的團隊采用Agile的模式。

造成Requirement和Design的界限更加的模糊毯盈。

因為兩者之間沒有很清晰的交接剃毒，而是不斷的迭代優(yōu)化，相輔相承搂赋。

Risk

在BABOK Guide3.0中赘阀，對Risk的概念及應(yīng)對措施的描述，與PMBOK一致脑奠。

Requirements Classification Schema

眾所周知基公，需求時分層分級的。

而這個層級在BABOK Guide3.0中是怎么描述的呢宋欺？

我們按照需求從High Level往下轰豆，分為：

Business Requirements——對應(yīng)Change

Stakeholder Requirements——對應(yīng)Need

Solution Requirements——分為功能和非功能需求

所以，你是否在日常的工作中直接就落到了最后一級了呢齿诞？

你是否遇到過Stakeholder和你提需求的時候酸休，根本就直接就提了Solution Requirement了呢？

另外祷杈，在這三類需求之外的另外的一個維度上斑司，還有一個需求：Transition Requirement

一般來說，我們寫產(chǎn)品的SRS都會有一個章節(jié)專門寫“升級影響”但汞。

也就是說宿刮，新的版本部署上去后是否會有一些影響。

比如對原有歷史數(shù)據(jù)的影響私蕾，是否需要更新僵缺、遷移。

這類需求其實就是Transition Requirement踩叭。

它有一個特點就是：當(dāng)實施后就失效了谤饭。

我做系統(tǒng)升級只會做一次數(shù)據(jù)遷移，不會反反復(fù)復(fù)的做懊纳。

所以這個需求只會發(fā)生在升級的時候揉抵。

但是千萬要注意這個需求不能省。

作為用戶我曾經(jīng)經(jīng)歷過因為軟件供應(yīng)商系統(tǒng)升級導(dǎo)致數(shù)據(jù)丟失的痛苦嗤疯。

這個影響會很大冤今，后果會很嚴重。

Stakeholders

在BA的工作中會遇到形形色色的Stakeholder茂缚，甚至比項目經(jīng)理遇到的種類更多戏罢。

因為BA的工作不僅僅是在項目進行中屋谭，而是在項目開始前的收集、項目中的參與以及項目后的跟蹤龟糕、評估桐磁。

BA

工作中也許你是團隊唯一的BA，但是你需要考慮到未來這個需求是否會被復(fù)用讲岁，是否會擴展到別的部分我擂。

更何況現(xiàn)在大部分情況下，你并不是團隊中唯一從事BA相關(guān)工作的人缓艳。

另外校摩，作為BA你基本上也會有很大的幾率兼任以下的角色。

Customer

Customer uses or may use products or produced by the enterprise and may have contractual or moral.

我想把Customer和接下來的End User放在一起進行說明阶淘。

End User

End user is who directly interact with the solution.

對比一下不難看出衙吩，兩者之間的差別。

有的時候Customer就是End User溪窒，但是也有不是的時候坤塞。

比如，你作為ATM的供應(yīng)商澈蚌，你的Customer是銀行尺锚，而End User是儲戶惜浅。

我們以前最常遇到的問題是瘫辩，你去業(yè)務(wù)訪談的對象并不是一線的用戶伐厌，而是一些管理人員卷扮。

他們可能曾經(jīng)是一線用戶，但是因為離開一線很長時間了均践，對于現(xiàn)狀其實了解是很有限的晤锹。

對他們提供信息有效性的錯誤評價，將導(dǎo)致需求的偏差以及解決方案實施的失敗彤委。

另外鞭铆，在后面的章節(jié)中，對于Customer和End User的界定焦影，會分別被界定為External和Internal车遂。

對封断，你沒看錯，是Customer在外舶担，End User在內(nèi)坡疼。

我仔細思考了下，這個內(nèi)外應(yīng)該是對于Solution而言的衣陶。

End User直接包括在Solution中柄瑰。

Domain Subject Matter Expert

業(yè)務(wù)領(lǐng)域?qū)＜覀兒苤匾愕男枨笞娲辍⒔鉀Q方案的評估都要聽取他們的意見狱意。

而小婧也一直都在說湖苞，BA一條路就是走“專才”拯欧。

深鉆業(yè)務(wù)，把自己培養(yǎng)成為領(lǐng)域?qū)＜也乒牵敲茨阍谧鰶Q策和分析的時候更有底氣镐作。

而在面對下面這類角色時，BA就是領(lǐng)域?qū)＜摇?/p>

Implement Subject Matter Expert

實施團隊主要的職責(zé)是實現(xiàn)解決方案隆箩。

他們以BA的Requirement為輸入该贾，進行Solution的設(shè)計，最終提交BA進行Value的評估捌臊。

這個實施團隊會包括很多的角色杨蛋，比如：架構(gòu)設(shè)計師、開發(fā)工程師等理澎。

Tester

很奇怪逞力，BABOK Guide3.0把Tester作為了一個單獨的部分，而沒有合并在Implement SME中糠爬。

我細想了一下寇荧，這有可能是和職責(zé)相關(guān)的。

在一個職能比較完備的企業(yè)中执隧，實施開發(fā)與質(zhì)量保證一般是平級的兩個部門揩抡。

而他們關(guān)注的內(nèi)容也有不同。

實施開發(fā)關(guān)注設(shè)計和實現(xiàn)镀琉，而質(zhì)量保證關(guān)注質(zhì)量和結(jié)果達成峦嗤。

Operational Support

這個Stakeholder是一個會被忽略的角色。

我們在講非功能需求的時候會有個“可維護性”屋摔。

在我們的需求分析過程中寻仗，需要考慮對于運營、售后的相關(guān)角色的訴求凡壤。

比如是否需要加入一些監(jiān)控的報表署尤，一些報告耙替，一些檢查點來方便他們開展工作。

在進行需求評審的時候曹体，是否需要邀請他們參加俗扇，畢竟他們承擔(dān)著一線的壓力。

Sponsor

這個不用說了箕别，相當(dāng)?shù)闹匾模o錢的老大。

基本上相關(guān)的所有需要審批串稀、簽字確認的除抛，都需要他參與。

Supplier

有的時候會有些供應(yīng)商之類的干系人母截。

比如你使用了第三方控件到忽，或者開源的什么代碼。

比如你需要其他系統(tǒng)提供數(shù)據(jù)接口清寇，或者其他系統(tǒng)需要你提供接口喘漏。

Regulator

把這個放到最后講，我想說华烟，這個是最最最最容易被忽略的干系人翩迈。

這個月我去上海出差，晚上去外灘轉(zhuǎn)了圈盔夜。

返回的路上想著騎一輛mobike回酒店负饲。

結(jié)果走了很遠才在路邊找到一輛。

我在刷二維碼的時候喂链，過來了一個警察叔叔返十。

“這里不能停車●锰伲”他以為我把車子停這里了吧慢。

“不是我停的，我準(zhǔn)備騎走赏表〖焓”我趕忙解釋。

“快騎走瓢剿，要不我就拖走了逢慌。”

在騎回去的路上间狂，我真的看到有警察叔叔拖著一輛單車攻泼。

真的是拖著。

我想，當(dāng)初應(yīng)該是沒有做Regulator的相關(guān)分析吧忙菠。

相關(guān)的道路何鸡、城市管理法規(guī)，在進行產(chǎn)品設(shè)計的時候需要進行考慮牛欢。

特別是一些金融類的骡男、涉密類的產(chǎn)品，在進行分析的時候傍睹，一定要考慮一些規(guī)章制度的要求隔盛。

而在我們企業(yè)內(nèi)部，也存在一些Regulator拾稳。

比如我們的QA部門吮炕、PMO等等。

小婧是一名行走在實踐路上的資深業(yè)務(wù)分析師（BA）访得，如果想與我同行龙亲，就請關(guān)注我吧！