这是项目管理的经典话题——“多快好省”一直是项目管理的核心目标。

这里不谈通常的项目管理，还是从独立开发者的角度来聊聊如何进行个人管理。

独立开发者的个人管理

不管是一个人还是一个团队，时间始终是有限的资源。对于独立开发者而言，通常还要面对资源有限（硬件、软件、技术甚至自身精力）的现实挑战。所以，关键问题在于：如何在有限的时间内，利用有限的资源，尽可能做出优质的作品。以下是一些具体建议：

1. 明确优先级：聚焦核心价值

独立开发者最大的敌人是“功能蔓延”——不停地增加新点子，却无法专注完成核心内容。要牢记：

• 核心是什么？ 游戏的核心体验（Core Gameplay Loop）是否明确？玩家能否快速体验到这个亮点？
• 次要内容的优先级？ 先完成“必需”的内容，再考虑“可选”的优化和扩展功能。

这就像搭建房子，先有地基（核心玩法），然后才是装饰（附加功能）。不要试图一口气把一切都做好，特别是那些对整体体验影响不大的细节。

2. 制定“现实”的时间表

不要低估任何一项任务的复杂性。独立开发者容易过于乐观地预估开发时间，最终导致拖延或牺牲质量。

• 分解任务：将目标分解成可执行的小任务，每个任务都有明确的完成标准。
• 灵活时间分配：留出时间应对意外问题，比如Bug修复、优化。
• 分阶段发布：如果是长期项目，优先发布基础版本，通过用户反馈来改进。

一个实用的方法是采用“时间盒管理”（Time Boxing）：为每个任务设定固定时间，完成后即使不完美也先搁置，以便按时推进项目整体进度。

3. 善用工具：提高效率

独立开发者通常既是策划、设计师，又是程序员和测试员。善用工具可以显著提高效率：

• 原型开发：Unity 或 Godot 的快速原型功能，可以在早期快速验证玩法。
• 资源管理：使用版本控制工具（如 Git）来保存历史版本，避免关键数据丢失。
• 自动化流程：利用脚本化工具完成重复性工作（如批量导入资源或自动打包）。

4. 确定质量的“底线”

独立开发者没有时间和资源做到“面面俱到”，但必须确定质量的底线：

• 玩家体验：确保核心玩法是流畅和有趣的，优先修复可能破坏体验的Bug。
• 艺术风格：并不需要顶尖的画面，但美术风格要统一，让玩家觉得“舒服”。
• 优化性能：避免明显的性能问题（如掉帧），但不要过度优化早期原型。

质量的关键在于：知道什么时候应该“够好就好”，避免掉入无休止的细节打磨。

5. 借力反馈：优化而非闭门造车

独立开发者容易陷入“自嗨”模式，以为自己知道玩家需要什么，但实际情况往往不同。

• 快速测试：尽早将原型交给目标玩家群体进行测试，收集他们的真实反馈。
• 迭代开发：基于玩家的反馈逐步优化产品，而不是在第一次发布时试图完成所有功能。

这不仅可以帮你明确方向，还能提高时间和资源的使用效率。

6. 保持热情与健康

独立开发通常是孤独而高强度的创作过程，很容易陷入疲惫和倦怠：

• 设定休息点：定期休息，避免长时间工作影响健康和效率。
• 定期反思：每隔一段时间回顾进展，看看是否需要调整目标或方法。

热情是推动独立开发者前进的动力，但也需要科学的时间管理来支撑。

总结

独立开发者面对“快速、便宜、优质”的选择时，通常需要根据项目阶段和个人能力进行动态调整。

• 在早期，可以优先选择快速和便宜，快速验证概念。
• 在中期，需要平衡质量与时间，集中资源打磨核心体验。
• 在后期，适当牺牲速度，确保最终作品的稳定性和完整性。

独立开发是一场策略游戏，资源有限，但如果管理得当，同样可以交出令人满意的答卷。

---

原文：

原理 51：三选二：快速，便宜，优质

开发者在每一个项目中都需要在快速、便宜和优质中做出平衡。在理想情况下，一个完美的游戏应该同时做到这几点——快速地开发出来，没有太高的成本，并且表现出非常高的质量，但是这过于理想化了。几乎没有团队能同时做到这三点，其中总有一点要被牺牲。

我们很容易看到“快速”和“优质”之间的关系。有野心的计划总是与紧迫的工期相矛盾的。这正是为什么我们要有项目的“范围”(scope)这个概念。有时候计划一个较小一些的、不那么有野心的项目(范围小一些)，并且坚决地拒绝功能点的扩张，在不花费太多时间的情况下，项目的完成质量能相对高一些。然而，高质量的工作总是不便宜的。

人们通常会举出这样的反例：一些典型的独立开发者可以独立完成一个优秀的作品。但多数提出这一点的人们都忘了，这个开发者可能花了整整一年的时间来开发这样一个有野心的作品。尽管这可能是优质又便宜的(只需要个人的预算)，但它没有办法太快。

弗雷德·布鲁克斯(Fred Brooks)的书《人月神话》(The Mythical Man-Month: Essays on Software Engineering)是针对这个课题的一本知名著作。他推荐“原型”(参见原理 54“原型”)作为一个推进产品开发的方法，而这可以看做是一种在前面描述的三选项中牺牲掉“优质”的一个方法。他同时指出：“9个女人加起来也并不能在一个月内生出一个孩子。”有一些项目需要一定的时间并且没有办法更快，不管往其中投入了多少人力和财力。

当我们必须在这三者中做出选择的时候，记住没有人必须在每一种情况下都做出相同的选择。在项目的不同阶段，我们需要强调的可能是这三者中不同的方面。也就是说，尽管一个游戏开发的初始阶段可能需要是快速和便宜的，到了正式开发阶段，可能要求会变成快速和优质(同时会变得昂贵)。

当然，对于那些不那么重要的功能，我们可以牺牲掉一些质量，以便能够快速完成，这样可以将预算和人力更多地集中在大功能和“核心游戏循环”(参见原理 33“核心游戏循环”)上(参见原理 65“细节”)。遗憾的是，这个规律反过来并不成立。一个游戏的开发又慢又贵并且劣质是完全有可能的。