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