BA全稱Business Analyst，即業(yè)務(wù)分析師。經(jīng)常會被別人問起：

在一個不熟悉的人眼里，BA的工作看起來就是不停的溝通、寫寫用戶故事、主持一下會議什么的。最風(fēng)光可能是在showcase（產(chǎn)品展示會議）的時候，產(chǎn)品受到了用戶和客戶的肯定；最落魄可能是在IPM（迭代計劃會議）的時候，被開發(fā)們不停地挑戰(zhàn)需求的合理性和完整性。除此之外，有時BA自己也感覺忙忙碌碌、但卻又不知道在忙些什么。

有文章介紹了在ThoughtWorks做BA是怎樣一種體驗，也有新BA分享她的ThoughtWorks BA初體驗。

接下來，我想從一個“老BA”的視角，分享一下在一個軟件交付項目中BA到底都會做些什么？

BA的工作因產(chǎn)品所處的階段不同而略有不同

首先要說的是，本文主要說的是BA在產(chǎn)品Delivery階段需要做的事情。項目從前期的探索發(fā)現(xiàn)（Discovery）——定義要解決的問題和原型方案，到啟動（Inception）——對產(chǎn)品定位、MVP范圍、迭代計劃達成一致，再到進入開發(fā)（Delivery）——完成產(chǎn)品的第一個MVP版本，最后通過產(chǎn)品運營收集反饋，迭代地進行產(chǎn)品演進（Evolution）。在這一系列環(huán)節(jié)中，BA做的事情不盡相同，各有各的側(cè)重點。

Discovery中的BA：負責(zé)行業(yè)研究，企業(yè)業(yè)務(wù)的快速梳理，并和用戶體驗設(shè)計師（UX）一起通過用戶訪談、現(xiàn)場調(diào)查等方式收集需求，定位問題并形成粗粒度的解決方案。

Inception中的BA：在梳理業(yè)務(wù)需求的同時能夠?qū)Ψ桨高M行收斂，定義MVP和產(chǎn)品路線圖，并配合開發(fā)進行工作量估算和給出具體的發(fā)布計劃。

Delivery中的BA：將粗粒度的方案進一步細化，并將需求溝通給整個交付團隊，保證需求可以正確地交付。如果有新的需求涌現(xiàn)出來，也需要按照Discovery和inception階段中的方法來進行分析和交付。

Evolution中的BA：在產(chǎn)品上線后收集線上用戶的反饋，參與產(chǎn)品運營和持續(xù)演進。

其中，Delivery環(huán)節(jié)往往是時間最久、精力耗費最多的一個環(huán)節(jié)，也往往是一個新BA起步的地方。所以接下來主要關(guān)注在這個環(huán)節(jié)。

BA都有哪幾個方面的工作？

作為連接業(yè)務(wù)和開發(fā)的橋梁，BA的主要工作可以分成三個部分：第一部分是圍繞需求展開的，涉及需求生命周期的各個環(huán)節(jié)。第二部分是圍繞交付展開，包括確保需求在各個角色之間的流動過程中不失真，確保需求被正確地開發(fā)出來。第三部分是一些“雜事”。項目中大大小小的事情往往都需要BA的照料，只要能夠推動整個項目按正確的方式做事，那就義不容辭地納入自己的工作范圍。

所以簡單來說，

詳細來說，包括以下：

需求發(fā)現(xiàn)、收集和方案提議

雖然在產(chǎn)品開發(fā)之前會有一個產(chǎn)品定位和業(yè)務(wù)全景圖，但是任何產(chǎn)品在進入開發(fā)之后一定還是會源源不斷地涌現(xiàn)出新的需求。這些需求或來自各個層面的反饋，或來自客戶領(lǐng)導(dǎo)，或來自客戶其他的業(yè)務(wù)部門，或來自我們的主動挖掘。持續(xù)不斷地發(fā)現(xiàn)、接受和處理這些新需求是BA的一個工作常態(tài)。

比如，一個汽車行業(yè)的客戶，兄弟業(yè)務(wù)部門提出需求：希望我們的產(chǎn)品可以支持他們的汽車售后保修業(yè)務(wù)。對于客戶而言，需要思考要不要接下這個需求？

1. 大致要做什么功能？對現(xiàn)在的產(chǎn)品定位、業(yè)務(wù)流程和價值有什么影響。

2. 如果要做的話，需要多少人天，對預(yù)算有什么影響？

對于BA而言，接下來要做的就是回答上面的問題，把信息提供給客戶輔助他們做決策。

可是需求太粗略了，怎么辦呢？于是，BA計劃了一次用戶走訪，搞清現(xiàn)在的業(yè)務(wù)流程和痛點。搞明白其他業(yè)務(wù)部門提的需求到底是在說什么，是不是真實的需求，有沒有什么坑。接著，根據(jù)走訪的結(jié)果梳理需求，然后和UX一起討論粗粒度的業(yè)務(wù)方案，這個過程跟Inception很像。

接著拿著這個方案跟客戶大致過一下，沒有什么問題的話就叫上開發(fā)一起估算工作量，這時候估算只是粗略的，可能以20人天為一個單位。有了大致的方案、低保真的原型圖和粗略的工作量估算，就可以把這些整理一下匯報給客戶了。

最終的結(jié)果可能是一個做或者不做的決定，以及對應(yīng)的排期計劃。有了這些，那么這塊BA的工作就算告一段落了。一般一個100人天+的大塊新需求分析下來，可能至少需要1~2周的時間。注意你還有日常的交付要做，這些只能抽時間精力來搞。

這一塊的工作對于BA往往比較有挑戰(zhàn)，雖然有可能并不會進入后續(xù)的交付，但卻是體現(xiàn)BA核心價值的一部分工作。

需求分析與方案落地

一個大塊的新需求有了方案之后，接下來就是把它細化，然后拆成用戶故事并寫出驗收條件。這就是BA的基本功了。

從這時開始，思考粒度會從粗到細迅速下降。BA會和UX一起討論：頁面上具體該有什么信息呈現(xiàn)，有什么樣的功能按鍵，交互和體驗是怎樣的。會針對各種細節(jié)爭論不休，就為了呈現(xiàn)最好的用戶體驗。

然后就是把腦子里的想法寫出來啦。按照用戶故事的格式，思考怎么寫可以讓開發(fā)和業(yè)務(wù)部門都能看的明白清晰。寫的過程中還可能會有新的想法出來，然后又跑去跟UX或者Dev討論。

最終這一部分工作的產(chǎn)出就是拆分后的用戶故事列表，以及已經(jīng)填充好內(nèi)容的用戶故事。

如果一定要說BA的核心職責(zé)，那這部分應(yīng)該算得上。又快又好的把這部分工作完成，然后騰出精力去做其他的事情。不要滿足于停留在這里，畢竟這只是BA的基本功。

需求和方案對齊

因為Thoughtworks是一家專業(yè)服務(wù)公司，也就是說我們?yōu)榭蛻籼峁┙鉀Q方案?；谶@樣的合作模式，意味著BA需要將自己設(shè)計的方案和客戶進行溝通，確保大家對于需求以及對應(yīng)的方案有一致的理解。

為了這個目的，理想的方式是和客戶一起工作。增加客戶的參與感，讓他們也參與到自己的產(chǎn)品設(shè)計過程中去。這樣就不用花費過多的精力去跟客戶同步方案，然后來來回回的修改、匯報。但鑒于每個項目客戶的情況不同，有時候BA可能需要專門安排一些Story Review或者Solution Review的會議來跟客戶過方案。

這塊的工作其實很考驗BA的軟技能，因為在這個過程中往往充滿了各種意見上的沖突。怎么樣能把自己的想法有條理地表達出來，怎么樣能管理好客戶的期望，怎么樣去應(yīng)對客戶的質(zhì)疑都是一門學(xué)問。

需求溝通與交付

如果客戶拍了板，那么接下來就可以進入開發(fā)了。BA工作中的溝通部分從主外變成了主內(nèi)。也就是說，外部跟客戶之間已經(jīng)達成了一致，接下來主要是把需求和方案準確地傳達給交付團隊，然后保證用戶故事可以被準確的開發(fā)出來。BA主要做的事包括，制定迭代計劃、主持IPM、參與Story Kickoff和Desk Check、組織Showcase、追蹤迭代速率，以及隨時澄清Dev，QA提出的各種問題。

別看這個過程貌似簡單，卻可能會有很多意料之外的情況發(fā)生。如果前面的工作做得好，這里可能會比較順利，否則很多問題都會在這時候暴露出來，讓BA疲于應(yīng)付。比如：

1.  開發(fā)說這個用戶故事卡的功能比想象中的復(fù)雜，可能做不完了。

2. 有些新功能與舊功能有沖突，事前沒有想到。

3. 正在開發(fā)的過程中，客戶提出了一個新的需求。

4. Desk Check的時候發(fā)現(xiàn)功能實現(xiàn)與設(shè)計的有出入。

等等。

理想情況下，在保證效果的同時，這部分工作所花的時間和精力越少越好。如果主要精力都花在了這上面，就要思考是不是哪些環(huán)節(jié)出了問題。

第三方集成支持

對于大客戶而言，很少有不涉及集成的項目。有些項目，集成是一個大部頭。以我上一個項目為例，涉及到的集成系統(tǒng)有將近10個。BA有時會花大量的時間在討論集成方案、梳理接口字段、制定集成計劃上。

BA也要關(guān)心集成么？當(dāng)然。集成也事關(guān)業(yè)務(wù)場景、數(shù)據(jù)流。這些接口在什么業(yè)務(wù)場景下被調(diào)用，我們需要發(fā)什么樣的數(shù)據(jù)給第三方，需要從第三方拿什么樣的數(shù)據(jù)。從索要第三方的數(shù)據(jù)樣例文件，到一個一個地分析這些字段的業(yè)務(wù)價值以判斷哪些可以為我所用，再到撰寫需求文檔給第三方，這些都需要BA的參與。

而且集成最大的精力消耗在于溝通和談判。比如，按對齊的接口文檔開發(fā)，卻發(fā)現(xiàn)第三方的實現(xiàn)沒有按照文檔來；單方面的接口變動沒有事前通知；接口傳的數(shù)據(jù)有誤，污染了自身系統(tǒng)的數(shù)據(jù)，等等。

集成可能是BA最不喜歡參與的事情了。

上線和線上支持

如果以上的工作都順利扛過來了，那么恭喜你，產(chǎn)品終于可以上線了。

這部分的工作包括上線過程的準備和上線之后的支持。比如寫一大推的文檔：用戶手冊，發(fā)布版本說明書等等。然后是密集的showcase, 畢竟新產(chǎn)品要上線，各個干系人都聞訊而來。某個客戶方的大老板來了要show一下，用戶代表來了要show一下，其他部門的人來了也要show一下。

千辛萬苦終于上了線，接下來還要面對一大堆的線上問題。一般會有一、二、三線的產(chǎn)品支持團隊，幫助將一些簡單的問題進行過濾。但最終到BA這里的問題也不在少數(shù)。

除此之外，BA可能還會需要思考如何收集反饋進行產(chǎn)品演進。比如，用一些用戶行為檢測工具對產(chǎn)品埋點，追蹤用戶使用產(chǎn)品的情況?；蛘哂杏媱澋匕才乓恍┯脩糇咴L來收集反饋。還要對各個渠道收集到的反饋進行整合，劃分優(yōu)先級，排進計劃。

新人培養(yǎng)

對于一個項目制的公司來說，一個項目團隊在穩(wěn)定運行一段時間后就要開始考慮人員更替的問題。保持適度的人員更替率是一個團隊健康的表現(xiàn)。不僅對于個人還是對于團隊而言都是好的。

在人員更替的過程中，知識傳遞和能力培養(yǎng)是必不可少的。

一個新人上項目，不論什么角色，BA都要給他們講解行業(yè)背景，業(yè)務(wù)知識，當(dāng)前產(chǎn)品的功能模塊，未來產(chǎn)品的走向等等。如果新加入的是一個BA，項目上的老BA還需要承擔(dān)起B(yǎng)uddy的職責(zé)，負責(zé)BA的能力成長。除了日常項目上的事情，可能還需要計劃一些針對性的講授和練習(xí)，利用工作之余開展session。而作為新BA，也要投入巨大的精力快速了解業(yè)務(wù)上下文，在面臨日常項目上的挑戰(zhàn)之外，還得抽時間給自己充電。

一個交付壓力比較大的項目，往往會疏于人員培養(yǎng)，平常項目上的事都忙不過來哪還有時間去帶新人呀。這樣的局面往往造成老人們越來越忙，承擔(dān)越來越多的上下文，變得越來越重要，也越來越不可替換。最終老人們抱怨在項目上做的太久卻下不了項目，新人們抱怨沒有人帶自己，幫不上忙。所以，帶新人是一個一勞永逸的事情，每個項目上的BA都應(yīng)該做好帶新人的準備。

項目管理

BA最后的一塊工作就是項目管理。ThoughtWorks是敏捷的倡導(dǎo)者，所有的團隊也都是敏捷團隊，它們是自組織跨職能的。所以，有很多團隊并沒有項目經(jīng)理這樣的角色。項目經(jīng)理的職責(zé)被分散到整個團隊身上，由整個團隊共同承擔(dān)。

而BA由于本身工作職責(zé)的原因，具有更大的視野，離客戶更近，天然地具有承擔(dān)項目管理的優(yōu)勢。所以，也應(yīng)更加義不容辭的承擔(dān)起部分項目管理的職責(zé)。

需求變更的處理，迭代計劃的指定，客戶關(guān)系的管理，還有組織日常大大小小的會都可以BA來做。

BA也會扮演起敏捷管理教練的角色，對于敏捷實踐進行裁剪找到最適合這個項目的實踐。引導(dǎo)團隊成員如何正確的站會、IPM、DeskCheck、Retro。及時指出團隊日常實踐中的問題，慢慢的形成團隊自己的敏捷文化。

BA的工作因項目的不同而略有不同

以上大約是BA在產(chǎn)品Delivery階段的工作內(nèi)容全景。

以我上一個項目為例，BA工作的各個部分精力分配大約如下：

不要擔(dān)心，并不是在所有的項目中BA都要做這么多的事情。每個項目因為所處階段，客戶合作方式，團隊組成方式的不同，BA的工作側(cè)重點也不同。

比如，對于離岸交付類型的項目，客戶和交付團隊分處兩地。這樣在需求和方案對齊方面花費的精力就會更多。反之，對于在岸項目，交付團隊在客戶現(xiàn)場工作，那么這部分的工作就相對少一些。

對于Time & Material，也就是按人天收費的項目。由于項目風(fēng)險主要落在甲方，所以為了減少風(fēng)險，客戶往往會把需求把控的比較嚴格，攥在自己手里，給予我們BA的分析空間不大。因此，這種項目的需求發(fā)現(xiàn)和收集部分的工作就會比較少，主要精力在需求分析和方案落地方面。由于一般這種項目乙方不會配備專門的項目經(jīng)理，所以BA也會兼職來做項目管理的事情。而對于Fix Bid，也就是一口價收費的項目，項目風(fēng)險落在乙方。所以我們會配備自己的項目經(jīng)理，并且對需求和產(chǎn)品的把控度更大。這樣，需求發(fā)現(xiàn)和收集部分的工作就會很多，而項目管理的事情也可以有項目經(jīng)理承擔(dān)起來。

還有對于比如3-4個月的短期項目，沒有換人的需要，BA自然也就沒有帶新人的工作了。而對于某些超過一年的長期項目，BA就需要花一部分精力在帶新人上。

寫在最后

在ThoughtWorks與其說BA是一個職位，不如說是一系列職責(zé)的集合。在這里，沒人會清晰的告訴你一定要做什么，或者不能做什么。

對于一個敏捷團隊，與眾不同的一點在于，BA要做的工作不是寫在Job Description上的，而是需要自己去定義的。所以剛上項目的新BA可能會感到些許迷茫，不知道自己該做什么，不知道自己與其他角色的分工是怎么樣的，不知道該如何與其他人合作。我常常會告訴新人，上項目后的第一件事就是找出自己在這個團隊中的定位，明白自己能夠或者應(yīng)該提供什么樣的價值。同樣是BA，每一個項目中的定位都會與以往不同，相應(yīng)的工作內(nèi)容也不盡相同。

怎么去找定位呢？不妨和項目里的BA，PM或者TL聊一聊：

1. 說說你對這個項目的期望，你希望從這個項目中獲得什么？得到哪方面的成長？希望這個項目提供給你哪方面的機會？

2. 讓PM、TL、BA說說團隊對你的期望是什么？希望你承擔(dān)什么樣的職責(zé)，做出什么樣的貢獻。

兩邊對齊的期望即是BA的定位。

其實，BA的工作沒有說明書，也不必照本宣科地工作?？梢宰龅氖虑榭赡芊浅５亩?，但應(yīng)找準重點并適當(dāng)?shù)胤峙渥约旱木?，以免陷入忙碌的?dāng)下，迷失了方向。

名詞解釋：