Как насчет Сфинкса ?
Вы пишете свою документацию в reStructuredText (синтаксис похож на Markdown, который использует переполнение стека) в простые текстовые файлы (= легко контролировать версию), а Sphinx выплевывает HTML-страницы.
Двумя наиболее известными пользователями Sphinx (о которых я знаю) являются язык Python и TortoiseHG (см. Ссылки на документацию, созданную Sphinx).
РЕДАКТИРОВАТЬ:
Я только что прочитал, что вы говорите о внутренней документации проекта, а не о документации конечного пользователя.
На мой взгляд, что-то вроде Sphinx также является лучшим способом для внутренней документации (при условии, что вы можете заставить своих аналитиков написать reStructuredText), потому что:
- Вы можете легко управлять версиями документов (а различия текстовых файлов занимают намного больше места, чем двоичные файлы, такие как .doc или .pdf).
- Если разработчику нужен хороший читаемый файл .doc или .pdf, он может создать его с помощью Sphinx из исходников.
Если Sphinx слишком сложен, есть даже более простой способ: вы можете написать свою документацию в Markdown и использовать Pandoc для создания (например) .rtf, .doc или .pdf файлов (это может сделать намного больше).
Я обнаружил, что Pandoc легче начать, чем Sphinx, но Pandoc не может создавать красивые иерархии меню, такие как Sphinx (как в документации по Python и TortoiseHG, которую я связал выше).
Независимо от того, какие инструменты вы используете, если у вас есть внутренний веб-сервер и сервер сборки, вы можете настроить его так, чтобы сервер сборки генерировал вывод HTML и копировал его на веб-сервер каждый раз, когда кто-то что-то передает в документацию. Таким образом, вашим аналитикам даже не нужно думать о конечном результате, им просто нужно зафиксировать и внести свои изменения.