对于以下情况，您有什么建议：
十几个开发人员需要构建和设计一个复杂的系统。需要为未来的开发人员记录此设计，并且必须注意设计决策。这些报告需要大约每两个月进行一次。我的问题是应该如何记录这个项目。
我看到了两种可能性。每个开发人员都会写下他们帮助设计和集成的东西，然后一个人将这些文档中的每一个组合在一起。最终的文件有时可能会不连贯或多余，因为负责组装所有东西的人没有太多时间来调整每个部分。
假设每个开发人员的文档部分在截止日期前几天到达。协作系统（即 wiki）将无法正常工作，因为直到截止日期前几天才可以阅读任何内容。
还是应该让少数人（2-3 人）负责编写文档，而团队的其他成员则负责实际开发系统？开发人员需要一种方法将他们的设计选择和结论传递给技术作者。如何有效地做到这一点？
我们使用 confluence（atlassian 的 wiki-like-thing）并记录各种不同的“事物”。开发人员不断地做这件事，我们互相推动文档——我们让同伴压力决定什么是必要的。每当有新人出现时，他/她的任务是通读所有内容并找出仍然正确的内容。因此，不正确的内容要么被删除，要么被更新。当我们可以删除东西时我们很高兴；）
这个过程的好处是相关的东西会留下来，不相关的东西会被删除。我们总是“摆脱”更正式的要求，声称如果“他们”需要，我们总是可以构建他们想要的 word 文档。“他们”从不需要他们。
我认为备选方案 2 不太灵活，因为它意味着项目的新阶段（尽管它可能与测试并行）。
如果您处于敏捷模型中，那么只需添加文档（按照指南）作为故事。
如果您采用分阶段的方法，那么我仍然会要求开发人员按照一些指导方针处理文档，并沿着设计和代码审查该文档。最终，您可能会有一位技术作家审查所有内容以获得正确的英语，但这将是一种“发布”活动。
我们使用 RUP 风格的方法从两个方面进行处理。在第一种情况下，您将有一位领域专家负责粗略设计您将要交付的产品 - 开发人员会根据需要参与进来。在第二种情况下，我们使用技术作者 - 他们记录应用程序，因此他们应该很好地了解它是如何连接在一起的，并且您可以让他们直接参与设计和开发过程。在这种情况下，他们可以帮助完善设计，并确保它与他们认为正在开发的内容相匹配。
它不是一个完整的文档，但确保使用Doxygen 样式的注释对接口等进行注释意味着编写代码和记录它更紧密。
这样，开发人员应该记录他们所做的事情。我仍然认为需要架构师进行审查以确保质量始终如一，但确保人们记录他们所做的事情是确保他们遵循架构的最佳方式。