軟件項目可行性分析定義

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/

軟件項目可行性分析定義

總結

以上是生活随笔為你收集整理的软件项目可行性分析定义_如何定义最低可行产品的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。