开发如何需求分析,校本课程开发需求分析

需求分析与产品开发之间的根本区别是什么？一定的不确定性。不确定性程度决定了是否需要进行需求分析。

为什么预先知道不确定程度很重要？

假设三种情况（大部分产品开发过程中都会经历这三种情况）。在每种情况下，我们产品团队都需要进行数据跟踪，以便更好地了解用户的注册情况并最终提高注册转化率。让我们看看当我们改变不确定性的程度以及改变处理不确定性的方法时会发生什么。

方案1：确定环境中的执行

比如：创业公司新开发一款APP，通常会将注册量作为指标，而作为产品负责人，我们就需要分析分析每一个用户行为以提高注册转化率。一般有经验的产品经理，都会对提高注册转化率有很丰富的经验。能分析跟踪数据并从中提出有价值的见解的看法。

根据以前的经验，我们对所涉及的步骤具有相对的把握，并且对任务将花费多长时间有了很好的了解。如果CEO表示，他希望在两周内完成注册数据跟踪。我们会制定了一个相当详细的计划，并非常准确地估计需要三个星期。我们可以证明为什么需要花费额外的一周，并且可以对CEO承诺在一定期限内完成任务。

由于整个项目的不确定性较低，因此我们产品团队可以立即开始工作。去实施注册数据跟踪，并在截止日期之前完成注册转化的渠道分析。

我们实现了目标并为公司创造了价值。我们与管理团队建立了信任，这不仅仅是因为我们达到了目标而已，还是因为我们在达到目标的过程中，展现了对时间的把握。我们创建了一个计划，该计划可以用作管理团队的可靠锚点，以跟踪团队朝着正确方向的进度。

总的来说，预测未来是困难的-但上述情况并非如此。

为什么？

因为不确定性较低，我们知道所有不确定因素以及如何确定成功，我们可以对实现目标需要交付什么以及何时可以实现做出正确的预测。结果，我们团队无需花费大量时间去探讨该如何进行工作。

当面对不确定性的程度很低时，我们很容易朝着自己的目标迈进。

方案2：不确定环境中的执行

当我们很少或根本没有完成任务的经验，会发生什么？在这种情况下，我们无法确定地说出涉及哪些步骤以及将花费多长时间。

当CEO要求您在两周内完成注册数据跟踪时，我们会感到有压力，因为要遵守这一期限，我们首先要写连自己都不确定的需求，然后将其交给开发工程师，工程师很有可能也难以理解这个需求。

然后随着截止日期的临近，我们意识到自己不会成功，然后就拼命的去熬夜试图挽救这个项目，我们会对现在不可能完成的任务感到沮丧和愤怒，士气低落。

最后，不仅注册数据跟踪分析的不完整，而且CEO也会不高兴，我们也失去了团队的信任。

我们可能面临高度不确定性，这可能是由于缺乏经验或技术知识所致。但是致命的缺陷不是我们缺乏经验，而是缺乏需求分析，没有评估需求的时间周期。相反，我们应该提前进行需求分析，至少要检查技术可行性，而不是直接从执行开始。

如果产品目标更加复杂（例如要我们改进百度的搜索结果，使用户获得更相关和个性化的结果）会怎样？

在这种情况下，也许没有人真正了解用户想搜索什么。或者没有人知道如何构建一个可以为数百万用户进行个性化的搜索引擎（技术可行性的高度不确定性）。这项工作可能要花费数月甚至数年，而且如果执行不当，没有产生实际效益，很容易打击人的信心。

方案3：在不确定环境中先进行需求分析

让我们探讨在执行阶段之前，面对不确定性进行需求分析时可能发生的情况。

我们回到团队，并对我们期望的数据进行用户分析的讨论。团队中的每个人都有机会发表他们确定的事情（从过往经验中）和不确定的事情（没接触过）。

然后，我们开始写下认为对实现目标至关重要的所有假设。根据重要性和不确定性程度评估假设。

我们会很快发现产品可行性是最大的未知因素，对成功至关重要。但是我们对如何为移动平台实施注册数据事件跟踪了解得很少。因此，我们决定进行产品调整，这大约需要一周的时间。

四天后，我们团队已经对产品可行性有了很好的了解，因此我们估计可以在三到四个星期内达到目标。

我们将其传达给CEO，团队便能够按照承诺实施注册数据跟踪。

这一共花了四到五个星期，但是每个人（无论是领导层还是团队）都对我们的处理方式感到非常满意。

这对我们的日常生活意味着什么？

注册数据跟踪是一个简单的示例，但是我们可以将相同的思维模型应用于所有目标。如果我们面临太多不确定性，则不应该直接开始去构建产品解决方案。

相反，应退后一步来了解不确定性的根源，并做出相应行动来证明是为了实现我们的目标。

在产品管理中，我们将这些行动总结为需求分析。在最佳情况下，我们可以将不确定性降低到可以开始构建解决方案的水平，来使我们更接近实现目标。或者，我们找不到任何理由来证明可以实现我们的目标的时候，可以在没有大量投资的情况下尽早停止。

这两种情况都是成功的，可以节省团队宝贵的时间并减少挫败感。

总而言之，不确定性程度决定了我们是否可以直接进行产品开发，还是需要先退后一步进行需求分析来证明我们可以进行产品开发。能够识别处于低不确定性或高不确定性的环境，对于实现目标的成功和效率有很大的不同。

评估不确定性并采取正确的措施

评估不确定性程度的一些实用策略和减轻风险的策略。

不确定性规则

不确定性规则的目的：帮助我们评估最大不确定性的地方。

马蒂·卡根（Marty Cagan）在他的《启示录：打造用户喜爱的产品》一书中谈到了四种不同类型的风险：

1. 价值风险–人们会购买/使用它吗？
2. 可用性风险–人们可以弄清楚如何使用它吗？
3. 可行性风险–在我们现有的技术条件下，能否成功开发出产品？
4. 商业可行性风险–解决方案能否创造商业价值？

在确定要开发产品之前，问问自己这四个问题，是否已经足够清晰。

如果我不知道所提出的解决方案对用户是否有价值，那么我需要进行需求分析以更好地了解用户所面临的问题以及他们真正的需求所在。

如果从用户的角度来看我不知道所提议的解决方案是否可用，那么这也会造成不确定性，在开始构建解决方案之前，应该通过可用性测试来解决这些不确定性。

实际上，对这四种风险的思考会引发了很多更为详细的问题，这些问题有助于量化我们在开发新的产品时面临的不确定性程度。这些详细的问题构成下面的问题。

请记住，这些问题会根据我们当前的目标去调整程度，而不是一成不变。

尝试回答每个问题，并以1到10的等级对我们的确定性进行评分，其中1表示“我对这个问题有100％的把握”，10表示“我只是在猜测”。可能永远不会百分百确定任何事情，所以我们将收集大量的定性或定量数据来支持我们的主张。我建议我们不仅要给问题打分，还要写下详细的描述-描述用户或用户群，即我们要解决的确切问题。

如何处理计分的分数？

如果我们和我们的团队将每个答案标记为3或以下，则表明我们对自己的方向具有高度的确定性，可以开始进行产品开发。开发过程中我们能仍然会发现新的问题，但是我们需要一边调整一边去适应它-这就是我们使用诸如Scrum的敏捷方法的原因。

标记为4或以上的答案表示我们应该进行需求分析以减少不确定性的地方。在此阶段，最好找出正确的做法，而不是致力于结果。

一旦确定了需要进一步理解的地方，就需要引入另一个变量条件：影响程度。

我们可以把评分为4或更高的每个问题都可以视为假设（因为不确定）。

如果我们仅有一个假设，则可以跳过引入这个变量，直接进行实验。但是，如果我们确定自己面临的不只是一个假设，则必须优先考虑最关键的目标假设。通常，产品创建过程中假设的优先级为：用户->解决方案->资金->规模。

假设我们已经确定了在做正确的事情方面不确定性高的两个方面–最重要的用户利益和所建议解决方案的可用性。

谈到对当前目标的影响时，我们觉得至少在产品初期过程的这个阶段，确保用户利益比可用性更重要。因此我们觉得用户利益的影响很重要，而可用性相比而言就没那么重要。所以让我们填一下影响程度的分数：

接下来，将我们的假设绘制在下面XY轴上，其中x轴描述对目标的影响，y轴描述我们面临的不确定性量。我们的示例如下所示：

在着重于可用性假设之前，我们应该着重于证明有关用户利益的假设。通常，我们应该从不确定性和影响都很大的地方开始。

有了一个优先级的假设列表，可以将其用作设计和进行实验的起点。

设计和进行实验

下一步是将我们的假设按照优先级转换为实验。根据假设的性质和业务环境，实验可能会大不相同。我们要经历很多最佳实践，从用户研究，到灰度测试，到可用性测试等等，都需要一步步的来。

回到我们的案例，那么现在的目标是设计一个经济高效的实验来降低实验风险。该实验应通过收集数据点来增加我们的信心，并使我们清楚地制定出最重要的用户利益。然后，可以关注可用性问题以及如何创建一个新的具有成本效益的实验，以降低围绕该假设的实验风险。

同时要为自己设定个具体的时间周期，例如：两周后，希望收集足够的证据以继续进行此工作。这在可以进行大量生成实验的早期阶段特别有用。设定自己的时间周期，去评估为一个特定的想法需要投入多少时间和精力。

我们可以并且应该在必要时重复执行所有三个步骤，尤其是当我们拥有新问题时。但是，一旦我们对所有重要因素都建立了足够的清晰度，就应该开始提供产品解决方案。

结论

创新意味着不确定性，但是适当地管理它会带来很大的不同。能够识别我们要处理问题的不确定性程度，可以使我们更加成功和高效地实现目标。如果现在将整个案例简化为一种产品原理，那么就是这样：如果我们面临的不确定性太大，请从需求分析而不是产品开发开始。

我希望这种结构化的方法对我们有所帮助，并在需要决定是开始构建产品，还是退后一步以找出适合我们的用户和企业的建议时为我们提供一些帮助。

#专栏作家#

lennon，微信公众号：张论（ID：woshipm123），人人都是产品经理专栏作家。关注新零售电商、供应链金融的产品经理，擅长产品设计与需求分析。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash ，基于 CC0 协议。