微信=聊天工具+插件

本文部分内容，来自于@行者慎思的微信分享，特此感谢。

在近期参加了简书-产品交流微信群组织的一次微信线上分享，@行者慎思带来的《微信发展历程中的必然和偶然》，而当天也是微信小程序公布内测的第二天。

在分享中，回顾了微信的发展路径，微信的前生、微信的对手以及总结了微信发展过程中的必然和偶然。当然里面是干货满满，也至于已经过去一周了，才开始提笔写这篇文章，因为一直在消化和理解分享的内容。

在分享中，@行者慎思反复提到过一个词，那就是“插件化模式”，不管是在微信的前身——QQ邮箱中，进行社交尝试，还是在微信中最初的公众号、支付，接入滴滴、京东等，都是类似于插件一样的存在。甚至最近刚刚发布的小程序，未来发布的小程序，也更像用户为微信安装的插件一样存在。

这里提到的“插件化模式”，恰好与我之前发表的文章《浅谈产品的功能边界》有点不谋而合，插件化模式，也类似于提出的产品的功能边界的观点。

在文章中，我举了这样一个例子 — 产品的功能就如同乐高一块块独立的积木，而产品就是通过不同积木组合，依据业务需求和产品经理的一点奇思妙想，拼出来的模型。而积木与积木之前拼合在一起的只是那简单的几个卡扣而已。一旦某一块积木出现问题或需要调整，只需要动到那一块积木和与之相连的即可。

如果将微信进行分拆和解构，其实就会发现微信更像是一款聊天工具，增加了很多的插件。当然，这里的插件，不会像垃圾插件一样，表现的多余和臃肿，而是恰如其分的出现在适合的位置。

其实，你打开微信的我，点击设置，通用，进入功能，不管是语音记事本、微信运动，就连附近的人、摇一摇，也都是功能插件的模式存在的。

我—设置—功能

最能体现微信插件化模式的有两个页面，一个就是发现，在一个就是钱包页面。

发现              钱包

那为什么选择用插件化模式呢？

一方面，是可以降低试错的成本。就如同在当初要上公众号时，最初是做了两个插件功能进行尝试，微博阅读、腾讯新闻，腾讯微博由于不如新浪微博，所以微博阅读不行，所以微博阅读下掉了，但腾讯新闻给新闻带来了很大的高质量的流量，也将腾讯新闻达到现在的位置。尝试乐新闻阅读的可能，微信将此功能最终演变成公众平台，因此让微信成为最大的内容分发及阅读平台，微信也成了最大的浏览器。

另一方面，就是功能的可复制性。在微信前身QQ邮箱阶段，就进行诸如广播、QQ离线消息、订阅中心的尝试，而当微信时，就直接进行了功能的迁移和对微信的适配调整。

在我的文章《浅谈产品的功能边界》时，提到了两个好处：

从产品的角度来看，功能应该是独立和模块化的，产品只是根据业务和用户体验，在不同的页面，拼接不同的功能模块，从而达到产品体验的最大化，同时使产品富有灵活性和可扩展性的特性。

通过借助产品的功能边界，去设计功能，从产品金字塔最低端的细小功能点一点点去设计，到后来功能块、功能、页面，乃至整个产品，看似是个完整的整体，其实里面又独立者大大小小的个体，通过个体与个体之间的独立又紧密配合，来达到整体的配合，无疑这是最完美的情况。

当然，正如乐高积木一样，有些人可以将乐高积木拼接成个很富有想象力的模型，获得人人称赞，也有人缺乏对产品的理解和巧思，导致产品尽管按照插件化设计了，但依旧臃肿不堪。

其实不管是插件化模式，还是其他模式，总归是个实现思路，最核心的还是要对产品的理解，正如在分享中，@行者慎思提到的一个，微信在发展过程中， 每个功能都是当下阶段所需要而补充的。清楚的知道产品的定位和当下的最需要的、最需要补充的，才是最关键的。插件化模式只是最终实现的一个思路而已。