本文來自微信公眾號“人人都是產(chǎn)品經(jīng)理”（ID:woshipm），作者：麋鹿產(chǎn)品手冊，36氪經(jīng)授權(quán)發(fā)布。

每個人的職場之路都不是一帆風(fēng)順的，總要經(jīng)歷一些磕磕絆絆，產(chǎn)品經(jīng)理也是如此。在工作過程中，前輩的意見能夠減少踩坑，更快獲得成長。才能本文作者從自身經(jīng)驗出發(fā)，總結(jié)了一些容易踩的坑，希望對你有幫助。

本篇文章主要是為了分享和記錄我整理的避坑小指南和一些小案例分享。

減少踩坑，人人有責(zé)。

主要包括產(chǎn)品思考過程中針對：歷史數(shù)據(jù)兼容、歷史版本兼容、數(shù)據(jù)初始化方案、灰度設(shè)計、數(shù)據(jù)埋點這五個方面內(nèi)容的思考。

兼容歷史數(shù)據(jù)

產(chǎn)品的工作很大一部分是在優(yōu)化和迭代，也就是說我們在對一些已經(jīng)在使用中的功能進行升級；那么這些歷史功能在線上使用時必然已經(jīng)產(chǎn)生過數(shù)據(jù)，新功能的設(shè)計時，需要考慮融合歷史的數(shù)據(jù)信息，同時還要考慮到已經(jīng)在使用當(dāng)前數(shù)據(jù)的上下游系統(tǒng)。否則可能導(dǎo)致上下游的調(diào)用異?；蛘弑旧硐到y(tǒng)數(shù)據(jù)使用的異常。

小案例分享-1

筆者近年在負責(zé)物流相關(guān)的系統(tǒng)，其中涉及到對內(nèi)部員工車輛的管理，前期管理的較為寬松，因此只涉及到車牌、車型、品牌的信息。

但這些信息已經(jīng)在下游業(yè)務(wù)中進行了正常的使用，隨著業(yè)務(wù)精細化運營，業(yè)務(wù)側(cè)對車輛管理進行了統(tǒng)籌的規(guī)劃，提出了對車輛的用途(可以理解為使用場景）、車輛證件、承載量、車輛基本信息均需要進行管理。

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

OS：馬有失蹄，人有失手，項目上線前發(fā)現(xiàn)由于某個字段允許為空和原來的表定義不符導(dǎo)致DBA審批不通過間接導(dǎo)致項目上線延期了。同時，上線后，在用戶系統(tǒng)使用數(shù)據(jù)時，歷史用戶無車輛信息時會導(dǎo)致系統(tǒng)異?？罩羔樢沧屛覀兂粤艘惶?。

小案例分析-2

第二個案例就是最近發(fā)生的，我屬于其中的下游系統(tǒng)。

前提設(shè)定：在物流系統(tǒng)中，維護物流供應(yīng)商的合作關(guān)系是會根據(jù)供應(yīng)商當(dāng)前合作的業(yè)務(wù)來源(可以簡單的理解成業(yè)務(wù)線或事業(yè)部）進行一層過濾，用戶只能選擇指定業(yè)務(wù)來源下的供應(yīng)商。所有供應(yīng)商可選信息來源于商戶系統(tǒng)。

然后某天業(yè)務(wù)同學(xué)說某個供應(yīng)商選不到，我在排查過程中發(fā)現(xiàn)商戶系統(tǒng)頁面找不到[業(yè)務(wù)來源]這個字段了；同時在維護信息時也無法進行相關(guān)數(shù)據(jù)的維護。

在和對接的產(chǎn)品經(jīng)理溝通后才知道他們在迭代過程中以為這個字段沒有用，直接去掉了。導(dǎo)致物流系統(tǒng)功能使用異常。

兼容歷史版本

由于考慮用戶使用感受，除非功能真的極具價值或存在阻斷型問題，通常是不建議發(fā)布強制升級的APP版本的。因此當(dāng)功能涉及到APP端升級后才可以使用時，必須要提前考慮到，如果用戶不升級，那系統(tǒng)要怎么處理以及如何用舊前端兼容新后端且確保系統(tǒng)不會報錯。

這種情況，如果前端是新增入口后的功能，則通常影響不大，畢竟用戶不升級時，是看不到新功能入口的，則不會觸發(fā)新邏輯，對用戶來說只是因為個人沒有升級而繼續(xù)使用老功能而已。

但是如果本身入口是歷史存在的，那么就需要謹(jǐn)慎考慮了。

小案例分享

前提設(shè)定：業(yè)務(wù)期望限制某種類型倉庫在APP端的退貨功能。系統(tǒng)原操作流程是點擊退貨，進入新頁面后可以創(chuàng)建不同類型的退貨單進行退貨處理。

這其實是一個比較簡單的小功能，只需要對于特定類型的倉庫在點擊退貨時進行阻斷或者不展示退貨按鍵就可以了。

但是由于起初沒有考慮到首頁代碼是原生的（即依賴版本升級后才可以生效），上線后發(fā)現(xiàn)還是會出現(xiàn)退貨單據(jù)，溯源后才發(fā)現(xiàn)部分倉庫人員并沒有升級安裝包的習(xí)慣導(dǎo)致一直使用舊包在操作，所以還有這個“漏洞”在。

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

雖然我也認為產(chǎn)品確實可以不用太關(guān)心開發(fā)代碼邏輯實現(xiàn)的細節(jié)，但是新舊版本的考慮個人認為產(chǎn)品還是需要關(guān)注到的。

（當(dāng)然，不可否認的，業(yè)務(wù)實操培訓(xùn)和執(zhí)行確實也是有問題的）。

數(shù)據(jù)初始化方案

上面兩個點都是針對于現(xiàn)有功能優(yōu)化時，要注意的點。而第三點-數(shù)據(jù)初始化則是針對于新功能上線來說。

所有的流程都會產(chǎn)生數(shù)據(jù)，而線下流程的運行往往是先于系統(tǒng)的流程化的，那么在系統(tǒng)上線后，已經(jīng)有的數(shù)據(jù)如何“搬到”線上來，這就是我所指的數(shù)據(jù)初始化

（并不是指系統(tǒng)上線后一些配置的初始化哦）。

數(shù)據(jù)初始化實際上不會影響后續(xù)功能的正常使用，但是在初期系統(tǒng)推廣和用戶入門使用時卻是必須的。

如果上線后，馬上業(yè)務(wù)要用了才想到現(xiàn)在數(shù)據(jù)不對，可以就顯得略有些不專業(yè)了。

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

小案例分享-1

第一個思路是：可以利用已有的功能，通常需要業(yè)務(wù)配合執(zhí)行。

比如，我們在做倉儲平臺向X業(yè)務(wù)線實施時，由于X業(yè)務(wù)線的倉庫線下都是在正常運營中的，所以倉內(nèi)一直是有庫存的，而在實施上線時，系統(tǒng)初始化的庫存均為0（因為系統(tǒng)是無法知道倉內(nèi)庫存的）。

那么，如何能確保開始操作前倉內(nèi)賬實庫存一致呢？

我們可以通過后臺現(xiàn)有的手動創(chuàng)建入庫申請單的功能，對X業(yè)務(wù)線下所有倉庫創(chuàng)建特殊場景的入庫申請單(全物料），倉庫開始使用系統(tǒng)前，清點倉內(nèi)物資，將庫存通過入庫的方式增加到系統(tǒng)中。

–不使用盤點的原因是因為系統(tǒng)盤點功能限制倉內(nèi)只允許盤點有過出入庫記錄的物料。

小案例分享-2

第二個思路則是通過開發(fā)腳本的方式，這就需要前置在產(chǎn)品需求方案中就考慮到并向開發(fā)提出。

比如，筆者去年在做物流費用線上化相關(guān)的項目時，為了防止業(yè)務(wù)異常操作導(dǎo)致費用數(shù)據(jù)錯誤，系統(tǒng)功能上是只允許創(chuàng)建當(dāng)下發(fā)運的物流相關(guān)的費用，不支持手動創(chuàng)建（評估在日常使用中確實也沒有這樣的場景）。

但是因為費用結(jié)算的對象是整個月的數(shù)據(jù)，實際項目上線計劃時間也不會正好卡在月初。

所以問題是在于：無法手動創(chuàng)建歷史費用數(shù)據(jù)的情況下，如何補齊當(dāng)月已經(jīng)發(fā)生的物流費用用于月賬單的結(jié)算呢。

最終的解決方式是研發(fā)側(cè)提供根據(jù)月份+供應(yīng)商+物流公司手動生成物流費用的腳本，用于上線時費用的補齊。這也算是給自己預(yù)留的一個小后門吧。

灰度設(shè)計

有時候我們會發(fā)現(xiàn)，哪怕前期設(shè)計再謹(jǐn)慎、開發(fā)再小心、測試再嚴(yán)謹(jǐn)還是有可能會出現(xiàn)西安航問題。

因此當(dāng)功能范圍涉及較大且對原流程改動較大時，除了謹(jǐn)慎回歸外，通常建議不要一把梭哈直接全部上線，很有很可能出現(xiàn)一個小問題導(dǎo)致整體需要回滾的悲劇。

而是提前和業(yè)務(wù)溝通好推進進度，試點單位成功后逐步推進，將異?？刂圃谧钚》秶鷥?nèi)。

一但捕捉到異常，如果是非阻斷性的，則快速響應(yīng)在最小范圍內(nèi)解決問題，而如果是阻斷性的也可以通過灰度開關(guān)快速的切回原流程。

灰度維度設(shè)計需要根據(jù)實際項目的內(nèi)容進行確定，我們有遇到過按照供應(yīng)商、按照倉庫、按照城市、按照單據(jù)末尾號（主要是為了按百分比灰度單據(jù)）等方式進行灰度。

小案例分享

這部分讓我印象比較深的案例是在做供應(yīng)商以銷定采費用結(jié)算項目時。

以銷定采是指，在供應(yīng)商發(fā)貨給我方主體及我方主體進行簽收時并不觸發(fā)結(jié)算，而是根據(jù)前端銷售信息發(fā)起結(jié)算。鏈路很長，涉及到商戶、采購、倉儲、前端銷售、財務(wù)等系統(tǒng)。

我們除了要保證鏈路系統(tǒng)沒有問題之外，還需要保證鏈路上的相關(guān)業(yè)務(wù)方都清楚的新流程的執(zhí)行和處理，所以還是有一定難度的。

但是因為以銷定采模式的供應(yīng)商不是特別多(不超過10家)，所以確實也疏忽大意了，一沒有做功能總開關(guān)，二沒有做灰度開關(guān)；也就是說一旦上線，如果有問題，就只能回滾代碼了，而且代碼回滾之后還可能要面臨著已經(jīng)產(chǎn)生的數(shù)據(jù)的修復(fù)。特別是像結(jié)算類的項目，每一筆對應(yīng)的都是公司需要支付的貨款，還是需要非常謹(jǐn)慎的對待的（當(dāng)時年輕還沒有意識到）。

而我們正好也悲催的碰上了，最終也只能回滾后重新增加灰度的代碼，先把第一個標(biāo)桿供應(yīng)商跑通再推進后續(xù)的實施。

數(shù)據(jù)埋點

所有的產(chǎn)品都是出于特地的背景和目的來設(shè)計的，需要對應(yīng)的業(yè)務(wù)成果來體現(xiàn)產(chǎn)品價值。那么如何能夠有效的體現(xiàn)產(chǎn)品價值呢，當(dāng)然是數(shù)據(jù)。

在立項初期，我們通常就會預(yù)計算好產(chǎn)品大概會帶來的成效，比如人力的提升、成本的降低等。而后期在復(fù)盤時，則需要確認實際帶來的項目成果是否達到預(yù)期。

這就需要我們在初期就已經(jīng)考慮好哪些數(shù)據(jù)是需要采集用于驗證的（這也考驗我們自己對產(chǎn)品的理解和設(shè)計），提前在方案中提出需要進行特定的埋點采集相關(guān)數(shù)據(jù)。

嚴(yán)格的說這其實不算是個坑，但確實是一個很容易被遺漏的重要點。

小案例分享

筆者之前做過一個關(guān)于履約成本降低的項目，其中的一個子項目是涉及拆合單優(yōu)化。

原訂單履約的拆單邏輯會導(dǎo)致多商品的包裹有約30%左右的概率被拆分為2個包裹發(fā)貨，哪怕用戶購買的商品在同一個倉庫有貨可以通過一個包裹發(fā)出（詳細拆單邏輯此處不展開講解），也因此大幅增加了履約成本。

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

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

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

總結(jié)

以上就是本期想分享的內(nèi)容啦，總結(jié)下來就是：舊功能的優(yōu)化不要忘記歷史數(shù)據(jù)和歷史版本的兼容；

新功能設(shè)計不要忘記數(shù)據(jù)初始化方案和灰度方案；

以及該做的數(shù)據(jù)埋點還是要做起來。

有很多坑其實還沒有提到。

人嘛，要么是在坑里，要么是在去往坑的路上。

本篇分享希望可以對你有所幫助，如果寫的有不好的地方歡迎指正。

關(guān)鍵詞： 5個 容易 踩坑 不要