易于使用的人工智能

by Turgay ?elik

由Turgay?elik

需求分析：如何使用這種易于啟動(dòng)的方法+一個(gè)案例研究 (Requirement Analysis: how to use this startup-friendly approach + a case study)

In our previous blog posts, we explained why we decided to develop the Badges App and how we evaluated the feasibility of our idea at OpsGenie:

在之前的博客文章中，我們解釋了為什么決定開(kāi)發(fā)Badges App以及我們?nèi)绾卧贠psGenie中 評(píng)估我們的想法的可行性 ：

Since we found that our idea is worth developing, the next step is analyzing the requirements.

由于我們發(fā)現(xiàn)我們的想法值得發(fā)展，因此下一步是分析需求。

Requirement analysis — a very well studied area of software engineering — is the process of determining user expectations for a product, or briefly defining the product scope. There are tons of available resources on requirements analysis methodologies, characteristics of good requirements and tracing requirements. Instead of repeating the literature, we are going to summarize the critical points in a startup thinking way.

需求分析是一個(gè)非常深入的軟件工程領(lǐng)域，是確定用戶(hù)對(duì)產(chǎn)品的期望或簡(jiǎn)要定義產(chǎn)品范圍的過(guò)程。 關(guān)于需求分析方法，良好需求的特征和跟蹤需求，有大量可用資源。 與其重復(fù)文獻(xiàn)，不如以一種新的思維方式來(lái)總結(jié)關(guān)鍵點(diǎn)。

We know, startup guys generally don’t like terms like “process”, “proof of concept”, “requirements”, “scope”, “schedule”, “design”, “documentation” or “maintainability”. Generally they are impatient and they just want to code and release. We accept that agility is vital in our world and we have to try, fail and recover fast. But benefiting from the heritage of the software world will help us on the way to success. The key point is keeping it agile.

我們知道，剛開(kāi)始的家伙通常不喜歡“過(guò)程”，“概念證明”，“需求”，“范圍”，“計(jì)劃”，“設(shè)計(jì)”，“文檔”或“可維護(hù)性”之類(lèi)的術(shù)語(yǔ)。 通常，他們不耐煩，只想編碼和發(fā)布。 我們接受敏捷性對(duì)我們的世界至關(guān)重要，我們必須嘗試，失敗和快速恢復(fù)。 但是受益于軟件世界的遺產(chǎn)將幫助我們邁向成功之路。 關(guān)鍵是保持敏捷。

Following a process is not an objective, it is a tool that helps us achieve our goals. So, let’s see how we can adopt classical approaches to our world in the context of requirements management.

遵循流程不是目標(biāo)，而是幫助我們實(shí)現(xiàn)目標(biāo)的工具。 因此，讓我們看看如何在需求管理的背景下對(duì)我們的世界采用經(jīng)典方法。

The Project Management Triangle is a model of the constraints of software management. Despite the fact that it is an old concept from the 1950's, I think it is still relevant.

項(xiàng)目管理三角形是軟件管理約束的模型。 盡管它是1950年代的舊概念，但我認(rèn)為它仍然有意義。

In summary, project management triangle says that the quality of work is constrained by the project’s budget, deadlines and features. There is a trade-off among these three constraints to achieve the necessary project quality. So we can say that software development is a multi-objective optimization problem.

總而言之，項(xiàng)目管理三角表示工作質(zhì)量受到項(xiàng)目預(yù)算 ， 期限和功能的限制 。 為了獲得必要的項(xiàng)目質(zhì)量，需要在這三個(gè)約束之間進(jìn)行權(quán)衡。 因此可以說(shuō)軟件開(kāi)發(fā)是一個(gè)多目標(biāo)優(yōu)化問(wèn)題 。

We don’t like to constrain ourselves by classical approaches, so let’s adapt the old Project Management Triangle to the new startup world. Recall the Startup Success Factors that we mentioned at Feasibility Analysis post.

我們不喜歡用經(jīng)典的方法來(lái)約束自己，所以讓我們將舊的項(xiàng)目管理三角形適應(yīng)新的創(chuàng)業(yè)世界。 回想一下我們?cè)诳尚行苑治龊筇岬降膯?dòng)成功因素。

Here is how we map these success factors to the classical project management triangle:

這是我們將這些成功因素映射到經(jīng)典項(xiàng)目管理三角的方法：

As shown in the table above, all startup success factors relate to various project management triangle constraints. Since these three constraints are in a trade-off, we can say that keeping the scope neat is vital for the success of a startup.

如上表所示，所有啟動(dòng)成功因素都與各種項(xiàng)目管理三角約束有關(guān)。 由于這三個(gè)約束是折衷的，所以可以說(shuō)保持范圍整潔對(duì)于啟動(dòng)成功至關(guān)重要。

To define a neat scope, we have to perform a good requirement analysis before starting the development. Please note that this does not mean we are going to perform a fully detailed requirement analysis just like defined in waterfall process. We are going to do it in agile way.

為了定義一個(gè)整潔的范圍，我們必須在開(kāi)始開(kāi)發(fā)之前進(jìn)行良好的需求分析。 請(qǐng)注意，這并不意味著我們將像瀑布過(guò)程中定義的那樣執(zhí)行全面詳細(xì)的需求分析。 我們將以敏捷的方式做到這一點(diǎn)。

需求分析技巧 (Tips for Requirement Analysis)

In this section, we will provide important tips that you should keep in mind:

在本節(jié)中，我們將提供您應(yīng)該記住的重要提示：

深入檢查替代/同類(lèi)產(chǎn)品 (Inspect Alternative/Similar Products In Depth)

As always, don’t reinvent the wheel. Check what others do to meet your objectives. Even you may end up realizing that your product does not seem to have business impact that you were thinking before.

與往常一樣，不要重新發(fā)明輪子。 檢查其他人為實(shí)現(xiàn)您的目標(biāo)所做的事情。 甚至您可能最終也意識(shí)到，您的產(chǎn)品似乎并沒(méi)有像您以前想的那樣對(duì)業(yè)務(wù)產(chǎn)生影響。

This is a good sign to pivot your idea. It may seem like a failure, but remember, we have to fail as fast as possible.

這是改變您的想法的好兆頭。 這似乎是一個(gè)失敗，但請(qǐng)記住， 我們必須盡快失敗 。

記錄您的要求 (Document your requirements)

You don’t have to use a requirements management tool such as IBM Rational DOORS. But a short, bulleted requirements document will help negotiate with the stakeholders.

您不必使用諸如IBM Rational DOORS之類(lèi)的需求管理工具。 但是，簡(jiǎn)短的項(xiàng)目符號(hào)需求文檔將有助于與利益相關(guān)者進(jìn)行談判。

讓您的(潛在)客戶(hù)保持聯(lián)系 (Keep Your (Potential) Customers In the Loop)

I think this is one of the most important things about requirements development. A capability that you think that is killer may not make sense to the customers.

我認(rèn)為這是需求開(kāi)發(fā)中最重要的事情之一。 您認(rèn)為致命的功能對(duì)客戶(hù)而言可能沒(méi)有意義。

To keep your potential customers in the loop, you have to follow an iterative approach. You can do this by shipping an initial version of your product — Minimum Viable Product (MVP) — and evolving it according to customer feedback.

為了使您的潛在客戶(hù)保持聯(lián)系，您必須采用迭代方法。 為此，您可以交付產(chǎn)品的初始版本-最低可行產(chǎn)品(MVP)-并根據(jù)客戶(hù)反饋對(duì)其進(jìn)行改進(jìn)。

For example, Amazon Web Services team utilizes this approach frequently. They ship a service with minimum capabilities and evolve it based on customer feedback.

例如，Amazon Web Services團(tuán)隊(duì)經(jīng)常使用此方法。 他們以最低的功能交付服務(wù)，并根據(jù)客戶(hù)的反饋進(jìn)行發(fā)展。

Another approach is to develop mock applications that just provide a dummy user interface (UI) to help potential customer to understand the product features and give feedback. You can use products like InvisionApp to produce these mocks.

另一種方法是開(kāi)發(fā)僅提供虛擬用戶(hù)界面(UI)的模擬應(yīng)用程序，以幫助潛在客戶(hù)了解產(chǎn)品功能并提供反饋。 您可以使用InvisionApp之類(lèi)的產(chǎn)品來(lái)生成這些模擬。

需求管理是一個(gè)連續(xù)的過(guò)程 (Requirements Management is a Continuous Process)

You don’t have to spend months for requirements analysis at the beginning of a project, and please don’t — it is not the agile way.

在項(xiàng)目開(kāi)始時(shí)，您不必花費(fèi)數(shù)月的時(shí)間進(jìn)行需求分析，請(qǐng)不要這樣做-這不是敏捷方法。

At the beginning, your objective is to define boundaries of the system, negotiate with the team and other stakeholders, and prepare the definition of the Minimum Viable Product. The requirements should be detailed or can even evolve during iterations of development.

首先，您的目標(biāo)是定義系統(tǒng)的邊界，與團(tuán)隊(duì)和其他利益相關(guān)者進(jìn)行談判并準(zhǔn)備最小可行產(chǎn)品的定義。 需求應(yīng)該是詳盡的，甚至可以在開(kāi)發(fā)的迭代過(guò)程中不斷發(fā)展。

分組您的要求 (Group your requirements)

After you create a list all of your requirements, group them (divide and conquer) to form sets of related features. Grouping requirements to feature groups will ease your life during development phase and even it can help you to define bounded contexts, microservice architectures, and so on.

創(chuàng)建所有需求列表之后，將它們分組(分而治之)以形成一組相關(guān)功能。 將需求分組到功能組將簡(jiǎn)化您在開(kāi)發(fā)階段的工作，甚至可以幫助您定義有限的上下文 ，微服務(wù)體系結(jié)構(gòu)等。

考慮UX (Think About UX)

It is not necessary to say that User Experience (UX) is a very important factor in the success of a product anymore; today it is so obvious. But we have to still remind that User Experience is not just about fancy User Interfaces.

不必說(shuō)用戶(hù)體驗(yàn)(UX)成為產(chǎn)品成功的一個(gè)非常重要的因素； 今天是如此明顯。 但是，我們?nèi)匀槐仨毺嵝延脩?hù)體驗(yàn)不僅僅是花哨的用戶(hù)界面。

As the name implies, it is all about the “experience” and it is hard to improve a system’s UX after it is developed.

顧名思義，這一切都與“體驗(yàn)”有關(guān)，開(kāi)發(fā)系統(tǒng)后很難改進(jìn)其用戶(hù)體驗(yàn)。

Think about UX starting from requirements analysis, it could even be a motivation during the feasibility analysis phase to develop a new product if available alternatives in the market lack good UX.

從需求分析開(kāi)始考慮用戶(hù)體驗(yàn)，如果市場(chǎng)上的可用替代品缺乏好的用戶(hù)體驗(yàn)，那么甚至可能是在可行性分析階段開(kāi)發(fā)新產(chǎn)品的動(dòng)機(jī)。

User Experience affects the business requirements. For example, if you are developing an e-commerce application, designing a fast responding customer support system is about improving the User Experience.

用戶(hù)體驗(yàn)會(huì)影響業(yè)務(wù)需求。 例如，如果您正在開(kāi)發(fā)電子商務(wù)應(yīng)用程序，那么設(shè)計(jì)一個(gè)快速響應(yīng)的客戶(hù)支持系統(tǒng)就是要改善用戶(hù)體驗(yàn)。

盡可能不了解實(shí)施技術(shù) (Be Agnostic of Implementation Technologies As Much As Possible)

Of course this is not applicable if you are developing an infrastructure or a library for a specific technology :)

當(dāng)然，如果您正在為特定技術(shù)開(kāi)發(fā)基礎(chǔ)結(jié)構(gòu)或庫(kù)，則此方法不適用：)

Don’t fall into “If all you have is a hammer, everything looks like a nail” trap. Find new tools and utilities instead of limiting product capabilities to the technologies that you are familiar with or that you enjoy playing with.

不要陷入“如果只有錘子，一切看起來(lái)都像釘子”陷阱。 查找新的工具和實(shí)用程序，而不是將產(chǎn)品功能限制為您熟悉或喜歡使用的技術(shù)。

In enterprise companies, requirements analysis is generally performed by non-software engineers who are generally known as business analysts or systems engineers. This separation has some disadvantages, especially in terms of transferring requirements to development teams, but I think it also has some advantages.

在企業(yè)公司中，需求分析通常由通常稱(chēng)為業(yè)務(wù)分析師或系統(tǒng)工程師的非軟件工程師執(zhí)行。 這種分離有一些缺點(diǎn)，特別是在將需求轉(zhuǎn)移到開(kāi)發(fā)團(tuán)隊(duì)方面，但我認(rèn)為它也有一些優(yōu)點(diǎn)。

In my opinion, the biggest advantage of independent analysis teams is that they are agnostic of the technologies that will be used during development.

在我看來(lái)，獨(dú)立分析團(tuán)隊(duì)的最大優(yōu)勢(shì)是他們對(duì)將在開(kāi)發(fā)過(guò)程中使用的技術(shù)不可知。

But in the startup world, most probably as a team member (or even as a founder), you have to wear multiple hats: analyst, developer, hiring manager, or even more interesting roles that you were not imagining when you get in this path. So, if you are wearing the analyst hat at the moment, try to be agnostic of the technologies that you are planning to use during implementation.

但是在創(chuàng)業(yè)世界中，很可能作為團(tuán)隊(duì)成員(甚至是創(chuàng)始人)，您必須戴上多個(gè)帽子：分析師，開(kāi)發(fā)人員，招聘經(jīng)理，或者甚至更有趣的角色，而當(dāng)您走上這條路時(shí)。 因此，如果您現(xiàn)在戴著分析員的帽子，請(qǐng)不要理會(huì)計(jì)劃在實(shí)施過(guò)程中使用的技術(shù)。

We consistently hear expressions like “but Spring Framework does not support …” and “This causes a lot of work on the front-end” during requirement analysis.

在需求分析過(guò)程中，我們始終聽(tīng)到諸如“但Spring Framework不支持…”和“這在前端導(dǎo)致大量工作”之類(lèi)的表達(dá)。

Considering these kind of limitations at the start degrades the quality of the end product. Let’s define the ultimate capability and evolve it during development if necessary.

一開(kāi)始考慮這些限制會(huì)降低最終產(chǎn)品的質(zhì)量。 讓我們定義最終功能，并在必要時(shí)在開(kāi)發(fā)過(guò)程中對(duì)其進(jìn)行發(fā)展。

Ultimate capability is the final goal to reach, you can implement a more simple form of it when you start and evolve it in future versions. But knowing the point that we want to reach will help us to define our vision for the growth of the product.

最終功能是最終的目標(biāo)，您可以在開(kāi)始并在將來(lái)的版本中進(jìn)行擴(kuò)展時(shí)，以更簡(jiǎn)單的形式實(shí)現(xiàn)它。 但是，知道我們要達(dá)到的目標(biāo)將有助于我們確定產(chǎn)品增長(zhǎng)的愿景。

For example, think about “pinch-to-zoom” capability of mobile phones. It seems like a trivial capability but it was a revolution when Steve Jobs first demonstrated it. If the designers of iPhone didn’t think out-of-the-box and stuck to the available technologies and methods, we would not have this great functionality today. We know that it is an exaggerated example, but the main point is, don’t let the technology you would like to use limit you, you can move to other technologies if this will help you to create a niche product.

例如，考慮一下手機(jī)的“縮小縮放”功能。 這看似微不足道的功能，但這是史蒂夫·喬布斯(Steve Jobs)首次展示它時(shí)的一次革命。 如果iPhone的設(shè)計(jì)師沒(méi)有開(kāi)箱即用的想法，而是堅(jiān)持使用可用的技術(shù)和方法，那么今天我們就不會(huì)擁有如此強(qiáng)大的功能。 我們知道這是一個(gè)夸張的示例，但要點(diǎn)是，不要讓您想使用的技術(shù)限制您，可以使用其他技術(shù)來(lái)幫助您創(chuàng)建利基產(chǎn)品。

徽章應(yīng)用程序的需求分析 (Requirements Analysis for Badges App)

We performed requirements analysis according to the practices that we summarized above:

我們根據(jù)上面總結(jié)的實(shí)踐進(jìn)行了需求分析：

• We defined an initial set of requirements
  我們定義了一組初始要求
• We shared the requirements with our initial customer — The OpsGenie team — and updated the requirements according to the team’s comments.
  我們與最初的客戶(hù)OpsGenie團(tuán)隊(duì)共享了需求，并根據(jù)團(tuán)隊(duì)的評(píng)論更新了需求。
• At OpsGenie, we use Atlassian’s JIRA for issue tracking. To track the requirements, we created an issue with “New Feature” type for each requirement in JIRA.
  在OpsGenie，我們使用Atlassian的JIRA進(jìn)行問(wèn)題跟蹤。 為了跟蹤需求，我們?yōu)镴IRA中的每個(gè)需求創(chuàng)建了一個(gè)“新功能”類(lèi)型的問(wèn)題。

• We grouped related requirements with JIRA Epics. Some of our epics are User Operations, Group Operations, Badge Operations, Endorsement and 3rd Party Tool Integration.

  我們將相關(guān)需求與JIRA Epics進(jìn)行了分組。 我們的一些史詩(shī)是用戶(hù)操作，組操作，徽章操作，背書(shū)和第三方工具集成。

• In further steps of development, we created detailed issues for daily tasks, as Agile practices recommend. We linked each task with one or more requirements to keep traceability of development activities with requirements.
  在進(jìn)一步的開(kāi)發(fā)步驟中，我們按照敏捷實(shí)踐的建議為日常任務(wù)創(chuàng)建了詳細(xì)的問(wèn)題。 我們將每個(gè)任務(wù)與一個(gè)或多個(gè)需求相關(guān)聯(lián)，以保持開(kāi)發(fā)活動(dòng)與需求的可追溯性。
• Each epic contains a set of requirements (such as a New Feature), Development Tasks, and Bugs.
  每個(gè)史詩(shī)都包含一組要求(例如新功能)，開(kāi)發(fā)任務(wù)和錯(cuò)誤。

Want to follow our Badges app, or better, recommend new features and help us refine it? Join Badges App community!

想要關(guān)注我們的徽章應(yīng)用，或者更好地推薦新功能并幫助我們完善它？ 加入徽章應(yīng)用社區(qū)！

Further reading:

進(jìn)一步閱讀：

Badges App: OpsGenie’s Response to Skill Tracking and Management ChallengesAs we see skill tracking and management as a crucial task for the healthy growth of our company, we invested in a…engineering.opsgenie.comHow Did We Decide That Our New Product Idea Is Feasible?So, we have a new product idea, and we think that it’d be “useful,” “great” and further, “It will make the world a…engineering.opsgenie.com

徽章應(yīng)用程序：OpsGenie對(duì)技能跟蹤和管理挑戰(zhàn)的React當(dāng) 我們將技能跟蹤和管理視為公司健康成長(zhǎng)的關(guān)鍵任務(wù)時(shí)，我們投資了…… engineering.opsgenie.com 我們?nèi)绾螞Q定我們的新產(chǎn)品理念是可行？ 因此，我們有一個(gè)新的產(chǎn)品構(gòu)想，我們認(rèn)為這將是“有用的”，“偉大的”，并且進(jìn)一步說(shuō)，“它將使世界成為……工程。opsgenie.com

翻譯自: https://www.freecodecamp.org/news/how-to-analyze-the-requirements-of-a-new-product-a-startup-friendly-approach-and-a-case-study-833970e5c36c/

易于使用的人工智能

總結(jié)

以上是生活随笔為你收集整理的易于使用的人工智能_需求分析：如何使用这种易于启动的方法+一个案例研究...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。