关于保持小规模团队

我们经常被问到：为什么不招聘？为什么不加薪？为什么不扩大规模？

坦率地说，“规模”并不是我们的目标。与其推出两倍数量但质量低劣的应用，我们更愿意把每个应用都做得非常出色。团队中每增加一个人，都会带来额外的沟通负担——会议、Slack 讨论串、规格说明文档、设计评审。这些负担会蚕食实际开发的时间。.

小团队行动迅速。小团队拥有自己的决定权。小团队可以说 "不"。

“小”在实践中是什么样子的

Zydeno 采用“远程优先”模式，并依靠自有资金运营。 这里没有办公室，没有投资者委员会，也没有由团队外部人员设定的增长目标。大部分协调工作都通过书面形式进行：关于正在开发内容的简短说明、每个版本的共享检查清单，以及针对每款应用的讨论串。电话会议仅在决策确实需要讨论时才会举行，而非仅仅因为日程表上安排了时间。.

开发某个功能的人通常会亲自测试该功能、撰写发布说明，并回复关于该功能的首批支持邮件。这听起来工作量很大，有时确实如此。但这意味着没有人会发布一个自己之后再也不会听到反馈的功能，而且反馈能直接传达到能够采取行动的人手中，无需经过三次交接。.

这也意味着，从决策到其后果之间需要经过的环节更少。当店铺评价中指出一个问题时，阅读该评价的人通常只需发一条消息就能联系到能够解决问题的人——而且往往就是那个能解决问题的人。.

权衡取舍

规模小确实有其代价，如果我们假装并非如此，那就是在误导大家。我们的发布速度比大型团队要慢。有些好点子要等待很长时间，甚至永远无法实现。当某个人不在时，他负责的应用开发进度就会放缓。 而且，由于需要同时支持 iPhone、Android、Windows 平台以及两款浏览器，我们总是面临着将精力分散得比应有程度更广的压力。此外，我们也无法将不熟悉的环节交给专业部门处理；每家新应用商店的规则、审核流程和特殊情况，都必须由我们自己去摸索学习。.

我们通过严格把关接手的项目来实现这一点。现有应用的新平台必须能真正提升应用体验，而不仅仅是增加其可用性。新应用必须是我们自己也会使用、并且愿意长期维护的。大多数创意都未能通过审核，这正是该机制正常运作的体现。.

为什么不提高呢

外部资金往往伴随着外部期望，而这些期望通常指向一种与稳健开发节奏不相符的增长速度。自筹资金意味着每款应用都必须自负盈亏，这其实是一种有益的约束：它促使我们如实把握用户真正重视的内容，而不是只关注在推介中看起来光鲜亮丽的东西。.

我们的失误

我们有时会将“小”与“自给自足”混为一谈。试图将所有工作都由内部完成——每一次翻译校对、每一个图标、每一行店铺文案——反而以不值得的代价拖慢了我们的进度。 保持小规模并不意味着拒绝帮助。现在，我们会针对具体且界定明确的工作引入专家，例如请母语人士审核翻译，同时让核心团队专注于产品开发。.

当我们成长时

总有一天，我们可能会发展壮大。到那时，原因必定是某个特定的人能做某件具体的事，从而让工作做得更好——而不是因为投资者想要一份更轰动的新闻稿。.