mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-09 03:26:42 +08:00
72 lines
7.7 KiB
Markdown
72 lines
7.7 KiB
Markdown
<audio id="audio" title="35 | 对产品经理来说，做小程序有什么价值？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a9/be/a9517e70c6ada82c90cb1ae3fc7a27be.mp3"></audio>
|
||
|
||
极客时间的专栏读者你好，我是邱岳。从今天开始，我们一起来聊聊与微信小程序相关的话题。
|
||
|
||
我们的团队算是微信小程序比较早期的实践者，做了一些小程序，有不怎么成功的，也有数据还凑合的，在这个过程中，我也有一些思考和经验，在这里跟大家分享。
|
||
|
||
## 小程序的发展现状
|
||
|
||
微信小程序从两年前推出至今，已经有大量的人才和资本流进来，同时相关的争议一直没断过，每个阶段看好看衰的人都有很多，前几天，我看到还有文章在讨论是不是小程序被高估了。
|
||
|
||
我觉得，各方观点都应该去听一听，了解一下，但没有必要被这些观点左右了自己的判断。而且小程序的实施成本比 App 低了不少，完全可以自己下水做做看，试一下温度。
|
||
|
||
说到实施成本，这是小程序带来的最显而易见的收益。过去我们做 App，iOS 和 Android 俩平台、客户端服务端，各种兼容问题，还有版本管理等等一系列的限制。
|
||
|
||
这里说个题外话，虽然说可以通过一些技术框架去做跨平台的开发，但随着业务复杂度增加，终究还是要去解决各种各样技术上的细节问题。
|
||
|
||
据我所知，有很多用类似框架的团队在业务发展到一定程度之后，都在谋求回归或部分回归 Native 技术方案。
|
||
|
||
比如今年六月份 Airbnb 刚刚宣布放弃了 React Native。目前极客时间还在使用 Weex，我感觉随着业务发展和个性化需求的增加，当框架带来的限制开始影响效率时，说不定也会有变化。
|
||
|
||
我们回到小程序，小程序降低了多终端开发成本，几乎可以忽略 iOS 和 Android 之间的差异，开发效率得以大幅度提高，成本也相对低了一些。当然导致这个行业的门槛也低了不少，这个我们后面再说。
|
||
|
||
我们可以猜测一个趋势，随着智能手机的普及，这个生态其实趋于饱和，如果你不是做产品设计的，那么估计已经很少会去发现并下载一个新应用了，用户的时间可能会逐渐被几个高频的覆盖基础场景的应用所占据。
|
||
|
||
最终一些独立的服务提供商是透过这些超级 App 去服务用户，完成这一个服务的过程，或许就是通过类似小程序这样的机制。当然大家也看到了，目前微信、支付宝和头条系，以及百度都开始做小程序。
|
||
|
||
除此之外，作为大的平台提供方苹果，也一直在跟这些绕开自己的应用市场的超级 App 博弈。
|
||
|
||
比如从最早从应用号改名小程序，到反复不断的 iOS 支付相关的政策调整，都能看到苹果的警惕，毕竟 App Store 是苹果公司重要的生态环节，大家都不做 App 转去做小程序了，苹果会很不好受。
|
||
|
||
支付宝、头条系和百度的小程序我没有深入研究，没有发言权，我们的讨论也会集中在微信小程序的生态中。但一定要说清楚的一件事情是，不同的环境中做小程序的思路和逻辑是会有很大差异的。
|
||
|
||
## 小程序的价值
|
||
|
||
微信小程序的价值在于藏在其中的关系链，支付宝小程序应该是其中的信用体系和支付管道，头条和百度的小程序很可能会跟分发有关系，这会是不同生态结构的东西。
|
||
|
||
我看到网上有些表格在对比不同小程序之间的功能差异，支持什么技术特性之类的，我认为这不是最重要的，他们之间的差异一定不是技术特性的差异，而是环境和用户场景的差异。
|
||
|
||
我们还是回到微信小程序，刚才说微信小程序的价值在于：藏在其中的关系链，这是什么意思呢？就是说微信其实是通过小程序，把它其中人与人之间错综复杂的连接关系开放给了我们。
|
||
|
||
我们通过这张网迅速触及到了大量我们原来很难触及的人，比如举个极端一点的例子，我们怎样通过一个一线城市的白领迅速触及大量四五线城市的人群？
|
||
|
||
想象一下，其实北京高级写字楼上班的 David 可能同时还是微信里“家和万事兴”群里的狗剩儿，同时还是“XX 级 2 班青春不散场”群的老五。这就形成了一种奇妙的关系折叠，让一个人身上衍生出不同的关系类型，也可以触达到不同的人群，让我们通过这个渠道把信息传递下去。
|
||
|
||
当然，这个事情从原理上说，原来用 HTML 5 加上微信提供的 JS-SDK 也可以做，为什么非要用小程序呢？这其实也是小程序刚出现时很多人的疑问，而且如果我们往底层去看，往技术上去看，小程序也是通过 WebView 做的渲染，有什么不同呢？
|
||
|
||
**我的观点是有两个不同，一是体验上不同。** 基于 Web 做一些事情，比如做一些系统级的调用会受到限制，而且Web使用上总会感受一个加载刷新的过程，不顺滑，体验比较糟糕。
|
||
|
||
虽然小程序最终还是用 WebView 在渲染，但我觉得它算是在体验和灵活这件事情上，在 Native 和 WebApp 之间，又取了一个平衡。一定程度上保有WebApp 的跨平台灵活性，另一方面让小程序开发者能够更深度地分享微信的一系列原生能力。
|
||
|
||
同时小程序还在一定程度上保障了体验的统一，各种元素和控件之类的设计，包括流程和结构，不同的小程序都遵循微信的设计规范，保证了用户在整个小程序体系中的感受一致，不大会出现打开一个 Web 页面，半天不知道点哪里的状况。
|
||
|
||
**第二个不同，我觉得是用户归属的不同**。这个东西说起来有点微妙，就是过去我们做 WebApp 的时候，在微信打开一个页面，我们会觉得这个用户进到了我们的产品体系中，所以我们会让他注册登录，然后来使用我们自己的产品。
|
||
|
||
而在小程序的体系下，感觉用户还是在微信里，我们是给微信提供应用插件的，除了少数小程序之外，大部分小程序可能就简单地要一个授权便可以正常工作了。
|
||
|
||
其实按理说在 Web 上利用微信的 JS-SDK 去做授权，也是一样的效果，可是这两个差异确实存在，Web 上我们会想方设法引导用户去下 App，或者去关注公众号，好像是在努力把微信体系中的用户抢夺到自己手里。
|
||
|
||
而小程序中，由于微信做了非常严格的限制，所以大家都不得已变得很淡然，既然抢不走，那就到微信的地盘上好好服务用户，这样导致用户开始使用一个应用的门槛，降低了很多，打开小程序的时候心理负担也小了不少。
|
||
|
||
比如我打开小程序的卡片，就顺手可以开始使用了，而看到了Web页的时候，我就可能会预期它让我输入用户名和密码开始登陆。在技术上虽然没什么差距，但是在心态和体验上，确实会不一样。
|
||
|
||
## 总结
|
||
|
||
说完 WebApp 和小程序之间的这点差异，我们今天的内容就先到这里，我们从小程序的实施成本开始说起，提到小程序可能成为一些超级 App 与开发者分享用户的方式。提到微信小程序的厉害在于变相向开发者开放了微信的关系链，最后提到了 WebApp 和小程序差异。
|
||
|
||
接下来我们会展开来分享微信小程序是如何向我们提供关系链，以及我们应当如何利用这一点。虽然这很可能不是微信的本意，但这个特性在当前阶段却被开发者放大了。
|
||
|
||
你能想象到的，小程序和传统的 WebApp 之间有什么差异呢？欢迎留言讨论，我们下次继续。
|
||
|
||
|