为软件开发组织组织信息
随着时间的推移，我们的信息战略已经变得越来越广泛，我们希望有一个更清晰的政策和更明确的方式让每个人在信息共享上保持同步。需要注意的是，该组织拥有 300 多人，分布在世界多个国家/地区。此外，我们还有喜欢使用 Sharepoint 的人，喜欢喜欢 Confluence 的人等等，所以这里肯定存在“变化”因素。
以下是我们当前的问题以及我们正在考虑如何解决这些问题。我很乐意听到反馈、建议等。
我们今天的内容：
- 技术设计信息/架构文档
- 会议记录、行动项目等
- 项目计划和路线图
- 组织业务管理信息 - 旅行、预算信息、员工信息等
- 项目页面 #
以下是我们的一些主要问题：
数据应该去哪里 - Confluence WIKI 与 Sharepoint 与 Intranet 站点 - 我们使用 confluence WIKI 来处理 #1、#2、#3、 5 但我们也对 #1、#3、#4、#5 使用共享点。我们正在尝试弄清楚是否应该将每个数字指定到特定位置以使事情保持一致。我们使用 Sharepoint 更多的是文档的目录结构，并且我们使用 confluence 来获取更多临时的可更改内容。
过时的数据 - 这可能是组织的文化问题，但在某些时间点数据会变得过时并且不再相关。确保旧数据不会产生大量噪音并确保最新正确数据是最新的最好方法是什么。组织中是否应该有人对此负责，或者它是否应该是隐含的“每个人的工作”。当人们离开、加入等时，这更成为一个问题。 。
更积极地使用 - 让人们摆脱电子邮件并试图停下来思考“这对其他人有用吗......让我把它放在一个集中的地方而不是电子邮件链中的最好方法是什么”。 。
另外，还有任何其他关于改善组织沟通和信息管理的好方法的故事
over time our information strategy has gone all over the place and we are looking to have a clearer policy and a more explicit way for everyone to be in sync on information sharing. Some things to note is that the org is 300+ people and is in multiple countries across the world. Also, we have people that are comfortable in Sharepoint, people that are comfortable in confluence, etc so there is definately a "change" factor here
Here are our current issues and what we are thinking about doing about them. I would love to hear feedback, suggestions, etc.
The content we have today:
- Technical design info / architecture docs
- Meeting minutes, action items, etc
- Project plans and roadmaps
- organization business mgmt info - travel, budget info, headcount info, etc
- Project pages with business analysis, requirements, etc
Here are some of our main issues:
Where should data go - Confluence WIKI versus Sharepoint versus intranet site - we use confluence WIKI for #1, #2, #3, #5 but we also use sharepoint for #1, #3, #4, #5. We are trying to figure out if we should mandate each number to a specific place to make things consistent. We are using Sharepoint more a directory structure of documents, and we are using confluence for more adhoc changable content.
Stale Data - this is maybe a cultural thing with the org but at certain points in time data just becomes stale and is no longer relevant. What is the best way to ensure old data doesn't create a lot of noise and to ensure that the latest correct data is up to date. Should there be people in the org responsible for this or should it be an implicit "everyones job". This is more of an issue when people leave, join, etc . .
More active usage - whats is the best way to get people off of email and trying to stop and think "could this be useful for others . . let me put it in a centralized place instead of in email chains" . .
also, any other stories of good ways to improve an org's communication and information management
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
信息混乱的一个根本原因是“无所有权”。
人们被分配到项目中。项目结束（或取消），人们继续前进，文件留下来积聚“灰尘”并成为信息混乱。
这是很难预防的。 wiki 与 sharepoint 并不能解决混乱问题，它只是改变了用来积累混乱的技术基础。
让我们看看混乱的情况
技术设计信息/架构文档。老的没关系。有当前的，也有无关紧要的。维基百科。
去年过时的设计信息已经过时了。
会议记录、行动项目等。行动项目成为开发冲刺中某人待办事项的一部分，或者，它们可能永远不会完成。待办事项是 wiki 项目。其他一切都是历史，可能很有趣，但通常并不有趣。如果它没有创建冲刺积压项目、更新架构或解决开发问题，那么会议可能就是浪费时间。
项目计划和路线图。冲刺积压工作很重要——这就是“计划和路线图”所渴望的。如果你必须用路线图来补充你的计划，你可能应该放弃计划，只使用 Scrum 并保持积压工作最新。
最初的计划是某人在项目启动时的猜测，当前的项目团队并不是很感兴趣。
组织业务管理信息 - 旅行、预算信息、员工信息等。这是高度结构化的内容（预算、组织）和非结构化的内容（“旅行”？）的奇怪混合体
您需要多少历史记录？没有任何？维基最多。财务或人力资源系统才是它所属的地方。但是，在大型组织中，会计系统使用起来可能很困难且麻烦，因此我们创建了辅助信息源，例如包含过时预算数字的 SharePoint 页面，因为真正的预算数字隐藏在 Oracle Financials 中。
包含业务分析、需求等的项目页面。这是您的积压工作。您的项目路线图、您的要求以及您的分析应该是一个文档。在维基百科中。
历史很少重要。某人在项目开始时对需求的概念已经不再重要了。需求的最终演变形式比任何历史都重要得多。这是 wiki 材料。
多少岁算“太老”？
我曾与拥有 30 年历史软件的客户合作过。显然，该软件是相关的，因为它正在生产中。
然而，文档全是垃圾。该软件已维护。它充满了变更控制记录。 “原始”规范必须随着每个变更控制的折叠而被精心重写。由于变更控制文档可能非常普遍，因此了解变更应用在何处的唯一方法是阅读源代码，并从中得出——对当前状态规范进行逆向工程。
如果我们只能通过对源代码进行逆向工程来理解一个 30 年前的应用程序，那么，扔掉这堆 30 年前的纸吧。没用的。
一旦维护完成，“原始”规格就贬值了。
如何清理？
如果您创建了 wiki 页面或共享点站点，您将永远拥有它。
当您离开时，您的继任者将永远拥有它。
每位经理对其员工创建的每一条信息负有 100% 的责任。他们必须删除一些东西。较弱的解决方案是“归档”内容。这只是一种礼貌的说法，即不带“D 字”的“删除”。
清理工作必须是每个经理的持续责任。如果他们不记得它是什么，或者为什么拥有它，则应该要求（或“鼓励”）他们删除它。过去两年未访问的所有内容都应毫无疑问地存档。 10年前的一切都只是无关紧要的历史。
这很痛苦，而且看起来并不是创造价值的工作。毕竟我们是从事IT行业的。我们的工作是“编写”软件，而不是删除它。除非受到开枪威胁，否则没有人会这样做。
存储成本相对较低。清理成本似乎更高。
如何停止电子邮件链？
拒绝参加。创建一个“打破链条”活动，重点是用 wiki 更新（或共享点更新）替换电子邮件链。
确保您的 wiki 提供链接并且编辑速度比电子邮件更快。
你不能强迫人们放弃一个非常非常方便的解决方案（电子邮件）。您必须使 wiki 更有价值并且几乎像电子邮件一样方便。
提升维基上的价值。弃用电子邮件链。拒绝回复电子邮件链。拒绝通过电子邮件接受“待办事项”行动项目。
A fundamental root cause of information clutter is "no ownership".
People are assigned to projects. The projects end (or are cancelled), the people move on and the documents remain behind to gather "dust" and become information clutter.
This is hard to prevent. The wiki vs. sharepoint doesn't address the clutter, it just shifts the technology base that's used to accumulate clutter.
Let's look at the clutter
Technical design info / architecture docs. Old ones don't matter. There's current and there's irrelevant. Wiki.
Last year's obsolete design information is -- well -- obsolete.
Meeting minutes, action items, etc. Action items become part of someone's backlog in a development sprint, or, they're probably never going to get done. Backlogs are wiki items. Everything else is history that might be interesting but usually isn't. If it didn't create a sprint backlog items, update an architecture, or solve a development problem, the meeting was probably a waste of time.
Project plans and roadmaps. The sprint backlog matters -- this is what a "plan and roadmap" aspires to be. If you have to supplement your plans with roadmaps, you probably ought to give up on the planning and just use Scrum and just keep the backlog current.
The original plan is someone's guess at project inception time, and not really very interesting to the current project team.
Organization business mgmt info - travel, budget info, headcount info, etc. This is a weird mixture of highly structured stuff (budget, organization) and unstructured stuff ("travel"?)
How much history do you need? None? Wiki at best. Financial or HR System is where it belongs. But, in big organizations, the accounting systems can be difficult and cumbersome to use, so we create secondary sources of information like a SharePoint page with out-of-date budget numbers because the real budget numbers are buried inside Oracle Financials.
Project pages with business analysis, requirements, etc. This is your backlog. Your project roadmap and your requirements and your analysis ought to be a single document. In the wiki.
History rarely matters. Someone's concept at project inception time of what the requirements are doesn't matter very much any more. What the requirements evolved to in their final form matters far more than any history. This is wiki material.
How old is 'too old'?
I've worked with customers that have 30-year old software. The software -- obviously -- is relevant because it's in production.
The documentation, however, is all junk. The software has been maintained. It's full of change control records. The "original" specifications would have to be meticulously rewritten with each change control folded in. Since the change control documents can be remarkably pervasive, the only way to see where the changes were applied is to read the source and -- from that -- reverse engineer the current-state specification.
If we can only understand a 30-year old app by reverse engineering the source, then, chuck the 30-year old pile of paper. It's useless.
As soon as maintenance is done, the "original" specification has been devalued.
How to clean it up?
If you create the wiki page or sharepoint site, you own it forever.
When you leave, your replacement owns it forever.
Each manager is 100% responsible for every piece of information their staff creates. They have to delete things. The weak solution is to "archive" stuff. Which is just a polite way of saying "delete" without the "D-word".
Cleanup must be every manager's ongoing responsibility. If they can't remember what it is, or why they own it, they should be required (or "encouraged") to delete it. Everything unaccessed in the last two years should be archived without question. Everything 10 years old is just irrelevant history.
It's painful, and it doesn't appear to be value-creating work. After all, we work in IT. Our job is to "write" software, not delete it. No one will do it unless compelled on threat of firing.
The cost of storage is relatively low. The cost of cleanup appears higher.
How to stop the email chain?
Refuse to participate. Create a "Break the Chain" campaign focused on replacing email chains with wiki updates (or sharepoint updates).
Be sure your wiki provides links and is faster to edit than an email.
You can't force people to give up a really, really convenient solution (Email). You have to make the wiki more valuable and almost as convenient as email.
Ramp up the value on the wiki. Deprecate email chains. Refuse to respond to email chains. Refuse to accept "to do" action items through email.
您可以使用 Confluence Wiki 将文档存储为附件，并将 Wiki 的路径用作 Sharepoint 中的文件路径。
回复：过时的数据：拥有数据的所有权（个人和团队）并确保所有者的可交付成果包括所有数据的维护。
至于“关闭电子邮件”，这很难做到，因为你不能强迫人们这样做，除非主动监控所有电子邮件……但你可以尝试一些可交付成果，其中包含有关添加到 Wiki 的内容的指标。这样人们就更有可能想要重复使用电子邮件中已经完成的工作来粘贴到 Wiki 中以满足“配额”，而不是编写新的内容。
我们的公司和/或团队过去使用了所有这 3 种方法并取得了一定程度的成功
You can use Confluence Wiki for storing documents as attachements and have the Wiki's paths work as the file paths in Sharepoint.
Re: stale data: have ownership of the data (both person and team) and ensure that deliverables for the owners include maintenance of ALL the data.
As far as "Off email", this is hard to do as you can't force people to do this short of actively monitoring all email... but you can try some deliverables with metrics regarding content added to the Wiki. That way people would be more likely to want to re-use the work already done on the email to paste into Wiki to meet the "quota" instead of composing fresh stuff.
Our company and/or team used all 3 of these approaches with some degree of success in the past
有没有理由不让 wiki 保留这些文件？
另外，也许限制邮件服务器不允许在内部电子邮件上添加附件太过严厉，但是要求人们将需要多次通过电子邮件发送的所有内容都放入 wiki 中是非常有用的。
Is there a reason not to have the wiki hold the files?
Also, perhaps limiting the mail server to not allowing attachments on internal emails is too draconian, but asking folks to put everything in the wiki that needs to be emailed more than once is pretty darn useful.
高效的信息管理确实是一个非常困难的问题。我们发现“越简单越好”的原则可以创造奇迹来解决它。
数据应该去哪里 - 我们是 wiki 方法的忠实拥护者。事实上，我们使用 Confluence 来共享可能的所有类型的信息，除了非常大的二进制文件。对于这些，我们使用 Dropbox。它的简单性绝对是一个杀手级的功能。 （提示：您可以将它们与 Confluence 中的 Dropbox 插件集成。）
查找过时数据 - 在我们的定义中，过时数据是指在特定时间段内未更新或查看的数据。 Confluence 的归档插件可以快速自动找到这些内容，然后将其报告给作者和管理员，他们可以可能会更新它们（或删除它们，请参阅下一项）。当然，有些信息永远不会过期，但插件可以在您标记相应页面后跳过它们。
删除陈旧数据 - 我们在这方面相当积极。如果数据不再（高度）相关，请立即清理它！我们可以安全地遵循这种做法，因为我们从未真正删除数据。我们只是再次使用存档插件将过时的数据移动到隐藏的存档空间。如果我们后来改变主意，可以很容易地在档案中找到它、查看它甚至恢复它。
更积极地使用 - 我们的规则：如果需要持久保存信息，请勿通过电子邮件发送。把它放到 wiki 页面上。对于某些人来说，困难的事情是找到信息的最佳位置（哪个空间？页面层次结构中的哪个位置？）。不幸的是，组织混乱、范围模糊的空间是另一个巨大的效率鸿沟。大公司可能会考虑引入 wiki 园丁来解决这个问题。
Efficient information management is indeed a very hard problem. We found that "the simpler the better" principle can make miracles to solve it.
Where should data go - we are big believers of the wiki approach. In fact, we use Confluence for sharing possibly every type of information, except really large binary files. For those, we use Dropbox. Its simplicity is an absolutely killer feature. (Tip: you can integrate them with the Dropbox in Confluence plugin.)
Finding stale data - in our definition, stale data is something that is not updated or viewed for a specific period of time. The Archiving Plugin of Confluence can quickly and automatically find these, then report them to the authors and administrators, who may potentially update them (or remove them, see next item). There is, of course, information that never expires, but the plugin is able to skip them after you mark the corresponding pages.
Removing stale data - we are fairly aggressive on this. If the data is not (highly) relevant anymore, clean it up now! We can safely follow this practice, because we never actually delete data. We just move outdated data to hidden archive spaces using, again, the Archiving Plugin. If we changed our mind later, it is very easy to find it in the the archive, view it or even to recover it.
More active usage - our rule: if the information is required to be persistent, don't email it. Put it to a wiki page instead. The hard thing for some people is to find the best location for the information (which space? where in the page hierarchy?). Badly organized spaces with vague scope are another big efficiency divider, unfortunately. Large companies may consider introducing a wiki gardener to cure this.