产品开发中如何优化产品价值？

您是否在开发对组织来说有价值的产品？如何判断产品是否有价值？

如果没有经常提出这两个问题，那么您可能忽略了产品价值方面的问题。

产品是目前工作所要达成的目的，是组建团队的原因。产品也是你选择Scrum的原因，所以，你必须要集中精力理解并提高产品价值。

第1步：培养产品思维而非项目思维

产品思维聚焦于创造有价值的输出。

如果开发的产品没有人想要或使用，那么产出就毫无价值。

作为一名以传统项目管理作为职业起点的PMP，我对项目思维模式非常熟悉。衡量项目是否成功的标准通常基于一个铁三角：在规定的时间和预算内交付所有预期功能。

Scrum不是以更快、更便宜的方式交付更多产品。

Scrum旨在频繁交付更高的价值。

通过交付更高的价值，可以为组织降低风险，并挖掘更多的可能。虽然仍然需要做项目预算和时间表，但更需要重视的是要确保开发的产品是适合的。以下几步将详细介绍如何做到这点。但是，培养产品思维是一个持续的过程，因为人们很容易重拾旧思维，尤其是在压力下。

当出现“项目状态”的对话时，请注意倾听发起对话的人的思维模式。如果对话只涉及项目完成百分比、项目预警、问题跟踪等问题时，你需要问一些强有力的问题把大家的焦点带入产品思维模式中。这里有几个例子可供参考：

我们如何验证有关用户需求/市场需求的假设？

我们对价值了解多少？如何通过价值指导产品决策？

从我们开始这个项目以来，用户/竞争环境发生了哪些变化？

Scrum团队里的PO（Product Owner）在培养产品思维模式方面扮演很重要的角色。

第2步：描绘宏伟蓝图

由于你是以迭代递增的方式开发产品，因此必须清楚地了解工作的方向和原因。这样可以帮你确定是否与公司目标保持一致并在需要的时候做出相应调整。

有许多方法可以帮助企业明确产品目标（产品愿景）及其背后的商业模式。产品愿景描述的是对产品的期望，向目标用户传达的是其主要价值定位。

宏伟蓝图还包括价值定位。期望中的产品会有许多的特点和功能。所以为了衡量价值大小，必须要定义产品中最重要的价值点以及如何判定你达到了预期目标。

虽然对价值的定义高度依赖于背景，但以下几种价值类型也可以考虑：

商业目标（如，客户转化率）

利润/收入（如，每位客户带来的收益、回头客）

节约成本（如，获客成本）

客户/用户增长率（如，新客户、市场份额、使用最新版本的客户）

功使用率（如，使用某项功能的客户、使用某项功能的时间）

现在，具体要做的就是明确价值定义及如何衡量价值。

第3步：价值实现

复杂问题的解决办法总会在你认真工作（不仅仅是分析和谈论）的时候出现，你可能会判定那些假设是错误的，也可以看出市场甚至是商业模式已经发生改变。

因此，必须在开发产品的时候让价值涌现。产品Backlog代表计划开发的产品及开发顺序。而通过产品Backlog的细化过程来使价值涌现时，需要注意3点：

将任务分解到足够小——以便更灵活快速地交付价值。一旦确定了愿景，就会有一些实用的方法来构建更高层次的细节。首先，可以确定实现愿景的关键业务结果或目标。然后，再确定交付预期结果所需的关键特征、功能或性能。

任务分解越细，灵活性越强，交付价值和验证假设的速度就越快。还有很多补充的方法和理念会对细节上的工作有所帮助（如需求地图和假设地图）。达到“中等水平”后，可以考虑尝试进一步分解PBIs（Product Backlog Items）的模式。

记住不需要提前分解每件事。随着时间推移，产品Backlog会出现，这个时候你可以根据你在迭代递增式开发中所学的知识对其进行调整。

理解价值一致性——以交付更大的价值。在产品Backlog中聚焦价值的另一种方法是确定预期结果。很多时候PBIs（Product Backlog Items）会说明产品预期特征和功能。那么，我们是不是可以转而更多地关注产品特征或功能的预期结果？有许多方法可以让PBIs聚焦在价值上，包括求用户故事（如果运用得当的话），假设驱动开发和A / B测试等。还可以在产品Backlog中为每一个PBI捕获价值作为元数据。这个元数据也许是以美元为单位的投资回报率（ROI），也许是步骤2中定义的价值定位的映射。

不断拉远推近——以确保可交付价值没有偏离。在检验和调整时，需要“拉远”以查看不同之处，然后再“推近”查看现在有什么不同以及需要如何调整。这就是如何验证学习的有效性，然后学以致用的方法。拉远推近的频率取决于产品开发的情况、市场中验证假设的频率以及业务变化大小。注意：PO（Product Owner）不会单独确定什么是有价值的，不会知道价值细分的最佳方式，也不会以书面形式完美地描述分解过程让大家理解。这就是为什么PO必须想方设法让他人共同参与合作，一起改进产品Backlog。

第4步：验证实际价值

现在一切准备就绪，可以开始评估实际价值。没有得到市场验证之前，价值只是一个假设。

产品发布之后才能精准获知产品的实际交付价值。通过获取经验数据，来确保知情决策所需的透明度。

实际价值与预期价值的比率是多少？如何有效地收集这些经验数据？开发团队通常可以提供一些将数据收集功能构建到产品中的方法。随着产品规模和复杂性的增加，还需要增加流程和工具来收集这些经验数据。

一旦有了数据，就可以分析走势。记住，某一时间点的数据并不能说明多少，整体走势更为重要。而且需要收集多种类型的数据，单一类型的数据并不能说明全局的情况，因为影响产品使用的因素通常会有很多（有些因素超出控制范围）。

在分析价值走势的时候，请思考这些问题：已经发布了哪些产品更改，这些更改何时以及如何影响价值，哪些因素超出了可控范围（例如，即使已经实现了预期会增加销售额的新功能，但股市下跌也会影响用户决策）

将实际价值的测量方式透明化。听取利益相关者的看法以及他们如何看待走势对产品改进方面的影响，而Sprint评审会议是听取意见的良好时机。

总结

经验主义引导你积极处理这些棘手的产品价值问题。对价值而言，它必须具有透明性，并且必须经常检验它的实际值，以便根据需要进行调整。就像开发出一款可运行的产品一样，想清楚要做什么同样复杂且具有不可预测性。所以要学会边做边学，根据所学知识做出决策。

总之，Scrum的核心不是我们开发了多少东西，而是通过频繁交付可运行产品为组织创造了多少价值。因此，Scrum也强调不断学习和适应，以便从产品中获取更多价值。

文章转载请注明出处。

想了解更多关于研发管理、敏捷相关的知识，可登陆【Worktile敏捷博客】查看哦～