软件项目可行性分析定义_如何定义最低可行产品

软件项目可行性分析定义

by George Krasadakis

通过乔治·克拉萨达基斯(George Krasadakis)

如何定义最低可行产品 (How to define a Minimum Viable Product)

从概念转变为正确定义的MVP (Moving from a concept to a properly defined MVP)

The Minimum Viable Product, although a properly defined term, means different things to different people. In fact, it is one of the most misused terms in the technology domain. It is often poorly referenced to describe a prototype, a demo or even the first deliverable of a project.

最低可行产品 ，尽管定义得当，但对不同的人意味着不同的意思。 实际上，它是技术领域中最被滥用的术语之一。 描述原型 ， 演示甚至项目的第一个可交付成果通常引用很少。

“In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product

“在产品开发中，最低可行产品(MVP)是具有足够功能的产品，可以满足早期客户的需求，并为将来的开发提供反馈。” — Minimum_viable_product

定义MVP (Defining the MVP)

Assuming you have this great idea, you need a method to start defining the product. More specifically, the subset of the product features that can serve your objectives with the minimum cost and risk. The following explains how to get from an idea to an MVP.

假设您有这个好主意，则需要一种方法来开始定义产品 。 更具体地说，可以以最低成本实现目标的产品功能子集 和 风险 。 以下内容说明了如何从构思转变为MVP。

识别您的用户 (Identify your users)

Set the context — think of the problem, the situation and the opportunity. Think of what is already available in the market dealing with the same problem. Identify and name the types of users involved and how they interact. Document your users, their needs, the problems they are experiencing, their expectations, and the best-possible experience they could have in your context.

设置上下文 -考虑问题，情况 和 机会。 想一想市场上已经可以解决相同问题的产品。 确定并命名所涉及的用户类型以及他们如何交互。 记录您的用户 ，他们的需求 ，他们遇到的问题 ，他们的期望以及他们在您的环境中可能获得的最佳体验 。

The Minimum in the MVP implies that you already have the big picture, you have the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and the big picture.

MVP中的最小值意味着您已经有了全局，您具有产品愿景！ 一个常见的错误是，当团队“轻松地”将一组“显而易见的”用例确定为MVP时，却没有清晰的产品愿景和全局。

Check also: How (and why) to write great User Stories

另请检查： 如何(以及为什么)编写出色的用户故事

作为用户思考 (Think as a user)

Having the big picture you need to apply a process to identify the smallest subset of functionality that serves a very specific goal. The goal is to satisfy your users. You also want to enable critical user insights and feedback. This feedback can improve the next iteration in your product development plan.

有了大局，您需要应用一个流程来识别实现特定目标的最小功能子集。 目标是满足您的用户。 你也想 实现关键的用户见解和反馈。 该反馈可以改善产品开发计划中的下一个迭代。

The big picture is the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of epic stories. Then iterate across all identified users and try to define user stories covering their needs and expected benefit/ gains.

全局是确定的所有用户类别中用户故事的超集。 创建大量史诗般的故事是一个好主意。 然后 遍历所有已识别的用户，并尝试定义涵盖他们需求和预期收益的用户故事。

Use a compact format as the one proposed in Scrum: as a <user> I want to <be able to perform an activity> so that <describe the gain>. You don’t have to worry about priorities at this stage. A good idea would be to name each story/ assign a compact title for easier classification and organization.

使用一种紧凑的格式，如Scrum中建议的那样： 作为<用户>，我希望<能够执行一项活动>，以便<记录获取收益>。 在此阶段，您不必担心优先级。 一个好主意是为每个故事命名/分配一个紧凑的标题，以便于分类和组织。

As soon as you have your product feature super-set, you need to review it to ensure that it defines a product (the P of the MVP). Search for continuity, homogeneity and complementarity among your user stories.

一旦您具有产品功能超集，就需要对其进行检查以确保它定义了产品( MVP的P )。 在用户故事中搜索连续性 ， 同质性和互补 性 。

As a result of this process, you may realize that more than one of the related products are referenced in your backlog and need to be separated. Or you may realize that there are significant gaps that need to be filled.

作为此过程的结果，您可能会意识到积压中引用了多个相关产品，因此需要将其分开。 或者，您可能会意识到有很多空白需要填补。

Again, think as a user. Use empathy to identify interactions, scenarios and stories that need to be included.

再次， 以用户身份思考。 使用同理心来识别需要包括的交互，场景和故事。

You need to also gather feedback so you can try to validate your stories and the product. You can gather feedback through expert advice, user interviews, formal or informal surveys or public domain references (for instance any reliable public domain statistics that can help you test your assumptions).

您还需要收集反馈，以便您可以尝试验证您的故事和产品。 您可以通过专家建议，用户访谈，正式或非正式调查或公共领域参考(例如，可以帮助您检验假设的任何可靠的公共领域统计信息)来收集反馈。

认为是企业家 (Think as an entrepreneur)

Thinking as a user is great. You can be creative and forget, for a moment, about real-world challenges such as technical and financial constraints. Your objective is to compile the product super-set of user stories to satisfy — or to even to excite — all the different types of your users.

作为用户思考是很棒的。 您可以发挥创造力，暂时忘记现实中的挑战，例如技术和财务限制。 您的目标是编译用户故事的产品超集，以满足甚至激发所有不同类型的用户。

Now it’s time to think as an entrepreneur. You need to start considering and documenting implementation costs, priorities, strategic advantages and differentiators against competition.

现在是时候考虑成为一名企业家了。 您需要开始考虑并记录实施成本，优先级，战略优势和竞争优势。

You need to estimate the development cost of each user story. You also have to quantify the expected value for the user along with the expected impact on the business: your business.

您需要估算每个用户故事的开发成本。 您还必须量化用户的预期价值以及对业务的预期影响： 您的业​​务 。

The logic to identify the right minimum subset can be complex — requiring estimates of all the above at the user-story level. For each user story (or Epic) you need to have at least the following:

标识正确的最小子集的逻辑可能很复杂-需要在用户故事级别对所有上述内容进行估算。 对于每个用户故事(或Epic)，您至少需要具备以下条件：

1. The complexity / cost associated / feasibility

1. 复杂性/相关成本/可行性

2. The expected value for the user

2. 用户的期望值

Estimates of the above dimensions could be on a numerical or ordinal scale. As soon as you have those estimations you can then rank your stories. Also plot them in a simple chart against complexity and expected value for the user.

上述尺寸的估计可以是数字或有序尺度。 一旦有了这些估计，就可以对故事进行排名。 还要在简单图表中针对复杂性绘制它们 和用户的期望值 。

Check also: How to become a great Product Manager

另请查看： 如何成为一名出色的产品经理

优先，排名，设定重点 (Prioritize, Rank, Set the focus)

At this point you can start prioritizing high-value, low-cost stories over lower value, costly ones. Be aware, though, of those natural, strong dependencies between product features.

此时，您可以开始将高价值，低成本的故事优先于较低的故事 价值，昂贵的。 但是，请注意产品功能之间的那些自然而强烈的依赖关系。

In many cases there are technical or procedural dependencies requiring certain features to be implemented first, although their cost is high and the expected user value low. These dependencies need to be identified and possibly visualized in the user stories mapping.

在许多情况下，存在技术或程序方面的依赖性，因此需要首先实施某些功能，尽管它们的成本较高且预期的用户价值较低。 这些依赖关系需要识别，并可能在用户故事映射中可视化。

Having the above for each of the features (user stories) of your product allows you to define your MVP as:

具备以上每种产品功能(用户故事)的功能，便可以将MVP定义为：

“… the minimum set of features (stories) ensuring a good-enough product experience driving increased user engagement that can secure the next product development cycle”

“……最少的功能(故事)集，可确保足够的产品体验，从而提高用户参与度，从而确保下一个产品开发周期”

You can sort your entire product backlog by dependency sequence (start with foundation). Then by the value for the user in descending order. Then by complexity and feasibility in ascending.

您可以按依赖关系顺序对整个产品待办事项列表进行排序 (从基础开始)。 然后按用户的值降序排列。 然后由复杂性和可行性提高 。

You can also combine budget constraints, team’s velocity and go-to-market strategy makes it ‘easy’ to identify the red-line of your to-be-proved Viable MP.

您还可以结合预算约束，团队的工作速度和上市策略，轻松确定待验证的可行MP的红线。

现实检查 (Reality check)

In reality though, this will be just a draft definition of an MVP. What is needed in an ideal scenario is feedback and validation of the features by real users via prototyping, focus groups, market research, competition analysis and related methods.

但实际上，这只是MVP的定义草案 。 在理想情况下，需要的是真实用户通过原型制作，焦点小组，市场研究，竞争分析和相关方法对功能进行反馈和验证。

The more input from real users, the more confident you can be that your product concept has all it takes to become Viable (which also assumes a great execution/ implementation/ launch).

实际用户输入的信息越多，您就越有信心使您的产品概念具备成为可行产品所需的一切 (这也假设执行/实现/启动很好)。

Check out this other article on how to define an MVP (among other things).

查阅其他有关如何定义MVP的文章 。

Thanks for reading!

谢谢阅读！

Images: pixabay

图片：

翻译自: https://www.freecodecamp.org/news/is-it-an-mvp-really-6657db743544/

软件项目可行性分析定义