在我的执行演讲中，我花了大量时间讨论以下主题： 少做 ，谈论我们如何浪费大量或很少使用或从未使用过的功能和金钱。已发表的研究表明，这一数字远高于50％。我看到听众同意，但是我也看到微小的思想泡沫稍微浮在头顶，“但在我的组织中却没有。”当组织应该担心的是将客户需求效率提高25％时，组织会担心将开发生产力提高10％。我一直在说，由于不断关注简单性和对客户的最大价值，敏捷带来的最大的潜在生产力改进在于我们无法使用的所有功能。
但是，在大多数组织中，软件开发效率会受到无限分析，而根本没有提到客户需求效率。我们既没有在开始时就测量或计算特征值，也没有测量是否按照客户或产品经理的预测实际捕获了值。在许多大型公司中，项目投资回报率可能是投资组合管理过程的一部分，但是很少有人跟进来看看是否确实实现了投资回报率。因此，开发团队具有反馈机制，而客户/产品团队则很少，除非是在宏观层面（例如产品销售）。产品经理对大多数功能级别的决策都持直觉。难怪很少或从未使用过50％以上的已开发功能。产品管理团队不是罪魁祸首，但是缺乏足够的反馈机制。
如果我们看一个典型的敏捷项目团队，则有开发子团队和产品/客户子团队。已经定义了角色，职责和反馈机制，例如，产品团队可以识别故事，编写故事，对故事进行优先排序并制定验收标准（自动验收测试和功能展示评估）。因此，存在微观（特征和故事）反馈机制来指导开发工作。但是从产品管理到业务的反馈呢？这些通常更脆弱，例如，总体销售说明了产品在宏观水平上的运作方式，但对单个功能一无所知。在大多数情况下，内部IT产品的反馈甚至更少。缺乏反馈会导致功能膨胀，因为总是很容易满足客户的需求和内部需求以改进产品。
At the 敏捷 Brazil 2011 conference I was listening to Josh Keriesvky’s talk on his Lean Startup experience, and gravitated to thinking about this problem. Here’s a starter list of ideas about potential solutions:
- 为每个产品管理组织和团队制定客户需求有效性度量。
- 计算每个功能的相对或货币价值。
- 使用相对收益表盘（例如增加客户满意度，降低客户风险，改善我们的内部协作文化）来评估功能价值。
- 将功能使用信息构建到软件中，以向产品管理提供反馈。产品管理人员因此可以深入了解实际使用和未使用的内容。
- 将功能评估实验开发到功能识别和优先级排序过程中。例如，对功能进行A / B测试。
- 错误的特征分析。授予用户访问一项功能的权限，该功能被选中后会弹出一条消息，例如“此功能正在开发中。完成后，您“很有可能”，“有点可能”或“不太可能”使用它。 Josh谈到了昂贵的功能，由于这种测试的结果，他的公司决定不实施该功能。
- 使用简短，有针对性的调查来衡量客户满意度。例如，“您使用能力Y（能力是多个功能）的经验是什么？太好了，确定，不太热。
While there has been a lot alluded to in the 敏捷 and Lean communities about value-based development, the actual practices to support this objective are not yet sufficient. There aren’t sufficient feedback mechanisms at the feature level to help mitigate the constant push towards feature bloat. Maybe taking a look at some of the ideas from Lean Startup and other sources can help.
这些是我的一些初步想法。您对这个问题有什么想法？
