只买书：一个失败的微信小程序产品

背景

去年因为换部门的原因，我从原工位搬走，有很多旧书，送了些给同事，仍有一大堆需搬走。我便在想，这些旧书是否有更好的处理方式。我自己喜欢买书，但看完的书就成了鸡肋，丢掉也不舍得。虽然有多抓鱼、孔夫子这种旧书平台，但仍不是我理想中的处理旧书的方式。理想中的应该是像图书馆那样，想看的人去借阅，到了时间归还或传递给下一位借书人。因此，如果能有一个网上平台，大家可以把闲置的书籍共享出来，在网上自由流动，由需要的读者借阅，看完后再传递给下一个读者；就像是图书漂流，永远传递下去，这样会很有意思也很有意义。

我发现国外有个叫 bookcrossing 的网站¹，建站时间比亚马逊还早，很像我说的这种网上平台。bookcrossing 即图书漂流，玩法是在网站登记闲置书籍，用户得到一个唯一的图书编号 BCID, 下载带有 BCID 的标签，打印贴到书上。然后可以将书送人或放到“野外”：咖啡厅、车站、旅游景点等，等着被人“抓到”。这种图书漂流的方式挺有趣，不过问题是捡到书的人不一定会到网站上去登记，这样图书追踪信息会丢失。

而国内我也没找到类似的图书分享网站，于是就想不如自己动手做一个。说干就干，于是买了个 zhimaishu.com（只买书）的域名²，准备做个图书分享的平台。“只买书”这个名字源于我在公司内创建的一个兴趣组织“只买书不读书”，这是一个线上的团队，最多的时候有四千多人加入。团队成员还会自发组织一些线下读书活动，上个月在深圳开会时遇到一位未谋面的同事，她认出了我并提到“只买书不读书”团队，让我感到惊喜。因此，对“只买书不读书”这个名字我是很有感情的，而为了让域名短一些就取了前三个字。

设计实现

“只买书”的流程设计与 bookscrossing.com 不太一样：用户通过线下传递书籍，然后在“只买书”网上平台上记录追踪过程。一个常规的分享书流程如下：1) 藏书人在“只买书”上登记书本；2) 藏书人发布共享图书信息；3) 借书人浏览到共享图书信息并申请该书；4)藏书人确认申请并约定交书地点时间；5) 线下传递书本后，在“只买书”上确认。6) 书本成为共享图书后不能为私人所有，等到借书人看完或不再需要，下一位借书人会申请该书，重复上述3~5流程。

产品技术选型我考虑用微信小程序，因为微信的用户基础以及不需要额外的应用安装、跨平台；后台数据存储处理采用 ruby on rails³, 作 api server. 由于我没微信小程序开发经验甚至没有前端开发经验，在快速实现了基本的几个 API 后，便开始学习如果做微信小程序。在简单比较了微信小程序原生框架和其他开发框架后，我决定选用 taro 这个开发框架⁴。选用 taro 除了它支持多端特性外，更多是因为它使用 react 基础框架，技术栈上相对成熟且资源更丰富。

功能上除了图书共享，还实现了个人藏书的功能，通过扫描 ISBN 码获取图书信息并记录在案，这样可以管理自己的图书，选择是否将书共享出去，或做标记（未来也考虑做读书笔记等扩展功能）。在实现扫描图书 ISBN 码获取图书信息的功能时遇到了些技术难题。这块我记得豆瓣有 API 提供这种服务，可是当我动手做“只买书”小程序时，才发现豆瓣早已经停止了这项服务（网上的说法是做图书小程序的太多，豆瓣因此停止了义务服务）。于是我几经周折，找到了一位网友提供的豆瓣 API 代理服务，限制是该服务每小时一共提供一千次请求，因此每个小时的后半段往往获取不到信息。（后来该代理服务也停止了。）

在小程序起初的版本里，我还实现了借书功能：与共享图书不同的是，借出去的书还属于自己，等借书人看完后归还给自己。后来觉得该功能多此一举，且容易给用户造成误解，因此我在1.5版本时去除了该功能。仅保留了共享图书功能，以及个人藏书管理的功能。

发布上线

今年春节期间因为疫情而意外获得了长假，正好利用这段时间将小程序完成并上线。微信小程序上线过程总体上比较顺利，有两次版本被拒是一次因为后台没有数据，因此在审核时被误认为是测试版本；还有一次是因为增加了评论功能后，审核时认为超出了原申请小程序时的服务范围了，增加申请服务范围后通过。

上线后我给一些熟悉的朋友推广并询问他们的使用体会，虽然大家礼节性的给予热情的支持，但随着连我自己也用的越来越少后，慢慢的得到的反馈越来越少，而我更新的动力也越来越少。一方面上班后可支配时间变少，另一方面我也意识到这种共享图书的方式极不方便，因为“只买书”小程序并没有解决共享图书的便利性的问题，仅仅是提供一个共享图书的信息发布平台。开始的时候我把家里的藏书扫描了一遍，但后来便发现没有打开小程序的机会了。

于是，在几个迭代的修改和发布上线后，我便停止了小程序的开发和更新。而最终也没有在任何的论坛或社交网站去推广“只买书”。

总结

“只买书”的失败可以总结以下几点原因：

1. 伪痛点。共享图书看上去是源自我自己的一个痛点，但实际上这不是痛点，而是源于我的其他诉求：要开发一个软件产品。而共享书也不是要解决书多的“痛点”，而是一种公益活动。
2. 没有市场，缺少目标用户群。买实体书的人已经很少了，而有共享书需求的人更少。不过，我能看到的有分享（或出售）实体书的群体，是儿童的家长。童书（特别是绘本等）的更新频率更高，一般半年或一年就要换很多套童书，这些倒是有很大的二手或转让市场。
3. 缺少核心卖点，也缺少亮点。一位朋友跟我反馈使用感受，想了半天说“扫码添加图书挺方便的”；也许能想到的只有这点了。而扫码添加图书和个人书籍管理几乎是所有做图书应用类应用的必备特性，而核心的功能——图书共享又缺少让人眼睛一亮的特性。
4. 过于依赖线下流程。“只买书”的主交互流程中有太多线下的处理环节：登记、借书、确认，需要约定时间地点取书，这显然是非常不互联网的做法。

从去年国庆节假期的第一次代码提交到这个国庆节，刚好一年。半年业余时间实现，半年失败并遗忘。“只买书”微信小程序除了占用了些业余时间外及后台服务器的支出，倒是没有其他成本。所以，算是一次成本不大的失败尝试，而我也从中了解了小程序的开发及发布，并收获了一些产品开发的经验和教训。总体而言，还是值得的。

“只买书”的前后端代码已经开源在 GitHub 上，如果感兴趣，欢迎 star 或 fork。因为当时希望尽快上线，代码不是那么整洁；特别是小程序端的 js 代码，更是能 run 就行的那种。

• 后端： hutusi/bookshare
• 小程序： hutusi/bookshare-wechat

---