BA全稱Business Analyst，即業(yè)務(wù)分析師胸懈。經(jīng)常會被別人問起担扑，“BA平常到底都在做些什么呀”？
在一個不熟悉的人眼里趣钱，BA的工作看起來就是不停的溝通涌献、寫寫用戶故事、主持一下會議什么的首有。最風光可能是在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：負責行業(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的照料，只要能夠推動整個項目按正確的方式做事涮拗，那就義不容辭地納入自己的工作范圍乾戏。
所以簡單來說迂苛，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ù)温亲。對于客戶而言，需要思考要不要接下這個需求杯矩？
- 大致要做什么功能栈虚？對現(xiàn)在的產(chǎn)品定位、業(yè)務(wù)流程和價值有什么影響菊碟。
- 如果要做的話节芥，需要多少人天，對預(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的核心職責陵刹，那這部分應(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)付菜皂。比如：
- 開發(fā)說這個用戶故事卡的功能比想象中的復(fù)雜贞绵，可能做不完了。
- 有些新功能與舊功能有沖突恍飘，事前沒有想到榨崩。
- 正在開發(fā)的過程中，客戶提出了一個新的需求章母。
- Desk Check的時候發(fā)現(xiàn)功能實現(xiàn)與設(shè)計的有出入母蛛。
等等。
理想情況下乳怎，在保證效果的同時彩郊，這部分工作所花的時間和精力越少越好。如果主要精力都花在了這上面舞肆，就要思考是不是哪些環(huán)節(jié)出了問題焦辅。
第三方集成支持
對于大客戶而言，很少有不涉及集成的項目椿胯。有些項目筷登，集成是一個大部頭。以我上一個項目為例哩盲，涉及到的集成系統(tǒng)有將近10個前方。BA有時會花大量的時間在討論集成方案、梳理接口字段廉油、制定集成計劃上惠险。
BA也要關(guān)心集成么？當然抒线。集成也事關(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)品的情況∫眨或者有計劃地安排一些用戶走訪來收集反饋瘪匿。還要對各個渠道收集到的反饋進行整合，劃分優(yōu)先級纵朋，排進計劃柿顶。
新人培養(yǎng)
對于一個項目制的公司來說，一個項目團隊在穩(wěn)定運行一段時間后就要開始考慮人員更替的問題操软。保持適度的人員更替率是一個團隊健康的表現(xiàn)嘁锯。不僅對于個人還是對于團隊而言都是好的。
在人員更替的過程中，知識傳遞和能力培養(yǎng)是必不可少的家乘。
一個新人上項目蝗羊，不論什么角色，BA都要給他們講解行業(yè)背景仁锯，業(yè)務(wù)知識耀找，當前產(chǎn)品的功能模塊，未來產(chǎn)品的走向等等业崖。如果新加入的是一個BA野芒，項目上的老BA還需要承擔起B(yǎng)uddy的職責，負責BA的能力成長双炕。除了日常項目上的事情狞悲，可能還需要計劃一些針對性的講授和練習，利用工作之余開展session妇斤。而作為新BA摇锋，也要投入巨大的精力快速了解業(yè)務(wù)上下文，在面臨日常項目上的挑戰(zhàn)之外站超，還得抽時間給自己充電荸恕。
一個交付壓力比較大的項目，往往會疏于人員培養(yǎng)死相，平常項目上的事都忙不過來哪還有時間去帶新人呀融求。這樣的局面往往造成老人們越來越忙，承擔越來越多的上下文媳纬，變得越來越重要双肤，也越來越不可替換。最終老人們抱怨在項目上做的太久卻下不了項目钮惠，新人們抱怨沒有人帶自己茅糜，幫不上忙。所以素挽，帶新人是一個一勞永逸的事情蔑赘，每個項目上的BA都應(yīng)該做好帶新人的準備。
項目管理
BA最后的一塊工作就是項目管理预明。ThoughtWorks是敏捷的倡導(dǎo)者缩赛，所有的團隊也都是敏捷團隊，它們是自組織跨職能的撰糠。所以酥馍，有很多團隊并沒有項目經(jīng)理這樣的角色。項目經(jīng)理的職責被分散到整個團隊身上阅酪，由整個團隊共同承擔旨袒。
而BA由于本身工作職責的原因汁针，具有更大的視野，離客戶更近砚尽，天然地具有承擔項目管理的優(yōu)勢施无。所以，也應(yīng)更加義不容辭的承擔起部分項目管理的職責必孤。
需求變更的處理猾骡，迭代計劃的指定，客戶關(guān)系的管理敷搪，還有組織日常大大小小的會都可以BA來做兴想。
BA也會扮演起敏捷管理教練的角色，對于敏捷實踐進行裁剪找到最適合這個項目的實踐购啄。引導(dǎo)團隊成員如何正確的站會襟企、IPM、DeskCheck狮含、Retro。及時指出團隊日常實踐中的問題曼振，慢慢的形成團隊自己的敏捷文化几迄。
BA的工作因項目的不同而略有不同
以上大約是BA在產(chǎn)品Delivery階段的工作內(nèi)容全景。
以我上一個項目為例冰评，BA工作的各個部分精力分配大約如下：
不要擔心映胁，并不是在所有的項目中BA都要做這么多的事情。每個項目因為所處階段甲雅，客戶合作方式解孙，團隊組成方式的不同，BA的工作側(cè)重點也不同弛姜。
比如，對于離岸交付類型的項目，客戶和交付團隊分處兩地。這樣在需求和方案對齊方面花費的精力就會更多牙咏。反之，對于在岸項目，交付團隊在客戶現(xiàn)場工作，那么這部分的工作就相對少一些。
對于Time & Material，也就是按人天收費的項目。由于項目風險主要落在甲方，所以為了減少風險奸披，客戶往往會把需求把控的比較嚴格，攥在自己手里，給予我們BA的分析空間不大沃疮。因此，這種項目的需求發(fā)現(xiàn)和收集部分的工作就會比較少左医，主要精力在需求分析和方案落地方面。由于一般這種項目乙方不會配備專門的項目經(jīng)理同木，所以BA也會兼職來做項目管理的事情浮梢。而對于Fix Bid，也就是一口價收費的項目彤路，項目風險落在乙方秕硝。所以我們會配備自己的項目經(jīng)理，并且對需求和產(chǎn)品的把控度更大洲尊。這樣远豺，需求發(fā)現(xiàn)和收集部分的工作就會很多，而項目管理的事情也可以有項目經(jīng)理承擔起來坞嘀。
還有對于比如3-4個月的短期項目憋飞，沒有換人的需要，BA自然也就沒有帶新人的工作了姆吭。而對于某些超過一年的長期項目，BA就需要花一部分精力在帶新人上唁盏。
寫在最后
在ThoughtWorks與其說BA是一個職位内狸，不如說是一系列職責的集合。在這里厘擂，沒人會清晰的告訴你一定要做什么昆淡，或者不能做什么。
對于一個敏捷團隊刽严，與眾不同的一點在于昂灵，BA要做的工作不是寫在Job Description上的，而是需要自己去定義的舞萄。所以剛上項目的新BA可能會感到些許迷茫眨补，不知道自己該做什么，不知道自己與其他角色的分工是怎么樣的倒脓，不知道該如何與其他人合作撑螺。我常常會告訴新人，上項目后的第一件事就是找出自己在這個團隊中的定位崎弃，明白自己能夠或者應(yīng)該提供什么樣的價值甘晤。同樣是BA含潘，每一個項目中的定位都會與以往不同，相應(yīng)的工作內(nèi)容也不盡相同线婚。
怎么去找定位呢遏弱？不妨和項目里的BA，PM或者TL聊一聊：
- 說說你對這個項目的期望塞弊，你希望從這個項目中獲得什么漱逸？得到哪方面的成長？希望這個項目提供給你哪方面的機會居砖？
- 讓PM虹脯、TL、BA說說團隊對你的期望是什么奏候？希望你承擔什么樣的職責循集，做出什么樣的貢獻。
兩邊對齊的期望即是BA的定位蔗草。
其實咒彤，BA的工作沒有說明書，也不必照本宣科地工作咒精∠庵可以做的事情可能非常的多，但應(yīng)找準重點并適當?shù)胤峙渥约旱木δＰ穑悦庀萑朊β档漠斚滦穑允Я朔较颉?/p>
名詞解釋：
BA：業(yè)務(wù)分析師
UX：用戶體驗設(shè)計師
Dev：程序員
User Story： 用戶故事，敏捷中用以表述一小塊產(chǎn)品特性和用戶價值的載體范咨。
IPM：迭代計劃會議故觅，在每個迭代開始之前舉行的團隊會議，用來澄清下個迭代的開發(fā)任務(wù)和規(guī)劃下個迭代的工作范圍渠啊。
Story Kick-off: 用戶故事卡“開卡”输吏，在進行每個用戶故事的開發(fā)之前，由BA替蛉、DEV贯溅、UX、QA等相關(guān)人員一起參與的活動躲查，以便澄清將要開發(fā)的需求內(nèi)容和范圍它浅。
Story Desk Check: 用戶故事卡快速驗收，在用戶故事開發(fā)完成之后熙含，由BA罚缕、DEV、UX怎静、QA等相關(guān)人員一起參與的活動邮弹，以便快速驗證開發(fā)的功能是否符合需求黔衡。
Showcase: 產(chǎn)品展示會議，在一個開發(fā)迭代完成之后腌乡，對該迭代的產(chǎn)品功能進行展示盟劫。
Retro: 回顧會議，在一個迭代完成之后与纽，對該迭代中團隊的各個方面進行回顧侣签，提出建議以便持續(xù)改進。
文/ThoughtWorks汪澤遠
更多精彩洞見急迂，請關(guān)注微信公眾號：ThoughtWorks洞見
