IT-компании любят говорить, что у них «всё задокументировано». На практике это означает: где-то есть Confluence, в который последний раз заходили полгода назад, README в репозитории написан стажёром в 2021-м, а реальные знания живут в головах трёх сеньоров и в пятидесяти закреплённых сообщениях в Slack.
Когда один из этих сеньоров уходит — проект «осиротевает». Новичок смотрит в код, открывает пустую вики, пишет в чат: «ребята, а как деплоить?» — и получает в ответ «@Вася знает, но он в отпуске до понедельника». Знакомо?
В этом кейсе — история IT-компании, которая создала базу знаний компании с нуля. Не формально, не «для галочки», а так, чтобы новички реально могли работать самостоятельно с первой недели.
Кейс: IT-компания (заказная разработка), ~30 сотрудников, 4 года на рынке. Проблема: онбординг 2 месяца, знания только в головах, уход сеньора = провал проекта. После создания базы знаний: онбординг сократился до 2 недель, повторяющиеся вопросы в чатах снизились на 70%, тимлид экономит ~8 часов в неделю на объяснениях.
Хочу навести порядок в знаниях — записаться на консультацию
Клиент
IT-компания из Москвы. Профиль — заказная разработка: веб-сервисы, мобильные приложения, интеграции. Работают с 2020 года, выросли с 5 фрилансеров до штата в 30 человек. В команде — два проектных менеджера, 15 разработчиков (от джуниоров до сеньоров), тестировщики, дизайнер, DevOps и небольшой отдел продаж.
Компания стабильно росла: клиенты приходили по рекомендациям, проекты сдавались вовремя — пока в команде были люди, которые «всё знают». Но рост команды обнажил системную проблему: знания не масштабируются вместе с людьми.
Основатель — бывший техлид, который привык решать проблемы лично. Он знал архитектуру каждого проекта, помнил все договорённости с клиентами, лично ревьюил код ключевых фич. Когда в компании стало 30 человек — этот подход начал трещать по швам.
Проблемы: что ломалось без базы знаний
Когда компания обратилась к нам в Systemmatica, симптомы были типичными для IT-компании на стадии масштабирования. Но за каждым симптомом стояла конкретная потеря денег и времени.
1. Онбординг — два месяца «теней»
Каждый новый разработчик первый месяц ходил «тенью» за опытным коллегой. Задавал вопросы, смотрел через плечо, пытался разобраться в проекте по коду. Второй месяц — уже работал, но с постоянными вопросами: «А где конфиг для стейджа?», «Как запустить миграции?», «Кто отвечает за код-ревью этого модуля?»
Реальная продуктивность нового сотрудника начиналась через 8-10 недель. А опытный разработчик, к которому прикрепляли новичка, терял около 30% своего рабочего времени.
Пример: «Где пароль от стейджа?»
В Slack-канале #general один и тот же вопрос задавали минимум раз в две недели. Разные люди, один и тот же ответ. Иногда ответ находили в закреплённых сообщениях, иногда — нет (потому что кто-то перезакрепил другое). Иногда пароль успел поменяться, а обновить информацию забыли. Умножь это на десятки подобных вопросов — и получишь картину ежедневного информационного хаоса.
2. Знания только в головах сеньоров
В компании работали три сеньора-разработчика, каждый из которых «держал» по 2-3 ключевых проекта. Архитектурные решения, особенности клиентской инфраструктуры, хитрые баги, которые всплывали раз в полгода, — всё это существовало только в их памяти.
Джуниор не мог самостоятельно решить нетривиальную задачу. Даже мидлы часто простаивали, потому что «Женя в отпуске, а он единственный знает, как устроен биллинг».
3. Уход сотрудника = катастрофа
Полгода назад из компании ушёл ведущий разработчик. Проект, который он вёл — мобильное приложение для логистической компании — «подвис» на три недели. Новый разработчик потратил это время, чтобы разобраться в коде без документации: ковырял git log, искал логику в тестах (которых было мало), переписывался с клиентом, пытаясь восстановить бизнес-требования.
Клиент остался недоволен. Компания потеряла деньги — и едва не потеряла контракт.
Цена «незаменимого» сотрудника: когда из IT-компании уходит человек без передачи знаний, восстановление контекста занимает 2-4 недели рабочего времени другого специалиста. Это минимум 150-200 тыс. рублей прямых потерь — не считая рисков для клиентского контракта и репутации.
4. Замкнутый круг неактуальной документации
У компании был Confluence. Его создали два года назад на волне энтузиазма: написали десяток статей про архитектуру, настроили разделы. Через три месяца большая часть статей устарела. Кто-то обновил версию фреймворка, кто-то поменял процесс деплоя — а в Confluence осталась старая информация.
Началась эрозия доверия: «Зачем смотреть в вики, если там всё неактуально?» Раз люди не смотрят — зачем обновлять? Раз никто не обновляет — инструмент окончательно умирает. Классический замкнутый круг.
Замкнутый круг документации: «зачем смотреть — там неактуально» → «раз не смотрят — зачем обновлять» → «раз не обновляют — точно не стоит смотреть». Разорвать этот круг можно только одним способом: назначить ответственного за актуальность и внедрить привычку обновлять при каждом изменении.
5. Одни и те же вопросы в чатах
Мы попросили выгрузить статистику по Slack за последний месяц. Результат: около 40% вопросов в рабочих каналах — повторяющиеся. «Как настроить локальное окружение для проекта X?» «Где взять тестовые данные?» «Какой формат коммит-месседжей?» «Как запросить ревью?»
Каждый такой вопрос — 5-15 минут чьего-то времени. Умножаем на 40% от всех вопросов, на 30 человек, на рабочий месяц — и получаем десятки потерянных часов.
Решение: как мы создали базу знаний
Работа заняла два месяца в формате систематизации бизнеса: два интервью в неделю с ключевыми сотрудниками — от основателя до DevOps-инженера. Мы не просили команду «написать документацию». Мы задавали вопросы, фиксировали ответы и превращали их в систему.
Шаг 1. Описали процессы «как есть»
Первый и самый важный принцип: описывать не идеальные процессы, а реальные. Не «как должно быть по ITIL», а «как Женя на самом деле деплоит на прод в пятницу вечером».
Мы провели интервью с каждым тимлидом и записали реальные рабочие процессы: как берут задачу из трекера, как делают ревью, как деплоят, как общаются с клиентами, как передают проект. Всё — с конкретными шагами, инструментами и типичными ошибками.
Почему не идеальные? Потому что идеальные процессы никто не будет выполнять — они оторваны от реальности. А реальные — это то, что люди уже делают. Осталось только зафиксировать, убрать лишнее и стандартизировать.
Лайфхак: любая инструкция — это актив. Даже криво написанная. Лучше иметь неидеальную документацию, которую можно улучшить, чем не иметь никакой. Начни с записи того, что есть — отшлифовать можно потом.
Шаг 2. Выбрали структуру: по проектам + по функциям
Типичная ошибка — строить базу знаний только по проектам ИЛИ только по функциям. Мы сделали гибрид.
Проектный раздел: у каждого проекта — своя страница с архитектурой, контактами клиента, особенностями инфраструктуры, известными багами и историей решений. Когда новый разработчик подключается к проекту — он начинает с этой страницы.
Функциональный раздел: сквозные процессы, которые одинаковы для всех проектов. Как деплоить. Как проводить код-ревью. Как вести онбординг новичка. Как написать регламент. Как общаться с клиентом при инциденте.
Раздел быстрых ссылок: все конфиги, пароли, доступы, ссылки на мониторинг, ссылки на Jira-борды — одной страницей. То, что люди ежедневно ищут в чатах и просят коллег скинуть.
Шаг 3. Начали с того, что больше всего бесит
Мы не стали описывать все 50 процессов компании. Начали с двух, которые причиняли максимум боли: онбординг и деплой.
Онбординг. Создали пошаговый чек-лист: настройка окружения, доступы к репозиториям, знакомство с архитектурой, первая задача. К каждому пункту — ссылки на инструкции. Новичок открывает чек-лист и проходит его самостоятельно. Вопросы к тимлиду — только если инструкция не покрывает ситуацию. Подробнее о системе адаптации — в нашей статье про онбординг сотрудников.
Деплой. Каждый проект получил свою инструкцию по деплою: какие ветки, какие команды, какие проверки перед и после. Больше никаких «спроси Васю» — всё написано.
Приоритетная детализация в действии
Из 50+ процессов компании мы начали с двух: онбординг и деплой. Через месяц — добавили код-ревью, работу с клиентами и инцидент-менеджмент. Ещё через месяц — остальное. Такой подход даёт быстрый результат: уже через 2 недели новые сотрудники начали проходить онбординг самостоятельно, а деплой перестал быть «магическим ритуалом одного человека».
Шаг 4. Добавили тесты для закрепления знаний
Написать инструкцию — половина дела. Вторая половина — убедиться, что её прочитали и поняли. Мы создали тесты по ключевым разделам базы знаний: онбординг, деплой, работа с клиентами, код-стайл.
Почему это важно? Потому что некоторые люди банально не читают регламенты. Они открывают, пролистывают — и закрывают. А когда есть тест, который нужно пройти — хотя бы при прохождении прочитают. Тесты — это не экзамен с оценками. Это инструмент закрепления знаний.
Новичок проходил тесты в конце первой недели. Если что-то завалил — перечитывал раздел и проходил снова. Тимлид видел результаты и понимал, где пробелы — не через месяц на продакшене, а сразу.
Шаг 5. Назначили ответственного за актуальность
Самый критичный шаг — и самый недооценённый. Мы назначили конкретного человека (в данном случае — одного из тимлидов) ответственным за актуальность базы знаний. Не «все вместе поддерживаем», а конкретный человек с конкретной задачей.
Его обязанности:
- Раз в неделю проверять, были ли изменения в процессах (новый фреймворк, изменение деплоя, новый клиент)
- Следить за хэштегом #kb-update в Slack — каждый, кто меняет процесс, обязан написать короткий апдейт с этим тегом
- Раз в месяц ревьюить всю базу знаний на предмет устаревших инструкций
Механика обновлений: при любом изменении процесса сотрудник пишет в Slack с хэштегом #kb-update: «Поменял процесс деплоя проекта X — теперь через GitHub Actions вместо ручного скрипта». Ответственный за базу знаний раз в неделю пробегается по хэштегу и обновляет инструкции. Просто, дёшево, работает.
Шаг 6. Интегрировали в ежедневную работу
База знаний бесполезна, если к ней не обращаются. Мы встроили её в рабочие процессы:
- Онбординг: чек-лист нового сотрудника начинается со ссылки на базу знаний. Первый день = чтение ключевых разделов + прохождение тестов
- Код-ревью: если ревьюер видит нарушение стандарта — он не объясняет, а кидает ссылку на соответствующую инструкцию
- Стендапы: «Я обновил инструкцию по работе с API клиента X» — стало обычной фразой на ежедневных митингах
- Инцидент-менеджмент: после каждого серьёзного бага — пост-мортем с обновлением базы знаний (раздел «Known Issues» проекта)
Ключевой принцип: база знаний компании — не архив, а рабочий инструмент. Если к ней не обращаются ежедневно — значит, что-то не так со структурой или актуальностью.
Результаты: что изменилось
Замеры сделали через три месяца после запуска базы знаний. Вот конкретные цифры.
Онбординг: с 2 месяцев до 2 недель
Новый разработчик теперь выходит на полную продуктивность за 10-14 рабочих дней. Первая неделя — изучение базы знаний, прохождение тестов, настройка окружения по инструкции. Вторая неделя — первые реальные задачи с минимальной поддержкой тимлида.
Сравни: раньше это занимало 8-10 недель, и опытный разработчик терял 30% своего времени на наставничество.
Реакция новичков
Первый разработчик, который проходил онбординг по новой системе, сказал на ретроспективе: «Ого, как у вас всё системно. На прошлой работе я два месяца разбирался, где что лежит. Тут за неделю стало понятно». Это цитата, которую теперь используют на собеседованиях — и она реально помогает привлекать сильных кандидатов.
Повторяющиеся вопросы: -70%
Через три месяца провели повторный анализ Slack. Количество повторяющихся вопросов снизилось на 70%. Оставшиеся 30% — это в основном нестандартные ситуации, которые действительно требуют обсуждения (и которые потом добавлялись в базу знаний).
Вместо «а как деплоить?» теперь пишут: «В инструкции по деплою проекта X шаг 5 устарел — я обновил, проверьте». Это принципиально другой уровень коммуникации.
Уход сеньора: проект не пострадал
Через два месяца после создания базы знаний из компании ушёл один из сеньоров (по личным причинам, в другой город). Раньше это была бы катастрофа — полгода назад аналогичный случай стоил компании трёх недель простоя и одного недовольного клиента.
На этот раз передача заняла три дня. Проектная документация уже была в базе знаний. Сеньор дополнил пару специфичных моментов — и новый разработчик подхватил проект без провала. Клиент даже не заметил смену команды.
Тимлид экономит 8 часов в неделю
До создания базы знаний тимлид тратил в среднем 1.5-2 часа в день на объяснения: отвечал на вопросы, показывал «как это делается», восстанавливал контекст для коллег. Это 8-10 часов в неделю — целый рабочий день.
Теперь большинство вопросов закрывается ссылкой на инструкцию. Тимлид занимается тем, чем должен: архитектурой, код-ревью, развитием команды. А рутинные объяснения делает база знаний компании.
Итог: база знаний — это не «документация ради документации». Это инструмент, который напрямую влияет на скорость роста компании. Быстрый онбординг → быстрее нанимаешь → быстрее растёшь. Независимость от конкретных людей → устойчивость бизнеса. Меньше рутинных вопросов → больше продуктивного времени.
Пять принципов, которые сработали
По итогам проекта мы сформулировали принципы, которые применимы к любой IT-компании (и не только IT).
1. Описывай реальное, не идеальное
Забудь про «best practices из книжек». Описывай, как работа делается прямо сейчас. Реальный процесс с костылями — лучше, чем идеальный процесс, который никто не выполняет. Оптимизировать можно потом — когда зафиксируешь текущее состояние.
2. Начинай с боли, не с полноты
Не пытайся описать всё и сразу. Начни с процессов, которые вызывают больше всего проблем. Обычно это онбординг, деплой и работа с клиентами. Остальное — итеративно, по мере необходимости.
3. Назначь владельца
«Все вместе поддерживаем» = никто не поддерживает. Один конкретный человек должен отвечать за актуальность. Это не значит, что он пишет всё сам — но он следит, что информация не устаревает.
4. Тесты — обязательно
Написать инструкцию — 50% работы. Убедиться, что её прочитали и поняли — остальные 50%. Тесты — самый дешёвый способ это гарантировать.
5. Обновления — через систему, не через совесть
Не надейся, что люди будут обновлять документацию по доброй воле. Встрой механику: хэштег для изменений, еженедельный обзор, обновление как часть Definition of Done для задач.
Золотое правило: если процесс изменился, но инструкция не обновлена — это баг. Такой же, как баг в коде. И относиться к нему нужно так же серьёзно: фиксить сразу, а не «когда-нибудь потом».
Что дальше: база знаний как фундамент
Создание базы знаний — это не конечная точка, а фундамент для дальнейшей систематизации бизнеса. Следующие шаги для этой компании:
- Система учёта (CRM): базу знаний подключили к CRM — теперь менеджер при открытии сделки видит ссылку на проектную документацию
- Дашборды: метрики по базе знаний — какие разделы читают чаще всего, какие устарели, где пробелы
- Масштабирование: когда структура базы знаний отработана — её легко расширять на новые проекты и процессы
Сейчас компания продолжает расти: за последние полгода наняли ещё 8 человек, и каждый из них прошёл онбординг по базе знаний — без «теней» и без потери продуктивности опытных разработчиков.
Начни с аудита
Если узнал свою компанию в этом кейсе — начни с простого: посмотри, сколько повторяющихся вопросов задают в рабочих чатах за неделю. Если больше 10 — у тебя проблема с управлением знаниями. И её решение — не «давайте все будем документировать», а системный подход: структура, приоритеты, ответственный, тесты.
В Systemmatica мы помогаем IT-компаниям и digital-агентствам строить такие системы — от базы знаний до полной систематизации процессов. Если хочешь разобраться, с чего начать — приходи на бесплатную консультацию.
