我一直想尝试这样一种收费方式：

• 有全部功能、但交互复杂的版本，免费;
• 仅必要功能、但交互简洁的版本，收费。

听起来很奇怪？

看看下面这两款遥控器，如果你的电视可选这两种，左边免费、右边收费，你选哪个？

健身房也有类似的反向思维策略：先充值，如果能保证健身的次数，退钱。否则，不退。虽然健身房用这种方式刺激用户，但实际上还是有很多用户因为各种原因无法保证健身次数。

当我跟别人说起我是自由职业者、独立开发者，尤其当对方是大公司员工、甚至是中高层领导时，总会被表达这样的想法（或者他们有某种想法，只是没好意思表达出来）：

• 单打独斗是不行的，你总是要加入团队、公司，才能干大事
• 什么都自己做，可能都做不好吧？
• 你总不能一直写代码吧，以后怎么办？
• 自由职业者很自由是吗？
• 你是受不了公司的约束才出来的吗？
• 呵呵…

其实，我也只是在这条路上摸索过一段时间，说下我的理解、感想吧。

• 独立开发者并不一定是单打独斗
  • 比如，创意可能是在跟朋友聊天时产生的，Logo 可能是请人设计的，最开始的测试是热心用户完成的，推广可能是找媒体朋友帮忙的，等等。
  • 这中间有大量的协作。与公司相比，这样的协作 本质上是相同的，而且 可能更难，因为被协作者并没有同事、上下级关系，大家为什么要配合你？这就要看个人品牌、影响力了。
  • 当然，要做复杂的事，一定要有优秀的团队，这是肯定的。
• 真的不能一直写代码吗？
  • 一方面，能不能写辈子代码，这本身是可以讨论的问题。
  • 另一方面，独立开发者并不只是写代码。甚至，对于最终成型的产品来说，开发只是其中一部分，其他像创意、设计、测试、运营、推广、等等，可能会占用更多的时间。而做这些事所锻炼的能力，是可以做很多其他事的。
• 自律才有自由
  • 自由职业者并不是绝对的自由，而是在自律下的自由。如果不能自控，即使在公司也会偷偷上网玩乐；如果能自控，马路边也能打开电脑解决用户问题。
  • 尤其，自由职业并不意味着懒散，甚至是更忙碌。
• 自由职业的意义，在于最大化个人价值
  • 对于公司、组织而言，为了保持一致性，一定会在大家之间取最大公约数。而作为其中的一员，被约掉的可能是自己的个性、爱好；被强加上的，可能只是组织的共性。不恰当的约束，则会限制个人能力的发挥。
  • 自由职业都则可以很好规避这个问题。自己喜欢的、擅长的，多花些时间做；其他的，少花时间、或者外包给别人做。
• 大，不等于永恒
  • 一想到大公司，大家很自然会联想到稳定、可靠、持久这样的印象。但，其实大并不意味着稳定，比如诺基亚、摩托罗拉的衰落。
  • 不论是大公司、还是小个体，都需要不断调整自己、适应变化，没有哪一种具体的形态，能够永远持久。而在就对变化时，小，恰恰是种优势。
  • 大，可能辉煌极胜；小，可能很难死掉。
  • 突然想到刘慈欣的《微纪元》，如果人类像蚂蚁一样大，一辆汽车大小的飞船，就能飞到月球。
• 创业，活下去最重要
  • 创业成功，唯一的标准就是活下去、一直活下去。如果死掉了，所谓的学到经验、历练、教育用户、扩大市场总盘子、过往的耀眼，都是浮云。

继续赶路、Klib 继续优化中…

小众需求领域，更像是卖方市场：生产者生产出什么商品，消费者才能消费什么商品。反过来理解，并不是大家有需要，生产者一定会生产。因为需求太小了，生产可能很难收回成本。或者，机会以成本太高，生产者还不如去做大众需求、以赚得更多。

在这样的前提下、在生产者+消费者整体来看，更应该保证的是生产者的积极性，这样才能让这个市场继续下去。

对应到软件的小众需求领域，也是如此。这就可以推导出关于软件支付的个人理解：就当适当偏向于开发者的诉求。比如，订阅可能比买断更适合。一方面开发者的收入可能变得稳定；另一方面开发者才有动力对已经发布的软件进行更新。这样，最终受益的还是消费者。简单想想就好了：把价格作为报酬支付给消费者，他能生产出自己需要的软件吗？

当然，我理解消费者可能短期内不喜欢订阅制，但买断制带来的隐形的「难受」会让大家慢慢接受。比如，有 2 个同类型的 App，一个是订阅、另一个是买断，因为价格的因素选择了买断的 App。但几乎可以肯定，这款 App 后续不会有大的更新，自己用着不爽、App 也不会改进。这种感觉，就像是买了件款式不好、但价格便宜的衣服，虽然买的时候省钱了，但其实很少穿、或者穿上不舒服，那还不如买个自己更喜欢的、经常穿的衣服，性价比更高。

在开发过程中，尤其是开发前期、面对复杂功能时，会有明显的 混沌期。

在这个阶段，

• 有很多事要做，比较杂乱
• 很难分清各个事情之前的依赖关系、轻重程度
• 可能做着做着，之前已经做好的功能又被破坏了、甚至都不知道已经破坏了，还在此错误的基础上继续开发、错上加错
• 有很多变数。比如在开发过程中需求变动，或者发现了之前没有考虑到的功能、不完善的逻辑。这会让本身就困难的开发过程，变得更不稳定。
• 由于开发过程拖得比较长，一直没有结果，甚至连中间结点也没有，人也一直紧绷着，不能及时放松，很容易觉得厌烦、沮丧、对自己的能力产生质疑，等等

而一旦过了混沌期，又会觉得神清气爽，很有满足感。

而以我的经验，这样的混沌期不可避免，只是时间长短的问题。如果明白了这一点，至少在心理上有一定的预期，不会在遇到困难时轻易变得沮丧。

那么，如何缩短这一混沌期、尽快搞定问题呢？由于我刚刚经过了这个状态，简单总结下心得：

• 尽量分割为小任务。没有谁能一次性解决复杂的问题，都是一步步来。而怎么一步步来？就是要能将大问题量拆分成尽量独立的小任务。
• 开发各个小功能时，尽量相互隔离。这时候，单元测试 就派上用场了。一旦完成某个功能，立即完善单元测试。在完成新功能时，及时运行所有单元测试。这样，如果之前已经完成的功能被破坏时，能立即发现并修复，而不是成为隐患。
• 不忘初心。当开发周期拖得比较长时，很容易忘记最开始要做什么、以及重点是什么。这时候，就要不断回到原点来回顾、反思。另外，一个具体的把关就是，根据初心，尽量预定义出丰富的 测试用例。这些测试用例会避免走偏，并且在最后时用户验证

继续前行…

已经在 3 月份了。

可我还是 Klib 多数据源合并的大坑里。

白天还信誓旦旦地说：搞不完今天不睡了。结果，还是没搞完；并且，要去睡了…

感觉还是需要有大块时间来搞这个复杂的逻辑。不然，每次状态切换、恢复现场很花时间哎。另外，由于拖的时间太长，整个节奏都乱了。什么番茄工作法、频繁提交、等等，全都抛到脑后了。

明天，搞定合并、数据库升级。以此为目标，倒推先做什么、哪些可舍弃。