产品经理必知的7种容错机制

2 评论 8662 浏览 60 收藏 13 分钟

编辑导读:用户在使用产品的过程中,少不了会出现操作错误的情况,这时容错机制的重要性就显现出来了。本文从四个方面围绕容错机制进行分析,希望对你有帮助。

子曰:知错能改,善莫大焉。

产品经理说:且慢!容我想想……

可能很多时候,我们在设计产品时,主要精力投在主流程上,想如何完成闭环,如何节省步骤,提高用户体验,对于异常情况,就是给出友好的提示和引导。

但产品上线后,我们会发现客户老是因为自己点错的问题找我们,让我们改数据库。我们当然是理直气壮地拒绝了,但仔细想想,是不是我们的容错机制做得不够好。

说说我碰到的三个出错场景吧。

一、我真的知错了

例1:脉脉错过了好友

其实关于容错我之前没有好好想过,但有个同事对这块很重视,我当时还觉得他小题大做,直到我亲身经历了,那次感受特别深。

偶尔会打开脉脉,就会看到人脉,像下图有待处理请求,直接点击√或者×就可以,当时我拿左手在操作,想点√,结果手指不够长,在移动过程中碰到了×,这条就直接消失了,我就想找回来点√,我以为会有一个列表像微信好友一样,至少历史请求都在,但是当我点开列表时,发现也只有待处理的,没有历史记录。

我当时还发了一条状态说为什么点错了不让我改,客服说现在功能是没有,后面有考虑做。但很久过去了,这个功能还是没有。

或许产品经理认为,反正那么多人加你,大部分还不认识,点错了少加几个有什么关系呢。但我就是执着地想加上呢?

例2:入库单删不掉

在做医疗SaaS时,这个问题真的是隔三差五就有客户提。我们当时的设计是,入库完成后有审核,审核通过入库了就不让改了,如果有错,可以把这笔单子出了,再重新录。

按理说多了审核环节就能避免80%的出错率了,2个人都没看出来?但事实就是,很多人自录自审,然后还点错了,又不想再出后入,因为这样药品流水就会多2条没必要的记录,卫生局会来查,怕说不清。

现在在做wms,去仓库调查时,这个问题也被提出了。这里的入库单都不能仓管手动增,是由采购系统推送过来的,采购员录错了,推送了错误的几百条数据过来。后来发现了,又重新建了个采购单,再推送过来,但之前的单子没有调回,就一直挂在待出库这边,仓管员看了特别难受,想删又删不掉。

例3:昨天的病历改不了

病历规范里面其实是有这样的要求,门诊病历当天归档后就不能修改了,关于出事后篡改病历逃避责任这类的新闻想必大家都有听闻过。

我们当时就按这个标准来的,门诊病历过今天24时就不让改了,体检的可以,因为体检报告一般都要好几天才能写完。

但客户就是还经常要改,有时候是因为同名患者写错了,有时候是因为太忙了,才想起昨天有几份病历没来得及写完。

只要是人就会出错,小学时铅笔写错了字可以拿橡皮擦,高中时中性笔写错了还能用胶带粘掉,为什么电子化的系统反倒改个东西那么难呢?

二、为什么不让改

产品经理绝对是背锅侠,我们也想让客户随便改,但我们不得不全局地考虑系统啊,改了会不会出更大的问题?

数据对不上怎么办?

就像案例2中的入库单,如果采购系统查到有这条入库任务,但是在WMS里面被删掉了,客户会不会觉得是因为系统有bug,数据没有推送过来呢?

还遇到过一个比较大的问题,医生开完处方后药房也发药了,但是患者说不想要了,就把药退了,医生想把处方单里把这个药删掉,很合理。但是删掉后我药品的发药和退药记录要不要保留呢?保留的话后面查时发药依据在哪?

万一删错了怎么办?

用户可以因为手滑,点错了想删除,那如果又手滑,点错了删除,把有用的数据删除了怎么办呢?我们还要给他提供一个像照片一样的垃圾箱,或者word的回到历史版本吗?

肯定不可能啊!虽说删除都有二次确认,其实三次、四次都没用,有的人就是闭着眼睛在点,错了就问能不能复原。

好像关于出错我们是没法去避免的,但也不能不去处理,我总结了下7种常用的容错机制,可以在不同的时候用上,希望可以少背点锅吧。

三、容错可以这样做

1. 直接修改

对于列表页,我们最常见的按钮就是新增、查看、编辑、删除。这里的修改不止是随着时间场景的推移,事务发生变化,比如提成规则发生了变化,需要及时修改。还包括简单的就是因为输错了,想改,比如员工的姓名。

如果说修改的字段没有和业务流程挂钩,也没有被其他功能引用,那么事情就很简单了,随便改。但B端产品中,字段往往没那么单纯,大部分字段都是有深意的,特别是一些基础数据,那可以试试下面的办法。

2. 只可停用,不可删除

员工信息是系统中很基础的数据,很多地方都有用到,特别是统计报表中。

比如医务统计中会按医生统计看诊量,门诊金额,处方金额等,如果把医生删除了,有可能统计的数据就不对了,医务统计处的总金额就比收费统计那边的金额少了。

这时候可以让员工只能停用,不能删除。但这会引发另一个问题,员工太多了,看着碍眼,那可以在进入页面时用状态过滤下,当然还有强迫症的客户就是想删。

很多时候就算能删,我们也为了保险起见,让开发只做逻辑删除,不做物理删除,但只能针对重要数据,所有的都做逻辑删除对数据库的压力也是很大的。

3. 调错与红冲

调错与红冲这个概念在会计里面是用的最成熟的,记账凭证会计科目错误时,用红字填写一张与原始凭证完全相同的记账凭证,以示注销原记账凭证,然后用蓝字填写一张正确的记账凭证,并据以记账。

我们在WMS里面也经常会听到这些名词:红领料,红验收,就是说领料有问题,退回仓库;采购来的货有问题,退回供应商。

同样系统中有过的痕迹不能直接删、改,涉及流程有关的,可以用调错和红冲,把下游环节的流程给撤回来。

遇到财务系统中结转时也是如此,如果发现结转的账有错误,可以反结转,把账调回,修正后再重新结转。

4. 限时修改

这个用的最好的是微信了,我们都发生过这样的情况,一不小心把一条八卦或吐槽发给了领导或者客户群。微信可以让我们在短时内撤回消息,如果能不显示“xx撤回了一条消息”会更好,毕竟还有99%的人好奇撤回的是啥。

案例3中病历的情况就可以这样处理,限时还是必须的,但可以不一刀切,可以给医生缓一缓的时间,比如24小时,72小时内可修改,毕竟过了72小时,大部分人想不起之前的事了吧。

5. 加强审核

案例2中入库和出库,我们都有增加审核环节,对于管理严格的诊所来说,还是有会有效果的。但审核最好还是能搭配调错与红冲一起,这样容错率能更高一点。

另一种常见的场景就是我们的OA,我们在批假时,如果小于1天,上级领导批就可以了,2-5天需要总监再审核,5天以上可能又要增加HR,CEO之类的审批了。

当然OA的这么多审批本质不是为了容错,但这个例子能说明审核人越多,流程越长,错误率就越低。有时候我们也可以适当增加些环节。

6. 角色控制

系统角色来看肯定有超级管理员,超管拥有一切的权限,如果一些数据很重要,我们可以把修改和删除的权限只开给他。

除了系统里面的权限控制,还可以有专门的容错平台。我们之前为了方便修改病历,特地做了一个只能客服使用的病历修改小系统。如果客户有问题,客服输入具体的患者名称、时间等后可以改该条数据,不提供模糊搜索,以防恶意操作。

7. 日志留档

最后的最后,也是最重要的,所有的重要修改都要留档,不然有口说不清。

我们就经常碰到客户投诉,说病历没了,客户档案没了,系统有bug。那肯定是不可能的,我们说肯定是你的员工动了。他会说:我把员工都问了一遍了,都说没动。这不废话吗,如果我是员工,我也不想承认。

我们就可以把操作日志甩他们脸上,xx时间xx人改了xx,把xx改成了xx,然后你们自己去处理吧。

四、总结

犯错很容易,容错很难,但不让人家改又不行,做产品经理好难啊。

但有时候我们想想,其实没必要那么执着在系统数据的完整性上,保留好罪证,让他们愿意改就改去吧。如果有个回收站和历史版本最好,这样万一想回来也容易。

所以说了7种容错机制,最顶级的还是回收站和历史版本回退,下面让我们想想,这2个功能该怎么做呢?

#专栏作家#

司马特小队,公众号:司马特小分队,人人都是产品经理专栏作家。8年+互联网资深产品经验,多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 单据那个狠狠认同了

    来自广东 回复
  2. 医生改病例那个用于限时修改的例子不恰当吧,至少应该是加上要保存修改日志

    回复