产品经理产品文档_您的产品文档是否足够？

产品经理产品文档

Βethan

thanthan

In the real world, when we buy a phone, or a microwave or a washing machine, it comes with a quick start guide, a user guide, some technical documentation, and other similar stuff.

在现实世界中，当我们购买电话，微波炉或洗衣机时，会附带快速入门指南，用户指南，一些技术文档以及其他类似内容。

Without these documents, we’ll have to learn how to use the product leveraging solely on the ‘trial and error’ method – which is not a pleasant user experience at all.

没有这些文档，我们将不得不学习如何仅凭“尝试和错误”方法来使用产品-这根本不是令人愉快的用户体验。

The same is true for the products and tools made from web developers.

Web开发人员生产的产品和工具也是如此。

In the last few years we have witnessed huge explosion in the web development world.

在过去的几年中，我们见证了Web开发领域的巨大爆炸。

There are a vast variety of great projects out there. A deluge of plugins, libraries, frameworks, tools, and services have been created by smart people showing great insight and skill.

那里有各种各样的伟大项目。 精明的人创建了大量的插件，库，框架，工具和服务，这些人显示出深厚的洞察力和技能。

But there is one problem: many — perhaps most — lack of good documentation. No matter how great is a particular product might be, if it has poor documentation, we’re unlikely to use it fully and properly.

但是有一个问题：很多(也许大多数)缺乏好的文档。 不管某个特定产品的性能如何，如果文档质量不佳，我们都不太可能充分正确地使用它。

The goal of this article is to address the importance of having a good documentation both for the web developers, and for the users.

本文的目的是解决为Web开发人员和用户提供良好文档的重要性。

I mainly target programming products such as code libraries, plugins, and so forth, but all said below can be easily adapted to any kind of product or service. The principles are the same.

我主要针对编程产品，例如代码库，插件等，但是下面所述的内容可以很容易地适用于任何种类的产品或服务。 原理是相同的。

Let’s see them.

让我们看看他们。

取得巨大成功的三个步骤 (The Three Steps to the Great Success)

In the web development world there are three steps leading to great success.

在Web开发世界中，三个步骤可带来巨大成功。

1. Creating great product. First and foremost, you need to have something useful and valuable to propose to the people out there. It can be a product or a service, but in either case it must be of great quality.

   创造伟大的产品 。 首先，您需要提供一些有用且有价值的东西来向人们推荐。 它可以是产品或服务，但无论哪种情况，都必须具有高质量。

   Another important factor is the ease of use. Even a great product will bleed its value, if it’s difficult for people to use it. Completing this first step is a great milestone, but you must not stop here as some web developers do.

   另一个重要因素是易用性。 如果人们难以使用它，那么即使是优质的产品也会失去其价值。 完成第一步是一个伟大的里程碑，但是您不能像某些Web开发人员一样在这里停下来。

2. Writing great documentation. The second step is to write documentation for your product or service. Just imagine that you are in a beautiful but unknown country.

   编写出色的文档 。 第二步是为您的产品或服务编写文档。 试想一下，你在一个美丽而未知的国家。

   In order to see its sights you’ll need a guide to learn where they are, and a map showing you how to get there. The guide and the map from this example are much similar to your product’s documentation.

   为了查看其景点，您需要一个指南来了解它们的位置，以及一张向您展示如何到达那里的地图。 该示例中的指南和地图与您的产品文档非常相似。

3. Offering great support. Lastly, you need to offer genuine support for your product or service. Even with a good map and a proper guide at your disposal, there will be occasions where you’ll need guidance from real person to show you the right direction.

   提供大力支持 。 最后，您需要为您的产品或服务提供真正的支持。 即使有好的地图和适当的指南可供使用，在某些情况下，您仍然需要真实人物的指导才能向您显示正确的方向。

   That’s what support is all about. If you’re done the previous two steps well then doing this one will be much easier.

   这就是支持的全部内容。 如果您顺利地完成了前两个步骤，那么执行此步骤会容易得多。

Given the above three steps we can easily deduce the magic formula for great success:

鉴于以上三个步骤，我们可以轻松地得出成功的神奇公式：

出色的产品+出色的文档+强大的支持=成功 (Great product + Great documentation + Great support = Great success)

Simply enough, right?

很简单，对吧？

为什么需要好的文档？ (Why Do You Need Good Documentation?)

Sailing “Footprints: Real to Reel” (Ronn ashore)

航行“脚印：从实到卷”(罗恩上岸)

Good documentation does two important things.

好的文档可以做两件事。

On one hand, it adds value to your product. A well-documented product is always preferred to that with poor documentation; because it’s more complete, easier to use, and thus, far more useful.

一方面，它为您的产品增值 。 具有良好文档记录的产品始终比具有较差文档记录的产品更受青睐； 因为它更完整，更易于使用，因此更加有用。

On the other hand, it reduce the need of support, because the more complete your documentation is, the less likely is users to have issues with your product.

另一方面，它减少了支持的需要，因为文档越完整，用户遇到产品问题的可能性就越小。

Another important thing is the fact that a well-written documentation increase your reputation.

另一个重要的事实是，精心编写的文档可以提高您的声誉。

How? Poor documentation can allow potential users to leak away to your competition, whose product may not be as cool as yours, but can be better documented.

怎么样？ 劣质的文档可能会使潜在的用户流失到您的竞争对手中，您的竞争对手的产品可能不如您的产品酷，但可以提供更好的文档。

If I’m a user and see that your product’s documentation sucks, then do you know what I’ll be thinking of?

如果我是用户，并且发现您的产品文档很烂，那么您知道我会怎么想吗？

If you don’t care about your own product, why should I?

如果您不关心自己的产品，那我为什么呢？

I’ll switch to someone else’s product — someone who cares about their product and who does all possible in order to create a pleasant user experience for me – that is, making its product easier to use by providing a comprehensive documentation.

我将切换到其他人的产品-关心他们的产品并尽一切可能为我创造愉悦的用户体验的人-也就是说，通过提供全面的文档来使其产品更易于使用。

The natural conclusion of the above is, if users see that you respect them and their time by arming them with quality documentation, then they, in their turn, will respect you.

上面的自然结论是，如果用户发现他们通过提供高质量的文档来尊重他们和他们的时间，那么他们将依次尊重您。

What is it that differentiates a professional from an amateur is their attention to the detail. Providing a good documentation is one such detail.

专业人士与业余爱好者的不同之处在于他们对细节的关注。 提供良好的文档就是这样一个细节。

When you create a great product, it’s pretty tempting to stop here thinking that it’s more than enough, and that your product will speak about itself automatically. But this is not the truth.

当您创建出色的产品时，很容易就此止步，认为它已经绰绰有余，并且您的产品会自动谈论自己。 但这不是事实。

What is the benefit of your super-duper product if nobody knows how it’s supposed to be used?

如果没有人知道该如何使用超级杜邦产品，这有什么好处？

Null.

空值。

So, if you want your product to be actually used, then you need to tell the users how.

因此，如果要实际使用产品，则需要告诉用户如何使用。

那么，什么是好的文档？ (So, What Is Good Documentation?)

What follows is a set of conditions and requirements needed for a particular documentation to be classified as truly good.

接下来是将特定文档归类为“良好”所需的一组条件和要求。

Good documentation does several things:

好的文档可以完成以下几件事：

• It tells what the product is and what can be useful for (its definition and purpose).
  它告诉产品是什么，以及对产品有用(它的定义和目的)。
• It tells the difference from other similar products (if such exist) and what makes it unique.
  它说明了与其他类似产品(如果存在)的区别以及使其独特的原因。
• It tells users how to get started with the product.
  它告诉用户如何开始使用该产品。
• It tells users how the product can be used in real world projects (from simple to complex ones).
  它告诉用户该产品如何在实际项目中使用(从简单到复杂)。
• It tells how the product can be used in the best possible way (best practices).
  它说明了如何以最佳方式(最佳实践)使用产品。
• It gives plenty of examples and demos for the product’s uses.
  它提供了用于产品用途的大量示例和演示。

Good documentation must be:

好的文档必须是：

• Complete. Web developers must provide documentation for every feature and every aspect of their product, thus the latter to be used fully and properly. Everything which, if it’s omitted, will prevent user’s understanding, must be added.

  完成 。 Web开发人员必须为产品的每个功能和每个方面提供文档，从而可以完全正确地使用后者。 如果省略了所有会妨碍用户理解的内容，则必须添加。

• Concise. The product documentation must be written in such a way which removes all redundant things. Everything which is included, but if it’s omitted, won’t prevent user’s understanding, must be cut.

  简明扼要 。 产品文档的编写必须消除所有多余的内容。 包括在内的所有内容(如果省略)都将被删除，这不会妨碍用户的理解。

• Organized. Every web developer must bear in mind that randomly collected tutorials and resources – from here and there – cannot provide a systematical, logical, clear, and easy to follow guidance. All documentation’s content must be easy to follow and to navigate through, with gradual complexity, and clear hierarchy.

  有条理 。 每个Web开发人员都必须记住，从这里到那里随机收集的教程和资源不能提供系统，逻辑，清晰和易于遵循的指导。 所有文档的内容都必须易于遵循和浏览，并具有逐步的复杂性和清晰的层次结构。

• Up-to-date. Web developers always must provide actual documentation for the most recent version of their product. No excuses here!

  最新 。 Web开发人员始终必须提供其产品最新版本的实际文档。 这里没有任何借口！

什么是假文件或伪文档？ (What Is Fake, or Pseudo Documentation?)

In the above section we’ve seen what good documentation is, and knowing that we can easily grasp its opposite: poor, or bad documentation.

在上一节中，我们了解了好的文档是什么，并且知道我们可以很容易地理解它的反面：糟糕的文档或糟糕的文档。

What I’m going to expose here though, is something different. I call it fake, or pseudo documentation.

我要在这里公开的是不同的东西。 我称其为伪造的或伪造的文件。

And the best way to explain what I mean is to give you a couple of examples.

解释我的意思的最好方法是举几个例子。

API参考 (API reference)

As its name suggests, this is just a ‘reference’ or perhaps a ‘catalog’.

顾名思义，这只是“参考”或“目录”。

The only question it answers is: ‘What?’. What methods it contains, what properties they have, and so on.

它回答的唯一问题是：“什么？”。 它包含什么方法，它们具有什么属性，等等。

There is no ‘How?’ question in it at all.

没有“如何？” 根本没有问题。

It doesn’t shows you how to use all these methods and properties. It just outlines them, in the same manner as a table of content outlines the book’s content. Its purpose is to help you when you’ve already learned the product (or respectively read the book).

它没有告诉您如何使用所有这些方法和属性。 它只是用目录概述书的内容的方式来概述它们。 其目的是在您已经学习产品(或分别阅读本书)时为您提供帮助。

It can’t teach you how to use the product. It only gives you an overview of its features and capabilities.

它无法教您如何使用该产品。 它仅向您概述其功能。

So, if you think that by providing only an API reference for your plugin or library, you are offering real documentation, you better think twice.

因此，如果您认为仅通过为插件或库提供API参考来提供真正的文档，则最好三思而后行。

放置在代码文件中的文档 (Documentation placed inside a code file)

Some web developers tend to use comments inside their code files as a documentation source.

一些Web开发人员倾向于将其代码文件中的注释用作文档来源。

This practice is frankly wrong.

坦率地说，这种做法是错误的。

First, because this isn’t the true purpose of the comments, and second, because it makes the learning process difficult.

首先，因为这不是评论的真正目的，其次，因为这使学习过程变得困难。

To open the code file when I need instructions to do something is the same as if I must open my piano to see the notes I want to play (because some ‘clever’ person has decided to print them inside).

当我需要执行某些操作的指示时打开代码文件，就像必须打开钢琴才能看到要弹奏的音符一样(因为有些“聪明”的人决定将其打印在里面 )。

Moreover, superfluous comments makes the code hard to read and maintain. The product and the documentation must be separated in the same way, and for similar reasons because of that we separate our HTML, CSS, and JavaScript files.

而且，多余的注释使代码难以阅读和维护。 产品和文档必须以相同的方式分开，并且出于类似的原因，因为我们分开了HTML，CSS和JavaScript文件。

Generally speaking, every time when some web developers (most likely the lazy ones:)) try to ‘cheat’, the net result is fake documentation.

一般来说，每当某些Web开发人员(最有可能是懒惰的开发人员)尝试“欺骗”时，最终结果是伪造文档。

谁负责创建您的产品文档？ (Who Is Responsible for Creating Your Product’s Documentation?)

A good question, isn’t it? So, who is responsible? You, of course. As a creator, you are the person who best knows your own product and how it can be used in real world projects.

一个好问题，不是吗？ 那么，谁负责？ 当然是你。 作为创作者，您是最了解自己的产品以及如何在实际项目中使用它的人。

You don’t have to depend on the community and other people to write documentation and tutorials for your product. This is for several reasons.

您不必依靠社区和其他人来为您的产品编写文档和教程。 这是出于几个原因。

First, third party resources, collected from here and there, are not consistent enough. They cannot provide a clear, logical, and integral learning experience.

首先，从这里到那里收集的第三方资源不够一致。 他们无法提供清晰，逻辑和完整的学习体验。

Second, third party tutorials and articles are not enough reliable. They can be incorrect, outdated, or even deleted at some point of time.

其次，第三方教程和文章不够可靠。 它们在某些时候可能是不正确的，过时的，甚至被删除了。

And third, letting someone else to do your job can also discredit your reputation.

第三，让别人去做您的工作也会损害您的声誉。

好的文档包括哪些组成部分？ (What Components a Good Documentation Consists Of?)

A good documentation can consists of many different components. It’s the job of product’s author to decide which ones to include. To make this task easier I can propose the following list with some fundamental components:

一个好的文档可以包含许多不同的组件。 产品作者的工作是决定要包括哪些内容。 为了简化此任务，我可以提出以下列表，其中包含一些基本组件：

• Getting started section – One of the first things you must do in your documentation is to provide an adequate answer to the user’s question: ‘How to get started?’. This is important because it helps people to get confidence and gives them a starting point for further learning.

  入门部分 –您在文档中必须做的第一件事就是为用户的问题：“如何入门？”提供适当的答案。 这很重要，因为它可以帮助人们建立信心并为他们提供进一步学习的起点。

• User guide/manual – If your product is fairly complex, then this component is absolutely required. It’s a type of documentation which gives users comprehensive information on how a particular product can be and/or must be used.

  用户指南/手册 –如果您的产品相当复杂，则绝对需要此组件。 这是一种文档，可为用户提供有关如何使用和/或必须使用特定产品的全面信息。

• Examples/Demos – This is an extremely important component. If we paraphrasing the famous expression – ‘One picture worth thousand words.’ – we can say that, one shown example is better than thousand said instructions. So, the main principle here is: show, don’t tell.

  示例/演示 –这是一个非常重要的组成部分。 如果我们用著名的表述来解释“一幅价值千个单词的图画”。 –我们可以说，一个显示的示例要比数千个说明更好。 因此，这里的主要原则是：显示，不说。

  Examples/Demos give a real sense about the product and its usage. Almost every instruction, especially a complex one, must be accompanied with an appropriate example.

  实例/演示对产品及其用法有真实的了解。 几乎每条指令，特别是复杂的指令，都必须随附适当的示例。

• Code playground – This component offers a ready-to-go environment where users can start toying with your product immediately. It’s great for quickly trying things out. This is important because, for novice users – who don’t know yet whether they’re going to use your product – setting their own working environment can be a bit tedious. To some degree, this is similar to the ‘try before you buy’ concept.

  代码游乐场 –该组件提供了一个随时可用的环境，用户可以在其中立即开始玩弄您的产品。 快速尝试问题非常好。 这很重要，因为对于尚不知道是否要使用您的产品的新手来说，设置自己的工作环境可能会有些乏味。 在某种程度上，这类似于“购买前试用”的概念。

• Slide presentations – Slides are an elegant, concise, and easy to follow method for explaining a topic, or a concept.

  幻灯片演示文稿 –幻灯片是一种优雅，简洁且易于遵循的方法，用于解释主题或概念。

• Tutorials – These are one of the widely used and effective ways for teaching. You may think of them as short guides/manuals focused on more narrowed topics.

  教程 –这些是广泛使用且有效的教学方法之一。 您可能会认为它们是针对更狭窄主题的简短指南/手册。

• Screencasts – Some people prefer video instructions instead of written ones. For them you can offer video tutorials. And also, some topics can be better explained if they are in video format. The above principle – show, don’t tell – is of equal validity here.

  截屏视频–有些人更喜欢视频说明，而不是书面说明。 对于他们，您可以提供视频教程。 而且，如果某些主题为视频格式，则可以更好地进行说明。 上面的原理-显示，不要说-在这里同样有效。

• Cookbooks – These are especially useful when you need to provide solutions to particular or common problems. Instructions in a form of recipes are clear and concise, and users can pick only those they need.

  食谱 –当您需要为特定或常见问题提供解决方案时，这些手册特别有用。 食谱形式的说明简洁明了，用户只能选择所需的内容。

• API reference – As I said earlier this solely can’t be described as true documentation, but yet it’s an important part of it. The important thing here is how you present the API. It must be produced in a clear and easy to spot way, with easy to use navigation, and also with availability to search for particular method or property.

  API参考 -正如我前面所说的这种完全不能被描述为真正的文件，但仍然是它的一个重要组成部分。 这里重要的是如何展示API。 它必须以清晰，易于发现的方式，易于使用的导航以及可以搜索特定方法或属性的方式来生产。

• FAQ pages/sections – If you need to clarify some things about your product, or anything related to it, then it’s a good idea to offer a FAQ page or section.

  常见问题页面/部分 –如果您需要澄清有关产品或与产品相关的任何内容，那么最好提供一个常见问题页面或部分。

• System requirements – Before users to have your product up and running they need to know whether it’s actually possible for them. So, make sure that this information is clearly stated and put on visible place.

  系统要求 –在用户启动并运行您的产品之前，他们需要知道他们是否真的可以使用。 因此，请确保清楚地说明此信息并将其放在可见的地方。

• Change logs/Release notes – Seeing the path of your product, from its conception to its recent implementation, can be very useful to users. For example, knowing what WordPress functions are deprecated, and what are added in its newer version, allows you to make the required changes to your theme thus making it up-to-date.

  更改日志/发行说明 –从产品的概念到最新的实施，查看产品的路径对用户来说非常有用。 例如，了解不推荐使用哪些WordPress功能以及在其较新版本中添加了哪些功能，可以让您对主题进行必要的更改，从而使其成为最新的主题。

• License information – This component tells users where they can use your product and under what conditions.

  许可信息 –该组件告诉用户他们可以在哪里以及在什么情况下使用您的产品。

Of course, the above list is not fully complete, but it gives you a good foundation to build on. How many components you will use depends of your project’s complexity.

当然，以上列表并不完整，但是它为您提供了良好的基础。 您将使用多少个组件取决于项目的复杂性。

If you have some small utility library consisting of several API methods, including all of the above suggestions will be far too much. You need to decide on your own.

如果您有一个由几个API方法组成的小型实用程序库，那么上述所有建议都将太多。 您需要自行决定。

But in all cases you need to keep in mind one thing: there is no such a thing as perfect documentation.

但是在所有情况下，您都需要记住一件事：没有完美的文档之类的东西。

So, no need to be perfectionist. Just good enough is all you need to achieve.

因此，无需成为完美主义者。 您所需要的只是足够好。

好的文档示例在哪里？ (Where Are Examples of Good Documentation?)

Below are some examples which I consider as having a good documentation.

以下是一些我认为具有良好文档说明的示例。

To be honest, most don’t meet all the criteria mentioned above, but are much closer to them than many others out there.

老实说，大多数都不满足上述所有条件，但是比其他条件更接近这些条件。

The list is minimal and only for illustrative purpose. If you think that someone’s product documentation is leaved unmentioned, please feel free to add it in the comments below.

该列表是最小的，仅用于说明目的。 如果您认为未提及某人的产品文档，请随时在下面的注释中添加它。

减 (Less)

Less is an extremely useful product (a CSS preprocessor) widely used in all kind of projects which involve using CSS.

Less是一种非常有用的产品(CSS预处理程序)，广泛用于涉及使用CSS的所有项目中。

Besides that, it has a great documentation too. It offers a getting started section, fully documented language features, complete reference to its built-in functions, as well as a page dedicated to its usage.

除此之外，它也有很好的文档。 它提供了一个入门部分，完整记录的语言功能，对其内置功能的完整引用以及一个专门介绍其用法的页面。

The latter gives plenty of useful information about Less usage via command line and in the browser, browser support, Less compilers, editors with Less support, and frameworks where Less is used.

后者通过命令行以及在浏览器中提供了有关“较少使用”的大量有用信息，浏览器支持，较少的编译器，具有较少支持的编辑器以及使用较少的框架。

jQWidgets (jQWidgets)

jQWidgets is one of the most feature complete and universal jQuery-based widget libraries.

jQWidgets是功能最齐全且通用的基于jQuery的小部件库之一。

Not only it’s a great product on its own, but it has also a great documentation. Every single widget is clearly documented.

它不仅本身是一个很棒的产品，而且还有一个很棒的文档。 每个小部件都有明确的文档记录。

The API for every widget provides examples for each property, event, and method; plus interactive examples at jsfiddle.

每个小部件的API提供了每个属性，事件和方法的示例； 加上jsfiddle中的交互式示例。

Besides the widgets there is also information on how the library can be integrated with other popular products such as KnockoutJS, Bootstrap, WordPress and Joomla, PHP and ASP.NET, PhoneGap, and so on.

除了小部件外，还提供有关如何将库与其他流行产品(如KnockoutJS，Bootstrap，WordPress和Joomla，PHP和ASP.NET，PhoneGap等)集成的信息。

And on top of this, there are tons of demos for every widget with provided source code, which makes the learning process extremely fun, easy, and productive.

最重要的是，每个小部件都有大量的演示，其中提供了源代码，这使学习过程变得非常有趣，轻松和高效。

淘汰赛 (KnockoutJS)

KnockoutJS is another great product (a JavaScript library) with comprehensive documentation. It offers demo video, live examples, interactive tutorials, and least but not last a thorough guide describing its features in detail .

KnockoutJS是另一个很棒的产品(JavaScript库)，具有完整的文档。 它提供了演示视频，实时示例，交互式教程，并且至少提供了详尽的指南，详细介绍了其功能。

ox (qooxdoo)

qooxdoo is an universal JavaScript framework. It provides versions for web, desktop, mobile, and server. Every version is greatly documented.

qooxdoo是一个通用JavaScript框架。 它提供了适用于Web，桌面，移动和服务器的版本。 每个版本都有详细记录。

For example, qooxdoo desktop has full API reference, complete user manual available also as a pdf file, getting started and FAQ sections, and so on.

例如，qooxdoo桌面具有完整的API参考，完整的用户手册(还包括pdf文件)，入门和常见问题解答部分，等等。

Also it offers some interactive tutorials, code playground, widgets showcase, widgets browser, and demo browser with many examples.

它还提供了一些示例的交互式教程，代码游乐场，小部件展示，小部件浏览器和演示浏览器。

CodeIgniter (CodeIgniter)

CodeIgniter is a great PHP framework with a small footprint.

CodeIgniter是一个很棒PHP框架，占地面积很小。

At its home page you can get immediately answer to what it is and whether it’s appropriate for your project and requirements. And, in its user manual you can find detailed information about the framework: Getting Started, installation instructions, a short tutorial, API references, and more.

在其主页上，您可以立即得到答案，它是什么以及它是否适合您的项目和要求。 并且，在其用户手册中，您可以找到有关该框架的详细信息：入门，安装说明，简短教程，API参考等。

One of the main reasons for CodeIgniter’s popularity is the clear and concise documentation it provides. Sometimes offering too much documentation can be overwhelming and confusing for users, especially if it’s produced in a chaotic manner.

CodeIgniter受欢迎的主要原因之一是它提供的简洁明了的文档。 有时提供过多的文档可能会使用户不知所措，而且令人困惑，特别是如果文档以混乱的方式生成。

That’s why, conciseness is of equal importance as completeness.

因此，简洁与完整性同等重要。

谁做错了？ (Who’s Doing it Wrong?)

The list would be long, no doubt. But, I don’t want to include examples of poor documentation here, because I don’t want to name and shame anyone personally.

毫无疑问，这份清单很长。 但是，我不想在此处包含不良文档的示例，因为我不想亲自命名和羞辱任何人。

But if you’re read carefully this article it will be pretty easy to recognize such kind of documentation when you see it.

但是，如果您仔细阅读了本文，当您看到它时，将很容易识别此类文档。

结论 (Conclusion)

So far we’ve seen that having a great product is not enough for you to succeed, and for your users/customers to be happy.

到目前为止，我们已经看到拥有出色的产品不足以使您成功，也无法让您的用户/客户满意。

Providing a great documentation is a crucial step on the path to the success, and this fact should not be underestimated.

提供出色的文档资料是迈向成功之路的关键一步，这一事实不容小under。

Any self-respecting web developer should prove its professionalism by spending some additional time to create and provide a good enough documentation. And I’m deeply convinced that these extra efforts will pay back pretty well in the future.

任何自重的Web开发人员都应花一些额外的时间来创建和提供足够好的文档，以证明其专业水平。 我深信，这些额外的努力将在将来获得很好的回报。

翻译自: https://www.sitepoint.com/products-documentation-good-enough/

产品经理产品文档