交付较小的软件单元并限制本地主机分支的大小

在领导HackerNoon的过去十年中，我与许多才华横溢的软件开发人员一起工作，在他们任职的早期，我通常最终会说同样的话：交付较小的软件单元并限制本地主机分支的大小。为什么？以下是两个关键原因和一个重要原因：

1. 当您继续努力完成项目时，用户可以从您的工作中获得更多收益并提供反馈。

如果您有一个需要 6 个月工作的项目，并且在 6 个月内没有上线，那么用户在 5 个月零 30 天内从您的工作中获得的收益为零。只有当它上线时，互联网的其他部分才有机会从您发布的内容中受益。即便如此，这也正是大规模采用的艰苦战斗开始的时候。如果您每周交付部分项目，用户将开始在项目的生命周期中获得价值。

我的前同事Dane Lyons曾经对我说：“我们应该继续增加原子价值单位，并尽可能多地发布版本。在我们对它感到满意并准备好继续前进之前，我们可以轻松地发布 10 个[功能]版本。”

作为首席执行官，我经常根据新员工需要多长时间才能成为盈利贡献者来判断他们。在销售方面，这就更加简单了，他们的销售额是否超过了他们的报酬？当然还有其他事情需要考虑，比如营销、基础设施等的边际成本，但无论你如何划分，衡量软件开发人员如何影响利润都比销售人员更困难。如果您正在担任软件开发人员的新角色，我建议您在全垒打之前成功尝试将单打串起来。

在软件开发游戏中，分数的多少并没有通用的规则。当然，有些人分配积分系统，其他人定义 KPI，但最终，是使用你产品的人决定你是否以及如何创造价值。通过更快地发货，您可以更快地收到反馈。使用您的软件的人们将更清楚如何构建和不构建项目的下一个原子单元。

2. 您的分支机构偏离生产现实越远，队友就越难为您的项目做出贡献并推动相邻项目向前发展。

一开始可能很难看到不发布最新版本带来的外部影响。一切都是相连的。例如，在像 HackerNoon 这样的产品中，个人资料页面和故事页面并不存在于真空中。它们作为一个产品中的连接页面存在。如果某一页面的功能发生变化，则会影响与其连接的所有页面的功能。

如果您的本地分支非常大，那么一旦您的肥胖分支最终投入生产，与其连接的页面或功能上发生的其他更改通常将不起作用。这会破坏事情。这会产生错误。这迫使需要重做工作。这会让你的队友产生不想与你合作的愿望。这甚至可能会产生比您在本地分支机构投入所有工作之前已经拥有的产品体验更糟糕的产品体验。

通过更频繁地进行较小的更改，您可以授权其他人做出贡献。他们觉得他们发布的产品也能发挥作用，因为你们都已经就生产基线达成了一致。增量是你最好的朋友。它将你与现实联系起来。如果增量变化对产品产生负面影响，那么是什么让您认为同一方向上的较大变化会对产品体验产生积极影响？

最重要的是：不要害怕大胆的项目，它们可能会成为太大的分支，因为你是一个坏家伙，有能力改变这该死的东西对人们的运作方式。

有些项目只是必须是大型分支。例如，像新数据库这样具有大量依赖性的事物可能在现有使用中根深蒂固，因此最好倒转时间并像每年一次的本地 2.0 版本一样处理该项目。其他突破性技术，如 ChatGPT，需要很长时间才能构建，因此发布未经训练、不完整、糟糕的 UX 版本的新技术是没有意义的。采取大幅波动。当你拥有跑道时。当你有团队加入时。但不要夸大自己。大多数时候，软件开发并不是重新发明轮子。它只是运送下一个原子单元。