|前言

2021年換工作，要做一下階段性知識總結(jié)，另外跟Jira社區(qū)馬暢老師聊到C端產(chǎn)品經(jīng)理在B端的不適應(yīng)，由此想到B端大客戶交付中棘手的需求問題。照例，先說下視角基礎(chǔ)，筆者有10年軟件行業(yè)經(jīng)驗，近7年交付過多個大客戶項目，做過各種不同的項目，遇到過各種類型的客戶。視角局限性在于，所有大客戶均為運營商。

本文主要討論做需求時的棘手問題，在職責上與項目經(jīng)理有些交集。討論的主題包括：需求變更、交付不一致、需求收集、需求池管理、高管需求應(yīng)對等，每個主題先分析原因，再給出解決思路。若有不同想法，歡迎加微信（ecdoer）溝通。

注：文中“客戶”通常代指甲方或公司內(nèi)部統(tǒng)一接收業(yè)務(wù)方需求的接口人。

01

客戶是變更狂魔

客戶需求經(jīng)常變更是個頭痛的問題，意味著我們沒能解決客戶的問題，同時浪費了時間，也會讓團隊產(chǎn)生挫敗感而影響士氣?？蛻纛l繁變更可能的原因有4個：需求與產(chǎn)品間有鴻溝、客戶非原始需求提出人、客戶本身沒想清楚，客戶業(yè)務(wù)頻繁變化。

• 需求與產(chǎn)品間有鴻溝主要是客戶描述的需求和他真實想要的東西不一致，直到把產(chǎn)品給他用時，他才知道這是不是他要的；

• 客戶非原始需求提出人是客戶接到需求后，經(jīng)二次理解加工轉(zhuǎn)述給我們，即使我們給了他想要的，一旦原始需求人說不對，他分分鐘甩鍋給你背；

• 客戶本身沒想清楚是客戶直接把解決方案告訴我們，但他本身可能并沒有找到或者遺漏了真正的問題，這種功能即使交付了也解決不了問題。

• 客戶業(yè)務(wù)頻繁變化是個偽命題，更多是客戶對業(yè)務(wù)的理解頻繁變化，這種場景并不常見。

我們分3種場景來解決變更，分別是開發(fā)前、開發(fā)中和開發(fā)后。

01

開發(fā)前

開發(fā)前是需求分析階段，這里做好了可以解決80%的需求變更，解決方法是“多確認、多驗證”。

• 首先，我們一定要找到原始需求提出人，通過反復(fù)提問、多做假設(shè)、多做求證的方式，挖掘到需求“痛”的場景（5W1H）；

• 其次，借助紙、Xmind、Visio等工具把需求物化下來，讓需求方確認文字是否能表達他的想法；

• 再次，如果需求較大，還需要設(shè)計原型圖、需求說明書，讓需求方提前看到、摸到實實在在的功能和操作，來驗證是否滿足他的期望；

• 最后，我們作為B端產(chǎn)品經(jīng)理，應(yīng)該比客戶想的更多，提前把功能交付后可能的異常、引發(fā)的問題等與客戶溝通。

02

開發(fā)中

開發(fā)中是已經(jīng)進入開發(fā)過程中，客戶突然要求改方案，這種要么確實是突然業(yè)務(wù)變化了（如高管有新的指示），要么就是客戶描述需求時漏掉了關(guān)鍵信息。在這情況下更多是評估變更影響，改動量大小是否影響本次交付，是否將未完成的先簡化交付，抑或需求延遲至下期交付等。采用敏捷方法中“雙周迭代”可以弱化開發(fā)過程中變更產(chǎn)生的影響，小步快跑、迭代試錯。

03

開發(fā)后

開發(fā)后是開發(fā)上線后，每隔段時間客戶就要優(yōu)化功能。如果這種需求變更是無法避免的，解決方法是總結(jié)歷史所有變更，嘗試對功能進行抽象，看是否可以將功能設(shè)計成可配置的，抑或是否需要借用中臺的思想封裝出一個新產(chǎn)品。比如，我們在做各類流程時，發(fā)現(xiàn)列表頁、詳情頁、甚至流程本身經(jīng)常變化，消耗了大量開發(fā)團隊的時間，后來，我們做了“流程中臺”，此類變更迎刃而解。

02

客戶翻臉不認賬

明明跟客戶確認清楚需求了，開發(fā)交付后客戶翻臉不認賬，這種場景同樣既沒幫到客戶，又浪費團隊的時間。客戶不認賬的原因可能有2個：需求分析階段不負責任、參與度低，客戶承受了不便明說的壓力。解決這個問題分2種情況：

01

客戶不負責

這種首先把上文談的“開發(fā)前確認”工作做好；其次，養(yǎng)成郵件確認的習(xí)慣，把確認過程留痕，留下物證；再次，大型需求召開多人評審會議，并在會議結(jié)束后將會議紀要抄送所有人，留下人證。

02

客戶承受了不能明說的壓力

比如高管插手、本身無決策權(quán)等，這種情況首先要了解客戶的組織關(guān)系和他的處境，跟他以及其他人建立一定的私人關(guān)系，通過非正式溝通渠道盡可能多的了解情況，理解客戶面對的壓力，幫他一起應(yīng)對，適當加班修正，終有回報。另外，嘗試把關(guān)鍵決策人拉進需求確認過程，比如將需求確認郵件抄送給關(guān)鍵領(lǐng)導(dǎo)知會等。

03

客戶太沒想法（需求不明確）

客戶沒想法并不意味著給了B端產(chǎn)品經(jīng)理自由發(fā)揮的空間，如果你體會過出數(shù)十個版本，結(jié)果客戶都不認可的痛苦就能理解這種場景了?？蛻魶]想法的原因可能有2個：真的沒想法、不敢說想法。真的沒想法背后可能是懶得想，也可能是不懂業(yè)務(wù)；不敢說想法背后可能是不愿承擔決策的責任。解決這個問題有4個技巧：

01

對接Key Person

找到能明確需求的關(guān)鍵決策人，比如客戶的上級領(lǐng)導(dǎo)、關(guān)鍵業(yè)務(wù)需求方等。這種方法最直接有效，但有時客戶并不喜歡這種方法，需要產(chǎn)品經(jīng)理、項目經(jīng)理視場景拿捏尺度。

02

全面材料收集

收集跟需求相關(guān)的所有材料，包括Word文檔、匯報PPT、內(nèi)部郵件等，嘗試通過內(nèi)部材料分析可能的需求。

03

借鑒友商及互聯(lián)網(wǎng)思路

分析友商或互聯(lián)網(wǎng)相關(guān)產(chǎn)品功能模塊，根據(jù)需求相似度確認思路。

04

低成本、頻繁確認

如果對接人確實無法明確需求，此時應(yīng)該以最低成本頻繁確認，比如口頭確認、Xmind梳理核心方向等。

04

客戶太有想法（強給方案）

客戶直接給解決方案看似為產(chǎn)品經(jīng)理省事了，但如果客戶本身缺乏對業(yè)務(wù)的理解深度或不懂產(chǎn)品設(shè)計，會出現(xiàn)上線后變更率高、功能復(fù)雜等問題，對用戶、客戶和開發(fā)團隊都不利?？蛻魪娊o方案的原因可能有2個：客戶本身控制欲強、解決方案源于更高層。解決這個問題有4個技巧：

01

傾聽

多問問題多傾聽，搞清楚客戶解決方案背后的思考。

02

用數(shù)據(jù)和用戶說話

把平臺的數(shù)據(jù)和用戶意見領(lǐng)袖的反饋呈現(xiàn)給客戶，嘗試說服客戶轉(zhuǎn)變。

03

用競品說話

拿有相似需求競品的功能設(shè)計，嘗試引導(dǎo)客戶向我們期望的方向轉(zhuǎn)變。

04

適當妥協(xié)

按客戶的想法做，但爭取少做、分階段做，根據(jù)數(shù)據(jù)和用戶反饋，引導(dǎo)客戶做出轉(zhuǎn)變。

05

需求太多

需求太多是個很可怕的事，它意味著需求等待引發(fā)的業(yè)務(wù)方抱怨、頻繁加班引發(fā)的團隊怨氣、經(jīng)常被投訴引發(fā)的高管負面印象等。團隊明明干了更多的活，卻收獲了更多的差評。需求太多的原因可能有4個：對接的業(yè)務(wù)線過多、低價值需求過多、產(chǎn)品缺乏邊界、團隊研發(fā)效能低。解決這個問題有4種技巧：

01

建池

建立需求池和業(yè)務(wù)資源配額池，把團隊資源、當前需求積壓隊列、各業(yè)務(wù)方消耗的資源量等數(shù)據(jù)公開、透明的展示出來，把資源爭奪推給各業(yè)務(wù)方內(nèi)部、不同業(yè)務(wù)方之間。

02

邊界

明確團隊支撐的業(yè)務(wù)線和產(chǎn)品邊界，明確拒絕不屬于產(chǎn)品范圍的需求。

03

拉援

跟客戶打好關(guān)系，讓客戶看到團隊辛苦程度，幫忙拒絕一部分低價值需求。

04

交付改善

包括3方面：

• 簡化，復(fù)雜需求先交付核心功能；

• 復(fù)用，抽象常見功能為可復(fù)用的能力；

• 提效，通過DevOps等工具提升交付效率。

06

需求太少

需求太少同樣很可怕，它意味著我們的項目和團隊不再被需要，從長遠看可能會遭遇生存危機。需求太少的原因可能有2個：用戶有需求但沒反饋渠道、業(yè)務(wù)穩(wěn)定用戶真沒需求了。解決這個問題有2種技巧：

01

建通道、打關(guān)系

建立便捷的需求反饋渠道，可以讓用戶直接反饋工作中實際需求；跟用戶意見領(lǐng)袖打好關(guān)系，讓他們在一有需求時能直接聯(lián)系到我們。

02

造需求

首先要明確，B端造需求是件不道德的事，我們不能臆想需求。但有2種方法可以在缺需求時創(chuàng)造需求，一是產(chǎn)品使用數(shù)據(jù)，通過數(shù)據(jù)分析發(fā)現(xiàn)問題點并跟用戶進行確認；二是通過新技術(shù)、競品等借鑒式創(chuàng)新，發(fā)現(xiàn)改進點并跟用戶進行確認。離開了用戶確認，我們就走到了“偽需求”的路上。

07

考驗靈魂的高管需求

高管需求是把雙刃劍，做好、做壞的影響都很大。高管需求主要有2個難點：如何理解高管需求、如何與高管溝通需求。高管需求通常描述極簡單、抽象、空洞、難落地。理解高管需求還是要落在溝通上，與好相處的高管溝通相對容易，所以，我們從3個角度聊聊與脾氣不好、“官威重”的高管如何溝通。

01

調(diào)整心態(tài)，保持平常心

• 首先，我們要認識到很多高管在某些方面確實能力出眾，但同時，他們也存在認知的局限性，可敬仰，但無需神化；
  

• 其次，要理解在有些環(huán)境中，高管的無力感在于想法不能落地執(zhí)行，此時，官威是一種簡單粗暴的執(zhí)行力，很無奈、很悲哀，脾氣差、有官威的領(lǐng)導(dǎo)容易爭取到更多資源和下屬的執(zhí)行力，以對比其他高管形成政治競爭力，應(yīng)對他們，我們只需表現(xiàn)出自身的執(zhí)行力即可；

• 最后，有些高管拿脾氣、diss下屬當樹立權(quán)威的手段，更有甚者，只顧自己業(yè)績不顧下屬死活，同時如果他們?nèi)狈ι羁桃娊猓沁@類人不值得追隨（又累又沒成績），能遠離就遠離，遠離不了就自帶“情緒過濾器”，忽視他們的情緒，做好自己能做的事即可；

02

做事精細，少即是多

• 首先，多想少做，做的功能越多，越容易被挑刺，不如只做核心的功能，也給高管一個展示他思考全面的機會；
  

• 其次，凡做的功能必須要思考清晰、細致，用專業(yè)度鎮(zhèn)壓高管，此時，通過高保真、設(shè)計原則、細節(jié)等清晰的把想法表達出來；

03

思考、表達重邏輯

• 首先，表達簡潔有邏輯，比如結(jié)論先行、主次分明、因果清晰等，具體可讀《金字塔原理》；
  

• 其次，軟硬結(jié)合，面對自負的高管，適當?shù)恼J同，不重要的點不糾正解釋，核心理解偏差該硬剛就硬剛；

08

客戶工作敷衍or組織內(nèi)斗

客戶工作敷衍或客戶組織內(nèi)斗是一個敏感的話題，當存在這種場景，挖掘需求、確認需求、對需求達成一致等都很難。應(yīng)對這種場景，筆者暫時沒有好辦法，但提供2種應(yīng)對思路：

01

少即是多

在這種場景下做出成績很難，反而做多了被挑刺的概率更大，不如做少、做精。

02

謀與不謀

可以嘗試接近高管、貼近業(yè)務(wù)方等收集高價值的需求做，甚至嘗試謀求新的業(yè)務(wù)機會；但不應(yīng)該嘗試將客戶接口人替換掉，更換其他客戶接口人，除非足夠了解組織的政治、有足夠的政治影響力。

IT人關(guān)注并加入我們加*防走丟

企業(yè)服務(wù)IT圈：聚焦全球ToB領(lǐng)域：甲方. 廠商. 集成商. 服務(wù)商. 渠道. ISV等生態(tài)，分享業(yè)內(nèi)干貨，打造中國第一企業(yè)服務(wù)技術(shù)內(nèi)容社區(qū)和社交平臺。我們根據(jù)粉絲真實崗位情況，分別設(shè)置：創(chuàng)業(yè)高管微信群/運維技術(shù)專家群/架構(gòu)師之家/DevOps技術(shù)專家匯/ToB企業(yè)銷售互助會/ToB廠商市場人俱樂部，并為大家提供技術(shù)咨詢,營銷策劃.招聘及工作推薦等服務(wù)。請大家掃碼或者添加微信：tian1tiant,(備注個人真實職業(yè)身份信息邀請不同崗位微信群）。公眾號官方網(wǎng)站：qidao123.com，了解更多，ToB企業(yè)服務(wù)之家,社交平臺,限時注冊體驗更多服務(wù)！

關(guān)注發(fā)送關(guān)鍵字“阿發(fā)達”抽取高清視頻