作者和授权信息
本文由 Easy 撰写。

Weibo: https://weibo.com/easy
Twitter: https://twitter.com/easychen
Youtube: https://www.youtube.com/c/Easychen
(欢迎大家关注和订阅，等 Youtube 订阅过 1000 ，我会试试制作本方法论的视频版)

本文在 cc-by-nc-sa 协议发布。

您可以复制、发行、展览、表演、放映、广播或通过信息网络传播本作品，但必须署名作者并添加链接到本文。
不得为商业目的而使用本作品。
仅在遵守与本作品相同的许可条款下，您才能散布由本作品产生的派生作品
为什么有这篇文章
不管是独立开发还是IT课程，一个人做业务也好几年了，最近开始回过头整理通过实践获得的认知，并尝试将其梳理为一个方法论。

当然这个体系还不完善，但一直没有找到同一个方向又更为完善的。所以不如自己来整理和维护，对自己而言可以定期回顾修正，读过的大家也可以来参与补充。

什么是一人公司
这个方法论，我把它叫做「一人公司方法论」。那首先什么是「一人公司」呢？

字面的理解就是一个人运营的公司，但实际上它指代的是比较少的人运营的小公司，一般来说1~3个人运营的公司，也可以把它放到一人公司的范围以内。其他一些形式，比如说一个人再加上很多的兼职一块运营的公司，其实也可以看成一人公司。

所以从人数上来定义一个公司，实际上并不是很准确。我更喜欢另外一个层面的定义：

「 一人公司就是建立在个人品牌之上的公司。」

这个定义更为准确，它是说整个公司的业务和品牌影响力都主要源于基于一个人。它周围可能有一些辅助运营的团队，有一些外包、有一些兼职，甚至全职助理的角色，那也是一人公司。

为什么要单独来观察这一类公司呢？因为我觉得它是以个体创造财富的典型。之前我翻译过一篇趋势报告，叫做「百万美金的一人公司」。说的就是越来越多的一人公司，可以做到百万美金的价值。当然，直接盈利达到百万美金的不多，但是以 100 万美金估值卖掉的却不少，而且正变得越来越多。

一人公司的特点
优点
下面我们来看看一人公司的特点。先看优点。

第一个显而易见的优点就是成本低。因为整个公司只有一个人，所以无需办公场所等硬性成本；也没有长期雇员，所以它没有固定人工成本。

这里需要注意，固定人工成本，实际上是一个会引入风险的成本。很多程序员创业副业喜欢做外包，但是如果你做一家外包公司，就会纠结于固定人工成本。比如在你规模小的时候，接到几个大单子，就需要扩展人员来完成开发。但是如果做完这些项目以后，接不到同样数量的活，你还却依然需要支付同样的薪资来维持团队。这就成为了一个很高的风险。

你又不能把员工开掉，下次需要时再招。先不说这样干下次还能不能招到人，每次团队磨合和培养的成本就非常高。

回到低成本上来，因为你只有一个人，你不需要协同，所以没有沟通成本，很多事情可以保质保量的快速完成。

再一个，因为你没有团队，个人的话，想在哪个城市就可以在哪个城市。现在一些新一线和二线城市的生活成本非常低，生活环境也非常舒适，如果可以把业务放在一线城市，然后生活在其他城市的话，不但生活成本低，而且生活品质反而会得到提高，这也是一个非常划算的地方。

因为成本低，相应的对收入的压力就小。一个每月只能挣 10 万的业务，对大公司来讲可能成本都收不回来，但对于一人公司来讲，去掉成本和税都是自己的，很可能可以活得挺滋润。也正是因为存在这些结构性的市场空白，才让一人公司可以存在并得到发展。

缺点
一个人的精力是有限的
说完优点，下面我们来说一下缺点。

首先就是一个人的时间和精力是非常有限的。因为如果我们一天工作10个小时，一周工作5天，那一周其实就50个小时的工作时间。如果把这50个小时的工作时间均摊到各种要做的事情上边，就会发现其实每一件事都分不了太多时间，这会造成整体业务进展慢。

同时，因为就一个人，所以必须在多种业务之间来回切换，这会带来一些额外成本。

比如说我们正在编程、正在做架构设计的时候，是在进行深度思考，如果这时候有一些紧急但不重要的事情插入进来，就会把我们从深度思考中拉出来，之后需要再花很多时间才能重新进入到这个状态里边去，甚至可能再也回不到当时的状态，从而丢失掉一些很好的想法。尤其是对一些创造性高的工作来讲，这是非常可惜的。

一个人需要做全部事
第二个缺点就是，一人公司往往要求我们一个人把整个链条上的所有事情都做了。原因很简单，因为整个公司就你一个人，你不做就没有人做。

这样带来的一个非常明显的问题，就是工作量的大额增加。即使很多没有难度的事情，处理细节也会消耗大量的时间。

另外还有一个更严重的问题，「麻雀虽小、五脏俱全」。它不但要求工作量，还对技能有要求。如果你缺乏特定的技能，就需要投入上百个小时的学习时间，而且还不一定能学得好。

更有一些大型公司具有的资源，一人公司可能是不具备的，比如像做运营和销售时候的人脉资源。如果持续解决不了，就只能调整策略去绕开。

矛盾和解决
这里就出现了一个非常明显的矛盾：一方面是我们个人的时间精力非常有限（一周就50~60个小时）；另外一方面，我们又有非常大量的事情要做，因为公司就我们一个人，所有的事情都是要有人来做的。

这个矛盾不解决，一人公司就运转不好。怎么解决呢？还是从矛盾的双方分别入手。

提升效率

第一个方向，一个人的时间和精力是有限的，那我们能不能提升效率。

这个对于其他的行业来讲，可能会比较难，但是对于程序员来讲，可以考虑自动化和人工智能。如果在这两个方向上有突破的话，我们就可以把个人的时间和精力从重复劳动里面解放出来，让机器高效率的去处理重复的事情，把我们仅有的精力放到创造性的、开创性的业务上面来。

对于通用业务而言，这个难度可能很大，但如果针对某些特定的业务，还是有可能构造出一人+机器人的效率放大结构的。这个结构一旦完成，就可以极大的提升效率。

选择要做的市场

另一个方面，我们还可以从选择要做的市场入手。虽然每个公司都有各种业务，但对于不同的市场，每一种业务的工作量是完全不同的。如果我们对进入的市场进行取舍，就可以把精力集中到那些工作量小的细分市场或者小众市场。比如我们只针对一个小众人群去做一个功能简单的软件，产品和开发的工作量就会小很多。

但小众市场往往伴随获客问题。

通用渠道
首先是通用渠道的相对获客成本变高。比如同样是花一百万买开屏广告，面向大众的快消类产品，100 万人看，其中有 80 万都是潜在目标用户，最后点击可能是 20 万。但小众产品如果以同样价格去投放，100 万人中很可能只有 10 万人是目标用户，这样点击和转化就非常低了。相对而已，小众人群的获客成本反而高很多。

定向投放
除了通用渠道，我们还可以考虑做定向投放。所谓定向投放是说，对这个小众市场的行业网站和社区投放广告，或者向这个小众市场相关的意见领袖（KOL）做营销推广，再或者购买搜索关键字来导流。这部分的效果会好一些，但成本就要看这个行业竞争如何了，竞争激烈的比通用渠道投放还要贵。

自制内容
以上两种方式都是需要相当的市场预算的，对于一个刚刚启动还没有盈利的产品，更多的是没有什么预算的情况。这时候我们更多的会考虑自己来做内容、自媒体、成为 KOL。

但做内容是需要持续不断投入的事情，在精力上的投入比较大。如果我们是一个人的公司，那一周50个小时的时间，花在视频录制剪辑加字幕发布上的时间，很可能高达20个小时。40%的时间花在做视频上，而这个视频它还不是立竿见影的，需要很长的时间去积累用户。

这也是为什么你会看到很多的程序员，不是靠写软件挣钱，而是靠公众号卖广告挣钱。因为做内容就很费时间了，如果还要去开发一个软件，精力上很难支持住。

自传播
除了做内容，我们还可以在产品设计上发力。如果我们能让产品做到自传播 —— 就是让用户能不断地邀请来新用户，我们就不用花自己的精力在上边了。

有网络效应类的产品比较适合做自传播相关功能，因为用户的收益和用户数量成正比的。有的产品不一定适合传播，比如定位是一个非常私密的个人数据类产品，就不一定适合通过分享内容来拉新。

当然除了直接整合在产品中，我们也可以通过积分、物质回报来激励。比如现在已经很常用的分销返利或者邀请用户送付费会员等。

小结
对比以上方案，自传播应该是最好的渠道。需要付出的成本低，效果相对的也好。但它的问题在于如何优化产品，实现持续不断的自传播。这个是非常考验产品能力的。

选择成为平台或生态的一部分
除了选择市场以外，我们也可以选择成为平台或者生态的一部分。因为有平台在，我们就可以少做很多事情，甚至只需要关心业务逻辑。

对于早年的苹果市场来讲，只要会开发应用可能就OK了。苹果商店会帮你进行销售，其他的事情都不用管。

但这其实是理想状态，随着市场慢慢的从蓝海变成一个红海，我们会发现即使应用写完了，在市场里已经有很多同样的应用。我们又只能想办法去做营销相关的优化，在其他渠道去做一些推广。最后之前要做的事情，又回来了。因为对于每一个产品来讲，平台能提供的入口大家都能拿到，只能在这个基础上再竞争。用现在的词就是「内卷」，市场「卷」起来以后，我们就必须去做更多的事情。

当然我们也可以不做海，选择去做一个小池塘 —— 就是说这个市场非常小，不太可能变成红海，因为没有那么多的人看得上它。但相应的，这种市场一是很难发现，二是往往随着趋势的发展，它可能会消失掉。可能短期内还能挣点钱，但最后这个市场可能就没了，你又不得不从头来重新寻找新市场，这也是非常痛苦的。

苹果商店已经很成熟，所以比较卷。我们也可以去找一些新的平台和生态。比如 toB 的 SaaS 的话，国内可以看看企业微信和钉钉，国外的话可以看看 Airtable 这种新兴生态。如果进入的时间点合适，就能分到很多流量。

当然，还是想之前说的，一旦市场竞争变激烈后，红利就会消失，剩下的就是大家真刀真枪的竞争，要做的事情又会变多，如此往复。

分离非核心业务
确定了市场以后，我们还可以对自己的业务进行取舍。比如，我们把非核心业务给分离出来。这些业务，我们可以外包、可以兼职。对于一些基础设施，我们可以「以租代建」。

所谓「以租代建」，就是说以前我们需要什么系统都要自己开发，但是现在有各种各样的云平台、行业SaaS、以及不少按量付费的商业服务。比如商品代发，就已经有平台可以帮你来做。只要付一点钱，就可以让他们帮发货，自己就不用再搞个仓库或者店面来做中转。

基础设施和制造业也正在逐渐的成熟和开放，比如3d打印、周边印制。最后它们都会抽象成一些API接口，我们在网上去调用它，付费，剩下的事情就自动完成了。这样的话，很多非核心的业务都可以被分离出来。当然这个是一个过程。不同国家和地区的市场、不同的行业成熟度都不同，需要自己去考察。

强调「以租代建」对于程序员有特殊意义，因为对我们来讲写程序是很容易的事情，自己建一套系统也很方便的，而租用别人的还要花钱。以租代建的核心是节省时间和精力，如果我们只是通过不断开发各种系统来省钱，那这样跟我们去接外包挣钱不会有太大的区别。

（这也是我自己经常犯的错误，需要时刻提醒自己）

这里还有一个概念要明确，前面我们有提到说要分离非核心业务，那什么样的业务是核心业务呢。

这里有一个简单的判断标准。在我们做的这个业务中，最稀缺的资源应该成为我们的核心业务。比如对网课平台来讲，能持续不断生产优势课程的讲师就是稀缺资源，如何聚集和维护这个群体就是核心业务。只要保证这点，其他资源都会慢慢聚集过来。而其他的部分，比如课程平台的开发，就是非核心业务，可以通过租用或者购买的方式来解决。

增强优势
除了降低工作量，我们更需要想办法来增强优势。因为降低工作量只是保证我们能把产品完成，但如果产品和其他竞品一样的话，并不会具有优势。

从用户的角度来讲，大部分的用户并不关心产品背后的开发者是个人还是大企业，更看重付出的成本和得到的收益。所以我们最终还是要回到产品价值上来，为用户提供不可或缺的价值。

从标准品到独立品类
我们可以给一些标准化的产品去添加独有的特色功能，从而把它变成一个独立的品类。比如我之前做过一个软件叫做福利单词，它是一个背单词的软件。在任何一个市场上，这类软件都是一大堆。但福利单词有一个额外的功能，就是在输入单词正确时，会给你显示一张高清的萌妹子福利图。这就带来了完全不同的体验，在它和那些千篇一律的背单词软件中划出了界限，成为了一个同时融合叫教育和娱乐功能的独立品类。

如果你觉得这点小功能还不足使其以成为一个独立品类的话，可能我之前做的学前端 RPG 游戏 更明显一些。

副产品优势
另外一点就是，我之前在「从精益开发到精益副业」的视频 中提到的「副产品优势」。

虽然是在运营一人公司，但不一定非要全职来做这件事情。也可以一边上班，一边把一人公司作为副业来做。

在这种情况下，我们就会多出来一个优势，我叫它「副产品优势」。核心是说，因为有主业，所以可以保证基本收入和生活品质；在主业工作里边产生的副产品，可以进一步加工为商品，作为副业来销售。这样既没有生活压力，又降低了副业的制作成本。虽然刚开始可能收益的绝对值不大，但可以慢慢把它做大，直到有了充足的现金流，再把它当成主业来做。

营销优先还是开发优先
除了上边提到的这些，在实际运营中，我们还经常会遇到很多其他需要选择的地方。比如，在优先度上，到底是应该营销优先还是开发优先。

对于大一点的公司，有足够的人力，营销和开发都是不同的部门去做，所以可能不存在这个问题。但是对于一人公司来讲，其实很难一边做营销，一边不停的去给产品开发新功能。因为营销和运营不是一个短时间的事情，需要持续不断的进行。如果你不去做，很可能流量就没有了，没有流量就没有转化、也就没有收益。

另一方面，如果我们不断的开发新功能，时间长了就会有一堆项目需要维护，维护成本累加起来会很大。假设有 50 个项目，平均每个项目一年升级维护一次，每次两天，那么就会花掉我们工作时间的 40%。如果这些项目是免费的还好，可以随时关闭。但如果每个项目都有那么几十个付费用户，既不挣钱就要不断的提供维护和客服，是非常麻烦的。

这之间的取舍，会对我们的一人公司的运营产生很大的影响。

营销优先
营销优先模式是说，我们只开发一个很简单的产品，维持一个很小的功能集。然后不断的去为这个产品寻找新用户。

这个模式的优点是，我们开发的功能很少，维护成本比较低，不用不停地开发。

而它的缺点就在于，我们需要持续不断的进行营销，不断的获取新的用户。最后可能会发现，越来越多的精力都用到了营销上，用到了拉新上。最后完全变成了做内容或者做业务的竞争。

即使这样，如果能做好营销，那其实也不错。但大部分程序员并不喜欢和擅长做营销，而且在没有市场预算的情况下，要成为影响力不错的营销号是需要花很多的时间和精力，甚至还有运气的。

关于营销的难度，很多同学没有基本的概念。我这里有一个自己常用的参考转化率，是在以微博为主要流量入口的环境下测试得到的。从信息流展示次数到有效付费购买之间，转化率略为 1~5‰ 。当然，具体的数据会因为营销材料、产品需求有很大的不同（这其实是优化得不错的数据了），当你自己测试过后，可以得到自己的转化率数据。

如果你没有自己的数据，那么不妨以 1‰ 为基础简单评估营销难度。也就是说，如果想要获得 100 个购买，大概需要十万次的有效阅读，那么首先以 10 万的触达为基础思考如何达到。

开发优先
另一种模式叫做开发优先。是说我的营销能力可能不够，那我就面向同一群用户，不做营销了；改为针对已有的这些用户，不断的为他们开发付费产品。

这其实就是凯文·凯利那篇《1000个铁杆粉丝》的文章中的逻辑。文章中说，如果你有1000个铁杆粉丝，无论你卖什么东西他们都会买的那种，那你只需要面向他们不断推出产品，就可以维持不错的生活。

这种模式的优点是，我们不用到处去做营销，不用过多的去做我们（可能）不擅长的领域。而缺点就是，开发很累，维护也很累。如果不能形成规模效应，就要不断的开发付费应用，每一个产品可能就会做得很浅。

你可能要问，为啥我要不断的开发应用，我只开发一个应用，然后不断的收钱不行么？答案当然是可以，但难度有点高。

为什么要这么说呢，我们来计算下。假设我们期望每个月的毛收入在 5 万（除去成本和税以后大概在 3 万），如果以 1000 个铁杆粉丝来算，那每一个用户，就需要每个月消费50块钱。

这其实是一个很高的费用。从开发者的角度来讲，你可能觉得这个费用不高，但从用户的角度来讲，是很高的。如果你收集下自己和周围的人在软件和互联网服务上的实际开销，就会明白。

我之前在微博上发过一个提问，从评论来看，即使一年花销达到200左右的产品和服务都不太多，而且基本是资源导向的，比如视频音乐会员、电商外卖会员。很少有工具类软件能达到这个数的。所以，to C 的工具软件和 SaaS 里边，要找到每年能持续挣600块钱的需求，难度相当高。

to B 的服务在价格上相对容易上去，但是在获客成本和开发工作量上又相对较高。如果能在其中找到一个好的需求，倒是很不错。

总之，如果我们找不到这样的需求，就只能退而求其次，用多个付费服务来提升客单价。

实际操作
前面说了这么多的分析，但离落地还有一点点距离。在最后一部分里，我们就来思考下怎么落地。

发现一个趋势
寻找一个小市场
针对这个市场
面向 1000 个用户，提供一个每月 50 元定价的产品
或者面向 10000 个用户，提供一个每月 5 元的产品
开发产品并持续运营
发现趋势
首先，我们应该集中精力在发现趋势上。以前创业的时候，我经常思考一个问题。凭什么一个创业公司可以以很小的团队，在很短的时间，用很少的资源崛起。以前的人都没这些人聪明吗？显然不是。后来在阅读一些创业方法论的时候才明白，这是因为创业公司发现了趋势，找到了变化。因为这些变化是新出来的，所以以前的商业虽然有能力，有资源，但难以未卜先知。新的趋势就像山脉的崛起，将原来严丝合缝的商业逻辑撑开，出现了新的商业路径。

发现趋势，就是要看到变化。个人的努力虽然重要，但也要考虑时代的进程。尤其对于一人公司来讲，跟上大趋势，才能放大自己有限的精力投入。

关于趋势发现，简单粗暴的方式是读研究报告。比如艾瑞网会定期更新一些简版报告，从里边的数据可以发现很多有意思的趋势。不过这些报告更多的是面向创业投资领域，未必适合一人公司。像我经常在微博上提到的 Trends.vc 这种专门为独立开发者和一人公司准备的分析报告，就更有针对性一些。

寻找一个小市场
正在高速增长的赛道里往往有大量的巨头和创业公司，从资源上来讲，一人公司在这些领域很难占据优势。

但在这些赛道周边，通常都存在一些年收入最高几千万人民币的小市场，这些市场大厂和资本是看不上的，反而是一人公司很好的切入点。如果能结合趋势，选择到一个现在看起来很小，但是会随着趋势慢慢变大的市场，就能进一步保证将来的收益。早期进入，持续深耕，当这个市场成长起来时，即使是一人公司，也会具备很强的竞争力。

设计产品
然后就是针对这个市场设计产品了。根据自己的能力，可以有两个选择：

面向 1000 个用户，提供一个每月 50 元定价的产品
或者面向 10000 个用户，提供一个每月 5 元的产品
当然，其实你还可以进一步调节用户数和月定价，只要乘起来是 5 万就可以。而且 5 万也只是一个参考值，做不到还可以调低。如果一个产品做不到，可以把一个改成两个。这里量化数据的意义在于，给出一个清晰的模式，用来做前期的参考。

参考依据
在设计的过程中，我们可以准备很多备选方向和产品，通过比较选出最适合自己的。以下是我觉得有用的参考依据：

市场安全性：发展趋势（是否快要没了）、竞争情况（是否红海）
客户价值：MRR（每月经常收入预期）、LTV（客户生命期价值）
获客渠道和成本：是否能够自传播，传播系数
工作量：MVP（最简可行产品）所需工时、迭代和升级维护成本
资源匹配度：是否有自己难以掌控的资源
开发和持续运营
接下来就是 MVP（最简可行产品） 的开发，PMF（产品市场契合） 的寻找以及后续的持续运营（或者转型）了。这一部分的内容可以参考精益创业系列方法论。

一人公司的基础设施
无公司运营
虽然写的是「一人公司」，但其实我们并不需要一开始就注册一家公司。因为会带来办公地址和记账的固定成本。一般来讲，最理想的方式是以个人身份运营业务，在有了稳定的现金流以后，再注册公司。

在国内，很多平台对个人主体并不友好，需要自行寻找替代方案。以 Web 业务为例，我们需要和平台对接的部分通常包括：

第三方用户登入（比如微信登入）
支付（没有这个就没法收钱）
消息触达（群发通知）
其中，① 和 ③ 算是加分项，② 则是付费业务不可绕过的。

个人支付解决方案
就我了解，在目前个人主题可用的支付方案中，唯一安全而且稳定的是「小微商户」及类似方案。这种方案其实是支付平台（比如微信、支付宝）在提供底层能力，只是通常为了防止被滥用，不开放直接申请，而改用服务商代理的形式。

正因如此，它可以做到资金完全走支付平台（而不是你的支付服务商），保证了资金的安全而且没有二次清算问题。

国内提供基于小微商户支付方案的有好几家，通过搜索可以发现有 xorpay 、payjs 等服务商。但不少服务商不太厚道的自己搞了一个审核流程来收取审核费或者叫开通费。

我自己使用的是面包多推出的支付平台：面包多Pay。

官网注明的特点如下：

没有开通费，交易时才付费，非常适合启动期的项目，费率为每笔交易 0.1 + 2%
支付完成以后可以显示文字、图片或者跳转到网址，一些简单场景就不用写代码来接入了
不过对我而言，最主要的考量还是平台稳定性，现在面包多每月结算数百万，这个支付平台其实就是其业务核心「闪电结算」平台的扩展，属于主业副产品，因此不挣钱应该也会维护下去。

一个 Tips：面包多Pay（其他平台我并未交费试用，因此不做评价）的支付接口里边，有一个获取 openid 的接口。它其实可以用来做微信体系下的用户登入。换句话说，无需认证公众号就可以实现微信用户的登入和支付。这就非常适合个人。

消息触达
常规操作是，在登入时要求用户补全邮箱、手机号并将其作为消息触达主通道。但邮箱时效性差、短信被拦截可能性高，且费钱。因此微信成为了发送通知实时性和到达率最高的通道。但是未认证公众号只能被动回复消息，均不能主动发送消息。即使认证公众号，模板消息权限正在收回。

经过比较，我认为目前适合个人的消息触达方式是微信机器人/QQ机器人。通过关注机器人，发送 token 实现账号关联，之后就可以通过机器人推送消息给用户了。我知道的方案如下：

微信机器人方案： wechaty (网页版协议免费，其他协议收费)
QQ机器人方案：mirai （未亲测）
机器人方案除了可以用作消息推送，还可以用作登入。比起通过支付接口的 openid api 登入而言，没有因 openid 改变导致用户无法登入的风险。

公司注册
如果你不能找到满意的个人主体解决方案，那么就只能考虑注册公司了。需要留意的是，即使注册公司资质，其实也有个体工商户和公司两个选项。

个体工商户的申请流程虽然简单，但其背后是无限责任。而有限责任公司则以注册资金作为上限，更容易规避风险。

公司注册不是本文的内容范围，在此就不做展开了。

交付物

• 软件

100%实现需求明细列表所有功能，即100%满足业务需求的软件。

• 文档

项目验收

• 验收方式

1、将要交付的软件安装于指定服务器，并完成调试和上线；
2、完成培训后，业务验收人员根据需求明细列表实现情况进行验收评价，研发验收人员根据以下内容进行验收评价。

• 文档验收

1、文档齐全（参考如上文档清单）；
2、文档内容描述准确, 没有歧义和错误的表达；
3、文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；
4、文档对主要功能和关键操作尽量提供应用实例。

• 界面验收

1、界面设计符合自己公司的设计规范；
2、外包团队需提供与软件适配的浏览器、手机、PAD等品牌与版本号清单；
3、各界面需要做好PC、手机、PAD等UI兼容与机器适配；
4、原则上，浏览器至少需适配Chrome、Safari、火狐、IE8以上；
5、原则上，手机至少需适配苹果、小米、华为、vivo、OPPO、三星、魅族。

• 功能验收

1、功能验收范围覆盖（接口、数据库存取、页面功能）；
2、提供单元测试用例、集成测试用例和系统测试用例；
3、提供BUG管理跟踪记录表；
4、提供质量分析报告。

• 性能验收

1、提供性能测试报告；
2、相关重要指标达到以下要求：

• 安全验收

1、软件中的敏感数据需以密文方式存储；
2、软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等；
3、软件中各种用户的权限分配合理；
4、扫描出的安全漏洞（包含但不限于：越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等）外包团队需修复完毕。

• 用户验收

1、外包团队需提供稳定的用户验收环境和联调环境；
2、业务场景功能测试不通过数的比例<1.5%；
3、不存在严重等级为1的错误；
4、不存在严重等级为2的错误；
5、严重等级为3的错误数量≤5；
6、所有提交的问题都已得到修复；
7、以上功能，用户验收测试通过后，由用户负责人签署验收通过确认书。

源码交接

如涉及到源码交接，按下列规范进行验收和交接。

• 交接前提条件

1、需提供用户验收通过确认书；
2、涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块；
3、跟薪资类无关的软件或功能，所有功能需在线上稳定运行不少于3个月；跟薪资类相关的软件或功能，所有功能需在线上稳定运行不少于6个月；
4、线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个。

• 源码验收

1、代码应只保留跟本项目相关的代码，无效代码应一律去除；
2、数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等，无效内容应一律去除；
3、特别注意合理做好数据表结构设计，适当冗余提升性能；
4、代码结构清晰无冗余，注释完整有效，避免硬编码；
5、但凡不符合源码验收规范的，外包团队需修复完毕。

• 其他注意点

1、对于外包团队的软硬件选型，建议业务部门邀请本公司IT团队一起参与决策；
2、与外包团队商签署的商务合同和补充协议等，建议业务部门邀请本公司IT团队一起参与制定；
3、外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可；
4、如外包项目不符合或无法满足上述验收规范的，建议商务层面延长付款周期、扣除相应款项或终止合同；
5、每一笔合同款在支付给外包团队之前，除了需获得用户验收通过确认书之外，还应通过IT团队验收；
6、以上内容建议附加进商务合同，成为其中一部分。

软件外包存在风险，外包人员技术、态度、交付能力，如果想通过合同或者诉讼降低风险，由于太多的未知因素和太多的主观性，不现实。因此唯一的外包原则应该是：如果外包人员做得不好，有能力随时终止合作且可控费用损失和项目交付。

可以尝试渐进式方法，首先废除传统开发外包大瀑布方式（例如签订需求URS、项目总金额、进度款支付）（不过目前大部分外包会坚持使用瀑布法，并签订大额的预付合同），尝试新方案，项目按照功能或者阶段划分为多个子合同，做小项分包，或者改为签订人力外包合同。

• 针对我们想要构建的功能，拟定一个顺序列表。
• 找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。
• 对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。
• 让他们实现那个特性并测试。
• 让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。
• 符合要求后，合并并部署该特性，这样，所有创始人/用户就可以继续审核该 App，并提供反馈或者根据需要调整。
• 如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。
• 如果我们对他们的工作不满意，就解雇他们，并寻找替代者。

当前需要做的工作，整理敏捷开发平台或者公共开发平台，并且参照以下原则：

• 客户合作胜于合同谈判
• 个体和互动胜于流程
• 可运行的软件胜于详细的文档
• 响应变化胜于遵循计划

参考文章：
Experiences working with an Outsourced Dev Shop

我最近发布了个人对Django做为一款优秀应用框架的一些考虑。本文基于此从架构角度做进一步扩展，介绍从开发到生产环境的整体技术栈考虑。

2018 年至今，我一直使用该技术栈构建一些小型 SaaS 应用。

本文最初发布于 www.simplecto.com，经原作者授权，由 InfoQ 翻译并分享。

整体技术栈

随处部署的 Linux 服务器和虚拟机：我使用了 Azure、Digital Ocean 和 Scaleway，并计划在 2021 年将所有部署迁移到Hetzner提供的专用服务器上。

Docker：就是我们常用的 Docker.

Traefik：使用 LetsEncrypt 证书的反向代理和 TLS。

Postgresql：运行在 Docker 中的数据库。

Django：同样运行在容器中。

IntercoolerJS：提供平滑易用的类 Ajax 前端应用支持。Intercooler 的创作者在 2021 年发布了HTMX，是 IntercoolerJS 的更新换代。

Sentry：捕获生产环境中软件缺陷。只需在配置文件中添加几行配置。

Bitbucket Pipelines 替代 CI/CD：鉴于 CI/CD 引入了过多繁琐无用的工具，我在 2021 年不再对个人项目考虑 CI/CD。

ZeroTier：实现 VPN 和控制层。

我在开发小型项目时，采用本地 Docker 容器运行测试，进而直接推送到生产环境。我不考虑使用繁琐的 CI/CD，而是选择了 Bitbucket Pipelines。

上图给出了我所采用技术栈的概览，图中有很多需要详细展开阐述的部分。下面换成列表方式展示。

• 虚拟机
• Docker

• Django

• 挂载数据磁盘卷

• 使用长时间运行 Django 命令做为 Workers

• 挂载数据磁盘卷

• Postgres

• 挂载数据磁盘卷

• Traefik

• Zero-Tier

• SSH

托管环境

即便是无服务器架构，也需要一个云服务托管环境。我个人推荐Azure、Digital Ocean和Scaleway。每家都为计算、联网、存储和基本服务提供了充分的选项，支持用户任何构建需求。

同样推荐Hetzner，它提供了各服务层级的硬件、服务和价格。

虚拟机

一些企业应用和个人副业（side projects），并不需要同时为成千上万的用户提供 TB 级数据服务，因此可扩展性并非主要关注问题。对于此，我们可选用最小托管服务选项，通常不高于每月 20 美元。即便是服务价格相对最贵的 Azure，也可选用 Burstable 服务质量的虚拟机。个人推荐Scaleway的开发层级服务器。

注意：在我的技术栈中并没有 Kubernetes，因为我并未考虑可扩展性。

Docker

为确保新的虚拟机运行在最新版 Docker 上，我并没有依赖操作系统本身，而是使用了 curl|bash 方式，即：

curl -s https://get.docker.com | sudo bash

运行上面一行命令，就能获取最适用于当前运行环境的最新版本。

Traefik 实现反向代理

Traefik 对我简直是天赐之选。尽管 Nginx 也很强大，但其并非针对 Docker 环境构建。Traefik 的两个杀手级特性，为我节省了大量时间：

使用 LetsEncrypt 实现自动 TLS。简而言之，一旦设置，无需操心。结合适用的 API 和 DNS 服务提供商，还可以使用 DNS 验证。

使用 Docker label 实现无需重新加载的自动配置。一旦新服务发布，Traefik 通过监听所有 Docker 相关服务而自动发现更改。这使得服务的添加、移除和合并非常方便，不存在任何麻烦。

我对 Traefik 唯一意见是学习曲线略为陡峭。用户必须自行确定如何进行配置，包括配置文件、命令行选项、YAML、Docker label，乃至组合使用。

提示：我发布了自己使用的Traefik生产环境配置文件，供参考。

Postgres 数据库

亲测推荐，PostgreSQL 从不会令我失望。PostgreSQL 容器可毫无问题地添加到任何项目中。我只需简单地启动容器，绑定端口，挂接数据卷到主机磁盘，仅此足矣。

docker-compose.yml
version: '3.1'


services:


  db:
    container_name: postgres
    hostname: postgres
    image: postgres:11
    restart: always
    environment:
      POSTGRES_PASSWORD: secretsonly
    volumes:
      - ./data:/var/lib/postgresql/data
    ports:
      - 5432:5432
    networks:
      - web


networks:
    web:
        external: tr

用于 Web 的容器化 Django

Django 很好地支持发布到容器中，我多年以来一直这么用。我反复强调开发环境和生产环境匹配的重要性，Docker 为我实现了一切。

我在 2021 年新推出了一个 Django 项目，用做新项目的模板，参见https://github.com/simplecto/django-reference-implementation。

实现异步任务的 Django 命令

我使用做为标准框架组成的自定义Django命令实现异步任务。该模式采用具有 sleep()的 while 循环，轮询数据库相关操作，并采取相应的动作。

截止 2021 年，我已使用这一模式运行一个网站截屏项目一年多，回报丰厚。该项目每日对 1500 个网站做截屏，所有操作由 Django 命令计划和管理。项目地址：https://github.com/simplecto/screenshots。

IntercoolerJS 降低了复杂性

这里如果展开说，需推出多个帖子，恐怕内容太长，以至于不会有人愿意读。我结合 JQuery 和这个小型 JavaScript 库，实现部分类似单页应用的效果，尽管事实上并非单页应用。

IntercoolerJS 保留了 Ajax 的传统优点，从后端 HTML 更新 DOM，无缝且平滑，非常便于实现用户登录和更新小型表单等元素。

强力推荐访问IntercoolerJS官网。

其创立者在 2021 年继承发展了 IntercoolerJS，推出了HTMX。

Sentry 捕获生产中错误

任何应用都会出错，但不应向用户展示。Sentry 提供了一种捕获生产中软件缺陷的易用便捷方式，其特性包括：

开源许可，可在生产中任意部署。

只需在 Django 项目的 settings.py 中添加几行配置，即可生效。

与 Git 代码库和问题追踪系统紧密集成，提供全生产环境的缺陷可追踪能力。

另一个优点是，随时能在生产环境中禁用。

更多信息，可访问Sentry官网。

Bitbucket Pipelines 替代 CI/CD

2021 年，我不在个人项目的部署中使用 CI/CD。其中存在太多工具，复杂性高。我只是使用 PyCharm 运行测试，然后从开发设备直接交付生产环境。

当前存在多种 CI/CD 解决方案，但是我推荐 Bitbucket 提供的 Pipelines 的服务。该服务每月提供数百分钟的免费使用，只需很少费用就能提供自上而下的功能。我自己在使用中很少碰到问题，很喜欢它们的 YAML 配置文件。

我使用 bitbucket-pipelines.yml 文件，实现跨多个 Docker 容器的完全端到端测试，加载数据库，并在几分钟内执行数以百计的测试。该服务是我们团队高效的关键，支持生产环境中每日五次以上 Push。

更多信息，访问Bitbucket官网。

ZeroTier 实现 VPN

最后，推荐一种在很大程度上是可选的、但是最好应具备的技术。Zerotier 是一种独树一帜的网络/VPN 服务，我用其连接所有的个人计算机。它可穿透防火墙联通家庭和办公场所，一分钟即可配置好。

如果所有设备使用 ZeroTier，就可以避免 SSH 中令人头疼的密钥管理，单机上共享带宽。

Zerotier 可运行在 Linux、Mac、Windows、Android 和 iPhone 上，覆盖大部分设备。

ZeroTier 的一个问题在于，我并不完全了解它的工作机制。和 MacOS 和 iPhone 类似，它们会按用户期望工作，并不出问题，只是从用户体验角度看有些不爽。但对于一名 CTO，谁又会去关心具体的细节呢？

总结

希望上面的深入介绍能激发读者对 Docker、Django、Traefik，尤其是 IntercoolerJS 的兴趣。它们简单、易于使用，能在适当时大展身手。

原文链接： Docker, Django, Traefik, and IntercoolerJS is My Go-To Stack for Building a SaaS in 2021
https://www.infoq.cn/article/W4leI4XZ32eSTqFJ8qPl

作为一名忠于内心的工程师，每当我看到一家公司发布有关它们技术栈的文章时，我都会泡一杯咖啡，坐下来耐心阅读，看看有没有新的发现。了解其他公司业务背后隐藏的一些技术十分有趣。就像娱乐八卦一样，只不过这是技术层面的探索。

几个月前，我开始开发另一个 SaaS，该项目经历无数次迭代。幸运的是，尽管项目仍处于早期阶段，但是很多网站已经对其进行了集成。

作为一个自负盈亏的独立创业者，我相信正是由于专注于自动化，才让我能为来自 80 多个国家和地区的客户提供可靠服务，并且每周持续提供新功能。当我想要了解服务的运行情况或者其他方面的信息时，我会尝试利用我熟悉的工具。当然，我也明白，在一些特殊情况下这些工具并不会帮到我。

现在，我简要地介绍下平时使用的一些工具。

非常重要的一点是，虽然工具列表看起来很长，并且有一些是非常规且不常用的选项，但实际上我在基础架构上花费的时间很少，如果有的话，每个月平均下来也就是几个小时。还有一点就是个人推荐就像是开处方一样，我认为对我非常有用的一些工具，可能并不适合你。一定要考虑自己的实际情况，并利用好当下你熟悉的工具。

编程语言

多年来，我学习和使用过好几种编程语言，但是对于独立项目，我特别挑选出两种编程语言。这两种编程语言可以在生产力以及可靠性上取得很好的平衡。

Python：很多项目的后端代码都是用 Python 实现的。它可以让我能够以较快的速度发布新功能。另外，我使用 mypy 用于类型提示，这方便我进行代码管理。

Typescript：我以前会有意地避开前端开发的工作。直到大约 4 年前，我发现并开始使用 Typescript。它让我感觉写前端的工作体验更好了，现在我使用它并结合 React 框架一起构建我的项目。

框架

理论上，我会在这里介绍很多这方面的内容，但是相关论坛上有不少介绍，我也是站在巨人的肩膀上学到很多知识。因此我只想介绍几个非常不错的框架：

Django：该框架简直就是独立开发者的宝库。你在该行业中工作的时间越长，你越能体会到避免重复造轮子带来的幸福感。这一框架可以让你走的更远，因为它的功能实在是太全面了，应用场景也很广泛。推荐阅读Instagram如何优化Python提高服务性能、Sentry项目、10大Django构建的网站了解一下 Django 的使用场景。对我来说，该框架不管在性能还是功能方面都能满足我的需求。

React：数据展示相关的 Web 应用是使用 React + Webpack 构建的。在长时间使用 Angular 后，我最终切换到 React，因为它是支持可插拔的视图层，不会对其他功能造成影响。我使用性能表现不错的django-react-templatetags将 React 组件嵌入到我的 Django 模板中。

NextJS：我使用它进行页面、文档等的加载。它让我能重用各种 React 组件，并且可以提高静态页面的性能以及 SEO 优势。

Celery：我使用该框架用于后台/定时任务的管理。该框架的学习成本较高，但是一旦你了解了它的工作原理，并应用到项目中后，你就能体会到该框架的稳定性和可靠性了。

Bootstrap 4：我基于 Bootstrap 构建前端应用。它节省了我很多时间，并且文档资料详细丰富。这就是我选择使用它的原因。

数据库

我最初将所有数据都存储在 SQLite 数据库中，对数据进行备份意味着要将副本数据复制到 S3 之类的对象存储中。之前对于测试过的一些小型站点来说，没有什么问题。但是，随着项目的功能及页面越来越多，我需要更多专门的数据库来支持这些功能：

Clickhouse：我相信 Clickhouse 是为数不多的随着时间的推移而经久不衰的技术之一。说实话，这是一款十分给力的数据库，它能够实现原先在低配置硬件上几乎无法实现的功能。

PostgreSQL：我必用的关系数据库。默认配置合理，经历了充分的市场检验并且与 Django 深度集成。在 Panelbear 中，PostgreSQL 主要用于与分析无关的应用数据存储；对于分析用的数据，我使用 Django 实现了一个简单的接口从 Clickhouse 查询数据。

Redis：我在很多场景中使用了 Redis，比如缓存、速度限制、任务队列以及作为有生命周期的键值存储。Redis 功能强大且性能稳定，社区文档也十分丰富。

部署工具

与这篇文章描述的一样，我不会将我的基础设施视为宝贝一样对待。服务器和集群本来就是一个工具而已。所以如果某一台服务器出现问题，用另外一台正常的服务器替换一下就好了。这意味着所有的操作在 git 仓库中被描述为代码逻辑，并且我不会通过 SSH 登陆服务器进行一些操作。你可以将这个描述视为一个模板，可以通过一个命令将整个基础架构克隆到任何的 AWS 服务中。

这在灾难恢复时也会对我有所帮助。我只需要运行一些命令，几分钟后，我的应用服务就可以重建并能正常运行了。当我将应用从 DigitalOcean 迁移到 Linode，以及最近往 AWS 迁移时非常有用。所有的操作都通过代码描述和执行。因此，即使在几年后，我也很容易的跟踪项目的相关部署和运行情况。现在所有的公司都拥有 AWS IAM 策略或者 VPC 子网，这些都是通过一些 UI 界面点击操作完成的，现在所有人都离不开这一功能，因为确实给用户带来了很多便利。

Terraform：我使用 Terraform 来管理大部分云基础架构。在我的 Terraform 清单中声明了诸如 EKS 集群、S3 存储、角色和 RDS 实例之类的一些配置。这些数据会同步到另外的加密 S3 存储，以避免我开发用的笔记本电脑发生故障而无力回天。

Docker：我会将所有服务构建为 Docker 映像。甚至有状态的组件（比如 Clickhouse 或 Redis）也作为 Docker 容器打包并运行在我的集群中。这也让我的应用服务可移植性非常高，因为我可以在能够运行 Docker 的任何地方运行它。

Kubernetes：它极大地解放了我繁琐的工作。我并不是盲目地向所有人进行推荐，因为在工作的这些年里，我使用它解决了好几次大型的生产故障。为公司及时解决生产问题，让我感觉十分自豪。我还用它进行容器化应用的管理，这也帮我减轻了工作负担。

GitHub Actions：过去，我常常使用的是CircleCI（这个用起来也不错），但是对于这个项目，我更喜欢使用 GitHub Actions，因为它删除了需要访问代码库以及部署密码的一个不必要的服务。但是，CircleCI 同样具有很多不错的功能，我仍然向大家推荐它。

基础设施服务

我从最开始使用月费 5 美元的 DigitalOcean 单实例服务器开始，逐步转向使用 Kubernetes 来管理服务，因为我正在彻底改变 Kubernetes 提供的一些开箱即用的功能（比如：服务发现、TLS 认证、负载均衡、日志滚动管理、滚动发布、容量管理等）。

但是，即使在较大的服务器实例上，使用 Kubernetes 管理的 DigitalOcean 也同样存在可靠性问题。集群 API 服务经常会随机地停止工作并且无法恢复，这会破坏包括负载均衡在内的许多集群服务，也就意味着服务停机无法对外提供正常服务。每当发生这种情况时，我会重新创建一个新的集群，尽管使用 Terraform 可以很轻松的实现，但是这并不会增加大家对其托管服务可靠性的信心。我怀疑是他们的资源不是特别充足导致的，考虑到他们的服务收费较低，因此这是可以理解的。

不幸的是，几周后，我就无法解决上面提到的问题了。这就是为什么我决定迁移到Linode的原因，在接下来的一个半月的时间里，系统再也没有出现过任何问题。

但是，AWS 向我抛来了更加诱人的优惠，所以我最近又做了一次迁移。AWS 还支持使用托管服务比如 RDS 来减轻 PostgreSQL 的压力，这对我来讲是个很大的优势。我的迁移工作没有那么复杂，因为我的所有基础架构都是通过 Terraform 和 Kubernetes 配置清单进行描述的。系统迁移可能会花费或长或短的时间，所以一定要有耐心。这一方面的话题可以在其他文章中找到。

AWS：提供可预测服务以及大量的托管服务。我主要在全职工作的时候使用过它，所以我没有花费很多时间来处理问题。我使用过的 AWS 服务主要有 EKS、ELB、S3、RDS、IAM 以及专用 VPC，未来我可能会使用 Cloudfront 和 Kinesis 服务。

Cloudflare：我主要将其用于 DDoS 保护、DNS 服务以及负载各种静态资源的边缘缓存（目前减少了 AWS 的 80％网络出口带宽费用——它们的带宽定价是在是太贵了！）。

Let’s Encrypt：免费的 SSL 证书授权服务。我在 Kubernetes 集群中使用了 cert-manager，它根据我的入口规则自动颁发和更新证书。

Namecheap：我常常使用的域名注册服务商。它允许 MFA 登录，这是一个十分重要的安全功能。与其他域名服务商不同，它们不会每隔几年就会突然增加域名的高昂续费费用，十分的良心。

Kubernetes 组件
以下组件可以自动完成大部分开发运维工作。我也使用其他的一些组件，但是我最想推荐给大家的是下面几个：

ingress-nginx：一个性能稳定的使用 NGINX 作为反向代理和负载均衡的网络入口控制器，控制入口流量到集群节点的网络流量负载均衡。

cert-manager：该组件可以按照入口规则中的定义自动颁发和更新 TLS 证书。

external-dns：借助 DNS 服务（例如 Cloudflare）同步公开 Kubernetes 服务和网络入口。

prometheus-operator：可以自动监控大部分的服务，并可以通过 Grafana 对数据进行展示。

flux：可以实现在 Kubernetes 中进行连续交付。当我要发布新的 Docker 映像时，可以通过拉取镜像进行部署。

命令行工具

我使用的命令行工具有很多，但经常使用且值得推荐的就下面这几个：

kubectl：与 Kubernetes 集群进行交互的工具，可以对日志、pod 和服务进行监控，并且可以 SSH 登陆到运行中的容器。

stern：Kubernetes 的 pod 日志查看工具，方便易用。

htop：交互式系统进程查看工具，真的比系统自带的 top 工具好用。

cURL：网络请求工具，可以对请求头进行检查。

HTTPie：与 cURL 工具类似，但是对于 JSON API 而言更简单易用。

hey：网络负载测试工具，可以提供详细的延迟分布报告。

监控工具

Prometheus：可以高效地存储时间序列数据并进行监控。可以追踪所有群集和应用程序的性能指标。比使用 Cloudwatch 进行应用程序监控要便宜得多。

Grafana：可以对 Prometheus 监控数据进行展示。所有的展示数据以 JSON 文件进行描述，并在 git 仓库中进行版本控制。

Sentry：对应用程序异常情况进行监控。该工具在发现带有其他元数据的未处理错误时进行告警通知。

Loki：受 Prometheus 启发而发展出来的一款日志聚合系统。它附带了 prometheus-operator 功能，可以帮助我在整个群集中对海量日志进行搜索。

邮件工具

Fastmail：我优先选用的商务电子邮箱，功能齐全且稳定性高。

Postmark：我主要将其用于交易电子邮件（电子邮件验证、每周报告、登录安全警报、密码重置等）的收发。他们的电子邮件传输速度非常快，邮件移动应用程序在业界也是一流的。

开发工具

GitHub：源代码托管及版本控制工具。

PyCharm：可能是 Python 最好的 IDE 工具。使用它可以轻松地重构和导航整个项目代码，而不仅仅是单个代码文件。 即使使用大型动态代码库，该工具的使用表现也很好。

VS Code：非常适合 Typescript / React 编程，并且可以用作通用代码编辑器。

Poetry：Python 打包及有锁文件的依赖管理工具。

Yarn：具有本地缓存的快速 JS 依赖项管理工具。

Invoked：我使用它将所有代码库任务包装在可调用的命令中。例如，使用inv build可以准备静态资源，打包前端/后端环境依赖，并生成 docker 映像。这样，就可以在本地执行与 CI 运行的相同的命令。

其他工具

Panelbear：当然，除了 Panelbear，还有什么能比 Panelbear 更好的工具来跟踪 Panelbear 的网站分析呢？内部测试是有很大收益的，因为我就是我自己的客户。

Healthchecks.io：当计划作业未能正常运行时，就会通过电子邮件或者 whatsapp 通知到我。它也是基于 SaaS 的辅助程序，这个工具我使用了好几年了，非常高兴可以推荐给大家。

Trello：我使用它来记录和跟踪一些问题、需求及想法等等。

Figma：用于为目标页面快速制作模型、横幅和插图，它取代了Sketch作为我的入门工具。

原文链接

https://panelbear.com/blog/tech-stack/