B端產(chǎn)品工作不易，尤其是沒有相關(guān)經(jīng)驗的新人，難免會踩坑。為了不在同一個坑摔倒兩次，就需要及時復(fù)盤思考，針對問題給出解決方案。本文作者總結(jié)了自己在B端工作中的項目經(jīng)驗，與你分享。

可能有些朋友不了解B端產(chǎn)品交付方式，我先給大家講下目前主流的兩種交付方式，B端產(chǎn)品提供給客戶使用，目前主要有兩種方式。

一種是最近幾年非?；馃岬腟aaS模式，它是基于云的應(yīng)用，可以授權(quán)給企業(yè)、組織或者個人進行使用，通過公共網(wǎng)絡(luò)訪問使用。

另一種是較為傳統(tǒng)的本地化部署模式，也就是把應(yīng)用產(chǎn)品部署在客戶的服務(wù)器，產(chǎn)品必須通過客戶專屬網(wǎng)絡(luò)才能訪問，確保應(yīng)用以及數(shù)據(jù)的安全性。對于安全性要求比較高的企業(yè)，比如銀行和政府等企業(yè)的核心系統(tǒng)基本會選擇這種交付方式。

目前我在做的現(xiàn)場實施項目就是屬于第二種，需要把本身具備一定成熟度的產(chǎn)品在客戶現(xiàn)場的服務(wù)器進行部署，按照客戶的規(guī)章流程進行辦事，在產(chǎn)品本身的基礎(chǔ)上再迭代客戶定制化的需求，最終按照合同簽訂的項目功能范圍進行項目驗收結(jié)束。

從2021年3月底開始，我全程參與了我們公司活動營銷平臺項目的實施，如今項目一期實施已經(jīng)完成驗收，項目二期的合同已經(jīng)簽訂并開始。

在這一年多的項目經(jīng)歷中，我踩了不少坑，踩坑的過程中難免痛苦，但回頭想想也正是因為踩過坑的痛苦激勵我進行反思，才加速了我個人能力的成長。

如果你問我踩過的坑里面，哪些是我最難忘的？我會和你說是需求范圍蔓延、輕易承諾被打臉以及生產(chǎn)問題處理手忙腳亂。

下文中我會逐個進行分析，我相信這三點不僅是在現(xiàn)場實施過程中會遇到，在做B端產(chǎn)品很多朋友也有可能遇到。如果你也遇到了類似的情況，希望能給你幫助。

一、需求范圍控制

可能有些朋友對于需求范圍控制有點不理解，簡單來說就是客戶需求超出簽訂合同的約定范圍，這種情況出現(xiàn)很有可能會造成項目利潤減少甚至虧損。

針對項目制的產(chǎn)品交付，在雙方達成合作意向后，會在簽訂的合同內(nèi)明確需要交付的需求功能點清單以及系統(tǒng)要求等內(nèi)容?？梢哉f把合同內(nèi)的功能點上線完成達到合同要求后，項目就可以進入交付驗收階段，驗收通過后客戶就會把合同尾款付給公司，那么項目也就做完了。

所以從負責(zé)項目實施的乙方公司而言，自然是想辦法在合理的人力成本范圍內(nèi)，盡快完成需求功能點的上線，確保項目利潤可觀。

但是風(fēng)險點在于在簽訂合同的時候需求大多只有幾句話的描述，需要等到真正實施過程確認需求后，才能知道實現(xiàn)方式以及實際工作量。

需求是由客戶方提出及確定的，受外部環(huán)境變化影響。

客戶的需求并不會跟隨合同一成不變，而是會在合同需求的基礎(chǔ)上進行調(diào)整甚至變更，這本身是無可避免的，但是對于項目來說就會帶來不可控因素，如果把控不好就會導(dǎo)致項目虧損。

說實話，項目成本以及項目實施周期這類問題大多是公司領(lǐng)導(dǎo)或者項目經(jīng)理需要承擔(dān)的事情，但是產(chǎn)品經(jīng)理作為需求的具象化以及項目的關(guān)鍵角色，其實是需求范圍把控的關(guān)鍵人員，我們需要關(guān)注這件事情并通過自己的方法把控需求范圍，才能和領(lǐng)導(dǎo)以及項目經(jīng)理進行順暢溝通，也有助于自己未來的職業(yè)發(fā)展。

需求范圍蔓延這種情況其實并非不可預(yù)見，往往在雙方合同簽訂時，會協(xié)商預(yù)留一部分預(yù)算用于開發(fā)合同外的需求。

既然需求蔓延不可避免，那么產(chǎn)品經(jīng)理作為把控項目實施范圍的關(guān)鍵角色，可以做些什么呢？

可能大家會覺得控制需求范圍是項目經(jīng)理在開發(fā)階段需要負責(zé)的事情，其實并不是的，從成本角度來控制需求范圍必然會存在一定滯后性，而這種滯后性會增加項目的成本。

當(dāng)需求確定后，往往客戶對功能已經(jīng)產(chǎn)生一定的預(yù)期，如果發(fā)現(xiàn)預(yù)期工作量超標(biāo)再讓客戶調(diào)整需求，勢必會讓客戶感覺不爽，甚至可能會口頭說我們不專業(yè)。更不用說，實際工作量遠超預(yù)期工作量的情況。

實際上應(yīng)該由產(chǎn)品經(jīng)理從需求調(diào)研時就開始控制，其次才是開發(fā)環(huán)節(jié)控制。

需求調(diào)研前，產(chǎn)品經(jīng)理需要熟悉合同需求范圍，如果知道需求大致工作量更好。只有我們自己了解合同的需求范圍才便于進行把控，如果能參與項目合同范圍擬定當(dāng)然最好，如果是后期介入則需要熟讀項目合同。

熟悉后便于我們在需求調(diào)研的過程中能對客戶提出的需求進行識別，到底是合同內(nèi)還是合同外，合同外的需求需要識別，與項目經(jīng)理進行信息同步。

需求調(diào)研時，可以適當(dāng)發(fā)散，但要具備可落地性。適當(dāng)發(fā)散的關(guān)鍵在于不能過于限制客戶提出需求內(nèi)容，不能在最開始聊需求的時候就開始想著能不能實現(xiàn)，不能實現(xiàn)或者有難度的都建議客戶調(diào)整需求，調(diào)研目的在于需要客戶多提供些信息以便于我們挖掘需求真正的目的，而不是實現(xiàn)方式。

知道需求背后的目的后，便于我們針對目的提出我們的解決方案，而不是被業(yè)務(wù)牽著走。

具備可落地性是需要我們把控整體情況，不能任由客戶漫無邊際地提出實現(xiàn)方案，在進行具體需求設(shè)計的時候需要在具備可落地性的基礎(chǔ)上進行討論和細化需求。

在一次溝通需求的過程中，客戶提出想要實現(xiàn)活動在小程序及手機App用戶都能參與的需求，我當(dāng)時評估需求實現(xiàn)難度較大，提出能不能只在手機端實現(xiàn)。

客戶聽后就不滿意了，說為什么不能實現(xiàn)？目前已有的活動模板是在小程序進行的，而我們目前活動都支持在手機App參與，如果放棄小程序很多客戶參與都不方便，那么活動的參與人數(shù)肯定會受到影響。

在我了解到客戶的目的后，冷靜想了下雖然實現(xiàn)有難度，但是并不是一定不能實現(xiàn)，客戶的訴求并不過分，于是我便回復(fù)我明白了，我們繼續(xù)溝通其他需求，具體實現(xiàn)在開發(fā)階段進行評估。

需求調(diào)研后，發(fā)現(xiàn)開發(fā)難點及時溝通確認調(diào)整，給出理由及備用方案。前面提到了成本角度的滯后性，但是如果在開發(fā)過程中發(fā)現(xiàn)了問題需要調(diào)整實現(xiàn)方案。要敢于和客戶進行溝通確認，很多時候客戶雖然不爽，但是我們講清楚原因和備用方案后大多都會理解同意調(diào)整。

在和客戶溝通的時候，需要注意溝通方式。我總結(jié)的溝通框架是：目前遇到問題描述+問題導(dǎo)致的影響分析+調(diào)整方案描述+調(diào)整前后方案對比效果。

比如我最近做的一個需求，需求方案確定后需要調(diào)整方案。于是我找到客戶說明，在開發(fā)過程中發(fā)現(xiàn)活動發(fā)布后編輯事件規(guī)則會導(dǎo)致數(shù)據(jù)錯亂，這是需求設(shè)計過程中未考慮到的。

如果按照目前的方案上線后，可以預(yù)見會有很多客戶的記錄可能會丟失導(dǎo)致客訴。和開發(fā)人員討論后的建議方案是限制運營人員在活動發(fā)布后修改事件規(guī)則，沒有其他可行方案了。

這樣調(diào)整雖然會導(dǎo)致活動發(fā)布后無法變更事件規(guī)則帶來操作不便，但可以通過人工確認的方式規(guī)避問題出現(xiàn)，而且能夠保證客戶的數(shù)據(jù)不丟失，從而避免客訴。

客戶聽了我的描述后理解了出現(xiàn)的問題、解決方案以及影響面，同意進行需求調(diào)整。

二、不輕易承諾

如果要說在項目過程中踩過最慘痛的坑，那肯定是輕易承諾上線時間。

在和客戶溝通完需求后，客戶往往會追問一句，這個需求什么時候能夠上線？當(dāng)時缺乏”社會毒打”的我往往會根據(jù)自己對項目的了解情況，腦袋一拍給個上線時間。我想的是給個大概的時間，朝著這個目標(biāo)去努力。后面我發(fā)現(xiàn)客戶并不會這么認為，他會把我提供的時間當(dāng)成確定的時間，甚至?xí)蠄蠼o他的領(lǐng)導(dǎo)。

這種情況下我給的時間節(jié)點會成為上線的倒排時間，弄得自己和同事身心疲憊，這種情況下如果遇到難解決的生產(chǎn)問題就會打亂節(jié)奏，從而影響上線時間節(jié)點，整個項目的計劃都會被打亂。

如果沒有按時上線約定功能，客戶會找到我們要個說法，為什么承諾時間做不到？這會給到項目組壓力，催促我們盡快完成功能上線，于是項目成員往往需要加班加點完成工作，而往往這個時候更容易出現(xiàn)問題。

最后可以發(fā)現(xiàn)，因為我拍腦袋給出客戶的上線時間，不僅讓項目組上線壓力增加，而且還讓客戶面臨領(lǐng)導(dǎo)的苛責(zé)，會造成我本人信用度的降低，甚至影響后續(xù)項目的工作開展。

為什么客戶會找我這個產(chǎn)品經(jīng)理提供上線時間呢？

我想了下，首先是因為產(chǎn)品經(jīng)理和客戶的溝通頻繁，客戶對于產(chǎn)品經(jīng)理的熟悉程度和信任程度較高。其次是客戶需要了解功能上線情況做好工作安排，最后客戶是想要一個保證，保證需求上線的時間節(jié)點和自己的預(yù)期一致，實際情況是我們沒辦法保證，因為具體上線時間由客戶方項目經(jīng)理確定。我在當(dāng)時提供上線時間一方面是想滿足客戶的預(yù)期，另一方面是想證明項目組的能力，只是當(dāng)時沒想到會搬起石頭砸自己的腳。

記得今年5月份有次項目晨會，之前我評估是5月底能上線的。因為時間評估有偏差，導(dǎo)致該功能要延期在6月的版本上線。于是客戶就不滿意了，說每次你們評估的工作量都不準(zhǔn)確，我都通知客戶在端午節(jié)進行領(lǐng)取了，結(jié)果你們說功能上線不了，這個責(zé)任我沒辦法承擔(dān)，你們也承擔(dān)不了。這個情況我不滿意，你們最近加班趕下進度，務(wù)必要在5月底上線。

整個項目組經(jīng)過持續(xù)一周的加班才趕上進度，雖然按期上線了，但是同事們那段時間都很疲憊，也影響了后續(xù)功能的開發(fā)效率。

經(jīng)歷過幾次慘痛的教訓(xùn)后，我下決心改掉輕易承諾的毛病，想辦法提高自己的專業(yè)性，經(jīng)過一段時間的摸索后，我找到了自己的應(yīng)對方法。

現(xiàn)在當(dāng)客戶問我需求上線時間的時候，我會按照以下三個步驟進行處理：

1. 先反問客戶的預(yù)期時間是什么時候，以及為什么是這個時間節(jié)點。如果是個人意愿的原因可以嘗試進行說服，如果是外部不可變條件限制那就需要及時和項目經(jīng)理同步信息，提前進行風(fēng)險管理。
2. 根據(jù)目前項目的計劃告知預(yù)期的可實現(xiàn)性，如果存在風(fēng)險我會和客戶說明風(fēng)險點，先降低客戶預(yù)期，讓客戶提前做好風(fēng)險預(yù)案，避免后續(xù)因為未按預(yù)期上線導(dǎo)致的手忙腳亂。如果具備可能性，我會和客戶說，目前看具備可行性，具體需要和開發(fā)同事確認需求后進行工作量評估再給出答復(fù)。
3. 客戶如果再追問時間，我會說明即使我現(xiàn)在給出上線時間，也是我拍腦袋給出來的肯定不準(zhǔn)確，而且還有可能會打亂項目計劃。具體時間等我們明確需求后再評估相對可行的時間。

聽起來可能會感覺有些圓滑，但是這確實是我踩過坑后總結(jié)和使用的方法，也確實有效。不輕易承諾并不是學(xué)會圓滑，而是在降低客戶對于上線時間節(jié)點的預(yù)期，保持項目組的信用度，便于雙方長期合作。

有次在溝通活動模板的需求過程中，在溝通完具體需求后，業(yè)務(wù)又來問我大概的上線時間。

我回復(fù)說你的預(yù)期是什么，是要配合某個大型活動嗎?

客戶說是的， 最好是在10月份上線，我希望在國慶節(jié)用這個新的活動模板上線新的活動，這樣既能滿足節(jié)假日上線活動的目的，也能給客戶帶去新的玩法。

我回復(fù)，那我明白了。目前項目有兩個需求推進中，如果按照目前開發(fā)進度10月份上線會存在風(fēng)險，是否有其他備用方案呢？比如用現(xiàn)在的活動模板舉行活動。

客戶說沒有備用方案，這也是領(lǐng)導(dǎo)要求的時間點。那按照目前的開發(fā)進度，你估計什么時候能夠上線?

我說，這個時間我這邊目前給不出來，你的訴求我基本了解。我整理下最近準(zhǔn)備開發(fā)的需求，我們估計要調(diào)整下需求優(yōu)先級，確定需求優(yōu)先級后我和開發(fā)同事一起評估開發(fā)計劃后，在本周三下午給你反饋具體時間。

這時候客戶理解的具體情況，大多會接納我的意見，后續(xù)只要我們按照約定的時間給出開發(fā)計劃即可，有開發(fā)計劃后便于進行具體的溝通。

三、生產(chǎn)問題處理規(guī)范化

生產(chǎn)問題處理無疑是我最頭疼的問題。

因為生產(chǎn)問題它不可控，它出現(xiàn)的時候往往沒有跡象，而且需要盡快解決，但是想要解決需要項目組成員花費時間和精力，遇到難解決的問題耗時較多無疑會影響項目后續(xù)的開發(fā)計劃，影響項目整體進度。

經(jīng)過這一年多在客戶現(xiàn)場與生產(chǎn)問題的“交手”，我發(fā)現(xiàn)解決問題的最重要的并不是馬上響應(yīng)，而是對生產(chǎn)問題保持平常心，保持平常心的意思是對于生產(chǎn)問題的出現(xiàn)無需感到意外，更沒必要因為生產(chǎn)問題手忙腳亂，內(nèi)心急躁，只有對生產(chǎn)問題保持敬畏心和平常心我們才能冷靜地分析問題，盡快查找問題出現(xiàn)原因并解決問題。

按照我個人的經(jīng)驗，我會把生產(chǎn)問題歸為三類，分別是人為問題、設(shè)計問題以及系統(tǒng)問題。

第一類是人為問題，就是由操作人員錯誤的操作行為導(dǎo)致的。常見的原因是操作人員對于系統(tǒng)不熟悉或者操作過程不細心。如果分析問題后發(fā)現(xiàn)是人為問題，首先需要想辦法修復(fù)數(shù)據(jù)，恢復(fù)系統(tǒng)正常。然后分析問題出現(xiàn)的操作過程，對操作人員進行培訓(xùn)或者建立操作檢查規(guī)范，甚至可以增加審核流程用來規(guī)避人為的導(dǎo)致的問題。

第二類是設(shè)計問題，就是在需求設(shè)計或者開發(fā)設(shè)計的過程中影響考慮不充分，導(dǎo)致系統(tǒng)出現(xiàn)問題。這種情況常見的出現(xiàn)節(jié)點是上線后出現(xiàn)問題，這時候可以通過回退舊版本暫時解決問題，然后再針對出現(xiàn)問題的部分進行優(yōu)化迭代。如果是上線一段時間后，因為功能設(shè)計不完善導(dǎo)致問題出現(xiàn)，短時間內(nèi)就需要在開發(fā)層面先定位和解決問題，然后盡快優(yōu)化需求或開發(fā)設(shè)計方案，安排版本更新解決問題。出現(xiàn)這種問題，就需要想辦法在需求設(shè)計或開發(fā)設(shè)計階段規(guī)范流程，增加設(shè)計方案考慮場景，提升項目成員專業(yè)程度從而避免問題出現(xiàn)。

第三類是系統(tǒng)問題，就是系統(tǒng)本身出現(xiàn)的問題。比如服務(wù)器壓力較大或者數(shù)據(jù)庫出現(xiàn)問題，那就大多需要從系統(tǒng)或硬件層面去定位和解決問題，通過增加服務(wù)器或擴充數(shù)據(jù)庫容量解決問題，或者通過優(yōu)化代碼性能解決問題。這種問題大多是開發(fā)同事需要考慮優(yōu)化的，作為產(chǎn)品經(jīng)理需要了解問題出現(xiàn)以及解決情況，在后續(xù)做類似需求過程中進行考慮。

講完分類后，和大家講下我排查問題的思路。

當(dāng)出現(xiàn)生產(chǎn)問題后，首先是對問題情況進行描述，了解大致情況。然后是和操作人員（或客戶）確認操作流程，確認操作流程無誤后，開發(fā)同事查詢具體操作時的系統(tǒng)日志定位問題。大多數(shù)情況就能定位到問題出現(xiàn)的原因，如果查詢不到日志情況那么定位問題以及解決問題花費的時間就會增加。

定位到問題后，首先可在測試環(huán)境嘗試是否能復(fù)現(xiàn)，如果能夠復(fù)現(xiàn)那么大多是代碼問題，如果不能復(fù)現(xiàn)那么很可能是不同環(huán)境帶來的問題，具體情況就需要排查。

其次是評估問題的影響面，有多少數(shù)據(jù)或者客戶受到了影響，影響的結(jié)果是這樣，會造成多少損失。

最后是項目組成員討論給出問題解決方案，解決方案最好能在測試環(huán)境進行驗證，驗證無誤后再安排版本上線。

如果是因為生產(chǎn)問題造成客戶損失，需要進行道歉并做出相應(yīng)的解釋，如果損失較大還需要給出客戶的補償方案。

在問題解決后最好還與問題相關(guān)同事召開問題復(fù)盤會議，回顧問題出現(xiàn)的原因、問題排查和解決過程，降低后續(xù)相同問題出現(xiàn)的可能性，提升問題的處理效率。

出現(xiàn)問題并不可怕，怕的是手忙腳亂導(dǎo)致更大的問題。我們可以告訴自己，出現(xiàn)問題解決問題就好。當(dāng)然每個產(chǎn)品情況不同，我提供的流程只能作為參考，推薦你按照自己產(chǎn)品的實際情況，制定解決問題的流程。

四、結(jié)語

做B端產(chǎn)品并不是件輕松的事，沒有相關(guān)經(jīng)歷的我們難免踩坑，但最好我們要爭取相同的坑不踩兩次。這就需要我們在踩坑后及時復(fù)盤思考，思考問題出現(xiàn)原因，并針對問題制定解決方案，想辦法降低下次踩坑的概率。

想要控制好項目的需求范圍，需要我們深度參與到項目實施的過程中，不讓自己被產(chǎn)品經(jīng)理的角色限制，把項目保質(zhì)保量地交付作為我們的目標(biāo)。

不輕易承諾不只是對自己負責(zé)，也是對客戶負責(zé)，更是對公司負責(zé)。承擔(dān)責(zé)任并不輕松，但是只有承擔(dān)更多的責(zé)任后，后我們才能有更多的成長機會。

其實生產(chǎn)問題并不可怕，因為它一定會出現(xiàn)。保持平常心能讓我們更好地定位問題以及解決問題。

最后我想和你說，文中說的這三點并不只是在交付項目過程中會遇到，在做其他B端產(chǎn)品的時候也會遇到，希望文章中的方法能給你一些幫助，內(nèi)容較多，感謝你閱讀完。