组织信息软件开发组织

Question

随着时间的推移我们的信息化战略已经得到处都是，我们希望有一个更清晰的政策，并让每个人都在分享信息的同步更明确的方式。有些要注意的是，该组织有300多人，并且在全球多个国家。此外，我们有Sharepoint舒适的人员，舒适的合流人员等，因此这里肯定会有一个“变化”因素。

以下是我们目前的问题以及我们正在考虑如何处理这些问题。我将非常乐意倾听反馈意见，建议等

内容，我们今天：

1. 技术设计信息/架构文档
2. 会议纪要，行动项目等
3. 项目计划和路线图
4. 组织业务管理信息 - 旅行，预算信息，人员信息等
5. 具有业务分析，需求等的项目页面

下面是我们的一些主要问题：

数据应该去哪里 - Confluence维客与共享点与内部网站 - 我们使用＃1 Confluence维客，＃2，＃3，＃5，但我们也使用＃1，＃3，＃4，＃5的共享点。我们正在设法弄清楚，我们是否应该将每个号码都强制到一个特定的地方，以使事情保持一致。我们更多地使用Sharepoint文档的目录结构，并且我们正在使用confluence来构建更多特殊的可变内容。

陈旧的数据 - 这可能是一个组织文化的东西，但在某些时间点，数据只是变得陈旧，不再相关。什么是确保旧数据不会产生大量的噪音，并保证最新的正确的数据是最新的，最好的方式。组织中是否应该有人对此负责，还是应该是隐含的“每个人的工作”。当人们离开，加入等时，这更成为一个问题。 。

更积极使用 - 什么是让人们离开的电子邮件，并试图阻止，并认为最好的方式。“这会是对别人有用，让我把它放在一个集中的地方，而不是在电子邮件链” 。 。

也，的好方法来改善组织的沟通和信息管理

Answer 1

信息混乱的一个基本根源是“没有所有权”。

人们被分配到项目。项目结束（或被取消），人们继续前进，文件仍然滞留，以收集“灰尘”，并成为信息混乱。

这很难防止。 wiki与sharepoint并没有解决混乱问题，它只是改变了用来积累混乱的技术基础。

让我们看看杂波

1. 技术设计信息/架构文档。旧的不重要。目前有和无关的。维基。

   去年的陈旧设计信息已经过时了。

2. 会议纪要，行动项目等行动项目成为某人在发展冲刺中积压的一部分，或者，他们可能永远不会完成。待办事项是wiki项目。其他一切都是历史，可能是有趣的，但通常不是。如果它没有创建冲刺积压项目，更新架构或解决开发问题，那么会议可能是浪费时间。

3. 项目计划和路线图。冲刺积压很重要 - 这是“计划和路线图”渴望成为的。如果你必须用路线图补充你的计划，你可能应该放弃计划，只使用Scrum，并保持积压。

   最初的计划是某人对项目开始时间的猜测，对当前的项目团队来说并不是很有趣。

4. 组织业务MGMT信息 - （？“旅行”）旅行，预算信息，员工人数的信息等，这是高度结构化的东西（预算，组织）和非结构化的东西，一个奇怪的混合

   了多少历史你需要？没有？维基充其量。财务或人力资源系统是它所属的地方。但是，在大型组织中，会计系统使用起来可能比较困难而且麻烦，所以我们创建了二级信息来源，如带有过期预算编号的SharePoint页面，因为实际预算数字被埋在Oracle Financials内部。

5. 具有业务分析，需求等的项目页面这是您的积压。你的项目路线图，你的要求和你的分析应该是一个单一的文件。在wiki中。

   历史很少问题。在项目开始阶段，有些人的要求是什么概念并不重要。最终形成的要求演变得比任何历史都要重要得多。这是维基材料。

“太旧了”是几岁？ 我曾与拥有30年历史的软件的客户合作。显然，软件是相关的，因为它在生产中。

但是，文档都是垃圾。该软件一直保持。它充满了变更控制记录。由于变更控制文件可能非常普遍，因此要查看变更的适用位置的唯一方法是阅读源代码，并从中 - 读取源代码，反向设计当前状态规范。

如果我们只能通过对源代码进行逆向工程来了解30年前的应用程序，那么就可以查看这张30年前的纸张。没用的。

一旦完成维护，“原始”规范就被贬值了。

如何清理它？ 如果您创建维基页面或SharePoint站点，则永远拥有它。 当你离开时，你的替代品永远拥有它。

每位经理都对其员工创建的每一条信息负全部责任。他们必须删除东西。薄弱的解决方案是“归档”东西。这只是在没有“D字”的情况下说“删除”的礼貌方式。

清理必须是每个经理的持续责任。如果他们不记得它是什么，或者他们为什么拥有它们，则应该要求（或“鼓励”）删除它。在过去的两年中没有访问过的东西应该毫无疑问地归档。 10岁的一切都只是无关紧要的历史。

这是痛苦的，它似乎并不是创造价值的工作。毕竟，我们在IT方面工作。我们的工作是“写”软件，而不是删除它。除非被迫解雇威胁，否则没有人会这样做。

存储成本相对较低。清理成本似乎更高。

如何停止电子邮件链？
拒绝参与。创建一个“打破连锁”活动，重点是用维基更新（或共享点更新）取代电子邮件链。

确保您的wiki提供链接，并且编辑速度比电子邮件快。

你不能强迫人们放弃一个真正方便的解决方案（电子邮件）。你必须让wiki更有价值，几乎和电子邮件一样方便。

增加维基上的值。弃用电子邮件链。拒绝回复电子邮件链。拒绝接受通过电子邮件“做”行动项目。

Answer 2

可以使用Confluence维客用于存储文档作为附着物和具有wiki的路径中的任何其他的故事作为工作在SharePoint中的文件路径。

回复：陈旧数据：有数据（包括个人和团队）的所有权，并保证为业主交付包括所有数据的维护。

至于“关电子邮件”，这是很难做到的，因为你不能强迫人们去做这短短的积极监测所有电子邮件...但你可以尝试与有关内容加入到维基度量一些成果。这种方式，人们会更容易想重新使用上的电子邮件已经完成的工作，以粘贴到维基满足“配额”，而不是构成新鲜玩意儿。

公司和/或团队使用这些方法具有某种程度的成功的所有3过去

Answer 3

有没有理由不让wiki维持文件？

另外，邮件服务器可能限制不允许在内部电子邮件附件是太苛刻，但要求人们把一切都需要通过电子邮件发送不止一次维基是相当不错的实用。

Answer 4

高效的信息管理确实是一个非常难的问题。我们发现“越简单越好”的原则可以创造奇迹来解决它。

应该在哪里去的数据 - 我们是维基做法大的信徒。实际上，我们使用Confluence来共享可能的每种类型的信息，除了真正大的二进制文件。对于这些，我们使用Dropbox。它的简单性是绝对的杀手锏。 （提示：您可以将它们与Dropbox in Confluence插件集成）

查找陈旧数据 - 在我们的定义，陈旧的数据是什么，不更新或特定的时间内观看。 Archiving Plugin of Confluence可以快速自动找到这些信息，然后将它们报告给作者和管理员，他们可能会更新它们（或删除它们，请参阅下一项）。当然，信息永远不会过期，但插件可以在标记相应页面后跳过它们。

删除陈旧的数据 - 我们对此非常积极。如果数据不再（高度）相关，请立即清理它现在！我们可以安全地遵循这种做法，因为我们从未真正删除数据。我们只是使用Archiving Plugin将过期数据移至隐藏的存档空间。如果我们后来改变了主意，很容易在档案中找到它，查看它甚至恢复它。

更活跃的用法 - 我们的规则：如果要求信息持久，请不要通过电子邮件发送。把它放到wiki页面上。对于某些人来说，困难的事情是找到信息的最佳位置（哪个空间？在页面层次结构中的哪个位置？）。不幸的是，组织严密的空间范围是另一个大的效率分配器。大公司可能会考虑引入wiki gardener来解决这个问题。