数据驱动的产品开发

数据驱动产品开发的需求

产品开发具有许多细微差别和依赖性。 发现或设想的每个产品开发周期或SDLC都不充分。 每种提出的解决方案都属于目前存在的众多陷阱之一，并被证明对产品寿命的一个或另一个阶段均无效。

SDLC从瀑布方法开始，该方法期望在设计开始之前列出所有要求，在任何编码开始之前完成设计，在测试开始之前完成编码等等。 这显然是不够的，因为在进行模糊测试并且产品开发变得越来越模糊时，什么也做不了100％。 将瀑布模型修改为迭代模型，以解决缺陷。 它尝试通过允许在出现问题的情况下返回到先前的步骤来纠正问题。 但是，这样做的明显问题是迭代可能发生在开发的任何阶段。 因此，您放下需求，设计，开始编码。 在编码过程中，有人提出了一个非常模糊的问题，这变成了冰山一角，您必须回到制图板上，重新从需求开始。 浪费了很多时间。 SDLC将自身校正为螺旋方法，V模型，敏捷方法，敏捷的Scrum方法，每种方法都有其自身的缺陷。

当前的常规方法是scrum或敏捷方法，但这有其自身的陷阱。 首次创建产品或首次添加增强功能时，需要考虑和设计大量功能 。 从产品开发的开始就不能零星地做。 您需要花费适当的时间进行思考。 如果您不花时间进行深思熟虑，那么您将拥有大量功能的拼凑工作，这些功能拼凑在一起就好像是一个整体。 以这种方式构建的产品会在非常脆弱的基础上站立，并且在基础受到挑战的那一刻必定会崩溃。 在没有经过深思熟虑和正确放置基础的情况下，基础受到挑战的机会非常高，而基础坍塌的机会甚至更高。 虽然Scrum方法及其史诗和故事对产品生命周期的后期阶段很有用，但在最初的开发阶段或主要的增强阶段并不理想。 应该认识到，如果产品开发周期中的大部分时间都用于错误修复和维护，而不是主要的新增强功能，那么该产品就将失败，因为此类产品的回报主要用于维护而不是真正的研发。

当然，我们可以继续修补SDLC，并在出现问题时不断进行修复。 但是，我认为，我们需要问自己一个非常简单的问题：“为什么SDLC花费了这么多年的时间和迭代，而我们却无法提出开发产品的全面方法？” 我认为是时候问这个问题了：“ 我们是否忽略了产品开发的某个阶段，而这是产品开发生命周期的一部分？ 当前的SDLC始终只包括以下五个阶段：需求分析，体系结构/设计，编码，测试和部署，但是可以安排，瀑布式，螺旋式，V式或短周期式。

但是，应该认识到，软件产品的生命周期不仅仅是纯粹的产品开发。 它是由各种不连续的周期组成的：产品营销周期，产品开发周期，客户参与度，支持周期等，它们被称为“产品理念”的抽象脆弱线程串在一起。 在当前的工作方式中，这些循环中的每个循环都被认为是独立的，并且遵循各自的过程。 应当理解，虽然这些周期中的某些活动可以同时运行，但是所有周期都紧密地联系在一起，更具体地说，与产品开发周期紧密地联系在一起。 我发现这是因为我们不认识这些问题并将其集成到产品开发周期中，而是不断遇到不断变化的或未知的需求，不断变化的UX设计或不断变化的功能设计的问题。 所有或所有这些方面的变化都需要纳入产品开发周期。

例如，产品开发必须轻松应对产品营销的变化。 在产品或功能的市场研究期间，有可能确定并确定了某个细分市场。 但是，随着营销周期的继续，可能已经出现了产品或功能很容易被第二个细分市场而非已确定的细分市场接受的情况。 如果这种更改没有反馈到产品开发周期中，并且更改立即被纳入，那么我们正在寻找大量的浪费。 产品开发还必须轻松响应客户参与周期的响应。 客户参与不能是仅在每个产品发布结束时发生的活动。 必须不断努力，使客户可以参与产品开发的每个步骤，以减少浪费。 如果需要减少浪费，则产品开发周期必须是产品生命周期的集成周期，而不是不同的周期。 这正是数据驱动的产品开发。

数据驱动的产品开发

数据驱动的产品开发如何工作？ 我们从最简单的产品周期开始：

在当前形势下，创建MVP，修改MVP或修改产品功能被认为是产品开发，一旦构想完成或分析完成，就开始了SDLC。 但是，正如我之前所说的，产品开发的各个阶段都是尽可能模糊的。 在构思和产品开发之间没有明确的界线，或者在研究产品统计信息并根据结果修改产品之间没有明确的界线。 您可以认为已经确定了所有主要功能，可以认为您已经探索了所有可能性并解决了大多数问题，但这仅是在思想和文档上。 在大多数情况下，它只需要质疑一个单一的假设或揭露一个单一的先入为主的观念，然后再暴露出该观念的一个全新层面，使您能够探索新的可能性。 当什么将打破阻碍您看不到新尺寸或不必要地分解整个特征的障碍时，无论如何都无法预测，这与未来一样未知。

在这样的环境中，停止产品开发并根据其自身的刚性周期开发某些产品对产品生命周期中涉及的任何人，无论是业务还是技术，都无法奏效。 要求产品开发周期与产品生命周期集成在一起，而不是作为一个单独的“开发产品箱”，可以将其单独产生并在开发完成之前将其遗忘。 产品开发需要细分为各个组成阶段，并且由于市场反应或与客户的互动而受到商业决策的变化影响的各个阶段的设计必须吸收变化的发生时间 。 尽管Scrum尝试使用短篇小说来做到这一点，但应该认识到，只是将工作范围分成较小的部分，而工作仍与以前相同，这不是解决方案，而是引入了其他问题。

应该认识到，产品周期的整合不能仅仅是纯粹的过程变更 。 应当接受的是，当我们谈论目标市场领域的变化或由于客户观念改变而引起的变化时，我们正在谈论从定义阶段到编码一直对产品开发的影响。 尽管产品的戒律可能保持不变，但此类更改通常意味着功能重点的更改，功能优先级的更改等，这会影响固有的产品开发重点。 这意味着产品设计和开发需要对营销周期和客户反馈具有高度的反应性 ，这与过程无关。 它是对产品的过程，体系结构和设计的彻底反思。

首先，最重要的是，产品必须固有地具有数据收集功能，以便能够有效地做出反应 。 这意味着不能将产品分析视为使用第三方分析工具来监视使用情况的事后补充。 从需求定义的开始就需要对其进行设计。 例如，如果定义的功能被认为是产品的非常基本的功能，则需要在定义需求时就考虑“ 什么将指示该功能不是基本的，而适当的监控”。跟踪假设的能力 ”。 举例来说，例如，在多渠道网络零售商的运输产品中，我们将基本特征确定为“跨渠道合并运输”。 作为验证该要求的数据点，进行研究的重要重点是“使用来自多个渠道的订单创建了多少个货运”。 仅添加分析以研究使用基于URL的监视创建了多少个货运就不能验证此要求。 在整个产品开发过程中，必须考虑此类数据监视需求，并内置相关的功能监视功能以验证思想和假设。

这有多种帮助。 使用合并的分析进行事实分析后的产品分析有助于重新考虑需求并重新定义产品功能 。 这种监视标识的另一个重要用途是，当输入来自市场研究或客户的信息时，它将有助于标识需要更改的功能。

在上面的示例中，例如，多渠道网络零售商的运输产品，我们可以假设跨所有渠道都使用了“普通库存”。 但是，通过调查或与潜在客户交谈可以发现，大多数客户的每个渠道只有多个库存集。 在这种情况下，添加功能以组合来自多个渠道的订单对客户而言效果不佳。 在这种情况下，我们可以很容易地查找所有我们添加了适当监视功能的功能，然后删除或适当修改它们。

因此，需要的是高反应性的产品开发周期 。 高反应性的产品开发周期是这样一个周期，它与产品生命周期的其他阶段相互作用，并且产品开发变型需要它们的输入。 下面：

应当指出，市场变化和客户反应几乎总是影响产品需求和设计，而很少影响代码。 但是，在我们所有的产品开发周期中，与产品设计相反，我们将大部分时间都花在了编码和测试上。

因此，为了能够快速做出反应， 必须将用于需求分析，架构和设计的时间最大化，从而只有绘图板设计在变化，而一旦我们知道设计或多或少地完成了，则是编写代码的时间，应尽量减少测试并将产品推向市场，以避免临时变更。

因此，产品开发中实现数据驱动型产品开发的两个最重要的变化是：一是将数据分析纳入产品开发生命周期的所有阶段（从需求阶段开始），二是将编码和测试最小化到最大可能并增加产品设计阶段达到最大，并快速推向市场。

翻译自: https://www.javacodegeeks.com/2019/06/data-driven-product-development.html