Knowledge Management для dev-команд: Wiki, Notion, GitHub — сравнение
Команда из 60 инженеров, с которой я работал в прошлом году, имела 1400+ страниц Confluence, Notion-воркспейс на 380 страниц, GitHub wiki в каждом из 22 репозиториев и Google Drive с «командными знаниями». Задачей новой сотрудницы на второй неделе было найти runbook стейджинга. Ушло четыре часа. Он существовал во всех четырёх системах, с тремя разными URL, двумя противоречивыми версиями и одной корректной, но устаревшей на три года инструкцией в wiki.
Это сравнение четырёх подходов к knowledge management — Confluence, Notion, GitHub Wiki, Git-native docs (Obsidian/MkDocs/Docusaurus поверх репозитория) — и фреймворк выбора. Microsoft Research в отчёте по productivity 2024 назвал «не могу найти документацию» фактором трения №3 после медленных билдов и сломанных тестов, выше задержек code review. Выбор инструмента не нейтрален: он определяет, будет ли документация написана, найдена и доверяема.
{/* truncate */}
Позиционирование
Confluence (Atlassian): enterprise-wiki. Силён в иерархии страниц, апрувах, гранулярных пермишенах. Тяжёлый, медленный, дорогой.
Notion: гибридный workspace — доки, базы, задачи, project views в одном инструменте. Быстрый, красивый, developer-adjacent, но не developer-native.
GitHub Wiki: code-adjacent wiki. Живёт рядом с репозиторием, Markdown, минимальное трение на создание. Слабый поиск, фрагментация между репозиториями.
Git-native docs (Obsidian / MkDocs / Docusaurus поверх Git-репо): документация как код. Версионируется, проходит PR-ревью, деплоится пайплайном. Сильнейший для технической документации, слабейший для всего остального.
Ни один не лучший объективно. Каждый лучший для конкретной стадии команды и типа контента.
Feature-by-feature
Четыре инструмента, одна общая проблема: search + findability. Большинство команд выбирают инструмент, не планируя слой поиска, — отсюда испарение знаний.
Write-side friction (насколько больно добавить док?)
| Возможность | Confluence | Notion | GitHub Wiki | Git-native docs |
|---|---|---|---|---|
| Время на первую страницу | 3-5 мин | 1-2 мин | 30 секунд | 5-10 мин (setup репо) |
| Поддержка Markdown | Частично | Да (с нюансами) | Да | Да (нативно) |
| Встраивание кода с подсветкой | Да | Да | Да | Да (лучше всего) |
| Таблицы | Да (редактор) | Да (сильно) | Да (Markdown) | Да |
| Диаграммы (Mermaid и т.д.) | Плагин | Ограниченно | Частично | Да (нативно) |
| Черновик / неопубликованное | Да | Да | Нет | Да (PR-ветки) |
GitHub Wiki выигрывает по скорости создания. Notion — по богатству. Git-native — по технической точности, но с setup-ценой.
Read-side friction (насколько легко найти и доверять?)
| Возможность | Confluence | Notion | GitHub Wiki | Git-native docs |
|---|---|---|---|---|
| Full-text search (cross-workspace) | Сильно | Сильно | Слабо (per-repo) | Зависит от тулинга (Algolia, lunr) |
| Discoverability для новичков | Слабо (иерархия гниёт) | Средне | Слабо (фрагментировано) | Сильно (при нормальной IA) |
| Индикаторы устаревания | Ручные | Ручные | Ручные | Git-история (автоматически) |
| Гранулярность пермишенов | Сильно | Сильно | Привязано к репо | Привязано к репо |
| Внешняя (клиентская) документация | Возможно | Возможно | Нет | Да (предназначен для этого) |
Фрагментация GitHub Wiki между репозиториями — тихий убийца. В организации на 20 репозиториев 20 поисковых индексов. Найти «как устроена наша staging-авторизация?» — гадание, в каком репозитории смотреть, и если ответ между двумя репозиториями, wiki не слинкует их чисто.
Коллаборация и ревью
| Возможность | Confluence | Notion | GitHub Wiki | Git-native docs |
|---|---|---|---|---|
| Inline-комментарии | Да | Да | Нет (только issues) | Да (через PR) |
| Approval workflow | Да | Ограниченно | Нет | Да (PR review) |
| История версий | Да | Да | Да (git) | Да (git, сильнее всего) |
| Diff-view изменений | Слабо | Слабо | Да | Да (сильнее всего) |
| Bulk edit / refactor | Слабо | Слабо | Git-based | Сильнее всего |
Git-native docs выигрывают конкурс review/версионирования уверенно. Если ваша инженерная культура уже делает code review хорошо, docs-as-code переносит этот мускул напрямую.
AI-поиск / retrieval (релевантность 2026)
| Возможность | Confluence | Notion | GitHub Wiki | Git-native docs |
|---|---|---|---|---|
| Встроенный AI-поиск | Да (Atlassian Intelligence) | Да (Notion AI) | Нет | Зависит от деплоя |
| RAG-friendly для внутреннего LLM | Возможно (API + экспорт) | Возможно (API) | Нативно (Git) | Нативно (Git) |
| Структурная консистентность для AI | Средне | Средне | Низко | Высоко |
Если вы питаете self-hosted LLM внутренней документацией, Git-native — чистейший источник. Notion и Confluence оба предлагают API, но требуют ingestion-пайплайнов. Wiki, фрагментированная по репозиториям, — труднее всего RAG'ить без большого кастомного тулинга.
Реальность по деньгам
| Тир | Confluence | Notion | GitHub Wiki | Git-native docs |
|---|---|---|---|---|
| 20 пользователей | $6/user/мес (~$1 440/год) | $10/user/мес (~$2 400/год) | Бесплатно (в GitHub) | Хостинг: $0-30/мес |
| 100 пользователей | $6/user/мес (~$7 200/год) | $15/user/мес (~$18 000/год) | Бесплатно | $30-200/мес + билд-пайплайн |
| 500+ пользователей | $11/user/мес Enterprise (~$66 000/год) | $25/user/мес Enterprise (~$150 000/год) | Бесплатно | $200-1000/мес + поддержка |
Notion — самый дорогой на тире 500+ пользователей, и это число большинство не планирует, пилотируя на 20. Confluence — enterprise-дефолт не случайно: per-seat на масштабе бьёт Notion. GitHub Wiki бесплатный потому что у него слабейший набор возможностей. Git-native дешевле всего, если деплой-инфраструктура уже есть, и дороже всего, если поднимаете с нуля.
Фреймворк решения
Выбирайте Confluence, если:
- Вы уже в Atlassian (связка Jira + Confluence реально экономит время)
- У вас >200 инженеров и нужны гранулярные пермишены между командами
- У вас compliance или аудит, требующие page-level approval workflow
- Больше 50% контрибьюторов знаний — не инженеры (PM, дизайнеры, ops)
Выбирайте Notion, если:
- Вы быстрорастущий стартап (<200 инженеров), ценящий скорость записи выше структуры чтения
- Команда уже использует Notion для продукта или общекомпанийной документации
- Хотите один инструмент для доков + задач + баз (принимая trade-off разрастания)
- Чувствительность к бюджету низкая; фичи важнее
Выбирайте GitHub Wiki, если:
- У вас <30 инженеров и немного репозиториев (<5)
- Минимум трения на запись и максимум co-location с кодом
- Вы мирные с repo-scoped знанием (без cross-repo авторитета)
- Откладываете «настоящее» решение по KM на позже
Выбирайте Git-native docs (MkDocs / Docusaurus поверх репо), если:
- Ваша документация в основном техническая (архитектура, API, runbooks)
- Хотите ревью документации как кода (PR, апрув, деплой)
- Нужна external-facing документация для клиентов или open-source
- У команды есть платформенные навыки для поддержки билд-пайплайна
- Планируете кормить внутренним LLM (RAG-ready из коробки)
80/20 анализ
Большинство инженерных команд до 50 человек нормально живёт на GitHub Wiki для repo-scoped технической документации + Notion для кросс-командных процессов. Это прагматичный дефолт. Апгрейд до Confluence — когда compliance или размер вынуждают. Переход на Git-native — когда нужен внешний контент или LLM-ready база знаний.
Скрытая проблема: никто не платит за findability
Все четыре инструмента поставляются с поиском. Все четыре команды, которые я видел за последние три года, жаловались, что поиск «сломан». Проблема почти никогда не в инструменте; в том, что команда относится к поиску как к чему-то вторичному.
Правила findability, работающие независимо от инструмента:
- У каждого документа каноничный URL, ссылающийся из одного авторитетного источника. Если у вас три страницы «Staging Auth» — уже проиграли.
- Старые доки помечают stale или архивируют, а не оставляют молча устаревать. «Последнее редактирование 14 месяцев назад» в Confluence — сигнал, который все игнорируют. Явный тег
status: stale— нет. - Главную страницу wiki поддерживает именованный человек. «Все владеют» = никто не владеет. Именованный владелец, ревьюющий главную ежеквартально, — самая высокая ROI-практика KM.
- Новички записывают вопросы своего первого месяца в wiki. Не «что они узнали» — вопросы, которые задавали. Это ваш список дыр.
Команды, пропускающие эти правила, превращают любой инструмент в кладбище. Команды, применяющие их, получают 70% ценности независимо от выбора.
Измерение эффективности KM
Три реально важных метрики, измеримых в любом из четырёх инструментов:
- Время до первого ответа для новичков. Следите, за сколько новый инженер находит ответы на согласованный список из 10 вопросов. Должно идти вниз неделя за неделей. Большинство не меряет; измерение вскрывает дыры в findability.
- Reuse rate документов. Из страниц, созданных за 90 дней, сколько открыты хотя бы 3 разными людьми? Ниже 40% — большинство докумов написаны-один-раз-никогда-не-прочитаны.
- Коэффициент устаревания. Доля страниц, обновлявшихся >12 месяцев назад. Больше 50% — флаг, что команда накапливает гниль. У Confluence худшие показатели устаревания, потому что старые страницы тихо выживают.
PanDev Metrics не отслеживает качество документации напрямую — наша телеметрия видит код и IDE-активность. Что мы можем: коррелировать паттерны доступа к документации (через Git- и IDE-события для Git-native docs) со временем onboarding. Команды с сильной docs-as-code гигиеной достигают meaningful-PR milestone на 30-40% быстрее, чем команды с Confluence-only базами аналогичного размера. Корреляция не есть причинность, но паттерн стабилен.
Итоговое сравнение
| Область | Победитель | Примечание |
|---|---|---|
| Скорость записи | GitHub Wiki (ничья с Notion) | 30 секунд до новой страницы |
| Read-findability на масштабе | Confluence или Git-native | Зависит от дисциплины иерархии |
| Техническая точность | Git-native | PR-ревью ловит ошибки до публикации |
| Цена на масштабе (500+) | GitHub Wiki (бесплатно) или Confluence | Notion дорожает быстро |
| Внешняя документация | Git-native (Docusaurus) | Единственный под это заточен |
| LLM-RAG готовность | Git-native | Markdown в репо — чистейший источник |
| Не-инженерные контрибьюторы | Notion или Confluence | WYSIWYG выигрывает, когда пишут не-технари |
Типичные ошибки
- Принятие нового инструмента до решения проблемы владения. Миграция инструмента — театр, если главную никто не ведёт.
- Запуск двух инструментов параллельно «на время». «Время» становится постоянным, и вы получаете проблему 1 400 страниц.
- Оптимизация под пишущих, не под читающих. Notion быстро пишет, медленно ищет. Большинство команд read-heavy; выбирайте соответственно.
- Игнорирование LLM-будущего. Ваши документы будут потребляться AI в ближайшие 3 года. Закладывайте структурированные Git-источники.
- Отношение к поиску как к задаче инструмента. Это задача команды. Ни один инструмент не спасёт от команды, не кураторствующей.
Контрарная позиция: большинство команд винят wiki в «хаосе». Это не wiki. Это отказ команды относиться к документации как к инженерному артефакту первого класса с владельцем, процессом ревью и политикой устаревания. Любой из четырёх инструментов работает, когда эти три вещи есть. Ни один — когда их нет.
Честное ограничение
Наши данные сильнейшие по IDE- и Git-активности. Мы видим, где кликают по ссылкам документации и какие исходные файлы открывают во время onboarding — но не меряем качество документации напрямую. Числа по времени поиска — из интервью с клиентами, опубликованных инженерных блогов (Shopify, GitLab, Stripe) и 4 лет наблюдения за выбором клиентов. Ваш пробег будет другим; мерьте собственное время до первого ответа, прежде чем праздновать победу.
Похожие материалы
- Onboarding разработчиков: как метрики показывают ramp-up — сильнейший сигнал продуктивности, связанный с KM
- Design Docs: когда писать, когда пропустить — дополнение к инструментам знаний: документы, которые должны существовать
- Self-Hosted LLM для инженерных команд — почему doc-стратегия влияет на AI-стратегию
- Внешнее: GitLab Handbook — самый изученный публичный пример docs-as-code в масштабе, доступен как референс