В январе 2025 года к нам пришёл клиент с задачей, которая на первый взгляд выглядела понятно: «У нас 217 регламентов обслуживания оборудования, которые писали в разное время разные люди. Половина устарела, в половине — противоречия друг с другом. Нам нужно за полгода привести их в порядок». В реальности всё оказалось не так очевидно, и сегодня мы расскажем, что мы вынесли из этой истории.
Стартовая диагностика
Первое, чему мы научились на этом проекте: не верьте цифре «217». Когда мы провели инвентаризацию, выяснилось, что часть документов дублируется в трёх разных папках с минимальными отличиями, часть существует только в виде сканов десятилетней давности, а ещё около сорока «регламентов» по факту являются не регламентами, а письмами, в которых руководитель когда-то описал процедуру одному сотруднику.
Поэтому первые две недели мы потратили не на письмо, а на инвентаризацию. На выходе получился реестр на 184 уникальных документа: 142 — действующих, 28 — устаревших, но содержащих фрагменты актуальной информации, и 14 — полностью устаревших, которые можно было закрыть актом.
Архитектура раньше контента
Вторая важная вещь, которую мы поняли быстро: переписывать регламенты по одному, в произвольном порядке — путь в никуда. После первых десяти переписанных документов мы получили такую обратную связь от инженеров: «всё стало лучше, но мы не понимаем, где что искать». Структура хранилища оказалась важнее, чем качество отдельного документа.
Мы остановили писательскую работу, провели сессию с тремя ведущими инженерами клиента и спроектировали архитектуру разделов: оборудование → тип процедуры → роль исполнителя. У каждого документа появились метки и владелец. После того, как структура была готова, скорость переписывания выросла почти втрое.
«До этого проекта мы думали, что хорошая документация — это хорошо написанный документ. Сейчас я знаю: хорошая документация — это хорошо устроенное хранилище и нормальные процессы вокруг него.»
Парная работа аналитик-писатель
Мы попробовали два режима: один писатель на один регламент и пара аналитик-плюс-писатель. Парный режим оказался эффективнее в 1,8 раза по скорости и заметно лучше по качеству. Аналитик собирал контекст с инженером клиента, готовил скелет и черновик схем; писатель приводил это в финальный вид и проходил литературное редактирование.
Раздельная роль особенно помогла в случаях, когда инженер клиента был перегружен. Аналитику было удобнее «вытягивать» знания в коротких 20-минутных сессиях, а писатель в это время работал автономно — это сильно облегчало календарь обеим сторонам.
Ревью без эмоций
Ещё одна точка, которая чуть не сорвала проект: первые недели ревью документов превращались в эмоциональные обсуждения. Один из инженеров считал, что «так писать нельзя», другой — что «надо именно так». Мы остановились, ввели формальный чек-лист ревью и шкалу оценки. После этого обсуждения шли быстрее, а решения принимались за минуты, а не за полтора часа.
Что сработало
Если суммировать, что мы вынесли из проекта в виде готовых правил:
- Инвентаризация перед письмом обязательна — цифры заказчика почти всегда нужно проверять.
- Архитектура хранилища важнее качества отдельного документа.
- Парная работа аналитик-писатель сильно эффективнее одиночной.
- Чек-лист ревью спасает от эмоциональных обсуждений.
- Срок ревизии — обязательное поле в каждом документе, иначе через полгода история повторится.
Что не сработало
Не всё было гладко. Например, мы переоценили, насколько быстро инженеры клиента смогут согласовывать документы. Когда у людей основная работа — производство, а не документация, ждать ревью два-три рабочих дня — нормально. Мы заложили в план полтора, и в начале проекта это создавало напряжение.
Второе, что не сработало — попытка унифицировать стиль всех документов сразу. Мы стартовали с амбицией «вся документация на одном языке». В реальности это потребовало бы переписать литературно даже те регламенты, которые по сути были в порядке. От этой идеи мы отказались и сделали стиль-гайд, по которому будут выровнены только новые и обновляемые документы.
Сейчас, через год после старта, обновлённая база живёт без нас: квартальные ревизии проходят силами самой команды клиента, метрики «здоровья» базы остаются в зелёной зоне. Это и есть для нас критерий, что проект состоялся.
