編輯導讀：每個人的職場之路都不是一帆風順的，總要經曆一些磕磕絆絆，産品經理也是如此。在工作過程中，前輩的意見能夠減少踩坑，更快獲得成長。才能本文作者從自身經驗出發，總結了一些容易踩的坑，希望對你有幫助。

本篇文章主要是為了分享和記錄我整理的避坑小指南和一些小案例分享。減少踩坑，人人有責。主要包括産品思考過程中針對：曆史數據兼容、曆史版本兼容、數據初始化方案、灰度設計、數據埋點這五個方面内容的思考。

一、不要忘記-兼容曆史數據

産品的工作很大一部分是在優化和疊代，也就是說我們在對一些已經在使用中的功能進行升級，那麼這些曆史功能在線上使用時必然已經産生過數據，新功能的設計時，需要考慮融合曆史的數據信息，同時還要考慮到已經在使用當前數據的上下遊系統。否則可能導緻上下遊的調用異常或者本身系統數據使用的異常。

小案例分享-1

筆者近年在負責物流相關的系統，其中涉及到對内部員工車輛的管理，前期管理的較為寬松，因此隻涉及到車牌、車型、品牌的信息，但這些信息已經在下遊業務中進行了正常的使用。随着業務精細化運營，業務側對車輛管理進行了統籌的規劃，提出了對車輛的用途(可以理解為使用場景）、車輛證件、承載量、車輛基本信息均需要進行管理。

因此勢必需要對原有維護好的數據，在新功能裡進行相應的兼容，哪些字段是需要廢棄的，哪些字段對應本次規劃中的字段，字段的必填/非必填屬性是否有變更，相關的表格設計以及提供給下遊的接口（原接口中的字段和當前有所變更）需要如果兼容才可以避免對下遊的影響。

OS：馬有失蹄，人有失手，項目上線前發現由于某個字段允許為空和原來的表定義不符導緻DBA審批不通過間接導緻項目上線延期了。同時，上線後，在用戶系統使用數據時，曆史用戶無車輛信息時會導緻系統異常空指針也讓我們吃了一虧。

小案例分析-2

第二個案例就是最近發生的，我屬于其中的下遊系統。前提設定：在物流系統中，維護物流供應商的合作關系是會根據供應商當前合作的業務來源(可以簡單的理解成業務線或事業部）進行一層過濾，用戶隻能選擇指定業務來源下的供應商。所有供應商可選信息來源于商戶系統。

然後某天業務同學說某個供應商選不到，我在排查過程中發現商戶系統頁面找不到[業務來源]這個字段了；同時在維護信息時也無法進行相關數據的維護。

在和對接的産品經理溝通後才知道他們在疊代過程中以為這個字段沒有用，直接去掉了。導緻物流系統功能使用異常。

二、不要忘記-兼容曆史版本

由于考慮用戶使用感受，除非功能真的極具價值或存在阻斷型問題，通常是不建議發布強制升級的APP版本的。因此當功能涉及到APP端升級後才可以使用時，必須要提前考慮到，如果用戶不升級，那系統要怎麼處理以及如何用舊前端兼容新後端且确保系統不會報錯。這種情況，如果前端是新增入口後的功能，則通常影響不大，畢竟用戶不升級時，是看不到新功能入口的，則不會觸發新邏輯，對用戶來說隻是因為個人沒有升級而繼續使用老功能而已。

但是如果本身入口是曆史存在的，那麼就需要謹慎考慮了。

小案例分享

前提設定：業務期望限制某種類型倉庫在APP端的退貨功能。系統原操作流程是點擊退貨，進入新頁面後可以創建不同類型的退貨單進行退貨處理。這其實是一個比較簡單的小功能，隻需要對于特定類型的倉庫在點擊退貨時進行阻斷或者不展示退貨按鍵就可以了。但是由于起初沒有考慮到首頁代碼是原生的（即依賴版本升級後才可以生效），上線後發現還是會出現退貨單據，溯源後才發現部分倉庫人員并沒有升級安裝包的習慣導緻一直使用舊包在操作，所以還有這個“漏洞”在。

最終的解決方案是，增加後端約束-在提交退貨單據時，增加倉庫類型的判斷和約束，那麼不管用戶使用的是什麼版本，這個問題都可以解決了。

雖然我也認為産品确實可以不用太關心開發代碼邏輯實現的細節，但是新舊版本的考慮個人認為産品還是需要關注到的。

（當然，不可否認的，業務實操培訓和執行确實也是有問題的）。

三、不要忘記-數據初始化方案

上面兩個點都是針對于現有功能優化時，要注意的點。而第三點-數據初始化則是針對于新功能上線來說。所有的流程都會産生數據，而線下流程的運行往往是先于系統的流程化的，那麼在系統上線後，已經有的數據如何“搬到”線上來，這就是我所指的數據初始化

（并不是指系統上線後一些配置的初始化哦）。

數據初始化實際上不會影響後續功能的正常使用，但是在初期系統推廣和用戶入門使用時卻是必須的。

如果上線後，馬上業務要用了才想到現在數據不對，可以就顯得略有些不專業了。

這裡主要提供兩種初始化的小思路供大家參考。

小案例分享-1

第一個思路是，可以利用已有的功能，通常需要業務配合執行。比如，我們在做倉儲平台向X業務線實施時，由于X業務線的倉庫線下都是在正常運營中的，所以倉内一直是有庫存的，而在實施上線時，系統初始化的庫存均為0（因為系統是無法知道倉内庫存的）。那麼如何能确保開始操作前倉内賬實庫存一緻呢？

我們可以通過後台現有的手動創建入庫申請單的功能，對X業務線下所有倉庫創建特殊場景的入庫申請單(全物料），倉庫開始使用系統前，清點倉内物資，将庫存通過入庫的方式增加到系統中。

–不使用盤點的原因是因為系統盤點功能限制倉内隻允許盤點有過出入庫記錄的物料。

小案例分享-2

第二個思路則是通過開發腳本的方式，這就需要前置在産品需求方案中就考慮到并向開發提出。比如，筆者去年在做物流費用線上化相關的項目時，為了防止業務異常操作導緻費用數據錯誤，系統功能上是隻允許創建當下發運的物流相關的費用，不支持手動創建（評估在日常使用中确實也沒有這樣的場景）。

但是因為費用結算的對象是整個月的數據，實際項目上線計劃時間也不會正好卡在月初，所以問題是在于，無法手動創建曆史費用數據的情況下，如何補齊當月已經發生的物流費用用于月賬單的結算呢。

最終的解決方式是研發側提供根據月份 供應商 物流公司手動生成物流費用的腳本，用于上線時費用的補齊。這也算是給自己預留的一個小後門吧。

四、不要忘記-灰度設計

有時候我們會發現，哪怕前期設計再謹慎、開發再小心、測試再嚴謹還是有可能會出現西安航問題。因此當功能範圍涉及較大且對原流程改動較大時，除了謹慎回歸外，通常建議不要一把梭哈直接全部上線，很有很可能出現一個小問題導緻整體需要回滾的悲劇。

而是提前和業務溝通好推進進度，試點單位成功後逐步推進，将異常控制在最小範圍内。

一但捕捉到異常，如果是非阻斷性的，則快速響應在最小範圍内解決問題，而如果是阻斷性的也可以通過灰度開關快速的切回原流程。

灰度維度設計需要根據實際項目的内容進行确定，我們有遇到過按照供應商、按照倉庫、按照城市、按照單據末尾号（主要是為了按百分比灰度單據）等方式進行灰度。

小案例分享

這部分讓我印象比較深的案例是在做供應商以銷定采費用結算項目時。以銷定采是指，在供應商發貨給我方主體及我方主體進行簽收時并不觸發結算，而是根據前端銷售信息發起結算。鍊路很長，涉及到商戶、采購、倉儲、前端銷售、财務等系統。我們除了要保證鍊路系統沒有問題之外，還需要保證鍊路上的相關業務方都清楚的新流程的執行和處理，所以還是有一定難度的。

但是因為以銷定采模式的供應商不是特别多(不超過10家)，所以确實也疏忽大意了，一沒有做功能總開關，二沒有做灰度開關，也就是說一旦上線，如果有問題，就隻能回滾代碼了，而且代碼回滾之後還可能要面臨着已經産生的數據的修複。特别是像結算類的項目，每一筆對應的都是公司需要支付的貨款，還是需要非常謹慎的對待的（當時年輕還沒有意識到）。

而我們正好也悲催的碰上了，最終也隻能回滾後重新增加灰度的代碼，先把第一個标杆供應商跑通再推進後續的實施。

五、不要忘記-數據埋點

所有的産品都是出于特地的背景和目的來設計的，需要對應的業務成果來體現産品價值。那麼如何能夠有效的體現産品價值呢，當然是數據。

在立項初期，我們通常就會預計算好産品大概會帶來的成效，比如人力的提升、成本的降低等。而後期在複盤時，則需要确認實際帶來的項目成果是否達到預期。

這就需要我們在初期就已經考慮好哪些數據是需要采集用于驗證的（這也考驗我們自己對産品的理解和設計），提前在方案中提出需要進行特定的埋點采集相關數據。

嚴格的說這其實不算是個坑，但确實是一個很容易被遺漏的重要點。

小案例分享

筆者之前做過一個關于履約成本降低的項目，其中的一個子項目是涉及拆合單優化。原訂單履約的拆單邏輯會導緻多商品的包裹有約30%左右的概率被拆分為2個包裹發貨，哪怕用戶購買的商品在同一個倉庫有貨可以通過一個包裹發出，也因此大幅增加了履約成本。

當時物流成本在履約成本中占比較高，而物流費用中本身存在首重續重價格差異大的客觀問題，所以多包裹的費用必然會高于單包裹。

筆者的方案主要是優化了拆包的策略，減少不必要的拆包數。而如何證明策略的有效性呢？

最直接的辦法就是在訂單進入流程後，同時調用新老算法埋點記錄對于同一筆訂單新老算法的拆包裹數及對應的履約成本。而最終通過數據也确實驗證了新算法，因為從埋點數據可以非常直接的看出當前實際拆包裹及履約成本是遠低于原策略的。

六、總結

以上就是本期想分享的内容啦，總結下來就是：舊功能的優化不要忘記曆史數據和曆史版本的兼容；

新功能設計不要忘記數據初始化方案和灰度方案；

以及該做的數據埋點還是要做起來。

有很多坑其實還沒有提到，人嘛，要麼是在坑裡，要麼是在去往坑的路上。還有一些我打算再攢一波。本篇分享希望可以對你有所幫助，如果寫的有不好的地方歡迎指正。

如果你還碰到過什麼坑，也歡迎後台和我分享。

感謝關注。我們一起加油吧。

#專欄作家#

麋鹿産品，公衆号：麋鹿産品手冊，人人都是産品經理專欄作家。專注供應鍊挖掘提升，熱愛生活，熱愛産品。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

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

,

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

查看全部