本文來自微信公眾號“人人都是產品經理”（ID:woshipm），作者：麋鹿產品手冊，36氪經授權發布。
每個人的職場之路都不是一帆風順的，總要經歷一些磕磕絆絆，產品經理也是如此。在工作過程中，前輩的意見能夠減少踩坑，更快獲得成長。才能本文作者從自身經驗出發，總結了一些容易踩的坑，希望對你有幫助。
本篇文章主要是為了分享和記錄我整理的避坑小指南和一些小案例分享。
減少踩坑，人人有責。
主要包括產品思考過程中針對：歷史數據兼容、歷史版本兼容、數據初始化方案、灰度設計、數據埋點這五個方面內容的思考。
產品的工作很大一部分是在優化和迭代，也就是說我們在對一些已經在使用中的功能進行升級；那么這些歷史功能在線上使用時必然已經產生過數據，新功能的設計時，需要考慮融合歷史的數據信息，同時還要考慮到已經在使用當前數據的上下游系統。否則可能導致上下游的調用異常或者本身系統數據使用的異常。
筆者近年在負責物流相關的系統，其中涉及到對內部員工車輛的管理，前期管理的較為寬松，因此只涉及到車牌、車型、品牌的信息。
但這些信息已經在下游業務中進行了正常的使用，隨著業務精細化運營，業務側對車輛管理進行了統籌的規劃，提出了對車輛的用途(可以理解為使用場景）、車輛證件、承載量、車輛基本信息均需要進行管理。
因此勢必需要對原有維護好的數據，在新功能里進行相應的兼容，哪些字段是需要廢棄的，哪些字段對應本次規劃中的字段，字段的必填/非必填屬性是否有變更，相關的表格設計以及提供給下游的接口（原接口中的字段和當前有所變更）需要如果兼容才可以避免對下游的影響。
OS：馬有失蹄，人有失手，項目上線前發現由于某個字段允許為空和原來的表定義不符導致DBA審批不通過間接導致項目上線延期了。同時，上線后，在用戶系統使用數據時，歷史用戶無車輛信息時會導致系統異常空指針也讓我們吃了一虧。
第二個案例就是最近發生的，我屬于其中的下游系統。
前提設定：在物流系統中，維護物流供應商的合作關系是會根據供應商當前合作的業務來源(可以簡單的理解成業務線或事業部）進行一層過濾，用戶只能選擇指定業務來源下的供應商。所有供應商可選信息來源于商戶系統。
然后某天業務同學說某個供應商選不到，我在排查過程中發現商戶系統頁面找不到[業務來源]這個字段了；同時在維護信息時也無法進行相關數據的維護。
在和對接的產品經理溝通后才知道他們在迭代過程中以為這個字段沒有用，直接去掉了。導致物流系統功能使用異常。
由于考慮用戶使用感受，除非功能真的極具價值或存在阻斷型問題，通常是不建議發布強制升級的APP版本的。因此當功能涉及到APP端升級后才可以使用時，必須要提前考慮到，如果用戶不升級，那系統要怎么處理以及如何用舊前端兼容新后端且確保系統不會報錯。
這種情況，如果前端是新增入口后的功能，則通常影響不大，畢竟用戶不升級時，是看不到新功能入口的，則不會觸發新邏輯，對用戶來說只是因為個人沒有升級而繼續使用老功能而已。
但是如果本身入口是歷史存在的，那么就需要謹慎考慮了。
前提設定：業務期望限制某種類型倉庫在APP端的退貨功能。系統原操作流程是點擊退貨，進入新頁面后可以創建不同類型的退貨單進行退貨處理。
這其實是一個比較簡單的小功能，只需要對于特定類型的倉庫在點擊退貨時進行阻斷或者不展示退貨按鍵就可以了。
但是由于起初沒有考慮到首頁代碼是原生的（即依賴版本升級后才可以生效），上線后發現還是會出現退貨單據，溯源后才發現部分倉庫人員并沒有升級安裝包的習慣導致一直使用舊包在操作，所以還有這個“漏洞”在。
最終的解決方案是：增加后端約束-在提交退貨單據時，增加倉庫類型的判斷和約束，那么不管用戶使用的是什么版本，這個問題都可以解決了。
雖然我也認為產品確實可以不用太關心開發代碼邏輯實現的細節，但是新舊版本的考慮個人認為產品還是需要關注到的。
（當然，不可否認的，業務實操培訓和執行確實也是有問題的）。
上面兩個點都是針對于現有功能優化時，要注意的點。而第三點-數據初始化則是針對于新功能上線來說。
所有的流程都會產生數據，而線下流程的運行往往是先于系統的流程化的，那么在系統上線后，已經有的數據如何“搬到”線上來，這就是我所指的數據初始化
（并不是指系統上線后一些配置的初始化哦）。
數據初始化實際上不會影響后續功能的正常使用，但是在初期系統推廣和用戶入門使用時卻是必須的。
如果上線后，馬上業務要用了才想到現在數據不對，可以就顯得略有些不專業了。
這里主要提供兩種初始化的小思路供大家參考。
第一個思路是：可以利用已有的功能，通常需要業務配合執行。
比如，我們在做倉儲平臺向X業務線實施時，由于X業務線的倉庫線下都是在正常運營中的，所以倉內一直是有庫存的，而在實施上線時，系統初始化的庫存均為0（因為系統是無法知道倉內庫存的）。
那么，如何能確保開始操作前倉內賬實庫存一致呢？
我們可以通過后臺現有的手動創建入庫申請單的功能，對X業務線下所有倉庫創建特殊場景的入庫申請單(全物料），倉庫開始使用系統前，清點倉內物資，將庫存通過入庫的方式增加到系統中。
–不使用盤點的原因是因為系統盤點功能限制倉內只允許盤點有過出入庫記錄的物料。
第二個思路則是通過開發腳本的方式，這就需要前置在產品需求方案中就考慮到并向開發提出。
比如，筆者去年在做物流費用線上化相關的項目時，為了防止業務異常操作導致費用數據錯誤，系統功能上是只允許創建當下發運的物流相關的費用，不支持手動創建（評估在日常使用中確實也沒有這樣的場景）。
但是因為費用結算的對象是整個月的數據，實際項目上線計劃時間也不會正好卡在月初。
所以問題是在于：無法手動創建歷史費用數據的情況下，如何補齊當月已經發生的物流費用用于月賬單的結算呢。
最終的解決方式是研發側提供根據月份+供應商+物流公司手動生成物流費用的腳本，用于上線時費用的補齊。這也算是給自己預留的一個小后門吧。
有時候我們會發現，哪怕前期設計再謹慎、開發再小心、測試再嚴謹還是有可能會出現西安航問題。
因此當功能范圍涉及較大且對原流程改動較大時，除了謹慎回歸外，通常建議不要一把梭哈直接全部上線，很有很可能出現一個小問題導致整體需要回滾的悲劇。
而是提前和業務溝通好推進進度，試點單位成功后逐步推進，將異常控制在最小范圍內。
一但捕捉到異常，如果是非阻斷性的，則快速響應在最小范圍內解決問題，而如果是阻斷性的也可以通過灰度開關快速的切回原流程。
灰度維度設計需要根據實際項目的內容進行確定，我們有遇到過按照供應商、按照倉庫、按照城市、按照單據末尾號（主要是為了按百分比灰度單據）等方式進行灰度。
這部分讓我印象比較深的案例是在做供應商以銷定采費用結算項目時。
以銷定采是指，在供應商發貨給我方主體及我方主體進行簽收時并不觸發結算，而是根據前端銷售信息發起結算。鏈路很長，涉及到商戶、采購、倉儲、前端銷售、財務等系統。
我們除了要保證鏈路系統沒有問題之外，還需要保證鏈路上的相關業務方都清楚的新流程的執行和處理，所以還是有一定難度的。
但是因為以銷定采模式的供應商不是特別多(不超過10家)，所以確實也疏忽大意了，一沒有做功能總開關，二沒有做灰度開關；也就是說一旦上線，如果有問題，就只能回滾代碼了，而且代碼回滾之后還可能要面臨著已經產生的數據的修復。特別是像結算類的項目，每一筆對應的都是公司需要支付的貨款，還是需要非常謹慎的對待的（當時年輕還沒有意識到）。
而我們正好也悲催的碰上了，最終也只能回滾后重新增加灰度的代碼，先把第一個標桿供應商跑通再推進后續的實施。
所有的產品都是出于特地的背景和目的來設計的，需要對應的業務成果來體現產品價值。那么如何能夠有效的體現產品價值呢，當然是數據。
在立項初期，我們通常就會預計算好產品大概會帶來的成效，比如人力的提升、成本的降低等。而后期在復盤時，則需要確認實際帶來的項目成果是否達到預期。
這就需要我們在初期就已經考慮好哪些數據是需要采集用于驗證的（這也考驗我們自己對產品的理解和設計），提前在方案中提出需要進行特定的埋點采集相關數據。
嚴格的說這其實不算是個坑，但確實是一個很容易被遺漏的重要點。
筆者之前做過一個關于履約成本降低的項目，其中的一個子項目是涉及拆合單優化。
原訂單履約的拆單邏輯會導致多商品的包裹有約30%左右的概率被拆分為2個包裹發貨，哪怕用戶購買的商品在同一個倉庫有貨可以通過一個包裹發出（詳細拆單邏輯此處不展開講解），也因此大幅增加了履約成本。
當時物流成本在履約成本中占比較高，而物流費用中本身存在首重續重價格差異大的客觀問題，所以多包裹的費用必然會高于單包裹。
筆者的方案主要是優化了拆包的策略，減少不必要的拆包數。而如何證明策略的有效性呢？
最直接的辦法就是在訂單進入流程后，同時調用新老算法埋點記錄對于同一筆訂單新老算法的拆包裹數及對應的履約成本。而最終通過數據也確實驗證了新算法，因為從埋點數據可以非常直接的看出當前實際拆包裹及履約成本是遠低于原策略的。
以上就是本期想分享的內容啦，總結下來就是：舊功能的優化不要忘記歷史數據和歷史版本的兼容；
新功能設計不要忘記數據初始化方案和灰度方案；
以及該做的數據埋點還是要做起來。
有很多坑其實還沒有提到。
人嘛，要么是在坑里，要么是在去往坑的路上。
本篇分享希望可以對你有所幫助，如果寫的有不好的地方歡迎指正。
