交付是一项功能:独立开发者的项目管理
管理项目的实用策略,避免范围蔓延,以及真正完成你开始的事情。
我大约开始了四十七个副业项目。我完成了大约十二个。那些交付的和那些没有交付的区别不在于技术复杂性或时间可用性——而在于我如何处理项目管理方面的事情。
范围蔓延怪兽
这是一个熟悉的故事:你开始构建一个简单的待办事项应用。但然后你想,“它应该有分类。“然后,“分类应该有颜色。“然后,“用户应该能够共享列表。“在你意识到之前,你正在构建一个完整的项目管理套件,而当你只是想要跟踪你的购物清单。
范围蔓延是副业项目的无声杀手。它伪装成”让它变得更好”,但实际上阻止你完成。解决方案不是意志力——而是系统。
拥抱残酷的优先级排序
你添加的每个功能都有成本:构建时间、维护时间和用户的认知负荷。在添加任何东西之前,问:“如果我不构建这个会发生什么?“如果答案是”没什么”,那就不要构建它。
我使用一个简单的框架进行优先级排序:
- **必须有:**没有这个项目就无法工作
- **应该有:**显著改善核心体验
- **可以有:**会很酷但不是必需的
- **不会有:**明确决定反对(目前)
你的第一个版本应该只有”必须有”。其他一切进入待办事项。这感觉受限,但它是解放的。它给你专注的许可。
时间限制一切
帕金森定律指出,工作会扩展以填满可用的时间。如果你给自己六个月来构建某样东西,它将需要六个月。如果你给自己六周,你会找到在六周内完成的方法。
设定激进但可实现的截止日期。将工作分解为一或两周的冲刺。如果一个功能不能在该时间段内完成,进一步分解或削减范围。
约束的力量
约束不是障碍——它们是创造性的燃料。当你不能使用你喜欢的框架时,你学习你真正需要什么。当你时间有限时,你专注于真正重要的事情。
我的一些最好的作品来自于人为的约束:在周末构建它,只使用原生 JavaScript,不需要后端。这些约束迫使创造力并防止过度工程。
尽早交付,经常交付
你项目的完美版本只存在于你的脑海中。真正的版本——用户实际可以使用的版本——只有当你交付它时才存在。这里的秘密是:今天交付一个”足够好”的版本比永远交付一个”完美”的版本更好。
让某样东西工作起来。把它放在真正的用户面前。他们的反馈会告诉你什么是真正重要的,这几乎从来不是你原以为重要的。
管理长期游戏
不是每个项目都需要在周末交付。有些是真正的多个月或多年的努力。对于这些,关键是保持动力。
每天都做一点,即使只有三十分钟。小的、一致的进步胜过零星的爆发。当你碰壁时,处理不同的部分。当你卡在后端时,构建一些前端。当你厌倦了编码时,写文档或设计模型。
成功的真正指标
目标不是构建完美的项目。目标是完成某样东西并把它发布到世界上。一个交付的、人们实际使用的项目胜过一个永远不会离开你笔记本电脑的完美项目。
所以挑选你的四十七个副业项目中的一个。定义最小的、会有用的版本。给自己一个截止日期。然后交付它。
世界需要你正在构建的东西。但它需要它交付,而不是完美。