作者 | 劉一穎

寫在前面

To B系統(tǒng)的交付項目，往往是新手BA(Business Analyst，業(yè)務分析師)經(jīng)歷項目時最難上手的類型之一。

其原因是一般企業(yè)內(nèi)部系統(tǒng)業(yè)務邏輯復雜，年代久遠，集成的系統(tǒng)繁多，同時經(jīng)常又遠離終端用戶，很難產(chǎn)生共情。其次，由于B端產(chǎn)品往往涉及垂直領域較多，如車企、制造業(yè)、金融... 撲面而來的專業(yè)名詞，讓從未接觸過的小白們應接不暇。

于是，新手BA可能會給那些還未曾謀面的客戶們不自覺打上 “行業(yè)專家”，“深耕多年”，“經(jīng)驗豐富” 等標簽。但實際上，由于項目行業(yè)，和客戶類型的不同，一些“先入為主“的標簽，反而會不自覺的成為我們工作時的隱形障礙。

通過下面這幾個小故事，看看下面這幾個“標簽”，是否也曾在你的腦海中徘徊？

1. 用戶應該是“小白”

小A在一個遺留系統(tǒng)改造項目中發(fā)現(xiàn)，原有后臺管理人員系統(tǒng)中一些功能的操作異常復雜，甚至整個界面只有兩個按鈕，很多操作還要在系統(tǒng)外進行，對用戶仿佛很不友好。

當小A在提出可能的風險時，資深BA給出了解釋：

• 第一，當時客戶確實資金有限，部分功能連前端界面都沒做，因為發(fā)現(xiàn)數(shù)據(jù)量大且系統(tǒng)間依賴太強，不如用excel再上傳順手。
• 第二，這個賬號的操作人員都是客戶側(cè)資深的同事，大家都已經(jīng)系統(tǒng)非常熟悉。

一番話，小A受到了很大啟發(fā)。

原來“MVP"的思想不僅多用于To C 產(chǎn)品創(chuàng)意驗證, B端系統(tǒng)的設計同樣適用。在該類場景下用戶往往都不是“小白”，用戶的“資深”程度和對系統(tǒng)的熟悉程度是產(chǎn)品設計時很重要的考慮因素。

在之后項目的過程中，小A還遇到了很多類似的場景：

“某鏈接本不應支持該類跳轉(zhuǎn)，為什么我們還要給用戶這個入口?“

“某輸入框為什么沒有做類型校驗，而是可以隨意輸入?”

“某選項在真實場景下沒有用戶去選，為什么還要保留?“

......

在初步的業(yè)務梳理和系統(tǒng)走查的過程中，新手BA經(jīng)常發(fā)現(xiàn)，很多看似”不合邏輯“的功能或校驗缺失的情況。但每次和客戶溝通下來都發(fā)現(xiàn)，背后有很多的歷史和限制原因。比如一些看似“重要“校驗的缺失，也許會影響大家的一些操作效率，但是在對effort 與風險權衡，和對歷史用戶的使用習慣調(diào)研后，“線上”+“線下”，“系統(tǒng)邏輯”+ “規(guī)則約束” 等方式往往可能是客戶更青睞的選擇。比如上面故事中，對于小A有些復雜的操作，對于”資深客戶“來說，卻有著不太高的學習成本和較低的出錯風險。

所以，在B端系統(tǒng)設計中，我們不能一味地只追求要想“全“所有的場景和校驗條件，以“完全小白”的角度來對待“老玩家”，而更應該集中精力抓住問題的主要矛盾，想”準確“，想”必要“，想“適合”。同時，在該類場景下，不妨多問自己和客戶幾個問題，功能優(yōu)先級可能隨之就清晰起來：

如果沒有xx功能，

• “是不是會阻礙核心業(yè)務邏輯和場景？”
• “是否會帶來非常嚴重的管理上的漏洞和風險？”
• “是否會帶來金融或法務上的風險？”
• “根據(jù)用戶平時的熟悉程度和習慣，是否是必要？”
• “最壞的場景是什么，客戶是否能接受？”
• .....

以上只是列舉其中一些可能的角度，更多的也需要大家在實踐中不斷積累。

2. 上了新系統(tǒng)，用戶的習慣要“大改變”？

隨著項目的進展，小A又遇到一件“奇事”：在對某功能回歸測試時，測試環(huán)境中發(fā)現(xiàn)一個風險較高的bug，但在生產(chǎn)環(huán)境中卻從未發(fā)現(xiàn)，且該功能已運行多年。在QA小伙伴細細探查之后發(fā)現(xiàn)，生產(chǎn)系統(tǒng)雖然存在同樣的漏洞，但幸運的是，在系統(tǒng)沒有任何提示和校驗的情況下，客戶的后臺管理人員憑借自己多年的使用經(jīng)驗并保持著良好的習慣，總在不會產(chǎn)生問題的時間段進行操作，使得問題恰好沒有發(fā)生。

這個事情讓小A意識到，很多時候系統(tǒng)僅僅是服務于用戶工作的工具。即使我們設計了再詳密的系統(tǒng)規(guī)則，考慮再全的場景，很多一線業(yè)務人員的遇到的真實問題，我們還是會遺漏。

為了避免這類情況發(fā)生，我們可以考慮：

• 首先，在用戶調(diào)研階段，充分了解用戶真實的使用習慣和場景，而不應僅僅憑借已有系統(tǒng)的流程而想當然;
• 其次，重視后期上線前商家教育環(huán)節(jié)和操作指南的撰寫。重點強調(diào)系統(tǒng)目前無法覆蓋的一些場景，或需要商家自己注意和人工配合的案例;
• 最后，和客戶著重強調(diào)系統(tǒng)上新后，用戶流程都有了哪些改變，是否需要商家額外增加流程管理與規(guī)范。

【習慣和制度的約束】 有時候會大于 【軟件的約束】。這就是為什么大多數(shù)公司依舊保留著巡店，業(yè)務抽查等必要的監(jiān)督手段。我們無法只依賴于任何一個系統(tǒng)就滿足整個公司的業(yè)務所有流轉(zhuǎn)的環(huán)節(jié)。習慣的力量，我們往往不能忽視!

3. 客戶的優(yōu)先級應該“最”重要

小A在經(jīng)歷了幾個項目后，遇到了那道經(jīng)典命題 ——用戶和客戶的價值“不吻合”。

在和客戶討論某方案的過程中，小A發(fā)現(xiàn)，目前的方案雖然滿足了 靈活的【系統(tǒng)用戶(商家)使用場景】的需求，但某些場景下，要犧牲【終端的服務用戶(顧客)】的體驗。在交流方案改進點時，客戶重申了該次系統(tǒng)改造的三個訴求：

• 整個流程可以跑通，不要阻礙系統(tǒng)用戶的操作;
• 不會增加系統(tǒng)的不穩(wěn)定性和bug;
• 用戶不會因為我們系統(tǒng)的原因提t(yī)icket，造成總公司額外的工作量

用戶體驗嘛，其實, 我覺得沒那么必要。

短短幾句，“降本增效”這四個大字，被客戶詮釋得淋漓盡致。往往這種情況下， B端系統(tǒng)中的用戶體驗就草草被犧牲掉。但其實換一個角度，只要能滿足和強調(diào)客戶的基本價值點，就可以在有限的框架內(nèi)發(fā)揮。例如該故事中，小A之后的方案便在不損害用戶體驗的前提下，著重強調(diào)客戶方更加關心的系統(tǒng)穩(wěn)定性，和特殊流程出現(xiàn)頻率低等方面，成功說服了客戶，達到了更加“三贏”的結果。

其實，新手BA經(jīng)常會遇到這種兩難的境地，不妨從以下角度考慮：

• 首先需要從產(chǎn)品愿景、價值定位、當前戰(zhàn)略目標等出發(fā)衡量，客戶口中的優(yōu)先級是否和產(chǎn)品戰(zhàn)略層的價值相符合(詳見：“當用戶不是客戶，需求價值怎么定?”);
• 其次，不妨翻出來產(chǎn)品/項目規(guī)劃時，干系人對于價值優(yōu)先級的定義。當然，在產(chǎn)品發(fā)展不同的生命周期，價值優(yōu)先級會隨之改變，需要定時回顧和迭代。
• 最后，很多情況下，客戶真正關心的優(yōu)先級和價值，早已初見端倪。比如強成本導向的客戶可能會很關心每個功能的估點，而強體驗的用戶可能會在初期調(diào)研階段參與度很高。

故事中“用戶體驗”的價值只是一個例子，往往當我們被戴上了【價值優(yōu)先級】的“緊箍咒”之后，如何在客戶可能“不那么關心”的角落做文章，爭取最優(yōu)解，就看我們BA自己”討價還價“的真本事了。

4. 客戶應該“什么都懂”!

對于新手BA來說，很容易陷入被客戶需求“牽著鼻子”走的情況，但有時候，客戶可能真的不知道自己要什么。大部分場景下，客戶對于業(yè)務邏輯會較為熟悉，但是對于系統(tǒng)化語言或者數(shù)字化實現(xiàn)方案的術語可能存在盲區(qū)。當然，偶爾也會遇到對接人是新調(diào)來該產(chǎn)品線的PO, 或者是和其他部門協(xié)調(diào)集成系統(tǒng)時的PO。

那么當遇到PO是“新人“，小A也是新人的情況時, 可能會出現(xiàn)從客戶處輸入較少，需求確認不清等風險。此時，需要考慮：

(1) 和客戶統(tǒng)一語言。客戶可能不熟悉系統(tǒng)語言，或者是使用一些比較過時或非正式描述。所以，在確認需求的過程中，最好能用他聽得懂的語言進行講解，并強調(diào)系統(tǒng)和現(xiàn)實中的mapping關系。

(2) 從真實業(yè)務場景出發(fā)。客戶可能對一線系統(tǒng)操作人員的細節(jié)更熟悉，但對系統(tǒng)整體設計的邏輯不清晰。我們可以先嘗試從物理世界的操作出發(fā)再還原到系統(tǒng)上，便于他更好地理解

(3) 從宏觀到微觀。曾經(jīng)有客戶不認同迭代開發(fā)的方式，原因是沒有功能全景，零散的故事卡確認會議，使得需求看似沒有邏輯。由于對系統(tǒng)的整體性理解不夠，項目進展和迭代間的功能聯(lián)系總處于黑盒狀態(tài)。針對這種情況，我們可以考慮

• 首先，在寫故事卡的時候，針對客戶不熟悉的一些細節(jié)，可以適當展開描述，或者配系統(tǒng)圖、流程圖，方便其理解；
• 其次，在每次需求確認會開始時，就明確該迭代的需求對應整個用戶旅程中的哪個部分(比如，采購商品)和 完成客戶/用戶的哪些預期目標(采購流程中可以創(chuàng)建訂單 和 添加基本商品)；
• 最后，將有完整故事線的卡盡量放在相近的時間點去確認，并提前告知客戶主題，方便客戶去邀請相關更熟悉業(yè)務的干系人一同參會。

總結

期望通過幾個小故事，分享一些新手BA在與客戶“心理戰(zhàn)”的過程中，可能會遇到的情況。其實，歸根到底， 充分熟悉和理解項目背景，產(chǎn)品愿景和干系人關系永遠是重要的第一步。如果你與小A一樣，無法理解客戶做的一些決定，遇到無數(shù)卡住的瞬間，不如回到最初的起點，也許一切都有了答案。

最后的最后，在拒接“標簽化”客戶的同時，也不要“標簽化”自己，在認清當前不足的前提下，也要敢于質(zhì)疑，勇敢嘗試, 最終才能自信地和客戶"say no“。

歡迎大家討論你曾經(jīng)給客戶打過的那些“標簽”吧!