Gil Zilberfeld在2015东欧敏捷大会上做了新敏捷的演讲。InfoQ采访了Gil Zilberfeld，谈到了产品规划与跟踪的更好方式，他的观点#没有估算，包括在产品规划中价值的讨论，以及如何提高产品开发的决策。

\\

InfoQ：组织正在寻求产品规划及跟踪的更好方式。您能说一下吗？

\\

\

Zilberfeld:直到最近，组织都是在开发团队层面开始他们的敏捷之旅。Scrum、看板以及其他方式给与了我们规划和跟踪的方法。Scrum有现成的规划过程，包括发布、迭代以及每日工作。燃尽图和任务版可视化了状态以及查看分析是否到位，从而可提供良好的全局。例如，我与一个团队合作，他们持续地在一个迭代中交付60%的产品代办事项。幸运的是，我们只需要查看一下燃尽图，看到团队用稳定的速率工作，而他们花费太多的时间计划没有进入到迭代中的内容。

\\

看板提供了一个看板板，但这看似简单。如果我们应用看板原则“政策明确（Make Policies Explicit）”，我们可以追踪工作流程如何以及在哪里卡住了。如果我们创建累计流图（Cumulative Flow Diagram （CFD）），我们可以根据前置时间（Lead Time）和在线制品数量（WIP）提前规划。在这两种情况下，我们到底基于哪一个做规划，目前正在收集信息。这个好处就是在过程中有一些可预测性。如果我们应用精益原则，约束理论和排队理论可以通过可视化、识别瓶颈以及改进流程成倍地增加可预测性。

\\

搞清楚这部分的组织现在想要在组合管理上应用同样的原则。SAFe（一种规模化敏捷框架）为此提供了发布火车（Release Train），规模化看板是从开发团队到整个产品团队。这仅在最近几年才刚刚开始，因此比较明智的是慎重地把成功与失败的报告结果作为依据。参与的人越多，流程越复杂，并且可预测性开始遇挫。再次地，过程的可见性会带来较好的可预测性以及改进的能力。

\

\\

InfoQ：对于#没有估算，您有什么想法？

\\

\

Zilberfeld：当我第一次听说#没有估算的时候，听起来像开发人员想要从项目发起人那里争取得到更多的控制。我的意思是，难道为项目买单的人不允许在整个项目中得到一部分控制权吗？

\\

当我变得越来越感兴趣的时候，我问估算到底是做什么的。也许你对此答案并不惊讶：我们寻求可预测性！发起人想要估算，因为他们相信他们会帮助制定项目的最佳决策。哎，但并不总是这样。除了一些功能障碍，例如估算神奇地变成了承诺，或者估算通胀，我们并没有得到我们需要的工具。

\\

要求估算容易，但他们很少有所帮助。实际上，他们是基于成本，而非基于价值来驱动决策。当我们以成本驱动制定决策时，我们是降低风险，而不是创新。在这层意义上，估算限制了我们创建新事物、提供更强大解决方案的能力

\\

对于我来说，#没有估算变成了不仅是估算。如果决策在乎我们的估算，我们需要提供给他们，并提供其它因素，例如评估的复杂度以及历史数据。如果他们没有用，或者信心不足，那就不要投入太多。并且理所当然的，不管成本多少，开发同等的项目价值有时是值得的。

\

\\

InfoQ：如您提到的，估算就是有关成本，不是产品和服务可带来的价值。当我们做产品规划的时候，在讨论中可以做哪些事情把价值考虑进去呢？

\\

\

Zilberfeld：这很有趣，我们经常要求估算成本，从而用于制定决策，但我们几乎从不质疑价值。我们假设有人已经做好了正确的优先级排序。另一方面，我目睹过很多项目，在他们要求成本估算后，得到越来越庞大的数字，而项目依然前行。为什么？因为他们有足够的价值。

\\

价值估算和成本估算一样困难。然而，实践者可以用如延迟成本（Cost of Delay（CoD））的方法进行试验来进行功能和产品的价值估算。

\\

例如，让我们看一组选项：

\\

• 功能A可以卖得更多，从而赚更多钱。 \\
• 功能B可支持保留现有的客户。 \\
• 功能C可以增加我们快速添加更多功能的能力。 \

每一个功能都可以用真实货币来评估。我们可以估算，从功能A上期望赚多少钱，或者功能B，我们可以节省多少钱。现在我们问每一项的延迟成本是多少，然后可以进行比较。接着我们可以检查，从功能A的早期获利或者从功能B的节省上，先开发功能C对此的影响。

\\

一旦我们把所有功能都放在同一基准线上，并且估算每一项的价值，我们就可以决定先做哪个功能了。

\\

CoD及其类似的方法允许我们基于更多的信息做决定，而不仅是成本估算。

\

\\

InfoQ：产品开发涉及到很多决策制定。您可否给一些例子，通常是怎么做的？当制定类似决策的时候组织面临哪些挑战？

\\

\

Zilberfeld：我刚刚在ACE大会上做了一个演讲，名字叫“投资回报率（ROI）已死”，我谈到了产品经理从基于直觉到进行复杂的模拟来决定做什么。在项目组合层面，我们基于项目经理们告诉我们的内容制定许多决策。你可以说产品经理们是赌徒。不幸的是，就算你赌对了，产品也可能失败：一个好的产品会失败得很惨，仅仅是因为同一公司在两年前发布了很糟糕的产品，声誉变差，因此没有人会再看一眼新产品。

\\

所以组织面临的最大问题是复杂性。复杂性并不新鲜，它一直存在。但是在新的敏捷世界里，很难让我们忽视它。当旧的产品扼杀掉了新的产品，这就是复杂性。当我们遭遇了不可预知的事件，这是复杂性。它就是项目杀手，有时也是公司杀手。

\

\\

InfoQ：组织要怎么做才能改善产品开发决策？他们如何处理复杂性？

\\

\

Zilberfeld：不要忽视复杂性。相反，我们需要找到一种方式穿过迷雾而没有太多风险。我们需要假设我们在任意层面的无知，包括业务、开发和运营。一旦我们承认，难的部分就来了：我们需要改变工作方式。

\\

多年来，产品经理们定义产品，然后开发团队开发几个月。我们得到仅有的反馈就是当产品发布的时候。我们再也不能继续按照那种方式工作了。不要用几个月的周期，我们需要做没有风险的试验。不要对整个产品投100万美元，而是需要用1万美元看看它是否可以解决问题。如果我们对了，我们可以继续以增量式验证我们的假设。如果不对，我们则为公司节省了一大笔钱。

\\

当我与产品人员合作的时候，我总是缠着他们问他们对待办目录的价值有多少信心，包括问他们如何证实这些价值。如果信心不足，我们就计划一个短的试验，给到客户然后学习。如果对了，我们就继续。如果不对，我们就改变计划。

\

\\

查看英文原文：Q\u0026amp;A with Gil Zilberfeld on Agile Product Planning and Management