Documentation 让开发人员使用wiki

我在一个复杂的应用程序上工作，在这个应用程序中，不同的团队在不同的模块上工作，有一定程度的重叠。不久前，在我的提示下，我们设置了一个Mediawiki实例。我很难让人们真正使用它，更不用说贡献了

我认为分享信息有很多好处。这至少可以减少我们重新发明轮子的次数

维基不是很结构化，但我不确定这是一个问题，只要你能搜索到你需要的

---

有什么提示吗？

向开发者推销使用wiki的想法。您已经确定了一些好处，请与开发人员分享。如果他们能看到他们会从中得到一些有价值的东西，他们就会开始使用它

来自

• 适合写下快速的想法或更长的想法，给你更多的时间进行正式的写作和编辑
• 即时协作，无需通过电子邮件发送文档，保持团队同步
• 可以通过web连接从任何地方访问（如果您不介意使用web浏览器文本表单书写）
• 您的存档，因为每一页的修订都会保留
• 激动人心、立竿见影、充满力量——每个人都有发言权

正如我提到的，维基是非常无组织的

然而，如果这是开发人员的唯一论点，那么就投入一些精力创建一个简单的索引页面并保持更新（要么自己做，要么让人们将他们的贡献链接到索引）。这样，Wiki可能会成长为一个非常好、非常全面的文档集合，用于您的所有工作。

查找团队似乎一次又一次创建的“粘性”项目（sub-3 pg.docs/diagrams/etc），并将其发布到Wiki上。确保每个人都可以访问维基，并且知道它的位置——如果可能的话，建立一个通知机制。幸运的是，下一次他们必须访问，而不是从版本控制或他们的机器中挖出来，他们应该点击维基。

---

如果他们仍然不这样做，试着看看团队是否有足够的空闲时间来实际使用维基——更微妙的问题可能在于他们的不情愿

你不能强迫开发者去做他们没有动机去做的事情；不幸的是，Wiki和文档（事实上Wiki就是文档）一样，对开发人员来说很少有“酷”的价值。此外，他们已经深入到开发工作中——你真的能用维基打扰他们吗

这就是说，推动维基的人（例如，你）应该主要负责更新它，如果你认真对待它，你真的会有很多工作要做

您也可以尝试ff：

• 你说它不是很结构化——很多人对结构不良（难以搜索/浏览）的维基失去兴趣。所以也许你可以先解决这个问题
• 也许您可以让首席开发人员/项目经理在其中填充一些他们需要解决的问题：比如代码约定和特定项目的API设计
• 以身作则：虔诚地记录你的系统部分。树立先例可能会鼓励其他人也这样做

---

我做了一些销售，甚至举办了一些培训课程。我认为有些人对所见即所得编辑和从Word或Outlook粘贴格式化文本的能力缺乏兴趣。我知道有一些工具可以解决这些问题，但它们仍然是障碍

在某些区域，wiki被用来记录某些区域，但更新这些区域的人没有用它做任何其他事情

我将使用维基来记录我的专业领域，因为它是一个方便的大脑扩展。当开始一项新的开发时，我把它当作记事本，记下我可以在开发过程中扩展的想法

---

即使不是强制性的，如果管理层能给予一些口头支持也会有所帮助。

我们已经以某种形式使用wiki有一段时间了，但人们确实需要一段时间才能加入。你可能会发现，在一段时间内，你将是唯一一个写文章的人，但请忍耐，其他人最终会加入进来

如果有人发送了一封包含与项目相关信息的电子邮件，然后帮助他们指向维基的方向——并继续这样做——他们应该得到提示

我们有一个SharePoint门户，并从那里使用wiki——我们用自己的品牌对其进行了定制，使其“看起来像一部分”——我真的觉得这有助于提高对它的理解

---

确保每个人都知道维基甚至比电子邮件更非正式。。。。因为会有一个“恐惧因素”，人们可能会认为他们添加到维基上的任何内容都会被过度分析。

我认为目前为止的大多数答案都是正确的——你自己越是深入了解它，有用的信息就会变得越大，人们自然会慢慢地开始使用它

---

您可以使用的另一种方法是：建议每次有人向另一个团队成员询问有关项目的问题时，他们应该像平常一样回答问题，但也要将答案添加到Wiki的某个部分。这可能需要几分钟的额外时间，但这意味着下次有人问同样的问题时（他们不可避免地会问），你可以通过将他们指向Wiki来节省时间。反过来，这将有助于人们开始将维基作为第一个信息来源，并有助于提高整体的利用率。

看看“成长你的维基”上的建议

只是为了补充这里提供的一些优秀建议

作为一家小公司的开发人员，我发现我的时间通常是在开发和编写状态报告之间分配的（就在编写文档的上面，更糟的是！）。在编写报告的过程中，有一个wiki来记录杂乱无章的想法和注释，这大大减轻了编写报告的痛苦（不是没有痛苦，