从一个数字产生的一些感想

一年前的时候，我刚到公司，对于产品经理这个职位，很多东西都还不懂，记得那会儿去买家线技术部轮岗，做了这么一个需求：

买家页面的顶部需要有一个购物车的图标，在购物车图标旁边显示用户当前购物车中产品的数量，前端通过Ajax请求异步来加载用户购物车中产品的数量，而我就负责要去实现这个Ajax接口。

理所当然的，我自然就想到了根据用户的cookie拿到用户的id，然后去数据库里面根据id去count下用户的购物车中的产品总数就可以了，本来给我三天时间来完成这个需求的（主要是因为我是产品经理……非技术出身），但是我一下午基本就把代码写完了，提交上去后，居然被退了回来，架构给我的理由是：买家页面浏览量太大，每次访问一个页面都要去数据库里面count一下，压力肯定太大，所以要做缓存。

当时和项目的PD、架构几经讨论后，最终确认的方案是对用户的购物车产品数量做了一个20分钟的缓存，如果缓存没有超时就不去数据库中取数，而是直接取缓存中的数据。

这就带来了一个非常可笑的问题：用户有可能在把产品添加进购物车以后，发现居然这个数字没有变化，等到进入购物车后，才会发现这个产品确实被添加进去了，除非用户登上20分钟，等这个数字的缓存刷新。

当时我就这么让这个需求上线了，现在想想，如果是现在的我作为当时的PD，会如何做呢？

首先我绝对不会让这个需求上线！我们一直天天嚷嚷着技术驱动业务，如果这么简单的一个需求从技术上都无法做到，那拿什么来说技术驱动业务呢？我上一篇文章说到，用户体验是高于一切的东西，一个产品功能再怎么完善，用户体验差的话，永远都不会是一个成功的产品。不管是加机器也好，用其他的方案也好，不管如何，购物车中的产品数量根据用户的操作实时展示是绝对不能妥协的一个需求。

从而我又想到了最近在做的一个项目，开发前端测试加起来大约是40人日左右，按照工作量算是一个小项目，今天找开发聊资源的时候，开发提出拆分成小需求来做，先上一个简单的版本，再把后续的内容完善等各种拆分的方案，至少到目前为止我觉得真是扯淡。为什么我们要强调用户体验至上？因为不好的用户体验就意味着大量的用户流失，这是再怎么迭代都挽回不来的！在我看来，我宁愿选择晚一周上线，我也不愿意先上线一个畸形的版本来所谓的让用户“先用起来”。

工作了一年多了，直到最近才开始慢慢的找到了些许产品的感觉，以上论述仅代表个人观点，欢迎拍砖，但勿盲信！