11、软件研发中的吞吐量与响应能力平衡之道

软件研发中的吞吐量与响应能力平衡之道

在当今竞争激烈的市场环境中，服务于大量客户的公司都期望为尽可能多的客户提供其产品和服务的最大价值。这种价值以“特性”为单位体现，即用户能够识别为逻辑实体的功能单元。产品管理的主要职责是识别能为客户增加价值的特性，并对那些能为最多客户带来最大价值的特性进行优先级排序。而研发组织则致力于尽快开发这些特性，以便将其部署到客户手中。我们将持续开发的新特性流称为研发组织的吞吐量。

1. 吞吐量与响应能力的现状

许多研发组织都在努力最大化其吞吐量，因为这直接支持了为尽可能多的客户提供尽可能多特性的目标。然而，这往往导致公司的客户感觉公司对他们的需求和请求响应不够及时。这并非是产品和研发经理的恶意所致，而是“填充管道”模式的结果，这种模式以优化吞吐量为目标。客户请求的任何新特性都会被添加到已规划特性列表中，由于后续版本的特性内容通常已经规划好，所以这些请求的特性往往要在请求后的一年甚至更长时间才能交付。

2. 接近客户的重要性

与客户建立更紧密的联系以构建更能满足客户需求的解决方案至关重要。采用敏捷软件开发时，公司通常期望在业务层面也能变得更加灵活。公司希望能够更快地响应市场动态和客户请求。但在很多情况下，组织无法等待过长时间来与客户建立更紧密的联系并提高响应能力。

有人可能会建议，只与客户合作并构建特定于客户的软件版本是最佳方式，因为这能让公司对单个客户做出最及时的响应。然而，客户的需求存在相似性，为每个客户构建定制解决方案需要研发人员数量与客户数量成正比增加。而软件业务的优势在于，一旦产品开发完成，复制成本基本为零，与客户数量的关联很小。

因此，在多个客户请求功能的几乎所有情况下，采用可配