事件经过：
公司有一套图书管理系统(BMS)，不太美观，代码旧，技术旧，但已被使用了较长的时间，运行良好，稳定，不出错。
突然领导拍案而起，要重新用新的技术，新的UI，开发一套新的BMS。
领导拉了几个人，组建了一个开发小队，画了几个流程图搭配几句说明，然后跟开发小队说说他这些流程图的含义，开发小队就开干了。
开发小队看着旧系统，理解着它的逻辑，结合那几个流程图，以新的技术，新的UI，开发了个半成品，然后领导跟开发小队谈这个“复制过来”的半成品的问题。被领导刷完后，拿去给用户一看，想做个调研和验证做法是否正确。
结果用户大发雷霆“你相当于把旧系统搬过来了，做这个干嘛呢，一点用处都没有，不好用”。
此时用户用习惯了旧的系统，不想再学习这个新的了，看到这么大区别，想旧系统确实没这么美观，可旧系统用起来也很方便，并且还稳定，为何要浪费精力去学新系统。
我的看法是，先好好想想，我们如何打败“旧系统”，“旧系统”有一定的客户粘性(主要是有不小的转移成本，转移风险)。
新系统有新系统的好。更美观的界面？更快的响应速度？甚至更简便的操作(可是用户都用习惯了不那么简便的操作了，而且操作量又不大，频次也不高，不想学)？
嗯，我们都知道用户很懒(当初我也是迫不得已才愿意从office 2003转向office 2007的)，你这些卖点哪怕他信你，他也不想换。
所以我认为，应该从他的懒入手去解决问题。要去了解用户的痛点(有什么东西是他想要而旧系统目前是没有的？)，比如旧系统是以邮件的形式，通知用户去处理他的流程节点的，有时候工作太忙没看到邮件，或者在外无法处理，导致延误。那么我们是否可以考虑增加以微信通知他，并且可以在微信上处理节点？有了这个他需要的新功能，如果进展顺利，他可能就慢慢地愿意去尝试使用这个系统。然后慢慢地发现，原来新系统同样可以做旧系统的事。
网友评论