升级到2.1,添加软件产品构建章节、基础设施搭建章节。填平从理论到实践之间的鸿沟,帮助读者更快起步。
20
README.md
@@ -1,11 +1,15 @@
|
|||||||
# 《一人企业方法论》第二版
|
# 《一人企业方法论》V2.1
|
||||||
|
|
||||||
|
## 2.1 版本
|
||||||
|
|
||||||
|
1. 添加《基础设施及搭建》相关章节,填平从理论到实践之间的鸿沟,帮助读者更快起步。
|
||||||
|
|
||||||
## 对第一版的改进
|
## 对第一版的改进
|
||||||
|
|
||||||
1. 从长文到一本近6万字的小书,从有感而发的分享到两年迭代而得的**完整方法论**
|
1. 从长文到一本近6万字的小书,从有感而发的分享到两年迭代而得的**完整方法论**
|
||||||
1. 不再局限在独立开发,发展为**更为通用的方法论**,非技术读者也可创作数字商品或基于NoCode/开源项目+AI辅助构建在线服务
|
1. 不再局限在独立开发,发展为**更为通用的方法论**,非技术读者也可创作数字商品或基于NoCode/开源项目+AI辅助构建在线服务
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
## 作者信息
|
## 作者信息
|
||||||
|
|
||||||
@@ -25,7 +29,7 @@
|
|||||||
|
|
||||||
## 电子书
|
## 电子书
|
||||||
|
|
||||||
- 可使用 mdbook-epub 工具自行编译
|
- 可使用 mdbook-epub 工具自行编译:`mdbook-epub --standalone true` 然后 epub 在 book 目录下
|
||||||
- 扫码订阅《方法论》更新频道后下载: [进入](https://subdeer.cn/channel/landing/11)
|
- 扫码订阅《方法论》更新频道后下载: [进入](https://subdeer.cn/channel/landing/11)
|
||||||
|
|
||||||
## 在线阅读
|
## 在线阅读
|
||||||
@@ -46,4 +50,12 @@
|
|||||||
1. [一人企业≠一人业务](https://ft07.com/one-person-enterprise-does-not-equal-one-person-business?mtm_campaign=github&mtm_kwd=opbmv2)
|
1. [一人企业≠一人业务](https://ft07.com/one-person-enterprise-does-not-equal-one-person-business?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
1. [优势发现:副产品优势](https://ft07.com/discovery-of-by-product-advantages?mtm_campaign=github&mtm_kwd=opbmv2)
|
1. [优势发现:副产品优势](https://ft07.com/discovery-of-by-product-advantages?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
1. [风险评控:从副业开始](https://ft07.com/start-from-side-project?mtm_campaign=github&mtm_kwd=opbmv2)
|
1. [风险评控:从副业开始](https://ft07.com/start-from-side-project?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
1. [风险评控:管理和利用不确定性](https://ft07.com/managing-and-utilizing-uncertainty?mtm_campaign=github&mtm_kwd=opbmv2)
|
1. [风险评控:管理和利用不确定性](https://ft07.com/managing-and-utilizing-uncertainty?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
|
1. [产品构建:从零构建软件产品或服务](https://ft07.com/building-software-products-or-services-from-scratch-1/)
|
||||||
|
4. 基础设施及搭建
|
||||||
|
- [理想的一人企业基础设施](https://ft07.com/what-is-the-ideal-one-person-business-infrastructure?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
|
- [用户池和触达能力](https://ft07.com/infrastructure-user-pool-reach-capability?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
|
- [内容池和自动化能力](https://ft07.com/content-pool-and-automation-capability?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
|
- [产品池和支付能力](https://ft07.com/product-pool-and-payment-capability?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
|
- [众包能力](https://ft07.com/crowdsourcing-capability?mtm_campaign=github&mtm_kwd=opbmv2)
|
||||||
|
- [搭建一人企业基础设施](https://ft07.com/setup-a-one-person-business-infrastructure?mtm_campaign=github&mtm_kwd=opbmv2)
|
@@ -6,4 +6,4 @@ src = "src"
|
|||||||
title = "一人企业方法论"
|
title = "一人企业方法论"
|
||||||
|
|
||||||
[output.epub]
|
[output.epub]
|
||||||
cover-image = "src/images/opb-book-cover.jpg"
|
cover-image = "src/images/opb-book-cover-2.1.jpg"
|
@@ -10,4 +10,4 @@
|
|||||||
|
|
||||||
## 一人企业方法论
|
## 一人企业方法论
|
||||||
|
|
||||||

|

|
@@ -16,4 +16,12 @@
|
|||||||
1. [一人企业≠一人业务](./one-person-enterprise-does-not-equal-one-person-business.md)
|
1. [一人企业≠一人业务](./one-person-enterprise-does-not-equal-one-person-business.md)
|
||||||
1. [优势发现:副产品优势](./discovery-of-by-product-advantages.md)
|
1. [优势发现:副产品优势](./discovery-of-by-product-advantages.md)
|
||||||
1. [风险评控:从副业开始](./start-from-side-project.md)
|
1. [风险评控:从副业开始](./start-from-side-project.md)
|
||||||
1. [风险评控:管理和利用不确定性](./managing-and-utilizing-uncertaint.md)
|
1. [风险评控:管理和利用不确定性](./managing-and-utilizing-uncertaint.md)
|
||||||
|
1. [产品构建:从零构建软件产品或服务](./building-software-products-or-services-from-scratch.md)
|
||||||
|
4. [基础设施及搭建](./chapter-build-infrastructure.md)
|
||||||
|
1. [理想的一人企业基础设施](./what-is-the-ideal-one-person-business-infrastructure.md)
|
||||||
|
1. [用户池和触达能力](./infrastructure-user-pool-reach-capability.md)
|
||||||
|
1. [内容池和自动化能力](./content-pool-and-automation-capability.md)
|
||||||
|
1. [产品池和支付能力](./product-pool-and-payment-capability.md)
|
||||||
|
1. [众包能力](./crowdsourcing-capability.md)
|
||||||
|
1. [搭建一人企业基础设施](./setup-a-one-person-business-infrastructure.md)
|
516
src/building-software-products-or-services-from-scratch.md
Normal file
@@ -0,0 +1,516 @@
|
|||||||
|
# 产品构建:从零构建软件产品或服务
|
||||||
|
|
||||||
|
本文尝试完整地介绍一个软件类产品从规划到上线的全过程,希望能给你带来启发。内容节选和改写自[《精益副业》](https://github.com/easychen/lean-side-bussiness)。
|
||||||
|
|
||||||
|
产品流程
|
||||||
|
----
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
更适合一人企业的产品流程
|
||||||
|
|
||||||
|
在本文中,我们采用的是优化后的、更适合一人企业的产品流程。其中「商业模式画布」步骤,建议换为更加有针对性的「[一人企业画布](https://ft07.com/opb-canvas-and-opb-report/)」。
|
||||||
|
|
||||||
|
这个流程和很多硅谷公司的产品流程很像,但是针对一人企业做了一些调整和优化。经过三年多时间的使用,我们自己用起来已经很顺手。
|
||||||
|
|
||||||
|
1. 首先定义价值主张,然后围绕着价值来设计商业模式画布。
|
||||||
|
2. 完成画布以后,我们把画布里的「客户细分」部分拿出来,做成「用户画像」。这是一个将细分客户具体化、变得有血有肉的工具。
|
||||||
|
3. 有了画像,再据此还原用户使用产品的各个场景,他们是用电脑还是用手机、是在家里还是在车上使用等等。
|
||||||
|
4. 想象为了在上述场景下向用户传递价值,我们需要什么样的功能,这样就会得到一个功能列表。
|
||||||
|
5. 功能列表会很长,不同功能的优先级也不同。所以我们会对功能进行分期,其中最重要也是最靠前的一个功能分期,就是用来开发「最小可行产品」的分期。
|
||||||
|
6. 当「最小可行产品」开发完成后,进行「产品市场契合」的验证,如果达不到设定的验证目标,就需要调整功能,甚至重新设计价值主张。
|
||||||
|
7. 当通过「产品市场契合」后,我们就可以按照分期迭代开发产品的其他功能了。
|
||||||
|
8. 在迭代过程中,我们会持续对新上线的部分功能进行增长优化,保证每一部分功能达到预定的目标。
|
||||||
|
|
||||||
|
以上就是我们为一人企业优化的精益流程,虽然讲起来比较多,但实际操作起来还是比较简单的。而且我们其实省略了不少大公司流程中的环节,比如用户访谈、焦点小组等。
|
||||||
|
|
||||||
|
项目简介
|
||||||
|
----
|
||||||
|
|
||||||
|
先来介绍一下我们的实战项目 ------ 福利单词。
|
||||||
|
|
||||||
|
它来自于我在学习过程中的一个原生需求。最开始我是使用 Anki 这个软件来背单词,软件很好用,但是每次都有一种逼着自己去背的感觉,背完以后如释重负。为了提醒自己不要逃避,我还定了一个闹钟每天催自己。
|
||||||
|
|
||||||
|
有一天,我又因为上[Pixiv](https://www.pixiv.net/)(一个二次元内容创作社区)看图忘记了时间。突然间我想到,能不能把背单词和看图片这两个行为绑定到一起呢?
|
||||||
|
|
||||||
|
你看,背单词虽然有用,但让我痛苦,度日如年;看图片很欢乐,流连忘返,但似乎不是很「有用」。如果我们把两者结合到一起,一边看图一边背单词,是不是就可以让背单词不那么难受,可以持续不断地背下去了?
|
||||||
|
|
||||||
|
这就是福利单词的出发点。
|
||||||
|
|
||||||
|
接下来,我们就来看看,怎么从这个还有些模糊的想法中提出一个明确的价值主张,然后围绕它进行商业模式规划、功能和界面设计、验证和迭代开发,最终使其成为一个商业产品。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词APP
|
||||||
|
|
||||||
|
需要说明的是,开发过程很难在有限的篇幅中讲解清楚,也偏离了本文的主题,所以我们只会简略地提及一些需要注意的地方,并不会进行开发的教学。
|
||||||
|
|
||||||
|
第一步:商业模式规划
|
||||||
|
----------
|
||||||
|
|
||||||
|
首先我们通过商业模式画布来规划产品的商业模式。
|
||||||
|
|
||||||
|
### 价值主张
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的价值主张
|
||||||
|
|
||||||
|
福利单词的核心价值主张在于为那些觉得学习英语充满挑战的人提供一种轻松愉悦的学习方式。其目标是通过增添学习过程中的乐趣来减轻学习者的压力,使本来短暂且困难的学习活动变得更加可持续和习惯化。
|
||||||
|
|
||||||
|
因此,在「价值主张」部分,我们特别强调了两个关键点:「无痛学习」和「持续性学习」。这两点构成了该产品的核心价值。
|
||||||
|
|
||||||
|
有了这些价值主张,我们能够帮助客户克服以往阻碍他们学习的障碍,从而促进他们的个人成长和提升。
|
||||||
|
|
||||||
|
### 客户细分
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的客户细分
|
||||||
|
|
||||||
|
细化价值主张需要我们仔细考虑客户的细分。考虑到福利单词是一款学习软件,其目标客户群体自然与学习英语的需求密切相关。我们可以将目标客户分为三类:
|
||||||
|
|
||||||
|
1. 需要备考大学英语四六级的大学生。
|
||||||
|
2. 有留学或移民需求,需要准备雅思、托福考试的人群。
|
||||||
|
3. 希望通过提高专业英语水平以在职场中取得更好表现的职场人士。
|
||||||
|
|
||||||
|
这三类客户的学习目的各有侧重,但通过提供「词库切换」或「自定义词库」功能,我们的软件能够灵活满足他们的需求。
|
||||||
|
|
||||||
|
### 价值主张的细化
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
细化后的福利单词价值主张
|
||||||
|
|
||||||
|
仅仅提供词库供用户学习,并不能使我们的软件与众不同。因此,我们在价值主张中追加他们难以抗拒的部分------「糖」。
|
||||||
|
|
||||||
|
然而,对不同的用户群体而言,「糖」的含义并不相同。
|
||||||
|
|
||||||
|
如果只是放一些二次元的萌妹子,只有喜欢动漫的人会觉得这是他们的「糖」,可以吸引着他们,每天都来看一看。对于其他一些二次元无感的人群来讲,这些图就毫无吸引力,所以我们需要增加「糖」的种类。比方说有的妹子就喜欢看帅哥、有的粉丝就喜欢看偶像、有的铲屎官就喜欢看猫猫狗狗、有的吃货就喜欢看肉和甜点。这一部分,我们可以用多图库的方式来满足。
|
||||||
|
|
||||||
|
据此,我们为不同的客户细分制定更具体的价值主张:
|
||||||
|
|
||||||
|
1. 「每天看40分钟妹子,一个月记住四六级词汇」
|
||||||
|
2. 「看着帅哥,把雅思托福词汇搞定」
|
||||||
|
3. 「一边云吸猫一边升职加薪」
|
||||||
|
|
||||||
|
现在听起来是不是就有吸引力多了?
|
||||||
|
|
||||||
|
### 渠道通路
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的渠道通路
|
||||||
|
|
||||||
|
在「渠道通路」方面,我们计划通过微博引入种子用户。通过对种子用户的测试反馈,一旦产品转化率达到预期标准,我们便会展开更广泛的合作并通过微博启动广告投放,以此来衡量广告成本与带来的流量效果。
|
||||||
|
|
||||||
|
### 客户关系
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的客户关系
|
||||||
|
|
||||||
|
为了维护良好的客户关系,我们将利用腾讯的「兔小巢」工具提供售后支持。这样,用户可以方便地提交反馈,而我们则能通过微信或者QQ等多种渠道及时响应。
|
||||||
|
|
||||||
|
### 关键活动
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的关键活动
|
||||||
|
|
||||||
|
在关键活动方面,最小可行产品(MVP)的初版应包含基础的背单词功能、100个单词与相对应的图片,以及简单的互动式学习模块。此外,我们还需要关注用户的学习数据,以验证我们的价值主张。
|
||||||
|
|
||||||
|
在MVP验证成功后,我们将开发网页版应用,作为第一阶段的产品发布。此阶段的关键功能包括背单词界面和词库选择功能。为了实现收益,我们还将引入支付和订单系统,并开发分析工具以优化转化过程。
|
||||||
|
|
||||||
|
### 关键资源
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
福利单词的关键资源
|
||||||
|
|
||||||
|
关键资源方面,除了人力、资金和时间外,我们还需特别注意用于背单词的图片资源。尤其是在收费环节,我们必须确保图片资源的合法使用。
|
||||||
|
|
||||||
|
在最小可用产品中,因为不涉及到收费,我们可以使用的图片很多。一旦开始收费,如果还是不加识别地从网上下载各种版权不明的图片,放到自己软件里并以收费的方式进行售卖,很可能会出现侵权。
|
||||||
|
|
||||||
|
所以,我们就需要思考图片资源的解决方案。粗略分析后,有以下几种思路:
|
||||||
|
|
||||||
|
1. 作者授权
|
||||||
|
2. 换用无版权图片
|
||||||
|
3. 用户自行提供图片
|
||||||
|
|
||||||
|
#### 作者授权
|
||||||
|
|
||||||
|
直接找作者把图片买下来,然后作为付费词库卖给用户,这是最直接的方式。但有问题,那就是价格,光是大一点的词库就有超过一万个单词,也就是说我们要买一万多张图。如果按一张图 50 元计算,需要 50 万的投入。
|
||||||
|
|
||||||
|
在一分钱都还没挣之前就做出这么大的投入,风险还是很高的。这种方式更适合我们挣到钱以后,在扩大规模时使用。
|
||||||
|
|
||||||
|
#### 换用无版权图片
|
||||||
|
|
||||||
|
当然,我们也可以寻找无版权的图片来做图库。这样即使我们打包在软件里进行商业销售也不会有任何问题。互联网上已经有比较庞大的无版权高清图库了,比如 [Unsplash](https://unsplash.com/) 等。不过这些图库主要是风景和动物,人物类非常少。
|
||||||
|
|
||||||
|
#### 用户自行提供图片
|
||||||
|
|
||||||
|
本质而言,我们卖的是「看图背词」的工具,而不是图片本身。现在之所以在版权上有风险,是因为打包导致的。所以我们可以尝试着将付费的服务和免费的图片分离开。
|
||||||
|
|
||||||
|
比如我们可以给用户提供自定义图库的制作工具,让他们把自己收藏的图片导入进去。这样既能达到目的,又没有版权上的风险。
|
||||||
|
|
||||||
|
类似需要考虑的,还有背单词时用到的音频。最简单粗暴的方式是使用云平台的TTS(文字转语音)接口直接生成。
|
||||||
|
|
||||||
|
### 成本与收益
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的成本和收益
|
||||||
|
|
||||||
|
最后,通过填补商业模式画布的相关部分,我们可以开始对成本和收益进行预估,以计算预期利润区间。
|
||||||
|
|
||||||
|
由于我们开发的项目相对比较小,用到的资源也不是特别的多,所以商业模式画布做得还不算细致。不过通常来讲,第一版的商业模式,画布本身也不会特别细。它是随着项目的进展不断被细化的。
|
||||||
|
|
||||||
|
最后我们来看看完整的商业模式画布:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
福利单词的完整商业画布
|
||||||
|
|
||||||
|
第二步:为细分客户建立用户画像
|
||||||
|
---------------
|
||||||
|
|
||||||
|
### 什么是用户画像
|
||||||
|
|
||||||
|
在商业模式画布里面,我们对客户进行了细分,把客户分成了不同的组,每一组代表一个独立的需求。
|
||||||
|
|
||||||
|
用户画像(persona)呢,就是给这些已经分好的组,每一组搞一个人设、建一个虚拟形象,让其变得有血有肉、有姓名有年龄有性别、有自己的身份有自己的爱好、有使用产品的场景。
|
||||||
|
|
||||||
|
这样当我们聊到这个用户画像的时候,就像在讲自己的朋友、同事一般熟悉的人一样。
|
||||||
|
|
||||||
|
把抽象的需求变成活灵活现的人,这样我们在进行产品设计的时候,就更容易还原到场景,带着画面去想象这个人的需求和行动,这就是用户画像的意义。
|
||||||
|
|
||||||
|
### 福利单词的用户画像
|
||||||
|
|
||||||
|
接下来,我们就在福利单词的客户细分基础上,为每一类客户建立用户画像。
|
||||||
|
|
||||||
|
#### 四六级备考生
|
||||||
|
|
||||||
|
首先是备考四六级的大学生这个细分客户群。我们叫他王小康,设定为一个大三的男生。他现在有一个迫切的任务,就是一定要通过四级考试。这位同学是一个动漫宅,他喜欢看的图就是二次元的萌妹子。
|
||||||
|
|
||||||
|
#### 留学移民预备军
|
||||||
|
|
||||||
|
然后我们来给有留学移民需求、需要考雅思和托福的人群做一个用户画像。我们叫她章小留,她是一个大学刚毕业一年的女生,现在有出国留学的想法,正在准备雅思考试。这位同学是追星族,喜欢看的图片是韩国帅哥。
|
||||||
|
|
||||||
|
#### 专业提升小白领
|
||||||
|
|
||||||
|
第三个细分人群的用户画像,我们叫她卢小白,是一个毕业两年左右的女生。在生物公司从事技术相关的工作,她需要尽快熟悉大量的生物专业方向的英文单词,方便她更好地了解公司业务。她家里有猫,喜欢看的图片是萌宠和美食。
|
||||||
|
|
||||||
|
确定了这三个用户画像的基本资料以后,我们会给他们配上头像,写上他们的需求关键字,把它整理到一页A4纸上。
|
||||||
|
|
||||||
|
这样我们就可以把它打印出来,贴到墙上,在做产品设计的时候可以随时去看他们,就像看着我们身边的熟人一样。
|
||||||
|
|
||||||
|
### 画像的头像制作
|
||||||
|
|
||||||
|
很多书里面都强调说,用户画像的头像要尽可能真实,最好用真人头像。但需要注意在网上乱找真人头像容易导致肖像权问题,这里给大家推荐一个通过AI生成真人头像的网站,叫做 thispersondoesnotexist.com。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
thispersondoesnotexist.com
|
||||||
|
|
||||||
|
不过这个网站生成的多是欧美人,对国内的产品来讲,反而各种违和。我更喜欢使用日系的动漫捏脸网站来做,比如 [charat.me](https://charat.me/) 这个网站。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
charat.me
|
||||||
|
|
||||||
|
### 最终的用户画像
|
||||||
|
|
||||||
|
有了头像,再配上角色的说明和需求关键字,我们就有了一个简单好用的用户画像。下边是我们制作好的三个画像:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
用户画像:王小康
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
用户画像:章小留
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
用户画像:卢小白
|
||||||
|
|
||||||
|
第三步:画像→场景→功能和分期
|
||||||
|
---------------
|
||||||
|
|
||||||
|
### 使用场景分析
|
||||||
|
|
||||||
|
有了栩栩如生的用户画像,我们就可以从画像想象出场景,再由场景梳理出功能列表并进行分期。下边我们就具体来看下怎么分析使用场景。
|
||||||
|
|
||||||
|
#### 王小康的使用场景分析
|
||||||
|
|
||||||
|
首先是王小康的使用场景,包括在学生宿舍、在图书馆以及在课堂上。
|
||||||
|
|
||||||
|
在宿舍,他每天晚上八点到九点使用台式机。因为宿舍比较吵,他会戴着耳机学习。这时候他使用的是外接键盘。
|
||||||
|
|
||||||
|
晚上睡觉之前,他还会窝在被窝里玩一会儿手机,时间大概是晚上十一点半到十二点,也就是睡觉前的半个小时,这时候的使用场景就是用手机背单词。
|
||||||
|
|
||||||
|
图书馆也是一个典型场景,因为在这个环境里边,需要保持安静。所以你要么戴耳机,要么将设备调成静音。王小康一般是下午三点到五点去图书馆自习,这个时候他使用的是笔记本电脑和 iPad 。
|
||||||
|
|
||||||
|
需要注意的是使用 iPad 的时候是没有键盘的,所以在输入上面没有使用外接键盘方便,整体输入速度会下降很多。
|
||||||
|
|
||||||
|
图书馆和学生宿舍是两个相当不同的场景。宿舍里很可能有室友在玩游戏或者聊天,很容易分心,甚至连背单词这件事都很容易忘掉,所以我们需要有提醒。
|
||||||
|
|
||||||
|
相对而言,图书馆就是安静的沉浸式环境,没有人来打扰你,大家都在忙着学自己的东西。
|
||||||
|
|
||||||
|
#### 章小留的使用场景分析
|
||||||
|
|
||||||
|
下面我们来做章小留的场景分析。
|
||||||
|
|
||||||
|
她现在辞职在家,完全是备考的状态。每天上午会在家学网课、或者去线下的培训班学习,下午会在家学词汇。晚上的话,可能要看韩剧。
|
||||||
|
|
||||||
|
主要场景在学词汇的下午。因为是在家里边,她使用的是台式机,鼠标和键盘都是外接的。每天早上起床的时候可能也需要复习一下。
|
||||||
|
|
||||||
|
所以她的两个主要使用场景是使用电脑学习,以及早上起床时用手机进行复习。
|
||||||
|
|
||||||
|
实际上,这个场景和王小康在晚上用手机复习的场景非常类似,可以都写上,最后进行功能合并时,重复的内容会被合并掉。
|
||||||
|
|
||||||
|
同时,因为这两个用户都是在备考,所以他们其实还有「考试复习」这个特殊场景。
|
||||||
|
|
||||||
|
在这个场景里,它的词库是有范围的,不一定是整个词库。而背单词的时候,需要有一个考试模式,限时答题,并给出得分。这些需求我们不一定都要通过福利单词这个产品来满足,但可以先写下来。
|
||||||
|
|
||||||
|
#### 卢小白的使用场景分析
|
||||||
|
|
||||||
|
小白是上班族,所以学习时间是非常有限的,主要是在上下班通勤的时候学习,以及在周末的时候有一点空余时间。
|
||||||
|
|
||||||
|
通勤场景一般会在地铁上。运气好的时候就有座位,运气不好的时候还需要站立着。这时候她会使用手机和耳机来学习。
|
||||||
|
|
||||||
|
因为她的词汇学习主要是为了工作需要,所以在工作的时候可能还会有查词的需求,可以通过词典软件解决,但是她可能会想把生词加入到福利单词来记忆。
|
||||||
|
|
||||||
|
大部分时间地铁里是很挤的,有时候需要一个手扶住上面的吊环或者旁边的柱子,所以小白可能需要单手操作。
|
||||||
|
|
||||||
|
另外要意识到小白只是一个典型代表,她需要的是生物类的词汇,但是其他的上班族需要的词汇可能会覆盖各行各业,这部分的词库需要通过自定义词库来解决。
|
||||||
|
|
||||||
|
同时,小白很喜欢宠物,当她看见可爱的喵星人时,很可能希望将这个图片保存到相册。这里如果再结合到我们上面的考试模式的话,其实可以做得更游戏化一些。比如说我们可以加入一个图鉴,就是一个画册,里边有每一个单词对应的图。只有你对这个单词达到一定的熟练度以后,才能在里边看见。大体上这就是小白的使用场景。
|
||||||
|
|
||||||
|
### 从场景到功能
|
||||||
|
|
||||||
|
现在我们三个用户画像的使用场景已经分析完了。接下来,我们就可以根据场景来确定功能了。也就是说,为了满足这些场景下的需求,我们在产品上需要提供哪些功能来支撑。
|
||||||
|
|
||||||
|
在确定功能的时候,有两类需要特别注意。一类是核心功能,没有它,所有画像都没法使用我们的产品。另一类是边界功能,没有它,某一个画像就没法使用我们的产品。核心功能是交集、边界功能是并集。
|
||||||
|
|
||||||
|
我们会根据画像的设定,将一些边界功能分配给他们。比如说,为什么卢小白她就会想保存图片到相册,章小留就不会呢?事实上章小留也会,但我们不需要把一个边界功能重复分配,因为最终都会覆盖到。
|
||||||
|
|
||||||
|
画像需要注意的是它特有的场景,比如考试模式是备考生的特有场景。对于不考试的同学来说有没有都无所谓,但是对考试的同学是非常有用的。
|
||||||
|
|
||||||
|
我们把边界功能标记出来以后,就可以框定一个大体的功能范围。
|
||||||
|
|
||||||
|
比如说,章小留使用的是苹果台式机,这就要PC版需要同时支持 Windows 和 Mac 两个操作系统。路小白上下班通勤的时候是单手操作,我们在手机上设计浮动键盘时,就要考虑到小屏幕手机上26键的全键盘单手时容易按错的问题。
|
||||||
|
|
||||||
|
对于卢小白来讲,她的空余时间不多,所以可能还会利用家务和健身的时间,这个时候如果她想复习单词,可能还有一个语音播报的需求。
|
||||||
|
|
||||||
|
章小留是追星族,那她在网上看韩剧的时候,会顺便把喜欢的偶像的图片给保存下来,制作成词库,甚至还会分享给同好。
|
||||||
|
|
||||||
|
这些都是边界功能。在早期设计的时候,可以先不考虑工期、开发量这些很现实的问题,我们可以先把它放进来思考,至于做不做、什么时候做,那是以后的事情。
|
||||||
|
|
||||||
|
我们要做的东西在早期应该尽可能的少,但是思考的范围却应该尽可能的广。我们是把很多东西都想明白了以后,选其中最核心的、最重要的来做。而不是说很多东西我压根就不想,只做眼前看到的那一丁点就开始做了。这样到项目中期,就会出现很多思考上的盲点,这些盲点甚至会导致我们的项目重做,所以需要尽可能避免。
|
||||||
|
|
||||||
|
#### [通过思维导图梳理功能](http://r.ftqq.com/lean-side-bussiness/040305.html#%E9%80%9A%E8%BF%87%E6%80%9D%E7%BB%B4%E5%AF%BC%E5%9B%BE%E6%A2%B3%E7%90%86%E5%8A%9F%E8%83%BD)
|
||||||
|
|
||||||
|
我们可以通过思维导图软件来梳理功能。
|
||||||
|
|
||||||
|
想象一下新用户从什么地方开始使用我们的软件,跟着他的使用流程来同步构建功能。
|
||||||
|
|
||||||
|
比如说,首先会需要有一个用户系统,这样我们才能识别用户。接着我们肯定需要有词库,不然就没有单词可以背了。我们肯定也需要有单词的背诵、管理,如果我们要收费的话,肯定还需要有支付。
|
||||||
|
|
||||||
|
用户系统里边,我们考虑使用微信登入,这是目前最简单的办法,不用做用户系统、也不用做密码找回。有了登入肯定也得有退出。
|
||||||
|
|
||||||
|
有了用户系统以后我们就可以保存用户背单词的进度了。在词库这边呢,既然我们要做一个可切换和自定义的词库,那肯定会有一个列表。
|
||||||
|
|
||||||
|
这个列表,首先是会有一个官方的或者叫内置的,然后我们在建立一个本地的列表,给自定义词库用的。
|
||||||
|
|
||||||
|
自定义词库这边,我们可能还需要给提供一个工具来制作词库。我们需要有一个单词表、需要生成对应的音频、需要有对应的解释,以及我们背单词的时候看的图片。这是词库的大体功能。
|
||||||
|
|
||||||
|
如果我们要做图鉴的话,就需要有词库的完成度数据。就是用户背了词库里面百分之多少的单词、以及对每一个单词的熟练度。在这个基础上我们还需要有一个相册,用来欣赏高清图片。
|
||||||
|
|
||||||
|
自定义词库制作完成以后,它还需要有一个分享方式。我们可以允许用户通过二维码分享,其他的用户通过二维码扫码导入。
|
||||||
|
|
||||||
|
接下来,我们来看背单词的功能。
|
||||||
|
|
||||||
|
首先它需要有一个地方来输入字母,我们会根据输入的字母动态地进行遮罩的调整。然后我们需要把用户输入的时间或者错误的次数统计起来,这代表着对这个单词的熟练程度。我们也还需要有一些辅助按钮,用来显示单词的意思、以及跳过不会的单词。
|
||||||
|
|
||||||
|
在最后,当正确地输入了单词以后,我们需要显示一个高清图片,让用户可以很完整地看见这张图片,这是对其的奖励。
|
||||||
|
|
||||||
|
另外我们也需要把用户的背单词成绩记录下来,为了能更清楚地看见这个成绩,可能还需要提供一个进度统计,告诉用户背了词库里面的百分之多少,各自的熟练度是多少。
|
||||||
|
|
||||||
|
还有支付部分别忘了。首先我们要显示可以付费的商品,当点击购买按钮以后,要把微信支付给呼叫起来。在微信支付完成以后,要进行确认。同时我们也需要维护一个订单列表来进行售后和退款。
|
||||||
|
|
||||||
|
### 分期
|
||||||
|
|
||||||
|
确定好功能表以后,接下来就可以进行分期了。
|
||||||
|
|
||||||
|
#### 功能分期
|
||||||
|
|
||||||
|
最常见的流程这里其实是设计MVP而非第一版,但设计方式一致,因此我们选择相对复杂的演示。
|
||||||
|
|
||||||
|
因为我们现在的功能实际上已经非常多了,必须要把它分成不同的阶段来做。最小可行产品不太典型,这里我们以 PMF 验证完成后的第一个版本为例,来选择第一期的内容。第二期就是「以后再做」的功能,第三期就是「不知道啥时候做」的功能。
|
||||||
|
|
||||||
|
来看我们的功能列表:
|
||||||
|
|
||||||
|
- 推送提醒:可以放到第一期。但为了实现推送,需要有消息系统。如果要做定时提醒的话,还需要做设置界面。因为用户设置过提醒以后,可能有一天不需要了,要能及时取消,不然天天推送还挺烦人的。
|
||||||
|
- 考试模式:放到第二期。虽然对备考生很重要,但是因为整个开发量比较大,在挣钱之前可以先不做。
|
||||||
|
- 虚拟键盘:放到第一期。为了支持单手操作,我们需要给背单词的界面添加在移动设备上的键盘界面。不同输入法的键盘可能会导致兼容性问题,所以我们直接通过一个虚拟键盘来解决它。
|
||||||
|
- 自定义词库分享:放到第二期。
|
||||||
|
- 图鉴模式:放到第二期,也可能是第三期。
|
||||||
|
- 语音回放:放到第二期。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
使用思维导图构建功能列表
|
||||||
|
|
||||||
|
确定分期的时候,也要同时检查功能点是否都对应上了。比如支付里面,我们需要把「微信支付的对接」加上。
|
||||||
|
|
||||||
|
### 功能归类到界面
|
||||||
|
|
||||||
|
确定好某一期的功能列表后,可以把各个功能归类到界面里。新建一个思维导图,写上显而易见的各个界面,然后把功能放到界面下去。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
将功能归类到界面
|
||||||
|
|
||||||
|
如果发现有功能没有界面放,恭喜你提前发现了做丢的界面,赶紧把这个界面也加进去吧。
|
||||||
|
|
||||||
|
这一步完成以后,我们就可以开始进入设计阶段了。
|
||||||
|
|
||||||
|
第四步:产品设计
|
||||||
|
--------
|
||||||
|
|
||||||
|
推荐使用矢量原型软件来设计界面,常用的包括AdobeXD、Sketch、Figma和开源的Penpot。本文以XD为例,但各个软件使用起来大致方式类似,可以触类旁通。
|
||||||
|
|
||||||
|
### 什么是 Adobe XD
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
AdobeXD
|
||||||
|
|
||||||
|
Adobe XD是由 Adobe 开发的矢量设计工具,它和 Sketch 类似,既可以用来绘制矢量界面,又包含原型设计功能,还可以在手机上预览设计好的界面。XD 支持 Windows 和 Mac,是 Adobe 为数不多的可以免费使用的软件(当然你可以付费升级 pro 版本)。
|
||||||
|
|
||||||
|
Adobe之前准备收购Figma,于是放弃了XD的更新,但后来又收购失败。当下建议使用Figma或者开源的Penpot。
|
||||||
|
|
||||||
|
### 使用 Adobe XD 设计简单界面
|
||||||
|
|
||||||
|
软件的使用主要还是靠大家勤学多练,这里我们和大家演示下如何用它来设计背单词界面。
|
||||||
|
|
||||||
|
#### 理解画板
|
||||||
|
|
||||||
|
首先,我们在 XD 里新建一个画板(art board)。
|
||||||
|
|
||||||
|
画板是什么?它相当于 Word 里边的页面。一般的纯设计工具没有画板这个概念,但 XD 也包含了原型功能,有时候我们需要在多个界面之间来回切换,而一个画板往往就是一个界面。
|
||||||
|
|
||||||
|
点击左侧的菜单里面倒数第2个画板的按钮,
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
画板按钮
|
||||||
|
|
||||||
|
这时候在屏幕最右边就会出来一系列预置的画板尺寸。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
画板预设
|
||||||
|
|
||||||
|
它已经帮我们准备好了常用的规格,比如苹果的iPhone、iPad,谷歌的安卓机型,以及网页常见的尺寸。
|
||||||
|
|
||||||
|
我们只要从里边选择对应的尺寸就好了,当然也可以不选择它给你预置的,直接手工拖拽来画或者在属性里面调整画板的宽和高。那我们就新建一个iPhone Xs尺寸的画板好了。
|
||||||
|
|
||||||
|
然后按住 CTRL或者CMD + D,就可以直接复制画板。我们把第一个画板叫做背单词界面,然后开始设计。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
复制画板
|
||||||
|
|
||||||
|
#### 遮罩的制作
|
||||||
|
|
||||||
|
先来制作背单词时,字母没有输入完时显示的遮罩效果。选择左侧工具栏中的矩形
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
矩形工具\
|
||||||
|
工具,画出一个覆盖全部画板的长方形。然后调节填充颜色为黑色,透明度为 30%。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
遮罩的制作
|
||||||
|
|
||||||
|
然后我们到 unsplash.com 这个无版权网站上,找一只猫的图片,把它也放进来。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
添加猫图
|
||||||
|
|
||||||
|
这时候猫是在遮罩上方的,所以它挡住了遮罩。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
调整图层顺序
|
||||||
|
|
||||||
|
点击右键,选择「Send to back」将它放到遮罩后,我们就可以看到被半透明遮罩挡住的猫了。
|
||||||
|
|
||||||
|
#### 单词释义和输入框
|
||||||
|
|
||||||
|
接下来,在遮罩上边,我们来放上单词释义和输入框。点击最左侧工具栏中的
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
文字工具\
|
||||||
|
图标,切换到文字工具。
|
||||||
|
|
||||||
|
然后输入文字释义。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
添加文字
|
||||||
|
|
||||||
|
在右侧的属性面板里,我们可以调节文字的字体、大小、颜色和对齐。
|
||||||
|
|
||||||
|
然后我们放上之前设计好的 Logo,加上单词输入框。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
添加单词输入框
|
||||||
|
|
||||||
|
注意这个输入框不一定非要是「框」,比如我们这里也可以把它做成下划线。
|
||||||
|
|
||||||
|
#### 虚拟键盘
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
虚拟键盘
|
||||||
|
|
||||||
|
虚拟键盘的制作在 XD 中也很简单,直接用矩形工具绘制就行。需要注意的是圆角的做法。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
圆角的设置
|
||||||
|
|
||||||
|
其实很简单,在右侧的属性设置里边,把圆角从0 改为 5 就可以了。在做好一个按钮后,我们可以按住 Shift 同时选中按钮和上边的文字,在右键菜单中将其编组(Group);然后按 CTRL或者CMD + D 就可以复制按钮。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
批量分布和对齐
|
||||||
|
|
||||||
|
当按钮多起来之后,要对齐它们还挺费事的。其实选中多个按钮后,可以在菜单 Object → Align 中来自动对齐;也可以在 Object → Distribute 中让它们自动均匀分布。
|
||||||
|
|
||||||
|
#### 矢量图标
|
||||||
|
|
||||||
|
再下来,我们需要在界面中引入图标。既然是矢量界面,当然是矢量图标最好。前边我们已经介绍过 thenounproject.com 了,它还为 pro 用户提供了一个客户端。在这个客户端里边可以非常方便的复制图标。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
矢量图标
|
||||||
|
|
||||||
|
当我们通过关键字搜索到图标后,可以通过下载并将其拖拽到 XD 的方式引入;也可以直接在客户端中右键选择 Copy as SVG,然后直接粘贴。因为是 SVG 格式,调整完大小后可以很方便地更换颜色。
|
||||||
|
|
||||||
|
最后我们再微调一下输入框和单词释义的位置,背单词界面就做完了。其他界面的制作非常类似,就不在这里累述了。
|
||||||
|
|
||||||
|
后续步骤:产品开发、众筹、迭代开发
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
完成产品设计以后(第一版一般是MVP设计),我们就可以进入开发了。注意,对MVP来讲,产品设计和产品开发不是必须的,而且是应该在能验证需求的前提下尽可能避免的。只有无法通过图文说明、视频演示等办法展现产品特性,也无法通过开源软件快速搭建时,才进行产品级别的MVP的开发。
|
||||||
|
|
||||||
|
准备好MVP后,我们就可以通过众筹来验证需求和最基本的营销能力了。当众筹达标,我们才进入下一步的迭代开发。反之,则回到价值主张部分重新优化或者转型。
|
1
src/chapter-build-infrastructure.md
Normal file
@@ -0,0 +1 @@
|
|||||||
|
# 基础设施及搭建
|
119
src/content-pool-and-automation-capability.md
Normal file
@@ -0,0 +1,119 @@
|
|||||||
|
# 内容池和自动化能力
|
||||||
|
|
||||||
|
|
||||||
|
内容池
|
||||||
|
除了用户池,我们其实还需要一个内容池。原因有两个。
|
||||||
|
|
||||||
|
官网:品牌和入口
|
||||||
|
内容池首先可以用来存放官网,这是我们的品牌和入口。
|
||||||
|
|
||||||
|
一般在做软件产品时,大部分人会做一个产品官网,但在做媒体产品时,则很可能只在各个平台上有各种账号,却没有自己的官网。
|
||||||
|
|
||||||
|
但其实,官网的意义是非常重大的。往大了说,它代表着品牌、IP和入口。往小了说,它能解决「如果账号被平台封了怎么办?」这种现实问题。
|
||||||
|
|
||||||
|
如果我们在各个平台都有账号,但没有独立的官网,那万一我们在平台上的账号被封了,用户即使想找我们,知道我们的品牌名称,但他们没有办法与我们沟通,因为我们没有其他渠道了。
|
||||||
|
|
||||||
|
封号这事情,虽然是小概率事件,但是很要命。而且随着越来越多的平台采用不成熟的人工智能,即使是一个处处循规蹈矩的账号,也可能很莫名其妙的就触发了风控规则导致封号。
|
||||||
|
|
||||||
|
所以我们需要有一个完全控制在自己手上的东西。确保平台封了我们的账号,只要用户愿意,他们依然可以找到我们。一个好记的品牌、简短的域名就是很好的解决方案。
|
||||||
|
|
||||||
|
内容中心
|
||||||
|
内容池除了是一个入口以外,也是我们的内容中心,我们的内容都应该放到这个平台上。不是说用户只能到这个地方来看,而是说我们在其他平台上发的内容,应该在这个平台上都有一份。这样我们才能应对「内容被删了怎么办的问题」。
|
||||||
|
|
||||||
|
在各个平台上内容被删,或者审核不通过,或者审核通过后突然又不通过,这种情况已经司空见惯了。我们需要在自己的官网上来做一个备份。这样的话,即使我们发布在平台的内容被删掉,用户到官网还是可以看得见的。
|
||||||
|
|
||||||
|
有些同学可能觉得内容被删没有什么大问题,但如果是一系列的内容,其中有几集被删了,甚至说一个系列教程,最关键的几节莫名其妙的被平台给删掉了,而且自己还没有备份,那用户也没有其他地方可以看,这就非常的难受了对吧?
|
||||||
|
|
||||||
|
内容成本
|
||||||
|
全量内容备份可能会有成本问题。
|
||||||
|
|
||||||
|
如果只是图文内容,那整体成本比较低,我们直接使用云平台存储,通过CDN访问就可以了。但如果我们的内容视频很多的话,自己Hosting可能导致成本上升。
|
||||||
|
|
||||||
|
我们通过两个方案来解决视频成本问题。
|
||||||
|
|
||||||
|
多视频源方案
|
||||||
|
简单的说,在官网上,优先以嵌入方式展示其他平台的视频,只有失效、或者用户主动要求,才载入我们自己Host的视频源。
|
||||||
|
|
||||||
|
具体实现上,我们做了一个WordPress插件。它可以同时把多个视频源,放到一个视频播放框里。默认显示B站视频,通过点击Tab切换到Youtube或者我们自己的源。这样大部分的视频流量会去往B站。
|
||||||
|
|
||||||
|
海外存储和CDN方案
|
||||||
|
另外一个省钱的办法是在一些非关键业务上可以考虑使用国外的服务。
|
||||||
|
|
||||||
|
国内CDN因为成本的原因都比较贵,大概一个G反正也要几毛钱。但国外的网络网络资源的价格是不同的,我们完全可以用来做非关键业务或者备用方案。
|
||||||
|
|
||||||
|
|
||||||
|
R2 的定价
|
||||||
|
比如,CloudFlare的R2,它的流量是不计费的,它只对我们的存储容量和访问的次数收费。默认提供的免费额度也很高,在用户不多的情况下完全可以免费使用。
|
||||||
|
|
||||||
|
但它的问题在于,国内访问的时候,它的速度没有国内同类服务快。毕竟没有国内服务器,即使我们把它设置成东亚地区优先,访问速度依然还是会慢一点点。现在我们方糖07网站上面的图片就是放到R2里边的,大家可以测试一下速度。之前的用户反馈还算OK。
|
||||||
|
|
||||||
|
有了以上两个方案,我们基本可以零成本的做到内容全量备份了。
|
||||||
|
|
||||||
|
但是我们要非常清楚一件事情,就是即使从长期来讲,我们的官网的用户量、流量和影响力都很难比不过第三方的大平台。所以我们依然需要把内容分发到第三方平台去触达那些用户。
|
||||||
|
|
||||||
|
不是所有的平台用户都愿意从平台来到我们的官网,所以我们需要把内容分发到这些平台上,让这部分不愿意过来的用户在第三方平台上直接就可以看到我们的内容。只有我们长期地和他们建立起来信任关系以后,他们才会愿意到我们的官网来。
|
||||||
|
|
||||||
|
内容分发能力
|
||||||
|
事实上,内容分发是一个很痛苦的工作,它很简单,但是很频繁。
|
||||||
|
|
||||||
|
因为只要我们发布一次内容,我们都需要去做这么一遍,这其实是新媒体运营岗的很大一部分工作量。
|
||||||
|
|
||||||
|
下图是一个比较典型的内容分发示意图,也是方糖目前在用的。
|
||||||
|
|
||||||
|
|
||||||
|
方糖的内容分发方案
|
||||||
|
长内容
|
||||||
|
首先我们用 WordPress 架设了官方网站(ft07.com)用来放长图文内容(文章)。目前主要是一人企业方法相关的内容,以后会把其他内容逐步迁移过来。这些长图文,我们可以通过接口直接推送到公众号里边进行发布
|
||||||
|
|
||||||
|
短内容
|
||||||
|
短内容(像微博)这块,我们是自架了个 Memos ,这是一个比较类似于微博的开源项目,可以自行架设。首先在上面发布内容,再通过工具把它同步到微博和推特。这避免了短内容在平台被删的问题。同时,我们会通过挂件的方式把短内容显示到官网,因为官网才是内容池,所有的内容都应该在这个地方汇聚。
|
||||||
|
|
||||||
|
视频内容
|
||||||
|
视频这一块,因为我们之前是做网课,所以我们有一个网课产品。于是我们把视频放到网课产品平台上做本地的host。同时我们会把视频分发到哔哩哔哩和 YouTube,然后从这两个平台上反向为我们的官网导流。这个视频hosting不是必须的,直接用 WordPress 也能实现。
|
||||||
|
|
||||||
|
可以看到,在这个框架下,无论是短内容,长图文和视频内容都得到了较好的处理。
|
||||||
|
|
||||||
|
但要把这个流程完全用起来,却不容易。如果我们的内容每天都有更新,尤其是短内容,可能一天数十次,那分发本身就会很麻烦。就不是说它有什么难度,而是说它的工作量在哪,是一个体力活。
|
||||||
|
|
||||||
|
但比较幸运的是,我们现在可以通过自动化的方式来做这个事情,可以数十倍的提升效率。
|
||||||
|
|
||||||
|
当然,这不是说自动化能完全替代新媒体岗,这个岗位还有很多其他的职能,比如跟用户互动、客服、关系维护。这些目前自动化暂时还是做不到的。不过AI可能将来能做到,毕竟现在评论罗伯特已经会怼用户了(误)。
|
||||||
|
|
||||||
|
总而言之,就是我们现在其实通过自动化的能力可以把内容分发这件事情给做了。所以,这个内容分发能力本质上就是自动化能力。
|
||||||
|
|
||||||
|
自动化能力
|
||||||
|
自动化能力这一块,我们自己是用FlowDeer来做。
|
||||||
|
|
||||||
|
FlowDeer
|
||||||
|
您可以认为它是一个自动化脚本的管理工具,同时也自带了很多现成的脚本。可以阅读这篇文章了解更多。
|
||||||
|
|
||||||
|
|
||||||
|
FlowDeer界面
|
||||||
|
我们自己用得比较多的脚本,主要是微博发布,推特发布,然后RSS的监控内容抓取,然后翻译网页内容的监控,以及账号保活。
|
||||||
|
|
||||||
|
|
||||||
|
一些常用的FlowDeer/FXD脚本
|
||||||
|
所谓账号保活,比如说,我们要发布微博内容的时候,账号是需要登录的,对吧?而保活是说,我们登录一次以后,它每隔一段时间帮您去刷新一下,保证这个账号一直是登录的。这样要发布的时候就不用登录了,可以直接发布出去。
|
||||||
|
|
||||||
|
我们还做了这个文章小编,它是自动化和AI功能的一个整合。
|
||||||
|
|
||||||
|
像我经常分享一些GitHub上的开源项目,那以前都是我自己要撰写文案的。有了这个文章小编以后,我基本上就是丢一个链接给它,它自己过去截图然后提取主要内容,写一个总结,写完了给我做个审核,审核完了直接发布就好了。整个这个流程是非常顺畅的,一般一分钟不到。
|
||||||
|
|
||||||
|
所以自动化能力其实已经是内容池所必须的一个能力了。尤其对于一人企业来讲,我们的精力是非常有限的。所以能自动化的地方一定要自动化。
|
||||||
|
|
||||||
|
可编程浏览器脚本
|
||||||
|
当然如果不想用FlowDeer,实际上也可以自己手工来编写Puppetter脚本。这是一个无头浏览器,或者把它理解成可编程浏览器更为确切。我们可以编程控制浏览器的一切。可以打开某个网页,点击某个按钮,然后去检测对应的文本,可以上传文件,发布视频,而且是自动化的。
|
||||||
|
|
||||||
|
验证码问题
|
||||||
|
当然也有一些限制,比如验证码和类似拖动式的机器人验证。
|
||||||
|
|
||||||
|
我们是建议大家用它来代替自己的日常工作,就是完全模拟真人操作的频率范围以内来做自动化。这种情况下,实际上能遇到验证码的时候不会太多。当然你要把它规模化,这个问题就很大。但这不是我们的目标。我们的目标是代替日常工作。
|
||||||
|
|
||||||
|
用AI聊天驱动工作流
|
||||||
|
另一方面,自动化+AI聊天可以让自动化能力变得灵活。这里有一个例子,是FlowDeer里边集成的AI聊天窗口。
|
||||||
|
|
||||||
|
|
||||||
|
FlowDeer Chat 聊天工作流
|
||||||
|
在这个聊天环境里面,您可以把FlowDeer的里面所有的脚本都当做一个工具来使用。比如类似图中的,我可以调用图像生成工具让它生成一张图,然后同时调用微博发布工具,让它这种发微博。而这一切,我们只需要在聊天窗口里面通过聊天的方式就可以完成,这个是非常方便而高效的。
|
||||||
|
|
||||||
|
当然现在因为AI智能的问题,还只是一个辅助性的东西。但是我觉得这是暂时性的,因为AI的智能每个月都在提升,我觉得很快就可以达到普通人的标准。
|
78
src/crowdsourcing-capability.md
Normal file
@@ -0,0 +1,78 @@
|
|||||||
|
# 众包能力
|
||||||
|
|
||||||
|
最后还有一个基于产品池和用户池之上的、非常重要的能力 ------ 众包能力。
|
||||||
|
|
||||||
|
为什么需要众包
|
||||||
|
-------
|
||||||
|
|
||||||
|
对于一人企业来说,这个能力至关重要,因为我们需要严格控制人数。这是由于我们的商业模式和竞争策略都是按照这个设计的。
|
||||||
|
|
||||||
|
我们在很多策略中都提到,由于人数较少,我们可以专注于非常垂直的小市场。即使获得的利润相对于大公司来说较少,但因为人数少,所以人均高,这就成了我们商业模式和竞争策略的基础。如果我们有很多人,那么这种优势就不存在了。
|
||||||
|
|
||||||
|
我们现在可以通过AI和自动化处理很多事情,但总有一些问题是它们无法解决的,需要由人来解决。这就形成了一个基本矛盾。虽然在我们起步的阶段这个矛盾不会太明显,但随着业务量增加,它会日益明显。
|
||||||
|
|
||||||
|
为了解决这个矛盾,我们需要拥有众包的能力。简单来说,众包就是将任务分包给很多人,通常是我们产品的用户。在这种方式下,我们不需要雇佣员工,所以员工数量不会增加,可以很好地满足我们一人企业在规模上面的要求。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
众包能力在基础设施中的位置和重要性
|
||||||
|
|
||||||
|
众包能力的构成要件
|
||||||
|
---------
|
||||||
|
|
||||||
|
这个方案听起来很理想,但实际操作中有很多需要注意的细节。
|
||||||
|
|
||||||
|
首先,并不是所有的任务都可以众包,它们需要非常明确,而我们分包给的任务执行者需要具备相应的能力、时间和意愿。所以总体来讲,我们需要处理掉所有自己、自动化和AI能处理的事情,最后将处理不了的部分拿出来进行众包。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
众包系统的构成要件
|
||||||
|
|
||||||
|
众包系统的构成要件包括几个方面。
|
||||||
|
|
||||||
|
### 清晰的细分任务
|
||||||
|
|
||||||
|
首先,要有一个清晰的细分任务。不能将一整块任务扔出去,这样完不成的风险很高,沟通成本也高。需要多人紧密合作的任务也不适合直接众包。我们需要将任务分得特别细,无需沟通就可以直接执行。
|
||||||
|
|
||||||
|
例如,如果我们要翻译我们的整个网站,我们可以将要翻译的内容全部拆成单句,然后发给我们的用户。每一个用户只需要翻译这一句,然后提交。我们会对比两到三个人的翻译结果,然后从中选择一个较好的。而选择结果的任务又可以作为一个独立任务,再次通过众包系统分发下去。采用类似于这样的逐步分拆的方式,使每一个细分任务都足够明确。
|
||||||
|
|
||||||
|
另外,单人的工作量应该足够小。因为众包与外包不同,众包是任务执行人在业余时间来做这个事情,所以他的时间和精力都是非常不可控和不可知的。我们需要将承担的工作量变得足够小,然后执行任务的人足够多,这样我们才可以更好地进行控制质量和风险。
|
||||||
|
|
||||||
|
### 明确的验收条件
|
||||||
|
|
||||||
|
第二,是一个明确的验收条件。其核心是量化,即这个任务是否完成,完成的好不好,要有一个量化的标准。最好可以自动验收。
|
||||||
|
|
||||||
|
自动验收的最大优点在于,一旦验收完成,我们就可以实时发送奖励。这样对任务执行人的激励效果会放大,不但会刺激他继续来做众包任务,甚至还会推动他邀请自己的朋友来参与。
|
||||||
|
|
||||||
|
### 有吸引力的奖励
|
||||||
|
|
||||||
|
最后,有吸引力的奖励也非常重要。
|
||||||
|
|
||||||
|
现在各个APP里面的邀请任务已经非常多了,套路已经被用烂了,产生「吸引力」就很难。
|
||||||
|
|
||||||
|
我们发现依然有吸引力的奖励首先是现金或等价物,比如说京东购物卡;然后是与业务相关的一些有价无市的物品,比如说像我们设计的 NodeJS 实体包,这个现在已经买不到了。如果把它作为奖品的话,我觉得还是对我们的目标人群是很有吸引力的。总的来说,在奖励上,要多一点真诚,少一点套路。
|
||||||
|
|
||||||
|
发放时机刚才已经说过了,最理想的方式是实时发放,因为它可以在任务执行过程中就把激励循环转起来,最后获得的效果会好很多。
|
||||||
|
|
||||||
|
众包系统
|
||||||
|
----
|
||||||
|
|
||||||
|
那么,要完成众包,我们需要什么样的支持系统?
|
||||||
|
|
||||||
|
这取决于我们是否要自动判定验收条件,因为不同的任务的验收条件是完全不同的。
|
||||||
|
|
||||||
|
如果要自动判定,我们就需要各种垂直细分的专用系统。比如,像裂变和推荐返现就是非常典型的垂直众包。这个场景被单独拿出来优化运行,甚至现在大家都不觉得它算众包了。
|
||||||
|
|
||||||
|
但它本质上就是一种众包。我们可以回过头来看它的这几个要件:
|
||||||
|
|
||||||
|
1. 首先,它有一个清晰细分的任务。给你一个链接,你通过这个链接邀请用户来。
|
||||||
|
2. 然后,它的验收条件也非常明确,用户带着邀请码注册,系统直接就能识别到。
|
||||||
|
3. 最后奖励也是实时的发放的,一旦发现任务完成以后,立刻发送奖励,很多系统微信上立马就可以收到现金。
|
||||||
|
|
||||||
|
所以,众包不一定是一个独立系统,它也可以是一个垂直的功能。
|
||||||
|
|
||||||
|
如果接受人工验收,那么我们可以有一些更通用的方案。
|
||||||
|
|
||||||
|
比如论坛加积分商城。网龄稍微大一点的同学可能用过,基本流程就是,你可以在论坛发布任务,然后把积分悬赏放上去,然后其他人完成任务以后,你去结帖,然后积分就会转让给他。同时论坛本身提供一个积分商城来做奖励的兑换。当然,现在论坛的这个产品形态已经用得非常少了,但是类似的机制依然运行得很好。
|
||||||
|
|
||||||
|
如果你使用WordPress,它有一些现成的商业的威客插件。安装以后,可以为 WordPress 添加类似的任务发布、领取、验收、积分/现金结算的功能。
|
@@ -26,7 +26,7 @@ function downloadImage($url, $filepath)
|
|||||||
function replaceImageLinksInFile($filePath, $imagesDir)
|
function replaceImageLinksInFile($filePath, $imagesDir)
|
||||||
{
|
{
|
||||||
$data = file_get_contents($filePath);
|
$data = file_get_contents($filePath);
|
||||||
$regex = '/!\[.*?\]\((https:\/\/res07\.ftqq\.com\/.*?\.(jpg|png|gif|bmp|webp))\)/';
|
$regex = '/!\[.*?\]\((https:\/\/r2\.ft07\.com\/.*?\.(jpg|png|gif|bmp|webp))\)/';
|
||||||
|
|
||||||
preg_match_all($regex, $data, $matches, PREG_SET_ORDER);
|
preg_match_all($regex, $data, $matches, PREG_SET_ORDER);
|
||||||
foreach ($matches as $match) {
|
foreach ($matches as $match) {
|
||||||
|
BIN
src/images/Screen-Shot-2024-07-07-at-12.59.57-PM-1024x669.png
Normal file
After Width: | Height: | Size: 58 KiB |
BIN
src/images/image-10.png
Normal file
After Width: | Height: | Size: 126 KiB |
BIN
src/images/image-106-1024x511.png
Normal file
After Width: | Height: | Size: 74 KiB |
BIN
src/images/image-107.png
Normal file
After Width: | Height: | Size: 438 KiB |
BIN
src/images/image-108-1024x373.png
Normal file
After Width: | Height: | Size: 200 KiB |
BIN
src/images/image-109-1024x463.png
Normal file
After Width: | Height: | Size: 241 KiB |
BIN
src/images/image-110-1024x527.png
Normal file
After Width: | Height: | Size: 229 KiB |
BIN
src/images/image-111-1024x577.png
Normal file
After Width: | Height: | Size: 182 KiB |
BIN
src/images/image-112-1024x560.png
Normal file
After Width: | Height: | Size: 254 KiB |
BIN
src/images/image-113-1024x537.png
Normal file
After Width: | Height: | Size: 275 KiB |
BIN
src/images/image-115-1024x413.png
Normal file
After Width: | Height: | Size: 165 KiB |
BIN
src/images/image-116-1024x659.png
Normal file
After Width: | Height: | Size: 273 KiB |
BIN
src/images/image-117-1024x861.png
Normal file
After Width: | Height: | Size: 771 KiB |
BIN
src/images/image-118-1024x948.png
Normal file
After Width: | Height: | Size: 541 KiB |
BIN
src/images/image-119-1024x769.png
Normal file
After Width: | Height: | Size: 142 KiB |
BIN
src/images/image-12-1024x534.png
Normal file
After Width: | Height: | Size: 41 KiB |
BIN
src/images/image-120-1024x768.png
Normal file
After Width: | Height: | Size: 156 KiB |
BIN
src/images/image-121-1024x767.png
Normal file
After Width: | Height: | Size: 166 KiB |
BIN
src/images/image-122-1024x987.png
Normal file
After Width: | Height: | Size: 204 KiB |
BIN
src/images/image-123-1024x784.png
Normal file
After Width: | Height: | Size: 187 KiB |
BIN
src/images/image-124-1024x757.png
Normal file
After Width: | Height: | Size: 60 KiB |
BIN
src/images/image-125.png
Normal file
After Width: | Height: | Size: 1.7 KiB |
BIN
src/images/image-126-313x1024.png
Normal file
After Width: | Height: | Size: 73 KiB |
BIN
src/images/image-127-1024x614.png
Normal file
After Width: | Height: | Size: 103 KiB |
BIN
src/images/image-128-1024x527.png
Normal file
After Width: | Height: | Size: 50 KiB |
BIN
src/images/image-129.png
Normal file
After Width: | Height: | Size: 1.1 KiB |
BIN
src/images/image-13-1024x759.png
Normal file
After Width: | Height: | Size: 375 KiB |
BIN
src/images/image-130-1024x677.png
Normal file
After Width: | Height: | Size: 241 KiB |
BIN
src/images/image-131.png
Normal file
After Width: | Height: | Size: 452 KiB |
BIN
src/images/image-132.png
Normal file
After Width: | Height: | Size: 1.6 KiB |
BIN
src/images/image-133-1024x490.png
Normal file
After Width: | Height: | Size: 144 KiB |
BIN
src/images/image-134.png
Normal file
After Width: | Height: | Size: 238 KiB |
BIN
src/images/image-135-497x1024.png
Normal file
After Width: | Height: | Size: 181 KiB |
BIN
src/images/image-136.png
Normal file
After Width: | Height: | Size: 22 KiB |
BIN
src/images/image-137-1024x892.png
Normal file
After Width: | Height: | Size: 561 KiB |
BIN
src/images/image-138.png
Normal file
After Width: | Height: | Size: 290 KiB |
BIN
src/images/image-14.png
Normal file
After Width: | Height: | Size: 130 KiB |
BIN
src/images/image-15.png
Normal file
After Width: | Height: | Size: 125 KiB |
BIN
src/images/image-16-1024x382.png
Normal file
After Width: | Height: | Size: 27 KiB |
BIN
src/images/image-17-1024x503.png
Normal file
After Width: | Height: | Size: 32 KiB |
BIN
src/images/image-18-1024x501.png
Normal file
After Width: | Height: | Size: 47 KiB |
BIN
src/images/image-19-1024x683.png
Normal file
After Width: | Height: | Size: 89 KiB |
BIN
src/images/image-20-1024x679.png
Normal file
After Width: | Height: | Size: 68 KiB |
BIN
src/images/image-26-1024x858.png
Normal file
After Width: | Height: | Size: 47 KiB |
BIN
src/images/image-27.png
Normal file
After Width: | Height: | Size: 34 KiB |
BIN
src/images/image-29-1024x644.png
Normal file
After Width: | Height: | Size: 131 KiB |
BIN
src/images/image-30-1024x590.png
Normal file
After Width: | Height: | Size: 158 KiB |
BIN
src/images/image-31.png
Normal file
After Width: | Height: | Size: 70 KiB |
BIN
src/images/image-32.png
Normal file
After Width: | Height: | Size: 14 KiB |
BIN
src/images/image-33.png
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
src/images/image-34-1024x463.png
Normal file
After Width: | Height: | Size: 69 KiB |
BIN
src/images/image-36-1024x468.png
Normal file
After Width: | Height: | Size: 68 KiB |
BIN
src/images/image-37-1024x491.png
Normal file
After Width: | Height: | Size: 125 KiB |
BIN
src/images/image-39-1024x457.png
Normal file
After Width: | Height: | Size: 62 KiB |
BIN
src/images/image-40-1024x641.png
Normal file
After Width: | Height: | Size: 1.2 MiB |
BIN
src/images/image-41-1024x467.png
Normal file
After Width: | Height: | Size: 77 KiB |
BIN
src/images/image-42-1024x575.png
Normal file
After Width: | Height: | Size: 56 KiB |
BIN
src/images/image-43-1024x577.png
Normal file
After Width: | Height: | Size: 174 KiB |
BIN
src/images/image-44-1024x579.png
Normal file
After Width: | Height: | Size: 155 KiB |
BIN
src/images/image-45-1024x577.png
Normal file
After Width: | Height: | Size: 155 KiB |
BIN
src/images/image-46-1024x577.png
Normal file
After Width: | Height: | Size: 158 KiB |
BIN
src/images/image-47-1024x567.png
Normal file
After Width: | Height: | Size: 193 KiB |
BIN
src/images/image-48-1024x365.png
Normal file
After Width: | Height: | Size: 63 KiB |
BIN
src/images/opb-book-cover-2.1.jpg
Normal file
After Width: | Height: | Size: 170 KiB |
109
src/infrastructure-user-pool-reach-capability.md
Normal file
@@ -0,0 +1,109 @@
|
|||||||
|
# 用户池和触达能力
|
||||||
|
|
||||||
|
什么是基础设施
|
||||||
|
-------
|
||||||
|
|
||||||
|
在一人企业方法论2.0中,我们讲了三个方面。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
一人企业方法论的三大内容
|
||||||
|
|
||||||
|
第一,什么是一人企业;第二,如何规划一人企业;第三,如何构建一人业务。
|
||||||
|
|
||||||
|
前两部分,我们在专栏里之前的文章中讲得已经比较详细,都是理论和认知层次的内容,没有深入到实践中去。到了第三部分,虽然我们知道要构建一人业务,但具体怎么构建、怎么落地、怎么操作,缺乏一个可以看得见摸得着的例子或发力点。
|
||||||
|
|
||||||
|
在之前的内容中,我们反复强调,一人企业并不是一人业务。
|
||||||
|
|
||||||
|
这是2.0版本和1.0版本最大的区别。一人企业包含了很多个一人业务,只要其中一个业务做起来了,我们就可以实现财务自由。
|
||||||
|
|
||||||
|
按照这个说法,一人企业就像图中所示,在一个一人企业里有很多一人业务。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
每个业务各自为战
|
||||||
|
|
||||||
|
但实际上,一旦按照这个方式操作,你会发现有很多一人业务,但每个业务各自为战,1+1可能连2都达不到,甚至小于2。
|
||||||
|
|
||||||
|
因为精力被分散到各个业务上,所以一人业务之间必须要协同。一些公共的功能和资源需要抽取出来,放到一个地方公用,我们称之为基础设施。这就是我们今天要重点讲的内容。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
基础设施
|
||||||
|
|
||||||
|
用户池
|
||||||
|
---
|
||||||
|
|
||||||
|
首先,我们可以从每一个业务中抽取出来的,是用户池。所谓用户池,就是用户注册、登录、留存的地方。它的基本功能当然是注册和登录。
|
||||||
|
|
||||||
|
### 低成本登录
|
||||||
|
|
||||||
|
但如何以最低成本让用户登录,实际上是有讲究的。
|
||||||
|
|
||||||
|
比如在国内,如果通过电子邮件方式登录,邮件到达率会很差。很多用户不愿意用邮箱,收验证邮件时很痛苦。另一方面,如果用手机号登录,到达率还可以,现在有云平台可以发送,但会有成本问题。此外,技术人群很讨厌用手机号登录,而普通用户可以接受,主要还是成本的问题。
|
||||||
|
|
||||||
|
我们测试后发现,对一人企业来说,最低成本的用户登录方案是第三方登录。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
第三方登录
|
||||||
|
|
||||||
|
在所有第三方登录中,我们认为微信登录最好用。原因有两个。
|
||||||
|
|
||||||
|
第一,你可以用最低的成本覆盖最主流的人群。
|
||||||
|
|
||||||
|
我见过很多人没有支付宝,但很少见不用微信的人。偶尔遇到不用微信的,是不用智能手机的人。所以,微信的覆盖度非常高。还有一个更大样本的证据,我们方糖自己的国内服务只支持微信登录和微信支付,多年来要求使用支付宝支付的用户非常少,不到十个。
|
||||||
|
|
||||||
|
第二,微信的生态是一个完整的闭环。
|
||||||
|
|
||||||
|
这在国内很难找到同样的替代品:支付宝有支付功能,但没有社交功能,也没有内容分发平台和公众号,无法在上面做运营;微博可以做运营,但没有支付功能,私信到达率很差,无法做有效触达。
|
||||||
|
|
||||||
|
从生态角度看,只有微信的生态闭环是非常完整的,有公众号、推送、私信、社群和支付功能。
|
||||||
|
|
||||||
|
所以,如果只接一个第三方,我们建议只接微信登录。当然,你也可以把其他平台的登录接入,这没有影响。不过在一人企业的起步阶段,我们建议大家专注于一个平台,不要分散精力。等到业务运转起来后,再回过头来完善。毕竟多方对接终究会多一些额外成本。
|
||||||
|
|
||||||
|
触达能力
|
||||||
|
----
|
||||||
|
|
||||||
|
接下来,有了用户池后,如果无法触达用户,实际上这个用户池是没有意义的。在你这里和在其他平台上没有区别,甚至其他平台还能触达用户。
|
||||||
|
|
||||||
|
所以,我们做用户池必然要有触达能力,即能够给用户发送消息或以其他方式告知他,这样才能做到流量复用和产品的二次销售。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
触达方式
|
||||||
|
|
||||||
|
常见的触达方式包括以下几种:
|
||||||
|
|
||||||
|
### APP消息
|
||||||
|
|
||||||
|
效果可能所有推送渠道中是最好的,自由度也最高。但对一人企业来讲,却不是最适合的。
|
||||||
|
|
||||||
|
因为APP消息推送的前提是用户安装你的APP,这个成本现在已经变得很高;APP上架也非常麻烦,尤其对个人来说,基本上很难上架,因此不适合在起步阶段做。
|
||||||
|
|
||||||
|
### 短信
|
||||||
|
|
||||||
|
通过云平台发送,到达率还不错,但需要走短信模版。另外由于垃圾短信太多,很多用户是不看短信的。
|
||||||
|
|
||||||
|
### 邮件
|
||||||
|
|
||||||
|
邮件到达率低且实时性差。很多用户已经不用邮箱,就算偶尔会看邮件,但是可能一周或者甚至一个月才会去看一次。
|
||||||
|
|
||||||
|
### 群消息
|
||||||
|
|
||||||
|
这是我们实验下来,效果最好的两个渠道之一,另一个是微信模板/订阅消息。
|
||||||
|
|
||||||
|
可以通过以下几种方式将消息告知群里所有人,并进行有效的互动和实时沟通:
|
||||||
|
|
||||||
|
1. 群置顶:将重要消息置顶,确保所有群成员都能看到。置顶消息可以是重要通知、活动安排或新产品发布等。
|
||||||
|
2. 群代办:利用微信群的代办功能,创建待办事项,提醒群成员关注和参与。代办事项可以设置提醒时间,确保群成员不会错过重要信息。
|
||||||
|
3. 互动发红包:通过发红包的方式,提高群内的互动活跃度。红包不仅能吸引群成员的注意,还能增加他们对消息的关注度和参与度。
|
||||||
|
4. 实时互动:在群内发布消息后,及时回应群成员的反馈和问题。这种实时互动能够帮助你迅速发现消息中存在的问题,并进行及时的调整和解决。
|
||||||
|
|
||||||
|
### 微信模板消息或订阅消息
|
||||||
|
|
||||||
|
另一个较好的单向消息渠道是微信的模板消息或订阅消息。
|
||||||
|
|
||||||
|
由于订阅消息的权限较难获得,普通账号通常无法获取一次订阅即可无限发送的权限,这意味着用户在看完消息后必须再次订阅,操作不便。因此,我们通常使用模板消息来进行操作。模板消息虽然在推送形式、推送内容上有着诸多限制,但它不会被限流,实时性也非常高。
|
||||||
|
|
||||||
|
通过微信的推送接口、群机器人(Wechaty)或者手机脚本方案(Auto.js),我们可以实现触达能力自动化。
|
163
src/product-pool-and-payment-capability.md
Normal file
@@ -0,0 +1,163 @@
|
|||||||
|
# 产品池和支付能力
|
||||||
|
|
||||||
|
产品池
|
||||||
|
---
|
||||||
|
|
||||||
|
我们已经有了用户池和内容池,接下来我们再把视线移回业务这边。
|
||||||
|
|
||||||
|
实际上,对于单个业务来说,在多个业务之间存在许多共通之处,比如是由于它们都旨在创造利润,因此需要许多与商业相关的通用功能和能力。
|
||||||
|
|
||||||
|
另一方面,有了用户池和内容池,业务本身就转变为一个可插拔的模块。它无需关注内容和用户相关功能,一旦接入我们的用户池和内容池,就能开始运作,无需再成为一个独立完整的业务。
|
||||||
|
|
||||||
|
因此,我们将这些业务整合为一系列业务组件,同时用「产品池」用来容纳它们。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
从多业务到产品池+业务组件
|
||||||
|
|
||||||
|
支付能力
|
||||||
|
----
|
||||||
|
|
||||||
|
产品池最需要的是支付能力------这很容易理解。因为对企业而言,核心目的无疑是赚钱,而没有支付功能就无法产生收入。
|
||||||
|
|
||||||
|
### 支付能力服务商
|
||||||
|
|
||||||
|
#### 常用服务商
|
||||||
|
|
||||||
|
在国内,常用的有微信支付和支付宝,但这两者并不对个人开放,需要注册企业或个体工商户。
|
||||||
|
|
||||||
|
注册企业的成本集中在记账和场地。而个体工商户的注册地址在一些省份也有了要求,这无疑拉高了成本,因为办公地点其实是固定成本,而很多城市的民宅是不允许注册的。具体要求可以咨询当地的工商局,每个地方的政策都有所不同,但总体来说,这确实提高了成本。
|
||||||
|
|
||||||
|
#### 对个人开放的服务商
|
||||||
|
|
||||||
|
幸运的是,我们还有一些对个人开放的支付服务商。
|
||||||
|
|
||||||
|
像XorPay,这实际上是一个小微支付平台,在这个平台上,你可以接入微信和支付宝。可以自行申请开通,店面地址可以用住宅地址,店面照片可以用大门照片。另外我记得它有一个一百的开通费用,可以和客服确认下。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
XorPay的FAQ中关于开通费用的说明
|
||||||
|
|
||||||
|
支付宝的某些支付方案也对个人开放,比如「当面付」,但使用场景有些不匹配,因为从名字就能看出,它本来是面对面支付用的。
|
||||||
|
|
||||||
|
比较而言,我认为使用XorPay这种小微支付平台是一个更好的方案,支持的渠道更多,用户支付的钱也是直接进入我们的账户,这是比较安全的。
|
||||||
|
|
||||||
|
支付接入
|
||||||
|
----
|
||||||
|
|
||||||
|
我们具备了支付能力,还需要与我们的业务组件进行对接,才能用起来。
|
||||||
|
|
||||||
|
如果我们只有一个业务,那无所谓;但如果业务多了,我们就会面临两个问题。
|
||||||
|
|
||||||
|
首先,每个业务都需要单独接入,这实际上是非常麻烦的。因为服务商提供的往往是系统层的对接,而不是应用层的,整个过程颇为繁琐。
|
||||||
|
|
||||||
|
另一方面,有些系统在设计上不支持多业务。如果我们使用微信官方的支付,它的支付目录有限制,最多支持5个。那我们的业务超过五个怎么办?这就需要我们自己寻找解决方案。
|
||||||
|
|
||||||
|
### 自建收银台方案
|
||||||
|
|
||||||
|
我们的解决方案是建立一个自己的收银台,这可以很好地解决上述两个问题。
|
||||||
|
|
||||||
|
简单来说,它就是将每一个业务看成一个应用,然后给这个应用分配一个参数。用户带着这个参数跳转到收银页面进行支付。支付完成后,收银台使用这个订单ID进行转向,用户再拿着这个支付完成的订单ID到业务中进行验证,整个支付就完成了。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
收银台的流程示意图
|
||||||
|
|
||||||
|
收银台的意义在于,我们的多个业务可以共用支付和订单系统。
|
||||||
|
|
||||||
|
如果开发的业务足够多,会明白为多个业务单独开发支付和订单系统有多麻烦。虽然代码可以重用,但如果它分布到每一个业务中,我们维护起来会很麻烦。因此,将它做成一个共用的组件、将它封装成一个标准的基础能力是非常必要的。
|
||||||
|
|
||||||
|
### WooCommerce网关
|
||||||
|
|
||||||
|
如果我们使用 WordPress,那有一个更简单的方案,就是给 WooCommerce 添加支付网关。
|
||||||
|
|
||||||
|
绝大部分与支付相关的 WordPress 插件都会使用WooCommerce。这本来是一个第三方的插件,后来被WordPress 母公司收购了,虽然依然以独立品牌运营,但它其实是官方的产品。
|
||||||
|
|
||||||
|
它提供了完善的支付和商品相关的功能,但缺少一些国内常用的支付厂商。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
WooCommerce支付网关设置界面
|
||||||
|
|
||||||
|
我们只需要添加一些网关,比如微信官方的支付网关或XorPay的支付网关,然后所有支持Woocommerce的应用就可以直接使用我们的支付能力了。
|
||||||
|
|
||||||
|
众筹能力
|
||||||
|
----
|
||||||
|
|
||||||
|
### 众筹的意义
|
||||||
|
|
||||||
|
在我们的一人企业方法论中,我不断强调众筹的重要意义。因为重要的事情需要至少说三遍。
|
||||||
|
|
||||||
|
一人企业的精力非常有限,所以试错成本非常高,不仅是金钱,它还是一种机会成本,因为我们一年能做的事情是非常有限的。因此,使用众筹来进行验证这种能力是非常重要的。
|
||||||
|
|
||||||
|
在比较主流的创业方法论中,核心验证的是两个东西:一个是价值主张,即我们的商品对于我们的目标用户到底有没有价值;第二是渠道通路,即我们的产品对这部分人有价值,但它能增长吗?它能达到我们想要的规模吗?
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
两个最重要的假设
|
||||||
|
|
||||||
|
### 多点验证
|
||||||
|
|
||||||
|
众筹验证它是一个简单粗暴的多点验证,即一次性验证价值主张和渠道通路。确切的说,它可能验证不了后期的增长,但可以验证早期渠道。
|
||||||
|
|
||||||
|
众筹的达标值,一定程度上就意味着早期规模的下限;用户少的时候,我们可以将其设定为不赔本的点;用户足够多的时候,我们甚至可以将其设定为我们期望的规模,很多Kickstarter上的项目主要收入就来源于众筹。
|
||||||
|
|
||||||
|
众筹对价值主张的验证,更为精准,是真金白银的真实验证。如果我们做落地页或者做访谈来验证价值主张,很多用户他会跟我们说我们这个东西很好,回去试一下,然后就没有然后了。但是通过众筹的方式验证,真心觉得好的会掏钱,表面上觉得好的就不会掏这份钱,验证的结果是非常真实的。
|
||||||
|
|
||||||
|
### 销售前置
|
||||||
|
|
||||||
|
第二,众筹把销售前置了。验证通过销售就完成了,验证不通过我们就不会去构建一些卖不掉的产品。这个就很重要,对一人企业来讲,业务成本里可能80%以上都是构建成本,而我们如果在构建之前就知道它卖不掉我们就可以不做这件事情,从而节省非常大量的成本。
|
||||||
|
|
||||||
|
当然有同学可能会说,我的东西都没有做出来,它对用户的这个吸引力显然是不够的,我们的这个众筹它不能很好地演示我们的这个产品,所以用户才不会购买,这个是有可能的。
|
||||||
|
|
||||||
|
但解决方案不是去开发产品,而是把用来众筹的视频或者用来给大家在众筹时测试的demo做得足够细致,让支持者可以体验到我们最后完成以后的效果。
|
||||||
|
|
||||||
|
也有同学觉得众筹太依赖于销售能力,但开发过程并不会提升你的销售能力,也就是说,众筹时卖不掉的产品,开发完成再售卖,同样卖不掉的可能性依然非常高。
|
||||||
|
|
||||||
|
### 众筹的构成要件
|
||||||
|
|
||||||
|
事实上,众筹系统构成要件很简单。
|
||||||
|
|
||||||
|
- 收费
|
||||||
|
- 达标条件统计
|
||||||
|
- 批量退款或者发货
|
||||||
|
|
||||||
|
#### 用群实现众筹
|
||||||
|
|
||||||
|
我们甚至用一个群都可以非常好地完成众筹,而不用购买任何的软件来做这个事情。
|
||||||
|
|
||||||
|
比如说,我们做一个付费入群,这个就把收费解决了;然后达标条件统计我们通过群接龙来做,付完费的接一下龙,就可以知道我们的软件到底卖了多少套,我们的课程卖了多少份,达没达标,群里大家都一目了然。批量退款的话也很简单,我们只需要发一个定额的群红包,每一个人按固定额度领一下,这个钱就退回去了。
|
||||||
|
|
||||||
|
发货的话,做得比较简陋一点的话我们可以把软件或者视频放到网盘上,通过群公告提供给大家链接,也可以直接放到群文件里面,这个就看群对应的功能。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
通过群实现众筹
|
||||||
|
|
||||||
|
所以你看,众筹它是一种思维方式,其实并不是一个固定系统,不是说我们要有了一个系统才能做众筹,即使我们只有一个群我们也可以很好地来处理它。
|
||||||
|
|
||||||
|
而且像批量退款这个步骤,如果不能批量退款,大不了手工退款,辛苦一点而已。主要是我们退款的场景往往是没有达标的时候,所以这个用户反而不会太多,因为用户多了就达标了呀。
|
||||||
|
|
||||||
|
#### 用 WooCommerce 众筹
|
||||||
|
|
||||||
|
当然,如果我们经常做众筹,使用群就显得比较麻烦了。如果使用 WordPress ,我们也可以用 WordPress 插件来做。其实WooCommerce已经完成了一个标准的商品销售流程,商品购买和发货。
|
||||||
|
|
||||||
|
需要修改的地方只有两个。第一是,我们可能需要添加一个简码,用来输出这个商品的销量和是否达标的统计,比如说像下图这样。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
商品众筹简码渲染效果
|
||||||
|
|
||||||
|
其次,我们需要一个批量退款按钮。但这个其实都是可选的,没有这个按钮其实也可以退款,只不过麻烦一点。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
给WooCommerce添加批量退款按钮
|
||||||
|
|
||||||
|
所以呢,不要觉得众筹很麻烦,也不要觉得这个众筹必须要有系统,它是一种思维方式,希望大家把它用起来。这对一人企业和资源紧缺的小团队来讲,真的是非常非常重要的。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
众筹能力本质上是支付能力
|
||||||
|
|
||||||
|
归根结底,众筹能力本质上是一种支付能力,它其实是一个商业模式的创新。如果我们的支付能力的组件化和自动化做得足够好的话,我们会发现像什么众筹啊,什么学完免费啊,这些看起来比较创新的商业模式都是很容易实现的。
|
142
src/setup-a-one-person-business-infrastructure.md
Normal file
@@ -0,0 +1,142 @@
|
|||||||
|
# 搭建一人企业基础设施
|
||||||
|
|
||||||
|
通过前文的讨论,我们认为一人企业的基础设施需要具备三个核心容器和四项关键能力:用户池、内容池、产品池;触达能力、支付能力、自动化能力和众包能力。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
基础设施的三池四能力
|
||||||
|
|
||||||
|
明确了目标以后,我们就可以开始进入搭建阶段。
|
||||||
|
|
||||||
|
搭建方式
|
||||||
|
----
|
||||||
|
|
||||||
|
首先要做的选择是,是自行开发或雇人开发(外包);还是基于开源项目搭建,比如基于 WordPress 搭建。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
搭建方式的选择
|
||||||
|
|
||||||
|
不同的团队有自己不同的选择,恰巧我们两边都选过,这里分享下我们自己的经历。
|
||||||
|
|
||||||
|
### 自行开发
|
||||||
|
|
||||||
|
我们最初选择了自行开发,因为当时觉得WordPress过于臃肿。然而,现在回想起来,更多是因为认为自己的开发能力充足,误以为时间和技能成本较低,这最终被证明是一种误判。
|
||||||
|
|
||||||
|
从2019年到2022年,我们主要采用自行开发的方式,期间我们主要开发了网课平台,包括网课网站以及一些沙箱、在线运行环境,全部是独立开发的平台。
|
||||||
|
|
||||||
|
自行开发的优点在于完全可控,可以实现像素级的定制,将脑中的功能和细节百分百实现。
|
||||||
|
|
||||||
|
但缺点是工作量巨大,特别是当开发多个业务系统后,维护成本极高。我们已经从多个项目中抽离出公用部分,形成了自有的全栈框架,前端和后端统一,但框架的维护成本依然很高。比如,自有框架升级后,新项目自然可以直接使用,但可能需要回过头去升级老项目,这非常痛苦。
|
||||||
|
|
||||||
|
### 基于WordPress混搭
|
||||||
|
|
||||||
|
到了2023年和2024年,我们意识到大量开发时间被花在了本可以避免的事务上,而且业务量的增加最终可能需要我们开发一套内容管理系统(CMS),这实际上又等同于在做一个WordPress。因此,我们又重新采用了WordPress。
|
||||||
|
|
||||||
|
基于WordPress,其优点首先是通用功能都已实现,一些稍具特色的功能可以通过插件集成。例如,我们在搭建方糖07这个门户网站时,如果自行开发,至少需要半年才能迭代完细节。但通过使用WordPress并购买一个600元的主题,我们很快搭建完成、并使其达到了不错的阅读体验。
|
||||||
|
|
||||||
|
WordPress的REST接口也非常完善,可以通过插件在API层面实现功能扩展,甚至可以开发独立的前端,通过调用REST API来进行拓展。
|
||||||
|
|
||||||
|
非要找缺点的话,功能完成度和潜在的性能问题是WordPress的两大问题。功能完成度的问题在于,在可以偷懒(通过安装和购买插件实现)的情况下,可能最终实现的效果和我们想要的效果有10%的偏差。当然这肯定不是WordPress的错!😂
|
||||||
|
|
||||||
|
另一个潜在问题是,使用WordPress运营大规模的用户或内容网站时,性能可能成问题。尽管大部分性能问题由插件导致,但这仍是一个挑战。不过我们的产品用户数距离这个规模很远,一直在努力遇到这个问题中。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
搭建方式优缺点比较
|
||||||
|
|
||||||
|
### 最佳实践
|
||||||
|
|
||||||
|
我们认为的最佳实践是,首先基于WordPress做我们业务的最小可行产品(MVP)和众筹,同时也可以把产品的官网和文档放在这个平台上。随着业务的增长和用户量的增加,我们再自行开发。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
最佳实践
|
||||||
|
|
||||||
|
即使自行开发,我们也可以从三个层次上和 WordPress 进行混搭,分别脱离界面、后端和数据库的束缚。
|
||||||
|
|
||||||
|
首先,我们可以通过 REST 接口将 WordPress 作为后端使用,节省大量工作量。
|
||||||
|
|
||||||
|
然后,如果 WordPress 的后台系统效率依然不够高,我们可以共享数据库,自行开发一套新系统,直接从WordPress 的数据库读取数据,这样新系统的性能由我们的代码保证,数据共通,可以同时运行。
|
||||||
|
|
||||||
|
如果这样依然不够,我们还可以更进一步,建立一个完全独立的系统,但通过统一登录让用户可以关联起来。我们可以 WordPress 账户和微信关联。新系统虽然数据库不同,但通过微信登录走统一的Open ID,我们也可以定位到用户相关的信息。如果需要更多的用户信息,我们可以通过REST API的方式再读取相应数据。
|
||||||
|
|
||||||
|
通过这种多层次的混搭,我们可以实现最小量的开发,又拥有界面和性能的自由,同时尽可能降低维护成本。
|
||||||
|
|
||||||
|
参考方案:方糖OPB
|
||||||
|
----------
|
||||||
|
|
||||||
|
方糖OPB 是我们开发的系列 WordPress 插件,和 BudCoder、FlowDeer 配合使用,可以完成对「三池四能力」的高度覆盖。
|
||||||
|
|
||||||
|
### 产品界面
|
||||||
|
|
||||||
|
以下是它的界面,我们最近可能会做一些改动,以下截图供大家参考。
|
||||||
|
|
||||||
|
#### 微信账号整合
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
1. 我们添加了邀请码注册功能。这样产品还没有上线时,可以进行内测,只有知道邀请码的人才能登录。
|
||||||
|
2. 因为我们要支持个人运营,所以我们通过消息上行的方式来实现未认证公众号的登录。
|
||||||
|
3. 回调转发功能支持一个公众号在多个网站上使用。一旦接收到消息,会先转发到目标地址;如果目标地址不进行处理,再用当前网站的设置处理。
|
||||||
|
|
||||||
|
#### 微信支付
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
1. 标准的微信支付能力设置。
|
||||||
|
2. 收银台功能,包含支付APP和订单管理。只需一个页面跳转和一个HTTP请求验证就可以完成交易。
|
||||||
|
3. 实现了WooCommerce微信网关,包括官方微信和XorPay。所有支持WooCommerce的插件可以直接使用。
|
||||||
|
|
||||||
|
#### 消息推送
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
1. 实现了针对文章分类的订阅。您可以订阅某一个分类和该分类的更新,然后在文章发布时,可以点击推送按钮来推送给订阅该分类的用户。
|
||||||
|
2. 用户还可以通过一个管理界面来对这些订阅进行管理。
|
||||||
|
3. 还支持对评论进行订阅,使其实时性变得更高,可以大大提高互动性。
|
||||||
|
|
||||||
|
#### 商品众筹
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
在WooCommerce上实现的简版众筹。
|
||||||
|
|
||||||
|
1. 商品页在发布时选择开启众筹,设置一个截止时间和目标金额。
|
||||||
|
2. 在文章页面嵌入一个众筹状态简码,它会渲染当前这个商品的进度。
|
||||||
|
3. 商品管理的后台,提供批量退款功能。
|
||||||
|
|
||||||
|
### 基础设施结构和能力覆盖
|
||||||
|
|
||||||
|
我们来看一下回顾对比下一人企业基础设施的结构和能力。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
可以看到,方糖OPB插件最整体覆盖是很高的,除了被红线框出的几处:
|
||||||
|
|
||||||
|
1. 产品池,我们需要有一个快速构建简单需求的能力。
|
||||||
|
2. 自动化能力方面,因为WordPress只是一个B/S结构的网站,所以它不是很适合。
|
||||||
|
3. 众包能力这一块是没有覆盖的。
|
||||||
|
|
||||||
|
### 配合 BudCoder 和 FlowDeer 使用
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
在搭配 BudCoder 和 FlowDeer 这两个工具后,我们可以将覆盖度进一步提高。
|
||||||
|
|
||||||
|
BudCoder可以实现WordPress插件的AI生成,对于一些相对简单的需求,大概是300行以下的需求,它是可以处理的。而随着AI模型能力的提升,它的处理效果会越来越好。FlowDeer工作流在做内容分发方面现在已经很成熟了。
|
||||||
|
|
||||||
|
有了它们,我们可以覆盖到之前欠缺的产品池的简单需求生成、简单需求完成和自动化能力里边的内容分发。整个体系里唯一没有覆盖的是众包能力。
|
||||||
|
|
||||||
|
自动验收面对的场景太复杂,很难有一个通用的插件可以处理,但可以通过积分系统+自行开发/生成插件来单独处理;如果接收人工验收,可以自行购买对应的成熟商业插件。
|
||||||
|
|
||||||
|
获取方糖 OPB 源码
|
||||||
|
-----------
|
||||||
|
|
||||||
|
以上就是我们自己的解决方案。
|
||||||
|
|
||||||
|
之前在一人企业方法论里提到方糖OPB后,很多同学都希望我们能把这个工具开放出来给大家使用。
|
||||||
|
|
||||||
|
我们现在的这个版本是内部使用的,跟我们自己的系统有比较强的耦合,分拆出来有一些工作量,同时在客服支持上会有较大的成本。
|
||||||
|
|
||||||
|
因此我们做了一个众筹来验证需求,你可以到这里参加:<https://ft07.com/opb> 。
|
124
src/what-is-the-ideal-one-person-business-infrastructure.md
Normal file
@@ -0,0 +1,124 @@
|
|||||||
|
# 理想的一人企业基础设施
|
||||||
|
|
||||||
|
在了解方法论后,我们通常希望开始实践。但从这里开始,难度就会骤增,尤其是对一些没有技术基础的同学来说,会感到无从下手。
|
||||||
|
|
||||||
|
这是因为我们缺乏一些基础设施,而这些基础设施是使用互联网的企业所必需的,它们用于处理各种业务的通用场景。对于一些线下业务基础设施可能不一样,但一人线下业务往往难以规模化,所以我们这里只讨论以网络和数字经济为核心的一人企业基础设施。
|
||||||
|
|
||||||
|
为了将我们的想法和业务落地,让用户能够使用,我们需要构建一些基础设施。基础设施并不一定要自己构建,也可以直接使用现成的平台。例如,微信公众号就是一个很成熟的、用于付费阅读或广告商业模式的基础设施。
|
||||||
|
|
||||||
|
为什么要构建自己的基础设施
|
||||||
|
-------------
|
||||||
|
|
||||||
|
那么在有成熟平台的前提下,为什么我们还要构建自己的基础设施呢?首先要明确一点,并不是说平台的基础设施不能用,而是说在使用平台基础设施的同时,需要拥有一套完全自己可控的基础设施,并且实现用户的无缝连接。将单选变成多选。
|
||||||
|
|
||||||
|
### 商业模式
|
||||||
|
|
||||||
|
平台的核心商业模式是汇聚用户,从中获利。所以它对不同类型的用户以及在平台不同生命周期的策略是不一样的,这些策略可能并不适合我们的特定阶段。
|
||||||
|
|
||||||
|
例如,在一些平台上,如果某个账号影响力特别大,平台可能会削弱这种账号的能力。而对于一些特别小的账号,如果看不到增长趋势,就不会分配流量,甚至会限制你自己引来的流量。
|
||||||
|
|
||||||
|
另一方面,在平台早期,平台可能会扶持一些方向的账号,这时你会拿到较多的流量,但这些流量是从其他用户那里转移过来的。
|
||||||
|
|
||||||
|
如果没有自己的基础设施,就只能任由平台操控。但如果有自己的基础设施,当平台策略不匹配时,可以引导用户到自己的平台上消费内容、购买产品。
|
||||||
|
|
||||||
|
### 封号风险
|
||||||
|
|
||||||
|
平台有自己的红线和潜规则,甚至会出现一些失误。如果不小心碰到这些问题,可能会导致封号。对于个人用户,这可能没什么问题,但对于经营者,可能会导致数年构建的业务前功尽弃,所有努力化为乌有。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 产品形态和品牌
|
||||||
|
|
||||||
|
使用平台的基础设施还可能导致产品形态过于雷同。如果产品形态比较保守,可能没有问题,但如果在产品形态上进行创新,平台基础设施的约束就会非常大。
|
||||||
|
|
||||||
|
例如,我们原来的视频课程放在网易云课堂上销售,但当我们想为学员提供实际操作的沙箱环境时,平台并不支持。即使我们自己开发沙箱,要与网易云课堂的用户对接时,发现该平台不提供接口。
|
||||||
|
|
||||||
|
为了防止讲师从平台导流,一些平台甚至在课件中不允许出现独立域名。这种规则在平台中后期会特别严格。
|
||||||
|
|
||||||
|
### 混合生态
|
||||||
|
|
||||||
|
我们认为的最佳实践是首先拥有一个完全可控的基础设施,然后充分利用各个平台的资源和流量,分发内容到其他平台,并将用户回流至自有基础设施,形成一个混合生态。
|
||||||
|
|
||||||
|
为什么要自己构建基础设施
|
||||||
|
------------
|
||||||
|
|
||||||
|
市面上有很多构建基础设施的软件或SaaS服务,但当我们尝试使用时,会发现它们多多少少存在一些问题。
|
||||||
|
|
||||||
|
### 价格高
|
||||||
|
|
||||||
|
价格高是一个典型问题,因为绝大部分的SaaS是面向企业的。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
典型SaaS服务的定价
|
||||||
|
|
||||||
|
对企业来说可能便宜的价格,但对个人来说就很贵。在一人企业的早期,我们还没有赚钱,也没有风险投资,所以资源有限。一年上万的投入对没有收入的个人来说,还是太高了。
|
||||||
|
|
||||||
|
### 不对个人开放
|
||||||
|
|
||||||
|
另一个问题是很多基础设施不对个人开放,比如支付。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
微信支付申请材料要求
|
||||||
|
|
||||||
|
一些对个人开放的支付服务,又没有与这些现成的基础设施整合起来。这导致很多现成的基础设施不能直接用。
|
||||||
|
|
||||||
|
### SaaS而非自架
|
||||||
|
|
||||||
|
一个潜在风险是如果我们不能自行建设基础设施,而是使用服务商架设的在线版本,会有两种潜在风险。一是企业突然倒闭,即使退钱,但我们的业务就突然崩溃,没有补救方案。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
invision倒闭
|
||||||
|
|
||||||
|
另一个风险是企业突然涨价,因为业务已经在平台上,短时间内迁不出去,所以当服务商涨价时,议价能力很弱。如果我们赚到了很多钱,分润给服务商也无所谓,但对一人企业来说,如果费用过高,整体可能没有收益,甚至亏损。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
企业微信突然对外部联系人收费
|
||||||
|
|
||||||
|
理想的一人企业基础设施
|
||||||
|
-----------
|
||||||
|
|
||||||
|
可见,现有的用来搭建基础设施的服务多多少少存在一些问题。那么,理想的一人企业基础设施应该是什么样子的呢?
|
||||||
|
|
||||||
|
### 足够便宜
|
||||||
|
|
||||||
|
首先,它应该足够便宜,至少在用户量很少的情况下应该非常便宜。这样我们才能在没有赚钱的情况下持续运营。
|
||||||
|
|
||||||
|
可以自行架设的开源软件是一个非常好的选择,因为当用户量小的时候,对服务器资源的要求很低,只需租一个最低性能的虚拟机实例即可运营。
|
||||||
|
|
||||||
|
提供自架方案的在线SaaS是一个更省事的选择,因为你可以随时迁移到自架方案,没有lock-in的风险。
|
||||||
|
|
||||||
|
### 足够可控
|
||||||
|
|
||||||
|
另一方面,基础设施需要足够可控,不会因为别人的决定导致业务中断。虽然可能会受一些影响,但不能因为影响导致整个业务崩溃。
|
||||||
|
|
||||||
|
比如说,平台限流或封号,至少可以通过其他方法触达已有用户。服务商疯狂涨价时,至少可以将数据迁移出来,在自己的环境中快速搭建,让用户继续使用,不至于流失到竞争对手那里。
|
||||||
|
|
||||||
|
### 个人可用
|
||||||
|
|
||||||
|
我们希望这个基础设施可以以个人资质来运营。
|
||||||
|
|
||||||
|
因为注册公司的成本很高,虽然工商注册已经足够便宜,甚至有些城市连公章都是赠送的,但真正的费用在于每个月的记账。如果没有合适的场地,还需要租用场地,这两项加起来一年就需要几千甚至上万。
|
||||||
|
|
||||||
|
所以我们希望这个基础设施有一个完整的针对个人用户的解决方案,包括用户注册、登录、支付和消息推送等功能都可以个人资质使用。
|
||||||
|
|
||||||
|
### 足够开放
|
||||||
|
|
||||||
|
如果我们想在产品和商业模式上进行创新,必然会对常规流程、界面和功能进行修改。所以我们的基础设施需要足够开放,允许我们方便地进行二次开发。
|
||||||
|
|
||||||
|
另一方面,这个基础设施最好足够流行,这样才能容易找到二次开发工程师。不然就像现在的银行,全球有43%的银行依赖于COBOL程序,但已经很难找到对应的工程师来维护。
|
||||||
|
|
||||||
|
### 繁荣生态
|
||||||
|
|
||||||
|
即使能找到工程师进行开发,开发过程总是需要时间,而且由于需求和工程师理解问题,会经历很长时间的迭代才能出现相对成熟的产品。
|
||||||
|
|
||||||
|
如果使用的基础设施有繁荣的生态,很多功能可能已经被开发出来,并以免费或付费的方式发布为插件,我们可以直接使用。
|
||||||
|
|
||||||
|
即使插件有一些细节不符合需求,改动起来也会很快,成本会大大降低。
|
||||||
|
|
||||||
|
### 适配于方法论
|
||||||
|
|
||||||
|
当然,最重要的一点是,我们希望这个基础设施可以很好地适配「一人企业方法论」、为我们这套可能是唯一的针对一人企业的方法论提供全程支撑,让使用这套方法论的用户可以开箱即用,不要再花更多时间在测试和开发基础功能上。
|