"如果你对自己产品的第一个版本不感到尴尬,那你就发布得太晚了。" — Reid Hoffman 在Splits,我们遵循这种软件开发方法:先让它工作 → 再让它正确 → 最后让它快速。 顺序很重要。以下是我们在每个阶段交付中学到的经验:
让它工作 = 功能原型。 它应该是粗糙的。它应该是有点不稳定的。快速让用户看到它。 我们如何界定MVP: 1)列出我们认为可能对项目重要或相关的所有内容。 2)从这个列表中,我们能完成的*绝对最小*的内容是什么,以便拥有一个功能原型?
把它做好 = 修复所有损坏的部分。 在这个阶段进入市场时,要有明确的信号:持续的反馈,尽管存在明显的缺陷,但使用量仍在增长。 现在你已经赢得了投入更多资源的权利。
快速完成 = 优化性能。 老实说,我们仍在学习这个阶段。大多数团队目前处于“做好它”的模式 🤷‍♂️ 但这就是激励我们的灵感:
为什么这种方法有效: 顺序是策略。你今天学到的东西会影响你明天构建的内容。跳过某些步骤,你就没有解决问题所需的信息。 行动产生信息。但*有意*的行动会产生*更有用*的信息。
陷阱在于你试图在让它运作的同时让它变得正确。 不对。 “允许自己发布一些你知道不对的东西。” — @wminshew
1.8K