BA全稱Business Analyst，即業務分析師。經常會被別人問起，“BA平常到底都在做些什麼呀”？
在一個不熟悉的人眼裡，BA的工作看起來就是不停的溝通、寫寫使用者故事、主持一下會議什麼的。最風光可能是在showcase（產品展示會議）的時候，產品受到了使用者和客戶的肯定；最落魄可能是在IPM（迭代計劃會議）的時候，被開發們不停地挑戰需求的合理性和完整性。除此之外，有時BA自己也感覺忙忙碌碌、但卻又不知道在忙些什麼。
有文章介紹了在ThoughtWorks做BA是怎樣一種體驗，也有新BA分享她的ThoughtWorks BA初體驗。
接下來，我想從一個“老BA”的視角，分享一下在一個軟體交付專案中BA到底都會做些什麼？
BA的工作因產品所處的階段不同而略有不同
首先要說的是，本文主要說的是BA在產品Delivery階段需要做的事情。專案從前期的探索發現（Discovery）——定義要解決的問題和原型方案，到啟動（Inception）——對產品定位、MVP範圍、迭代計劃達成一致，再到進入開發（Delivery）——完成產品的第一個MVP版本，最後通過產品運營收集反饋，迭代地進行產品演進（Evolution）。在這一系列環節中，BA做的事情不盡相同，各有各的側重點。
Discovery中的BA：負責行業研究，企業業務的快速梳理，並和使用者體驗設計師（UX）一起通過使用者訪談、現場調查等方式收集需求，定位問題並形成粗粒度的解決方案。
Inception中的BA：在梳理業務需求的同時能夠對方案進行收斂，定義MVP和產品路線圖，並配合開發進行工作量估算和給出具體的釋出計劃。
Delivery中的BA：將粗粒度的方案進一步細化，並將需求溝通給整個交付團隊，保證需求可以正確地交付。如果有新的需求湧現出來，也需要按照Discovery和inception階段中的方法來進行分析和交付。
Evolution中的BA：在產品上線後收集線上使用者的反饋，參與產品運營和持續演進。
其中，Delivery環節往往是時間最久、精力耗費最多的一個環節，也往往是一個新BA起步的地方。所以接下來主要關注在這個環節。
BA都有哪幾個方面的工作？
作為連線業務和開發的橋樑，BA的主要工作可以分成三個部分：第一部分是圍繞需求展開的，涉及需求生命週期的各個環節。第二部分是圍繞交付展開，包括確保需求在各個角色之間的流動過程中不失真，確保需求被正確地開發出來。第三部分是一些“雜事”。專案中大大小小的事情往往都需要BA的照料，只要能夠推動整個專案按正確的方式做事，那就義不容辭地納入自己的工作範圍。
所以簡單來說，BA的工作就是確保整個團隊做正確的事，以及正確地做事。
詳細來說，包括以下：
需求發現、收集和方案提議
雖然在產品開發之前會有一個產品定位和業務全景圖，但是任何產品在進入開發之後一定還是會源源不斷地湧現出新的需求。這些需求或來自各個層面的反饋，或來自客戶領導，或來自客戶其他的業務部門，或來自我們的主動挖掘。持續不斷地發現、接受和處理這些新需求是BA的一個工作常態。
比如，一個汽車行業的客戶，兄弟業務部門提出需求：希望我們的產品可以支援他們的汽車售後保修業務。對於客戶而言，需要思考要不要接下這個需求？
- 大致要做什麼功能？對現在的產品定位、業務流程和價值有什麼影響。
- 如果要做的話，需要多少人天，對預算有什麼影響？
對於BA而言，接下來要做的就是回答上面的問題，把資訊提供給客戶輔助他們做決策。
可是需求太粗略了，怎麼辦呢？於是，BA計劃了一次使用者走訪，搞清現在的業務流程和痛點。搞明白其他業務部門提的需求到底是在說什麼，是不是真實的需求，有沒有什麼坑。接著，根據走訪的結果梳理需求，然後和UX一起討論粗粒度的業務方案，這個過程跟Inception很像。
接著拿著這個方案跟客戶大致過一下，沒有什麼問題的話就叫上開發一起估算工作量，這時候估算只是粗略的，可能以20人天為一個單位。有了大致的方案、低保真的原型圖和粗略的工作量估算，就可以把這些整理一下彙報給客戶了。
最終的結果可能是一個做或者不做的決定，以及對應的排期計劃。有了這些，那麼這塊BA的工作就算告一段落了。一般一個100人天+的大塊新需求分析下來，可能至少需要1~2周的時間。注意你還有日常的交付要做，這些只能抽時間精力來搞。
這一塊的工作對於BA往往比較有挑戰，雖然有可能並不會進入後續的交付，但卻是體現BA核心價值的一部分工作。
需求分析與方案落地
一個大塊的新需求有了方案之後，接下來就是把它細化，然後拆成使用者故事並寫出驗收條件。這就是BA的基本功了。
從這時開始，思考粒度會從粗到細迅速下降。BA會和UX一起討論：頁面上具體該有什麼資訊呈現，有什麼樣的功能按鍵，互動和體驗是怎樣的。會針對各種細節爭論不休，就為了呈現最好的使用者體驗。
然後就是把腦子裡的想法寫出來啦。按照使用者故事的格式，思考怎麼寫可以讓開發和業務部門都能看的明白清晰。寫的過程中還可能會有新的想法出來，然後又跑去跟UX或者Dev討論。
最終這一部分工作的產出就是拆分後的使用者故事列表，以及已經填充好內容的使用者故事。
如果一定要說BA的核心職責，那這部分應該算得上。又快又好的把這部分工作完成，然後騰出精力去做其他的事情。不要滿足於停留在這裡，畢竟這只是BA的基本功。
需求和方案對齊
因為Thoughtworks是一家專業服務公司，也就是說我們為客戶提供解決方案。基於這樣的合作模式，意味著BA需要將自己設計的方案和客戶進行溝通，確保大家對於需求以及對應的方案有一致的理解。
為了這個目的，理想的方式是和客戶一起工作。增加客戶的參與感，讓他們也參與到自己的產品設計過程中去。這樣就不用花費過多的精力去跟客戶同步方案，然後來來回回的修改、彙報。但鑑於每個專案客戶的情況不同，有時候BA可能需要專門安排一些Story Review或者Solution Review的會議來跟客戶過方案。
這塊的工作其實很考驗BA的軟技能，因為在這個過程中往往充滿了各種意見上的衝突。怎麼樣能把自己的想法有條理地表達出來，怎麼樣能管理好客戶的期望，怎麼樣去應對客戶的質疑都是一門學問。
需求溝通與交付
如果客戶拍了板，那麼接下來就可以進入開發了。BA工作中的溝通部分從主外變成了主內。也就是說，外部跟客戶之間已經達成了一致，接下來主要是把需求和方案准確地傳達給交付團隊，然後保證使用者故事可以被準確的開發出來。BA主要做的事包括，制定迭代計劃、主持IPM、參與Story Kickoff和Desk Check、組織Showcase、追蹤迭代速率，以及隨時澄清Dev，QA提出的各種問題。
別看這個過程貌似簡單，卻可能會有很多意料之外的情況發生。如果前面的工作做得好，這裡可能會比較順利，否則很多問題都會在這時候暴露出來，讓BA疲於應付。比如：
- 開發說這個使用者故事卡的功能比想象中的複雜，可能做不完了。
- 有些新功能與舊功能有衝突，事前沒有想到。
- 正在開發的過程中，客戶提出了一個新的需求。
- Desk Check的時候發現功能實現與設計的有出入。
等等。
理想情況下，在保證效果的同時，這部分工作所花的時間和精力越少越好。如果主要精力都花在了這上面，就要思考是不是哪些環節出了問題。
第三方整合支援
對於大客戶而言，很少有不涉及整合的專案。有些專案，整合是一個大部頭。以我上一個專案為例，涉及到的整合系統有將近10個。BA有時會花大量的時間在討論整合方案、梳理介面欄位、制定整合計劃上。
BA也要關心整合麼？當然。整合也事關業務場景、資料流。這些介面在什麼業務場景下被呼叫，我們需要發什麼樣的資料給第三方，需要從第三方拿什麼樣的資料。從索要第三方的資料樣例檔案，到一個一個地分析這些欄位的業務價值以判斷哪些可以為我所用，再到撰寫需求文件給第三方，這些都需要BA的參與。
而且整合最大的精力消耗在於溝通和談判。比如，按對齊的介面文件開發，卻發現第三方的實現沒有按照文件來；單方面的介面變動沒有事前通知；介面傳的資料有誤，汙染了自身系統的資料，等等。
整合可能是BA最不喜歡參與的事情了。
上線和線上支援
如果以上的工作都順利扛過來了，那麼恭喜你，產品終於可以上線了。
這部分的工作包括上線過程的準備和上線之後的支援。比如寫一大推的文件：使用者手冊，釋出版本說明書等等。然後是密集的showcase, 畢竟新產品要上線，各個干係人都聞訊而來。某個客戶方的大老闆來了要show一下，使用者代表來了要show一下，其他部門的人來了也要show一下。
千辛萬苦終於上了線，接下來還要面對一大堆的線上問題。一般會有一、二、三線的產品支援團隊，幫助將一些簡單的問題進行過濾。但最終到BA這裡的問題也不在少數。
除此之外，BA可能還會需要思考如何收集反饋進行產品演進。比如，用一些使用者行為檢測工具對產品埋點，追蹤使用者使用產品的情況。或者有計劃地安排一些使用者走訪來收集反饋。還要對各個渠道收集到的反饋進行整合，劃分優先順序，排進計劃。
新人培養
對於一個專案制的公司來說，一個專案團隊在穩定執行一段時間後就要開始考慮人員更替的問題。保持適度的人員更替率是一個團隊健康的表現。不僅對於個人還是對於團隊而言都是好的。
在人員更替的過程中，知識傳遞和能力培養是必不可少的。
一個新人上專案，不論什麼角色，BA都要給他們講解行業背景，業務知識，當前產品的功能模組，未來產品的走向等等。如果新加入的是一個BA，專案上的老BA還需要承擔起Buddy的職責，負責BA的能力成長。除了日常專案上的事情，可能還需要計劃一些針對性的講授和練習，利用工作之餘開展session。而作為新BA，也要投入巨大的精力快速瞭解業務上下文，在面臨日常專案上的挑戰之外，還得抽時間給自己充電。
一個交付壓力比較大的專案，往往會疏於人員培養，平常專案上的事都忙不過來哪還有時間去帶新人呀。這樣的局面往往造成老人們越來越忙，承擔越來越多的上下文，變得越來越重要，也越來越不可替換。最終老人們抱怨在專案上做的太久卻下不了專案，新人們抱怨沒有人帶自己，幫不上忙。所以，帶新人是一個一勞永逸的事情，每個專案上的BA都應該做好帶新人的準備。
專案管理
BA最後的一塊工作就是專案管理。ThoughtWorks是敏捷的倡導者，所有的團隊也都是敏捷團隊，它們是自組織跨職能的。所以，有很多團隊並沒有專案經理這樣的角色。專案經理的職責被分散到整個團隊身上，由整個團隊共同承擔。
而BA由於本身工作職責的原因，具有更大的視野，離客戶更近，天然地具有承擔專案管理的優勢。所以，也應更加義不容辭的承擔起部分專案管理的職責。
需求變更的處理，迭代計劃的指定，客戶關係的管理，還有組織日常大大小小的會都可以BA來做。
BA也會扮演起敏捷管理教練的角色，對於敏捷實踐進行裁剪找到最適合這個專案的實踐。引導團隊成員如何正確的站會、IPM、DeskCheck、Retro。及時指出團隊日常實踐中的問題，慢慢的形成團隊自己的敏捷文化。
BA的工作因專案的不同而略有不同
以上大約是BA在產品Delivery階段的工作內容全景。
以我上一個專案為例，BA工作的各個部分精力分配大約如下：
不要擔心，並不是在所有的專案中BA都要做這麼多的事情。每個專案因為所處階段，客戶合作方式，團隊組成方式的不同，BA的工作側重點也不同。
比如，對於離岸交付型別的專案，客戶和交付團隊分處兩地。這樣在需求和方案對齊方面花費的精力就會更多。反之，對於在岸專案，交付團隊在客戶現場工作，那麼這部分的工作就相對少一些。
對於Time & Material，也就是按人天收費的專案。由於專案風險主要落在甲方，所以為了減少風險，客戶往往會把需求把控的比較嚴格，攥在自己手裡，給予我們BA的分析空間不大。因此，這種專案的需求發現和收集部分的工作就會比較少，主要精力在需求分析和方案落地方面。由於一般這種專案乙方不會配備專門的專案經理，所以BA也會兼職來做專案管理的事情。而對於Fix Bid，也就是一口價收費的專案，專案風險落在乙方。所以我們會配備自己的專案經理，並且對需求和產品的把控度更大。這樣，需求發現和收集部分的工作就會很多，而專案管理的事情也可以有專案經理承擔起來。
還有對於比如3-4個月的短期專案，沒有換人的需要，BA自然也就沒有帶新人的工作了。而對於某些超過一年的長期專案，BA就需要花一部分精力在帶新人上。
寫在最後
在ThoughtWorks與其說BA是一個職位，不如說是一系列職責的集合。在這裡，沒人會清晰的告訴你一定要做什麼，或者不能做什麼。
對於一個敏捷團隊，與眾不同的一點在於，BA要做的工作不是寫在Job Description上的，而是需要自己去定義的。所以剛上專案的新BA可能會感到些許迷茫，不知道自己該做什麼，不知道自己與其他角色的分工是怎麼樣的，不知道該如何與其他人合作。我常常會告訴新人，上專案後的第一件事就是找出自己在這個團隊中的定位，明白自己能夠或者應該提供什麼樣的價值。同樣是BA，每一個專案中的定位都會與以往不同，相應的工作內容也不盡相同。
怎麼去找定位呢？不妨和專案裡的BA，PM或者TL聊一聊：
- 說說你對這個專案的期望，你希望從這個專案中獲得什麼？得到哪方面的成長？希望這個專案提供給你哪方面的機會？
- 讓PM、TL、BA說說團隊對你的期望是什麼？希望你承擔什麼樣的職責，做出什麼樣的貢獻。
兩邊對齊的期望即是BA的定位。
其實，BA的工作沒有說明書，也不必照本宣科地工作。可以做的事情可能非常的多，但應找準重點並適當地分配自己的精力，以免陷入忙碌的當下，迷失了方向。
名詞解釋：
BA：業務分析師
UX：使用者體驗設計師
Dev：程式設計師
User Story： 使用者故事，敏捷中用以表述一小塊產品特性和使用者價值的載體。
IPM：迭代計劃會議，在每個迭代開始之前舉行的團隊會議，用來澄清下個迭代的開發任務和規劃下個迭代的工作範圍。
Story Kick-off: 使用者故事卡“開卡”，在進行每個使用者故事的開發之前，由BA、DEV、UX、QA等相關人員一起參與的活動，以便澄清將要開發的需求內容和範圍。
Story Desk Check: 使用者故事卡快速驗收，在使用者故事開發完成之後，由BA、DEV、UX、QA等相關人員一起參與的活動，以便快速驗證開發的功能是否符合需求。
Showcase: 產品展示會議，在一個開發迭代完成之後，對該迭代的產品功能進行展示。
Retro: 回顧會議，在一個迭代完成之後，對該迭代中團隊的各個方面進行回顧，提出建議以便持續改進。
文/ThoughtWorks汪澤遠
更多精彩洞見，請關注微信公眾號：ThoughtWorks洞見