我在一家小公司工作，距离部署一个将被大量使用的网络应用程序几周。在一个地方的每个人都必须学会使用它，虽然我认为它非常容易和直观，但我可能会有偏见。
我已经写了一个帮助指南，其中包含大量的屏幕截图，每个页面都有，但我仍然需要培训所有人。什么是最好的方式？你怎么退后一步解释你已经工作了几周的代码？
答案 0 :(得分：9)
首先尝试避免培训：
执行usability testing以确保您的网络应用程序直观。可用性测试是测试的一个非常重要的方面，它经常被忽略。您如何看待您的系统可能与新用户如何看待您的系统有很大不同。
还要尽可能多地添加上下文帮助。例如，当我将鼠标悬停在堆栈溢出的标签上时，我确切地知道点击它会做什么，因为它告诉我。
这似乎也很明显，但请确保从网站本身链接到您的文档。人们可能不会考虑查看您的文档，除非它正好在他们眼前。
关于培训文档：
尝试将您的资料分成用户使用系统的方式。我个人喜欢Sun为他们的Java tutorials创建的“trail”选项。在本教程中，您可以做几件事，并且可以选择您想要去的路径。
支持随机读取您的帮助文档。如果他们在您的网络应用程序中有任务要做，那么他们应该能够在不阅读大量不相关内容的情况下获得帮助。
确保您的文档可供搜索。
关于实际培训课程：
如果您实际上正在进行培训课程，请远离解释与您的代码相关的任何内容。您无需了解驾驶汽车的发动机。
尝试将您的培训课程分成系统中非常集中的方面。如果您只有1个可用的培训课程，那么只需执行一个系统的专用用例+系统的整体描述。请参阅文档的不同部分，以获取帮助。
让社区自助：
无论您的文档有多广泛，您都会遇到未涵盖的案例。这就是为什么让系统的所有用户都可以使用论坛的好主意。让他们互相问问题。
您可以查看此论坛，并根据需要在文档中添加内容。
您还可以为文档本身打开一个wiki，但如果您的用户群不是很大，这可能是不可取的。
答案 1 :(得分：3)
很少有想法：
您是否有一些罐装演练场景？不知道它是否适用于您的产品，但几年前我制作了一个相当实质性的产品并开发了一些他们可以使用的培训模块 - 没有多长时间，每个可能只需15分钟。
我整理了一个幻灯片演示文稿，其中突出显示了它的作用。我会花大约10分钟浏览应用程序的亮点，以便在完成动手操作之前熟悉它们。
不幸的是，人们并不倾向于读东西。您可以将数小时和数小时放入帮助文档中，但仍然发现人们根本不会阅读它或浏览它。这可能令人沮丧。预计您的指南中的答案将成为您的用户将要遇到的问题。
将您所做的任何培训分解为可管理的块。我之前参加过一整天的训练，训练师将它分成短片，让我很容易将训练题目放在脑海中。你不想对它们进行数据转储，因为它们的眼睛会被遮住，你会失去它们。
最终，如果你的应用程序非常实用，它应该是小菜一碟。如果不是，你会发现。你可能希望有一些你知道的人提前通过你的训练，并给你建设性的批评。最好在大团队训练之前解决它。您将对产品和培训材料（无论它们是什么）更有信心，您可能会有更好的培训体验。
如果适用，请为他们提供在线帮助/维基/常见问题解答。有时这很有帮助。
祝你好运！
答案 2 :(得分：2)
在开发周期的早期，你应该真正解决这个问题 lot ，而不是你正在做的事情。
在我看来，企业软件的理想方案是用户设计自己的应用程序并编写自己的文档，我总是努力争取这个。您应该尽早识别关键用户并使用它们设计系统（我尝试让我的用户在Excel或类似的设备中进行基本的屏幕设计和菜单布局 - 然后我将其实现为静态页面并在编写一系列重要代码之前进行检查，显然他们不会在第一时间获得正确的设计，但是指导他们是你的工作 - 理想情况下他们认为他们提出了正确的设计决策，而不是你:-) ）。
然后，这些用户应该在开发系统的同时编写此设计中的用户文档。我有从未看到由IT部门/软件公司提供的帮助文档，这些文档在公司环境中得到了显着的使用。相反，用户将创建他们自己的笔记和解决方案文件夹，并参考这个（事实上，如果您进行系统分析以替换现有系统，发现旧系统的'用户可识别'是一个关键战略）。让用户预先编写自己的文档只会简单地利用将要发生的事情 - 但如果用户认为他们拥有系统的所有权，这是非常容易的，因为他们自己设计了它。
当然，这种方法需要用户的承诺和时间，但通常并不是那么难卖。它是陈腐的，但作为一个促进者，所以用户可以开发自己的系统，而不是作为第三方给他们一个系统几乎保证用户接受。
因为你在哪里，你实施这一切已经太晚了，但是如果你能找到一些敏锐的，关键的，用户并从他们那里得到时间来编写他们自己的文档那么这将是一个很好的举措。如果你不能得到那个，那么你需要找到一位福音传道者，你可以培养他成为“部门”专家并给予他们110％的能量来支持他们。
底线是用户接受是基于感知，这并不一定与系统实际可用的相关性。你必须把注意力集中在这个群体心理学上，就像系统的现实一样，这对于开发者来说往往是棘手的，因为我们比大多数人更基于事实。
答案 3 :(得分：1)
在接下来的几个月里，我也会考虑这样的事情。
在您的情况下，希望用户界面已经过用户验收测试。你说你在一家小公司工作。是否有可能让那里最不懂技术的人尝试一下？事实上，除了他们提出的问题之外，让他们在没有任何自己指导的情况下尝试一下。记录问题并确保用户指南回答问题。
对我来说最重要的是逻辑和一致性。如果应用程序的工作流程在逻辑上与其设计完成的任务相关，并且UI是一致的，那么您应该没问题。
答案 4 :(得分：1)
创建一个wiki页面来描述系统的使用。为用户提供编辑权限可以让用户：
答案 5 :(得分：0)
先在小公司中尝试一些用户，一两个用户。主要是观看，帮助尽可能少。这告诉您需要修复的内容，并创建一个经验丰富的用户群 - 因此您不再是“培训瓶颈”。
将核心要求/用例/故事卡转换为文档的HowTo /演练。
对于公共培训，准备一个10..15分钟的演示文稿（只是那个，而不是更多！），其中涵盖用户绝对必须理解的关键概念，而不是展示您的核心演练。保留额外的时间来解决有关如何解决各种任务的问题。
以用户身份思考，而不是作为技术人员： - 没有人关心它是否是SQL数据库并且您花费了大量时间来使锁定机制正确。他们确实关心“它会让我慢下来”和“当两个人同时这样做时会发生一些不好的事情”。我们的工作是让复杂的事情变得容易。
以可编辑的形式将文档放在Intranet上可能会有所帮助 - 页面“评论”或wiki也许。和/或为错误消息和blip设置“错误维基” - 您或您的用户可以快速添加推荐，解决方法和任何不符合预期的原因。
答案 6 :(得分：0)
而是训练我选择了一些超级用户（每个部门至少有一个人）的所有人，并训练他们教其他员工。这些超级用户
当然至关重要确保他们喜欢应用程序的简单方法是让他们定义应该如何工作的方式:-)。由于他们应该每天都使用这个应用程序，无论管理状态如何，他们都是主要的利益相关者