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

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

一種是最近幾年非?；馃岬腟aaS模式，它是基于云的應用，可以授權給企業、組織或者個人進行使用，通過公共網絡訪問使用。

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

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

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

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

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

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

一、需求范圍控制

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

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

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

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

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

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

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

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

既然需求蔓延不可避免，那么產品經理作為把控項目實施范圍的關鍵角色，可以做些什么呢？

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

當需求確定后，往往客戶對功能已經產生一定的預期，如果發現預期工作量超標再讓客戶調整需求，勢必會讓客戶感覺不爽，甚至可能會口頭說我們不專業。更不用說，實際工作量遠超預期工作量的情況。

實際上應該由產品經理從需求調研時就開始控制，其次才是開發環節控制。

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

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

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

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

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

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

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

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

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

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

比如我最近做的一個需求，需求方案確定后需要調整方案。于是我找到客戶說明，在開發過程中發現活動發布后編輯事件規則會導致數據錯亂，這是需求設計過程中未考慮到的。

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

這樣調整雖然會導致活動發布后無法變更事件規則帶來操作不便，但可以通過人工確認的方式規避問題出現，而且能夠保證客戶的數據不丟失，從而避免客訴。

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

二、不輕易承諾

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

在和客戶溝通完需求后，客戶往往會追問一句，這個需求什么時候能夠上線？當時缺乏”社會毒打”的我往往會根據自己對項目的了解情況，腦袋一拍給個上線時間。我想的是給個大概的時間，朝著這個目標去努力。后面我發現客戶并不會這么認為，他會把我提供的時間當成確定的時間，甚至會上報給他的領導。

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

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

最后可以發現，因為我拍腦袋給出客戶的上線時間，不僅讓項目組上線壓力增加，而且還讓客戶面臨領導的苛責，會造成我本人信用度的降低，甚至影響后續項目的工作開展。

為什么客戶會找我這個產品經理提供上線時間呢？

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

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

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

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

現在當客戶問我需求上線時間的時候，我會按照以下三個步驟進行處理：

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

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

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

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

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

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

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

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

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

三、生產問題處理規范化

生產問題處理無疑是我最頭疼的問題。

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

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

按照我個人的經驗，我會把生產問題歸為三類，分別是人為問題、設計問題以及系統問題。

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

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

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

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

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

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

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

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

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

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

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

四、結語

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

想要控制好項目的需求范圍，需要我們深度參與到項目實施的過程中，不讓自己被產品經理的角色限制，把項目保質保量地交付作為我們的目標。

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

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

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