The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
我们所接手的每个软件项目都始于一个产品愿景文件。我们在思考阶段创建此文件。尽管该文件只有两页的英文文字，但其开发却是整个项目中最费心的任务。
有一些技巧和建议我想分享。
通常我们将产品愿景分为四个部分：产品陈述、利益相关者和需求、功能以及质量要求。
Product Statement
产品说明是一个段落的声明意图，向一个完全陌生的人解释这个产品是关于什么以及它的用途。它与 “电梯演讲” 非常相似。这个说明必须按照以下特定顺序回答这些问题：
“谁是客户？”
她想要什么？
现在市场上有什么提供？
现有报价有什么问题？
我们的产品将如何解决这个问题？
你应该在60个字以内回答所有这些问题。如果你需要更多的字数，那说明你对正在开发的产品的理解有问题。如果你能用20个字回答这些问题，你的产品将征服全世界。
顺便提一下，不要把产品声明和使命弄混，后者是对你的业务整体目标的更广泛宣言。你可能有一百种产品，但只有一个使命。例如，迪士尼说他们的使命是：”让人们快乐”。他们有数百种产品来帮助实现这一使命。每个产品都有自己的产品声明。
我发现这些文章很有帮助：The Product Vision, Agile Artifacts: The Product Vision Statement, The Art of Agile Development: Vision.
Stakeholders and Needs
这个部分必须列出所有对产品有影响（无论是积极还是消极）的人员。您的利益相关者名单可能包括：赞助商、开发人员、用户、竞争对手、政府、银行、网络托管提供商、苹果商店、黑客等。
列出正面和负面的利益相关者非常重要。如果你的产品将自动化一些例行的手动操作，别忘了因此会有人被裁员。无论你的产品有多“好”，总是会有一面“邪恶”的存在。iPhone的发明让数百万人开心，但也给诺基亚和黑莓带来了很多麻烦。最终发明一种癌症疫苗会让数百万人更健康，但也会让成千上万的肿瘤学家失业。我的观点是，任何项目都有正面和负面的利益相关者。
每个利益相关者都必须有一个需求清单。它们必须简单明了，比如“赚钱”、“增加利润”、“分享照片”或“托管网站”。
我建议为每个利益相关者定义一个或两个需求。如果超过三个，再思考一下—你真的了解你的利益相关者需要什么吗？
如果您满足所有积极利益相关者的需求并消除负面影响者，那么您的项目将被认为是成功的。
这篇来自SEBOK的Stakeholder Needs and Requirements文章会很有帮助。
Actors and Features
在这个部分，我们列出演员（与产品进行通信的实体）和他们使用的关键功能。这是对产品的功能需求的最抽象定义。它不需要详细，而是必须非常高层次和抽象。例如，我们与一个知名产品的互动可能用两行来描述：
User can post tweets, read tweets of his friends,
follow new friends and re-tweet their tweets.
一个陌生人能明白我们在谈论什么吗？绝对不行——什么是“推文”，“关注”意味着什么，什么是“转发”？这些问题在产品愿景文档中没有答案，但很明显，用户将有四个主要功能可用。所有其他功能将类似于这些功能。
Twitter 是一家价值数十亿美元的企业，拥有价值数百万美元的产品。然而，我们仅用两行文字就能够解释其主要特点。你应该对你的产品也做同样的事情。如果你不能将所有特点压缩到仅仅两三行中，那就重新审视一下你对即将开发的产品的理解。此外，阅读一下“特性膨胀困境”的相关内容。
每个角色必须至少有三个特征，但最多不超过六个。如果有更多特征，你应该进行分组。如果特征较少，要将它们细分为更详细的特征。
Quality Requirements
这个部分列出了所有重要的非功能性需求。任何产品可能有数百个质量要求，以及数百个功能。然而，产品愿景文档必须专注于最重要的要求。考虑一些例子：
Any web page must open in less than 300ms.
Total cost of ownership must be less than $5000/mo.
Mobile app must be tailored for 10+ popular screen sizes.
Mean time to recover must be less than 2 hours.
DB must be scalable up to 5Tb without cost increases.
保持需求可衡量（如这些示例中的每个需求）也非常重要。这一部分的每一行都是发给产品开发者的信息。他们会阅读这份文档以便理解项目赞助方最看重什么。例如，以下质量需求是无用的：“用户界面必须吸引人”，“网站必须快速”或者“系统必须稳定”。它们无法被衡量或测试。它们只会分散开发者的注意力。如果你无法对质量目标做出严格且可衡量的陈述，那就不要写任何东西。与其设定虚假或模糊的目标，还不如什么都不说。
请尽量保持本节内容简短。最多应包含六个质量要求。
Remove Noise
每个部分的长度不能超过二十行。即使您正在开发一款预算为五千万美元的谷歌杀手，您的Vision文件也必须尽量简短，仅为两页。
对于我的大多数客户来说，这是一项非常复杂且令人头疼的任务。他们通常会带着一份50页的文件来解释他们的商业理念，并列出所有重要的细节。我们只需要从这份文件中提取真正有影响力的信息。
产品愿景文档必须让读者保持在最高的抽象层次上。这个文档必须在开始到结束的时间内读完不超过一分钟。
如果你不能把它说得简洁明了——那就说明你对你的产品了解还不够深入。
Example
这是一个非常简单的“脸书杀手”产品愿景的例子。
```text Statement Facebook doesn’t allow users to purchase “likes”, our social network will have this.
Stakeholders and Needs Sponsor: to raise investments. Developer: to earn money by programming. Users: to share photos and purchase popularity. Bank: to make commission on every purchase. Government: to protect society against abusive content. Competitors: to wipe us off the market.
Actors and Features User can create account, upload photos, share photos, send personal messages, like other photos, purchase likes. Admin can ban user accounts, view summary reports, authorize credit card transactions, configure system parameters, monitor server resource usage. Bank can process credit card transactions.
Quality Requirements Any page must open in less than 300ms. Availability must be over 99.999%. Test coverage must be over 80%. Development pipeline must be fully automated. Interfaces must include web site and iOS/Android app. ```
Diplomacy
我们在Zerocracy的项目中遵循所有这些建议。您也可以在您的项目中使用它们，但请记住，定义产品愿景的过程可能非常痛苦。有时候，您可能会因为过于简化客户的“伟大”商业想法而冒犯他们。“真的吗？我愿意为一些令人惊叹的东西支付25万美元，而你告诉我你只用了十行代码？哼？”
为了解决这种情况，将客户的文档分为两部分。第一部分将适合放入产品愿景文档中；第二部分将被称为“补充文档”，其中包含了从客户那里获得的所有有价值的信息。在产品开发过程中，您可以随后使用这些文档。
但不要走捷径。不要让客户（或其他人）强迫您夸大产品愿景。文件必须非常简短和明确。
没有歌词，只有陈述。
附注：除了这一切之外，我们通常还会放置一个术语表。
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-06 at 18:00
