没有“索引页”来组织所有不同的贡献。 没有人希望页面“从裂缝中掉下来”，但在 wiki 中，这是任何页面一旦编写后的默认命运。
没有反馈循环来确保写作真正完成。
使其发挥作用的方法是将某些流程应用到项目中，并按照该流程使用 wiki。
让人们能够在 wiki 中创建新页面，但只能通过自动将新页面链接到正确索引的界面。
定义文档的生命周期，以便确保在适当的阶段起草、审核和批准它们。
提供新页面的模板。 在每个页面中提供您需要的章节标题，并在审核过程中确认标题部分已正确填写。
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the best for project management. Considering Joel's history I'd give them the benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious. Depending on the size of your project, buying it might be a very good option.
At very least you could look at how they've structured it, or read the forums for ideas on how to build your own stripped down version
也许收集您的需求管理工具的需求（我知道是递归的）以及您可以从 wiki 文化和开放式沟通思维中获取哪些方面（沟通方面）。 如果需求管理工具或 wiki 都不符合要求，请考虑构建一个。 可能是下一件大事。 感觉就像是在说我可以使用 wiki 而不是 Bugzilla 吗？
一个用于需求管理的固定工作流程 Web 应用程序，强调开放式沟通，允许不同角色的人员查看和理解，这可能会很好！
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
显然，人们可以轻松地使用超链接和 Wiki 链接。 如果需要，FosWiki 还具有可用于强制执行特定工作流程的功能。 支持用例和其他范例的表单也很容易（我们过去已经这样做过，而且通常效果很好）。
FosWiki 等 Wiki 是可扩展的，可以开发更多模块来解决与可追溯性管理和影响分析、基于表格的需求修改、整体打包等相关的弱点。
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
作为自由格式 wiki 和需求管理工具之间的中间立场，请考虑使用结构化 wiki 就像Foswiki。 我还没有做过任何正式的需求管理（通过 wiki 或其他方式），但我已经使用 TWiki（Foswiki 的前身）来完成其他任务，它允许您根据需要定义工作流程、表单字段等当您不需要正式的结构时，同时保持 wiki 的灵活性。
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
我同意上面所有（大多数）人的观点 - 使用 wiki 听起来可能不错，但 wiki 的目的是提供信息并根据需要进行更新，而不是用作交互式项目管理工具。 我强烈建议使用 SmartSheet（我是该产品的强烈拥护者）——它提供了一个类似电子表格的界面，您可以在其中每行/任务存储多个文件、向用户发送自动更新并维护规范修订... 另一种方法可能是使用 Google 电子邮件、文档和日历 - 一种免费且友好的团队互动方式......我会回避用于项目管理的问题/错误跟踪工具 - 它们往往有不同的侧重点： PM 工具关于整个项目/资源/时间表以及针对特定输入问题的问题跟踪工具......
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions... The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.
发布评论
评论（8）
尽管使用 wiki，但仍可以按照您所描述的方式以协作方式开发需求。 维基范式对这个过程没有任何帮助。
我在 Zend Framework 项目上管理了一个 wiki，以跟踪组件的提案。 他们仍在使用它。 提案与功能规范不同，但用法不同与你的问题足够相似，我认为这是相关的。
维基百科不会照顾自己。 除非有人负责管理它并确保有一定的结构和一致性，否则它很快就会变得一团糟。 现实世界的类比是给每个团队一张白纸，并告诉他们写下自己的部分需求。 这样做的问题是：
使其发挥作用的方法是将某些流程应用到项目中，并按照该流程使用 wiki。
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
“与需求管理工具相比，使用这样的工具有什么优点和缺点？”
虽然这似乎是一个好主意，但你遇到的是那些不会也不会写作的人。
不会写作的人——呃——不会写作。 他们无法通过电子邮件、维基百科或任何声音以外的媒介进行交流。
有些人“杂乱无章”。 事实上，写作太线性，他们的思维也不是线性的。
有些人不明白“写给你的观众”并写出难以理解的东西。
有时你甚至无法弄清楚他们在说什么，更不用说他们在写什么了。 他们用行话或代码交谈。 他们知道的不多，但坚持希望被听到。
有些人不会写。
有些人拒绝做出承诺。 即使在可以撤回的维基百科中也是如此。 他们觉得必须预先讨论一切。
有些人习惯于通过向别人指示来完成所有事情。 他们要么不为自己写作，要么让人们站在办公室里听他们说话和打字。
有些人通常对任何类型的项目都是有毒的。 他们在最后一刻提出新的要求。 他们的第一反应是“那永远行不通”。 他们不太善于头脑风暴。 当他们说这有效时，你恳求他们改进，他们却没有改进。 他们只是知道这行不通。
我的经验是，只有程序员才能成功使用 Wiki。 而且只有高级程序员。
N00bz 没有足够的经验来从谣言和管理的废话中剔除设计中的需求。
N00bz 并不总是具备清晰写作的语言能力。 他们最终可能会这样做，但一看他们的 Javadoc 评论就知道他们正在努力解决写作的“清晰度”部分。
这非常吸引人。 我希望人们能够更好地使用维基，因为我认为它比更传统的方法（一个人采访每个人并将事情写下来）有很多优势。 但这需要一定程度的自信和沟通技巧，而这似乎很少有人具备。
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
考虑研究Fog Bugz。 他们标榜自己是最优秀的
最适合项目管理。 考虑到乔尔的历史，我会给他们
假定其无过失或无罪。 他们按照您刚才描述的方式使用 wiki。
如果您认真的话，我建议您注册免费试用。
根据您的项目规模，购买它可能是一个非常好的选择
选项。
至少你可以看看他们是如何构建它的，或者阅读
论坛提供有关如何构建您自己的精简版本的想法
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
专业工具有助于让事情步入正轨并引入固定的工作流程。 这就是重点，保持事情的重点和功能。 使用像 Wiki 这样的通用工具对于一群程序员来说可能很棒，但是引入一个用于“混合模式”工作的工具可能会很糟糕：
看看像 Basecamp 这样的东西。 它们可以被认为是一个应用维基或协作工具。 用于特定目的的通用工具需要改进。 我不知道 MediaWiki 或其他人是否有足够的定制来保持内容干净和集中。
也许收集您的需求管理工具的需求（我知道是递归的）以及您可以从 wiki 文化和开放式沟通思维中获取哪些方面（沟通方面）。 如果需求管理工具或 wiki 都不符合要求，请考虑构建一个。 可能是下一件大事。 感觉就像是在说我可以使用 wiki 而不是 Bugzilla 吗？
一个用于需求管理的固定工作流程 Web 应用程序，强调开放式沟通，允许不同角色的人员查看和理解，这可能会很好！
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
我们已经在该上下文中使用了 TWiki，现在又使用了 FosWiki。 有很多东西是免费获得的（版本控制、访问控制、基于 Web 的访问、搜索、远程管理、安全补丁……）。 在几分钟内，我们可以定义：
显然，人们可以轻松地使用超链接和 Wiki 链接。 如果需要，FosWiki 还具有可用于强制执行特定工作流程的功能。 支持用例和其他范例的表单也很容易（我们过去已经这样做过，而且通常效果很好）。
FosWiki 等 Wiki 是可扩展的，可以开发更多模块来解决与可追溯性管理和影响分析、基于表格的需求修改、整体打包等相关的弱点。
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
作为自由格式 wiki 和需求管理工具之间的中间立场，请考虑使用结构化 wiki 就像Foswiki。 我还没有做过任何正式的需求管理（通过 wiki 或其他方式），但我已经使用 TWiki（Foswiki 的前身）来完成其他任务，它允许您根据需要定义工作流程、表单字段等当您不需要正式的结构时，同时保持 wiki 的灵活性。
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
我同意上面所有（大多数）人的观点 - 使用 wiki 听起来可能不错，但 wiki 的目的是提供信息并根据需要进行更新，而不是用作交互式项目管理工具。 我强烈建议使用 SmartSheet（我是该产品的强烈拥护者）——它提供了一个类似电子表格的界面，您可以在其中每行/任务存储多个文件、向用户发送自动更新并维护规范修订...
另一种方法可能是使用 Google 电子邮件、文档和日历 - 一种免费且友好的团队互动方式......我会回避用于项目管理的问题/错误跟踪工具 - 它们往往有不同的侧重点： PM 工具关于整个项目/资源/时间表以及针对特定输入问题的问题跟踪工具......
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
现在可能有点旧了，但我目前正在使用 Atlassian 的“Confluence”，它非常棒。 我目前是一名用户体验工程师，在敏捷流程中扮演“产品负责人”的角色。 我可以记录离散接口的需求，允许多个用户的反馈和评论，并将每个接口与更大上下文（例如用户故事）中的其他接口交织在一起。 一切都是非常动态和模板驱动的。 非常适合我现在的需求。
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.