TO B產(chǎn)品設計專題：報錯體系

TOB產(chǎn)品設計專題：報錯體系“報錯”是系統(tǒng)中最常見的功能之一，報錯體系也涉及到方方面面的問題。本文作者分享了有關報錯體系的相關內容，講述了建立體系化的報錯模塊的原因、報錯設計、報錯場景的類型以及設計報錯體系的方法論和數(shù)據(jù)化運營價值等，一起來學習一下吧。一、為何需要建立體系化的報錯模塊無論哪種IT系統(tǒng)，無論面向哪類人群，系統(tǒng)中最常見的功能就是“報錯”，可能不少小伙伴會說，報錯soeasy！哪需要專門討論?？稍谏钊朐O計產(chǎn)品之后，經(jīng)歷過從0到1去設計一款產(chǎn)品的時候。你一定會發(fā)現(xiàn)。報錯遠遠沒有這么簡單。報錯體系涉及到多方面問題。比如報錯內容標準化問題、報錯樣式體驗最佳問題、報錯方案自助解決率問題、報錯轉換器問題等等。報錯需要體系化的產(chǎn)品設計。特別是一些TOB的產(chǎn)品。因為業(yè)務復雜、行業(yè)專業(yè)、對接頻繁、投入有效。更需要一套優(yōu)秀的報錯設計模塊。二、背景分析：哪些不良的報錯設計首先，我們需要做一個報錯模塊的背景分析，圍繞報錯這種業(yè)務形態(tài)，我們可以分析下有哪些經(jīng)常出現(xiàn)的不良點。從背景上去推演我們需要一款什么樣的報錯產(chǎn)品。1.報錯內容不良問題：報錯指向位置不明、報錯內容泰國專業(yè)、報錯內容和原因存在1對多情況很多TOB產(chǎn)品因為業(yè)務非常復雜、關聯(lián)外部系統(tǒng)接口較多、行業(yè)比較專業(yè)。故而在報錯層面經(jīng)常會出現(xiàn)報錯內容太專業(yè)的情況。比如銀行系統(tǒng)、財務系統(tǒng)、供應鏈系統(tǒng)等；然后報錯內容也存在指向不明的情況、比如不知道哪個位置、不知道哪個原因。還有的不良情況就是報錯內容和報錯原因存在1對多情況，比如報錯內容為“預算不足、無法實現(xiàn)扣減”，而實際的報錯原因可能存在多種情況，有預算部門選錯了、有日期選錯了、有確實沒有預算、有沖銷未關聯(lián)問題造成。而系統(tǒng)粗暴的說了一個報錯內容，發(fā)生原因讓用戶去猜測。這也無形之中增加了企業(yè)的運營成本。2.報錯樣式不良問題：報錯位置不統(tǒng)一、強弱控圖標不統(tǒng)一、報錯顏色不規(guī)范人類是感官動物，而且經(jīng)過千百年的感官訓練。人類已對一些固有的顏色、固有的圖標有很強的辨識力和歸屬定位。比如紅色代表警告和禁止、綠色代表通過和贊同。叉叉圖標代表不允許、感嘆號圖標代表提醒。系統(tǒng)也要沿用固有的設計模式，不要去挑戰(zhàn)常規(guī)認知。不過有些系統(tǒng)并沒有這么做，經(jīng)常會出現(xiàn)圖標不規(guī)范、顏色不規(guī)范的問題。同時也會存在報錯位置不統(tǒng)一問題。比如報錯在頁面頂部、報錯在頁面居中、報錯在輸入框下面、報錯在右下角等等。讓人琢磨不透。3.報錯無閉環(huán)方案問題：只是報錯不提供方案、只有方案無跳轉路徑、只有方案沒有制度說明這種不良問題是最為常見的，只有報錯問題，沒有解決方案。原因不外乎如下3種：第一種為產(chǎn)品經(jīng)理沒有經(jīng)驗，只是給出問題；第二種為系統(tǒng)很多報錯是無法在產(chǎn)品側定義好，而產(chǎn)品和開發(fā)又沒有形成協(xié)同機制；第三種為團隊不關注經(jīng)營，只負責IT系統(tǒng)搭建，缺失問題解決率、用戶應用體驗度、系統(tǒng)運營成本的考量。4.報錯無擴展性設計問題：報錯采用硬編碼形式這種是產(chǎn)品設計問題，整個系統(tǒng)缺失整體架構。所以報錯均采用硬編碼形式，全部寫在代碼上。結果一上線后，發(fā)現(xiàn)報錯看不懂、不好用。又需要花費時間去代碼上修改。而且針對多語言環(huán)境沒有綜合考慮，增加一種新的語言環(huán)境后，要所有的代碼均要去修改報錯。這造成整個團隊的開發(fā)效率低下、系統(tǒng)靈活性不足、運營成本偏高。5.報錯無法分析問題：無數(shù)據(jù)分析意識、無數(shù)據(jù)分析埋點這種不良是很多IT團隊最為忽略的。很多IT團隊在企業(yè)內不受到待見、其實有一部分原因就是IT團隊缺失產(chǎn)品運營思維。在整個產(chǎn)品價值鏈之中，干得最具有技術性的活、而職責卻自我定位為執(zhí)行者。軟件好不好用我不管、軟件可不可用我不屑。當然就不會去關注報錯的可分析性。報錯是最能體現(xiàn)軟件可用性的內容了，報錯是實際運營中的數(shù)字化反映，哪里模塊報錯最為頻繁、哪個時間點報錯最多。可以第一時間定位出產(chǎn)品優(yōu)化方向。三、調研：哪些報錯場景經(jīng)過背景分析后，下來就需要對整個系統(tǒng)的報錯場景做一次整理，歸納下報錯的類型。從而對接下來的報錯做體系化的設計。1.按照是否影響正常運作強控報錯形式：出現(xiàn)了該異常后，則系統(tǒng)會無法正常運作、該類報錯必須在事故發(fā)生的那一刻得到解決。若忽略或由后期流程進行補充，則會存在事故風險和規(guī)則風險。弱控警告形式：出現(xiàn)了該異常后，則系統(tǒng)依然正常運作、用戶可以選擇忽略；或者這是一種偏提醒類問題，用戶只需要知悉即可。2.按錯誤的觸發(fā)原因自身的系統(tǒng)邏輯：這類異常是系統(tǒng)本身的邏輯要求，不受到外部系統(tǒng)的影響，在系統(tǒng)內通過代碼修正、配置調整即可修復。外部的系統(tǒng)要求：外部接口報錯；這類異常不是系統(tǒng)本身的邏輯要求，而是由外部系統(tǒng)引發(fā)的，比如很多系統(tǒng)均要對接SAP、而在傳輸數(shù)據(jù)到SAP的時候，則SAP會返回報錯信息。這類異常大部分是由于數(shù)據(jù)不同步、數(shù)據(jù)為空造成。人為的報錯形式：審批人的駁回原因報錯，這類異常不是系統(tǒng)邏輯造成的，而是在業(yè)務流轉過程中，由人工維護的。比如在流程審批中、審批人駁回給填單人，則填單人收到的駁回原因。這類異常若無標準，也會造成大量的運營成本。底層框架的標準：系統(tǒng)底層報錯（SQL層）、框架（Hibernate），這類異常是工具框架造成的，是一些工具性軟件、硬件、服務器、操作系統(tǒng)的報錯。該類報錯對于大部分IT團隊而言是束手無策的。當然這類問題發(fā)生的概率很低。四、設計：報錯體系的產(chǎn)品設計方法論（雙輪驅動模型）筆者也針對報錯體系總結了一套設計方法論，總結名稱為“雙輪驅動報錯設計模型”，下圖為該模型的結構圖。整個模型由兩個輪組合而成，外輪為運營輪、內輪為設計輪。在設計輪層面，要求報錯產(chǎn)品要滿足四個要素，報錯的樣式和內容是標準的、報錯的解決是閉環(huán)的、報錯的內容和方案是可配置的、報錯的可用性是可分析的。在有了這四個設計要素后，則所有的報錯信息都要用運營三步閉環(huán)方法法進行推進。第一步先將報錯進行分解；第二步進行報錯的配置；第三步要通過實際運行進行分析，最后又回歸到分析后，對報錯進行更細顆粒度的分解。五、運營：報錯的數(shù)據(jù)化運營報錯在產(chǎn)品運營中也是非常重要的數(shù)據(jù)指標，筆者在做產(chǎn)品經(jīng)理的時候，經(jīng)常會去分析報錯內容。個人總結有如下價值：1.價值1：尋找產(chǎn)品新的優(yōu)化點對報錯做模塊分類、時間分類、組織分類、人群分類?？梢詮膱箦e上找出很多產(chǎn)品優(yōu)化點。2.價值2：增強方案的說服力在做需求評審、做方案研討時，并不是誰的嗓門大，誰就更有話語權。若產(chǎn)品能在溝通中，甩出幾個報錯數(shù)據(jù)分析，是很具備說服力的。3.價值3：驅動業(yè)務資源投入產(chǎn)品2/8原則在任何產(chǎn)品中都是適用的，20%的工作在軟件開發(fā)中，80%的工作上線后運營。而通過分析報錯，可以快速找到業(yè)務配合不良的地方，從而驅動業(yè)務配合產(chǎn)品推廣、驅動業(yè)務調整工作機制。就比如搶單模式若不做薪酬改造，就很難推行。六、總結復盤報錯雖然是整個系統(tǒng)中非常小的一個產(chǎn)品模塊，也是產(chǎn)品人員最為忽略的一個產(chǎn)品模塊。可細