先说两件事。第一件事，前段时间去医院看病，回到家后发现忘了挂复诊的号了，于是找到了我的南京APP。找医院，科室，医生，输入身份证号，就诊日期，一切ok。突然蹦出个就诊卡密码，是个啥？身份证后六位？123456？都不对。又去了支付宝，官方公众号，都是一样的需要就诊卡密码。没办法，开车去医院吧。一上楼，看到一个阿姨在推广公众号，问：密码是多少啊。答：六个0，一试果然对。一句话的事，花了我半天时间。

第二件事。今天坐地铁，发现可以支付宝支付，于是打开支付宝二维码，扫码后提示错误。不甘心，到边上一看，需要切换到乘车码，扫了一下，还是错误。果然验证了一句话，万事开头难！时间关系，用实体公交卡进了站。过会忙完了以后，再次坐地铁。还是不甘心，问了值班的小姐姐，怎么扫码失败啊？啥也没说，要了我的手机开始一顿操作，最后让我确认添加地铁卡。这回没觉得自己笨，因为自始自终都没有人告诉我要添加地铁卡啊，本以为刷了乘车码就万事大吉了，原来我刚才扫的是公交卡，不是地铁卡啊。这谁要是扫成功了就是奇迹了！

吐槽完这两件事以后，我想说，整天抱怨没有用户的运营同学，你们是不是也和我一样气到吐血啊。我也是呢，我还想打人呢！要打谁，你们知道吗？

先说说原因

我猜，参与测试医院公众号的那个同学，你一到这个项目组就有人告诉你，密码是六个0，于是经过了几百轮无懈可击的测试，产品顺利发布了。而参与支付宝地铁卡测试的同学，从进项目组第一天你就把地铁卡贴加到支付宝了吧。是不是都觉得很冤？然而没办法，我是这两个产品的终极用户，我在第一次使用这个产品时都失败了。

到底是谁的责任？

其实这个事情有很多个机会去避免。在产品发布之前，邀请小白用户进行测试肯定可以发现这个问题，但距离最终发布时间越长，这个需求丢失的可能性越大。在产品发布后，那位推广公众号的阿姨，还有地铁站售票的小姐姐，一定也不止一次听到过用户的抱怨，但他们都选择性忽略了这件事。又或者，他们确实帮（这个）用户解决问题了。彻底解决这个问题，确实不是他们的职责。新用户迟迟不来，运营同学难道不着急吗？也许，是海量成功的用户掩盖了事实。也许，是对异常场景的无能为力，他们确实无法及时，无遗漏的捕捉到这些异常事件。说来说去，这个事情似乎和所有人都没有关系，又似乎和所有人都有点关系。

所有问题的解决，都要靠可执行的机制

通过增加用户测试环节，可以发现用户接入的问题。通过用户访谈，可以知道用户抱怨什么，期望什么。通过建立用户反馈渠道，可以发现（积极的，不甘心的）那部分用户的问题，当然这需要激励机制，否则没有人愿意做这件事。然而可怕的是，这些问题只是冰山一角。更多的问题没有被提出来，更没有机会被解决，于是你的产品不知不觉就死了。

真正牛逼的机制，一定不依靠人

问题的原因找到了，各个环节都可以建立一定的规则去规避这些问题。不过，最大的问题在于人，只要是人执行的环节，都有可能有遗漏，误操作，执行不到位。不管是故意的，还是无意为之。其实解决这类问题的思路很简单，那就是异常监测。当用户遇到困境时，一定是走到了异常处理逻辑里。在设计产品时，除了要包含正常场景，还要捕捉异常场景。当出现异常场景时，一方面给予用户积极的提示，安抚用户的情绪。另一方面，要建立异常处理机制。对于严重级别高的异常，比如支付失败，开通失败，应该立刻触发平台告警，通知相关人员进行处理。而对于异常级别比较低的场景，应该定期进行自动化的归类和分析。只要能发现了问题，解决问题都不是个事。

敲黑板

说白了，对于核心业务的监控是产品不可或缺的一部分。一个好的反馈机制一定是自动化的，这会规避人性的弱点，同时解决量的问题。