第二章：Business Analysis Key Concepts

在正式介紹Business Analysis的六大知識領域之前，先就一些后面會用到的關鍵概念進行了介紹。

特別是這里面有些困惑大家已久的概念，對這些概念進行聲明，便于達成共識后進行后續知識的學習。

Business Analysis Core Concept Model

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

這個模型可以用作：

在業務分析過程中，對專業業務和領域進行描述。

對于業務分析過程中遇到的信息進行評估。

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

變革Change

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

It works to improve the performance of an enterprise.

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

也可以說，這個Change是需要與戰略、目標一致的。

需要Need

Need is a problem or opportunity to be addressed.

我們可以把Need理解為純業務的，與技術、解決方案無關的。

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

我們在做解決方案的時候，一般都是從問題出發的。

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

（可以點擊鏈接直接跳轉查看相應的文章）

我們的日常工作中最經常接觸到的是Need，對于Change一般是中高級領導會去思考的問題。

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

也是一種不忘初心。

當然也不排除分析Need后，導致了Change的發生。

解決方案Solution

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

解決方案是用來解決問題，滿足相應環境下的需求的。

這點就不多說了，沒有什么歧義。

干系人Stakeholder

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

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

考過PMP的同學都知道，基本上你想得到的人都屬于干系人。

這里也不做過多說明了。

價值Value

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

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

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

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

另外，有一點需要特別注意。

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

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

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

其認為風險與機遇都是需要管理的，都屬于風險管理的范疇。

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

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

上下文Context

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

這個概念在BABOK Guide 3.0里面被作為關鍵概念提出，我深感其專業。

現在很多的教程、文章在說需求分析的時候，從來不提業務環境。

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

這就是無視環境。

還有在分析一些非功能需求時，也從來不考慮環境。

另外，我一直覺得，任何的需求都是基于業務場景的。

不管你這個需求的性質是什么。

如果沒有合理的業務場景，并且假設太多，那么你憑什么說你的設計和解決方案是有價值的呢？

總結一下，當你在進行分析的時候，從這六個問題分別去尋找答案：

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

本節主要介紹了再BA工作過程中會涉及到的一些關鍵信息。

這些信息大部分會反復出現在六大知識領域的任務中。

Business Analysis

關于這個概念，在第一章已經進行了說明。

此處不再說明。

Business Analysis Information

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

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

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

Design

Design is a usable representation of a solution.

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

Design聚焦在如何才能讓Solution實現其價值。

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是一個比企業、組織更大的范圍。

我自作主張的將其理解為“圈子”，也就是為實現目標的一個大圈子。

這個圈子里有所有的干系組織，以及相關的解決方案。

這個圈子是虛擬的，沒有一個非常清晰的邊界，并且它的邊界是由業務定義的。

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顯然是我們常規意義上理解的組織、企業、單位。

Plan

Plan is a proposal for doing or achieving something.

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

以PMBOK為例，其中的過程組中就有不少在做規劃，也就是Plan的工作。

Business Analysis也是如此。

需要有一定的策劃和規劃去進行整體工作的指導。

Requirement

Requirement is a usable representation of a need.

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

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

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

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

但是至少BA需要參與到Design中，以確保Solution可以實現Requirement，這也是BA評估的一個職責。

另外，現在越來越多的團隊采用Agile的模式。

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

因為兩者之間沒有很清晰的交接，而是不斷的迭代優化，相輔相承。

Risk

在BABOK Guide3.0中，對Risk的概念及應對措施的描述，與PMBOK一致。

Requirements Classification Schema

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

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

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

Business Requirements——對應Change

Stakeholder Requirements——對應Need

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

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

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

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

一般來說，我們寫產品的SRS都會有一個章節專門寫“升級影響”。

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

比如對原有歷史數據的影響，是否需要更新、遷移。

這類需求其實就是Transition Requirement。

它有一個特點就是：當實施后就失效了。

我做系統升級只會做一次數據遷移，不會反反復復的做。

所以這個需求只會發生在升級的時候。

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

作為用戶我曾經經歷過因為軟件供應商系統升級導致數據丟失的痛苦。

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

Stakeholders

在BA的工作中會遇到形形色色的Stakeholder，甚至比項目經理遇到的種類更多。

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

BA

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

更何況現在大部分情況下，你并不是團隊中唯一從事BA相關工作的人。

另外，作為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的供應商，你的Customer是銀行，而End User是儲戶。

我們以前最常遇到的問題是，你去業務訪談的對象并不是一線的用戶，而是一些管理人員。

他們可能曾經是一線用戶，但是因為離開一線很長時間了，對于現狀其實了解是很有限的。

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

另外，在后面的章節中，對于Customer和End User的界定，會分別被界定為External和Internal。

對，你沒看錯，是Customer在外，End User在內。

我仔細思考了下，這個內外應該是對于Solution而言的。

End User直接包括在Solution中。

Domain Subject Matter Expert

業務領域專家們很重要，你的需求、解決方案的評估都要聽取他們的意見。

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

深鉆業務，把自己培養成為領域專家，那么你在做決策和分析的時候更有底氣。

而在面對下面這類角色時，BA就是領域專家。

Implement Subject Matter Expert

實施團隊主要的職責是實現解決方案。

他們以BA的Requirement為輸入，進行Solution的設計，最終提交BA進行Value的評估。

這個實施團隊會包括很多的角色，比如：架構設計師、開發工程師等。

Tester

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

我細想了一下，這有可能是和職責相關的。

在一個職能比較完備的企業中，實施開發與質量保證一般是平級的兩個部門。

而他們關注的內容也有不同。

實施開發關注設計和實現，而質量保證關注質量和結果達成。

Operational Support

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

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

在我們的需求分析過程中，需要考慮對于運營、售后的相關角色的訴求。

比如是否需要加入一些監控的報表，一些報告，一些檢查點來方便他們開展工作。

在進行需求評審的時候，是否需要邀請他們參加，畢竟他們承擔著一線的壓力。

Sponsor

這個不用說了，相當的重要，給錢的老大。

基本上相關的所有需要審批、簽字確認的，都需要他參與。

Supplier

有的時候會有些供應商之類的干系人。

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

比如你需要其他系統提供數據接口，或者其他系統需要你提供接口。

Regulator

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

這個月我去上海出差，晚上去外灘轉了圈。

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

結果走了很遠才在路邊找到一輛。

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

“這里不能停車。”他以為我把車子停這里了。

“不是我停的，我準備騎走。”我趕忙解釋。

“快騎走，要不我就拖走了。”

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

真的是拖著。

我想，當初應該是沒有做Regulator的相關分析吧。

相關的道路、城市管理法規，在進行產品設計的時候需要進行考慮。

特別是一些金融類的、涉密類的產品，在進行分析的時候，一定要考慮一些規章制度的要求。

而在我們企業內部，也存在一些Regulator。

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

小婧是一名行走在實踐路上的資深業務分析師（BA），如果想與我同行，就請關注我吧！