当您以可重复的、生产的方式开发软件产品时，您必须偶尔退一步，从长远的角度考虑问题，以便与客户恰当地讨论过程。我们最近也参与了这个活动，我认为分享一下我们为在线产品开发软件产品的方法是什么以及为什么会是有用的。

首先，有一个基本的想法告诉所有这些:

我们将“大爆炸”市场发布模式定义为:

• 一个黑箱项目，在这个黑箱项目中，人们预先做了大量工作，将需求文档整合在一起，这些文档对软件开发项目的特性和功能进行了深入的描述，通常持续12个月到2年。
• 在需求开发上花费的时间将为潜在的开发人员提供一个非常具体的产品视图，可以投标，将范围、成本和时间放在一起，并将持续整个项目。
• 发布后，详尽的功能列表有望推动市场采用，并超越现有的竞争对手。

这不同于封闭的盒子，快速的开发方法，有时也被称为“大爆炸”。在这种情况下，没有时间花在与用户或客户的规格或计划上。在“大爆炸”开发中，开发团队基于一个基本概念提出所有的特性和实现，然后离开，希望返回时能带来一些有用的东西。要说我们不是这种软件开发方法的信奉者，那就有点轻描淡写了。这是高风险和低回报，因为客户不完全了解他们想要什么或他们将得到什么。

相比之下，大爆炸市场发布的概念来自一个简单的想法，即一个产品只要存在于一个完整的愿景中，就可以创造一个市场，为一个可能从未存在过的概念吸引买家。在这种情况下指定软件产品开发是很棘手的。当这一概念被提出时，苹果一直是最成功的例子。那些想要创造市场，但又不能在内部完成整个产品开发的公司，非常明白他们需要减少在应用程序准备发布时实现其愿景失败的风险。通常，由于涉及到技术和创新，他们知道自己不能提供项目期间所需的深入技术监督。因此，在开发过程中不允许解释或适应，而是非常小心地写下非常具体的要求，并将其锁定。

不管那些有价值的目标是什么，这些项目还是失败了，因为:

• 随着项目复杂性和时间跨度的增加，在项目生命周期中控制范围变得越来越困难。预测精度会随着时间的推移呈几何级数下降——最终会产生一个只能在高水平上依赖的项目计划。
• 科技继续响应摩尔定律。需求开发花费的时间越长，项目进行的时间越长，在交付时满足市场期望的可能性就越小。在此期间，用户尝试了各种替代方案，他们的期望也随之改变。此外，当开发实际承担了功能集成的复杂性时，在一个长而复杂的项目开始时的技术假设并不总是有效的。因此，选择工具、框架或库乍一看似乎能解决很多问题，但在实践中可能会变成资源时间消失的黑洞。
• 无论需求有多详细——它们都受到两件事的限制:观点(盲人和大象的经典故事是共同的参考点)和最终用户对最终应用程序的实际反馈。无论最终用户对需求的反馈多么仔细，它都只有在他们对最终产品的愿景中才有价值。我们和其他人已经说过很多次了——如果你在20世纪初问人们他们想要什么样的个人交通工具——这些要求只会导致更好的马匹。需求很少能够正确地预测用户的需求，也很少能够以特定的方式交付它们的复杂性。需求变得越详细，风险实际上就越高——特别是在需求非常具体，以至于不能在开发过程的早期对最终用户的反馈做出响应的情况下。

那么，还有什么选择呢?

以“精益产品开发”为基础。我们已经将精益理念应用到软件产品开发中，并将其运用到多个项目和多个行业中:

精益软件产品开发

这些阶段和它们的目标可以这样分解:

• Sprint 0——在这个阶段,需求验证、技术选择是由详细(建筑、堆栈),用户故事是建立(我们使用敏捷开发技术——用户故事大致相当于用例),和用户体验(不仅仅是界面,用户如何使用产品)的方法是开发设置交互的标准。此阶段的结果是一组技术规范、个性(一定程度上的角色)，以及对每个故事进行工作评估的优先用户故事。
• Alpha版本——在此阶段，为关键终端用户构建底层框架并开发核心功能。这一阶段的要点是与应用程序的关键受众——执行最关键任务和使用应用程序最多的最终用户——验证产品愿景。这意味着核心终端用户需要实际尝试alpha版本。这通常需要客户合作伙伴——对于新供应商来说，这就需要进入市场并引入一些早期的采用者。其结果是降低了风险。与整个项目相比，此时的成本很低，因此仍然可以吸收变更，而不会损失开发代码的大部分和沉没成本。同样，在这一点上，开发团队执行客户愿景的方法可以尽早得到验证——这样就可以做出调整，客户和开发团队之间的信任也可以增强。这种方法遵循了Steve Blank提出的明智建议——早期用户验证的要点是“走出大楼”，尽早出现在用户面前，这样他们就可以在发生代价高昂的错误之前通知开发。
• Beta版本-这个阶段产生一个产品的市场版本的第一个版本。这个版本的范围被有意地限制在向最终用户交付价值所必需的范围，理解这一点很重要。换句话说——提供他们将使用和支付的东西。这是一个重要的评估，由主题专家的观点和来自Alpha版本的反馈提供信息。然而，问题是，无论视觉和反馈有多好，当产品触及市场中实际目标终端用户的许多不同上下文时，还会有额外的反馈。beta版本的发布还为供应商提供了内部操作的“启动”——对于大多数产品来说——支持、销售和市场营销。从测试版中获得的经验教训会通知到下一阶段，这样测试版采用者就会得到奖励(并被保留)，运营部门就会传递信息和服务来推动新客户和用户的采用。由于基于敏捷的发布周期的增量性质，在此阶段，产品之间的实际销售情况会有很大差异——但开发并不会停止。现在的变化是，随着新客户加入并参与测试，开发将更加直接地得到信息。在这一点上，一些公司比其他公司更积极地测试定价和营销——但一般的建议是尽早确定定价，并根据用户的感知价值进行测试。预期的结果不是直接调整价格，而是调整功能或包装，以更好地与感知价值保持一致。
• 市场发布——这一阶段标志着全市场产品的发布和“正常”产品增强的开始，以继续根据用户反馈增长功能。我们有时会添加一个阶段发展到市场释放本身是独立于β-但对于一般用途开发现在已经陷入一个增强模式,而不是全面发展,除非有一个显著的区别是什么计划发布测试版客户和广大市场。这一阶段的结果是通过目标用户的反馈、经过测试的业务操作，以及从“推出”产品到获得客户并持续增强特性和功能的关注点的转变，来得到产品。这不是终点——这只是一个“消费化”在线产品自然进化和“拉动”的开始。

这个过程的结果是:

• 尽早发布并从那些重要的人——该领域的实际付费用户那里得到反馈。
• 尽早确认愿景和需求都是产品交付价值和满足市场期望的结果。
• 降低前期风险，减少盈利时间。等待超过一年的时间才能将产品投放到市场上，让真正的用户使用，这无疑是一场灾难。进入市场，证明运营假设，在可行的情况下尽快启动现金流，是成功的关键。你越早进入市场，你就有越多的时间在你的初创公司的现金流耗尽之前调整你的现实。
• 简单——成功的几率更高，衡量标准是什么——采用、来自客户的现金流和留住用户。

然而，我们的一些客户面临着一个更困难的情况——他们在这个领域有一个已经存在的产品，开始时是传统的基于前提的产品，现在被拉向一种更动态的、在线的模式。这带来了一系列额外的问题:

• 如果开发周期很长，现有的客户可能会在完整的在线版本可用之前就跳槽了。
• 对现有产品的支持和维护可能会使产品团队的关键成员不堪重负，因为他们需要可用来塑造新产品。找到一个转折点，在不影响现有销售的情况下，可以有序地开始转型。

新方向提供了开发新市场、采用新定价水平和过渡到拉拽驱动的功能模型(而不是传统产品发布的推动)的机会，但时机是关键。对于一个满足垂直市场顶层需求的复杂产品来说，这是一个巨大的考验，而且坦白地说，很难分解成可管理的小块。

为了处理这个问题，我们有一个通用模型，它采用上面的新产品模板，并将其转换为一套产品的阶段性开发。在下面的图表中-你可以把每个蓝框看作是我们典型产品开发周期的改进运行:

 

渐进式开发一套在线软件产品

其中的主要步骤是:

• Sprint 0——一个完整的项目级需求、技术规格说明和特性分解，为整个项目奠定了基础——但没有锁定假设。这整个项目的重点就像以前一样，尽早推出产品，尽快得到反馈和现金流。这还包括对套件中的第一个产品的更详细的了解。
• Web增强——第一个产品发布的这一部分是可选的，但是值得考虑，这可以确保现有的客户能够长期留在公司，并尽早看到长远的愿景——因此，在产品的整个生命周期中，他们将成为反馈的关键。该产品采用的形式各不相同，但其理念是用特别适合Internet环境的特性来增强现有产品，并以以前由于内部版本的技术或固有限制而无法实现的方式对其进行扩展。
• 广泛的市场版本——为了能够得到早期的反馈并尽快进入市场，第一个产品需要是以前解决市场顶部问题的遗留产品中所表达的专业知识的一个集中子集。一般来说，这意味着提供一套能够为市场的第2层或第3层提供价值的特性。同样，我们第一次描述的典型产品发布的所有要点都需要在这个发布中实现，这样产品就能从目标市场的实际终端用户那里得到消息——而这恰好是供应商的一个新市场。
• 专业版——建立在与广泛市场版本相同的代码基础上，专业版的目标功能将满足70-80%的安装基础。这为迁移奠定了基础，并扩大了一组客户的潜在采用，他们将为产品交付的价值付出更多。这也标志着遗留支持和维护可以开始转向新的产品，并明显地转向新产品。
• 企业版本——同样，在相同的代码基础上，添加了企业功能，现在整个“产品套件”已经达到了在旧版本中从未达到的功能级别。用户是根据套件中的功能包来选择级别的——所以如果架构合适的话——在价格和包装上可能会有很大的变化，以满足不同市场的需求。

应该说，这里提出的时间框架是泛化的，并且会有所不同，但是——它们是基于开发应该集中于向最终用户交付有价值的特性的假设。在其他地方，只要可行，就应该遵循“少即是多”的简单规则，利用服务和框架。体系结构需要允许这些服务在需要的时候被使用，但是需要被替换，因为增长提供了降低服务成本的选项。还应该说，这种方法的特性和定制来自于对市场包和配置中角色可用的选择——而不是单独的版本。

现在，我承认这是一个很大的愿景，并且在任何情况下都需要吸收很多东西——无论是作为一个初创公司还是市场上有遗留产品的软件公司。这是我们看待软件产品开发方式的一个重大转变。它来自于我们自己在市场上反复发现的问题的经验。我不能说这是每个开发小组都能成功提供的方法。它取决于做出能够带来这些结果的明确选择，而不是含糊不清地采取折中措施。

你觉得怎么样?你能看到你的公司沿着这条路走下去吗?你能看到它的好处吗?让我知道…

 

原文：https://sciodev.com/blog/lean-software-product-development/

本文：http://jiagoushi.pro/node/1193

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【2245019】