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

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

一種是最近幾年非常火熱的SaaS模式，它是基于雲的應用，可以授權給企業、組織或者個人進行使用，通過公共網絡訪問使用。

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

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

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

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

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

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

一、需求範圍控制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、不輕易承諾

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、生産問題處理規範化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、結語

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

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

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

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

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

本文由 @樹園聊B端 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部