На производстве документация важна не меньше, чем сборка, тестирование или упаковка. Когда завод работает в режиме 24/7, а у сотрудников нет времени на раздумья, инструкции становятся их основным инструментом. По ним собирают, комплектуют, тестируют и проверяют оборудование. От того, насколько понятна и точна документация, зависит не только скорость работы, но и ее безопасность. Чтобы все это работало без сбоев, инструкции должны быть простыми, доступными и всегда под рукой.
Давайте знакомиться. Я Иван Холодков, старший технический писатель направления производственной документации в YADRO. В этой статье я расскажу, как мы адаптировали Lean к процессам разработки документов: где теряли время, как наводили порядок, что автоматизировали и почему стандарты стали опорой. Тут про реальный опыт, метрики, сложности и решения, которые помогли нам существенно упростить рабочие процессы без ущерба для качества документов и сделали нашу документацию частью живого производственного процесса.

Принципы бережливого подхода
Термин «бережливая разработка документации» я придумал при подготовке этой темы к выступлению на TechWriters Days. Это попытка связать практики бережливого производства (Lean Manufacturing) с процессами работы над технической документацией.
Прямая отсылка к «бережливости» не случайна: до перехода в команду техписов я сам работал инженером-технологом, участвовал в оптимизации производственных процессов и был хорошо знаком с философией Lean. Перенеся этот опыт в область документации, я обнаружил, что принципы бережливого подхода отлично работают и здесь — от стандартизации до постоянного улучшения.
Философия Lean — это подход к управлению, направленный на сокращение затрат при сохранении/повышении ценности для конечного потребителя. Главная цель Lean — устранение всех видов потерь и неэффективности в процессах.
Ключевые принципы Lean включают: ориентацию на потребителя, непрерывное улучшение, вовлечение сотрудников, выстраивание потоков ценности и быстрое реагирование на изменения.
Изначально Lean возник как часть производственной системы Toyota (которая, в свою очередь, использовала наработки ЦИТ СССР), но со временем его начали применять в самых разных отраслях — от промышленности и логистики до IT, здравоохранения и услуг.
Когда речь заходит о бережливом производстве, на ум приходит система 5S — это пять базовых принципов, направленных на организацию эффективного и чистого рабочего пространства. Но в нашем случае это пространство — не производственный цех, а рабочее окружение (исходники, инструменты), которые мы используем для создания и сопровождения документации. Тем не менее, для техписов система 5S «лечит» те же проблемы, что и на заводе: хаос в исходниках, потеря времени на рутину и невозможность быстро сориентироваться в потоке задач.
На производстве Lean и документация тесно переплетены. Инструкция — это не просто сопроводительный файл, а полноценный инструмент в системе бережливого производства. От того, насколько точно и понятно она написана, напрямую зависит скорость и качество выпускаемого продукта.
Проблема, когда ресурсы ограничены: в команде всего шесть технических писателей, а нам необходимо обеспечивать своевременную поставку качественной документации для двух производственных площадок. Объем в ~1200 документов, постоянные изменения на производстве и высокая нагрузка делают процесс уязвимым. Любая задержка публикации или ошибка в документе напрямую влияет на производственные операции. В результате страдают производственные подразделения: задержки или ошибки в документации приводят к потере времени, сбоям в операциях и росту производственных рисков.
Мы стали искать подход, чтобы выпускать документацию быстрее, не снижая ее качества. Так и появилась идея «бережливой документации». Чтобы сделать работу с документацией устойчивой, быстрой и прозрачной, мы адаптировали принципы производственной методологии 5S под задачи технических писателей. Но, прежде чем наводить порядок, мы создали и перенесли документы в отдельный репозиторий.
1. Стандартизация (Seiketsu)
Внутренняя работа техписов была неструктурированной: при наличии большого объема документации — более 1200 документов только на производственном портале — приходилось иметь дело с множеством исходников. Их поиск занимал много времени, а единых подходов к оформлению не существовало. Все это замедляло выполнение задач и мешало команде работать слаженно. Чтобы навести порядок в задачах, мы с командой:
Ввели единый стиль оформления задач, документов и исходников.
Определили правила именования файлов, веток, структуры репозитория.
Согласовали формат взаимодействия внутри команды.
В команде разработали и зафиксировали внутренний стайлгайд, который (важно!) мы постоянно изменяем, если правки снижают наши потери.

Мы начали шире использовать возможности языка разметки, что позволило сократить объем повторяющегося кода и сделать его более читаемым и удобным для поддержки.

Стандарты позволили работать в одном ритме, сократили число недопониманий и ошибок. Команда начала говорить «на одном языке». Это дало прирост скорости, упростило делегирование и уравняло качество и содержание документов для разных процессов производства и продуктов.
Большие изображения могут замедлять загрузку инструкции, например у сборщика. А это уже прямые потери времени на производстве, где каждая секунда — деньги. Кроме того, неоднородная композиция изображений портила читаемость и замедляла восприятие информации. Мы убрали визуальный шум и ускорили работу:
Ввели правила обработки изображений: набор фиксированных размеров, формат, плотность.
Стандартизировали визуальный стиль (рамки, шрифты, композиция).
Удалили лишние детали — обесцветили яркие элементы и расфокусировали то, что не должно отвлекать внимание.
Мы обеспечили контролируемую скорость загрузки документации, установив ограничение на размер изображений. Улучшилось восприятие документации, снизилась нагрузка на портал, а производственные процессы ускорились. Визуальный порядок стал частью культуры качества — как внутри команды, так и для внешних пользователей.
Раньше каждый новый технический писатель вникал в процессы в ходе работы. Это было неустойчиво: занятость или отпуск одного куратора могли тормозить онбординг новичка. Мы сделали процессы независимыми от людей:
Зафиксировали архитектуру репозитория и описали, как он устроен.
Подготовили подробные инструкции для новых участников.
Внесли эти знания в базу: гайды, онбординг-документы.
В итоге обеспечили преемственность и обмен знаниями между сотрудниками. Процесс стал независимым от конкретных людей. Новички начали быстрее включаться в работу. Команда больше не зависела от «устной памяти» и не боялась отпусков и ротаций. Знания — формализованы и доступны.
Если хотите стать частью команды технических писателей с интересными задачами и организованными процессами, эта вакансия может вас заинтересовать →
2. Сортировка (Seiri)
Внутри репозитория есть единый источник, где техписы всей компании хранят инструкции. Объем документации был настолько велик и разрознен, что любое изменение грозило затронуть другие продукты. Это ограничивало гибкость: техписы не могли безопасно править документы без риска «сломать» чужой. Мы расчистили себе пространство для работы:
Создали отдельный репозиторий под производственную документацию. Когда приходит задача на руководство по сборке, мы просто обращаемся к нужному блоку контента и переиспользуем его.
Перенесли туда только необходимое, удалили лишнее и устаревшее.
Настроили новую структуру — упорядоченную и логичную.
Среда техписов, работающих с производственной документацией, стала чистой, прозрачной и предсказуемой. Теперь каждое изменение — под контролем, структура логична, ничего не теряется и не ломается. Это стало прочной базой для автоматизации.
Далее — три принципа, которые не проходят один раз, а работают постоянно. Это уже не этапы, а устойчивый режим, в котором живет команда каждый день.
3. Содержание в чистоте (Seiso)
Если документ больше не используется, мы удаляем его исходники — так репозиторий остается чистым, а сборка документации идет быстрее. Чтобы этого добиться, мы:
Настроили процесс отслеживания неактуальных документов.
Ввели регулярную проверку на востребованность контента.
Репозиторий стал контролируемым, а его структура еще более понятной, сборка документов ускорилась, техписам стало проще ориентироваться в рабочем пространстве.
4. Соблюдение порядка (Seiton)
Мы устроили документацию так, чтобы с ней было легче работать не только вручную, но и автоматически. Структура стала предсказуемой, правила — прозрачными, а логика — формализованной.
Это дало нам возможность перейти от ручной рутины к инструментам, которые берут часть работы на себя. Вместе с командой DocOps мы разработали систему автоматического конструктора документации, которая формирует инструкции под конкретную модель оборудования. Как она работает, расскажет мой коллега в статье, которая выйдет через неделю.
5. Совершенствование (Shitsuke)
Мы добавили инструменты, которые позволяют отслеживать задачи в разных статусах («ожидание», «в работе», «согласование» и т. д.), собрали статистику и получили 16,5 часов времени реагирования. Это много с учетом того, что у нас есть задачи, которые необходимо выполнить в день их появления. Чтобы сократить время, создали систему приоритизации задач:
Ввели ротацию дежурного техписа для оперативного реагирования на критичные задачи. Дежурства прохоядт ежедневно: с 10:00 до 19:00 техписы должны быть на связи — это активное время для заводов. Если от технолога поступает задача с высоким приоритетом, дежурный берет ее в работу немедленно. Каждый производственный техпис дежурит один день в неделю по расписанию. У меня, например, это вторник.
Вместе с технологами мы договорились, какие задачи нужно делать в первую очередь. Все зависит от того, как сильно они влияют на производство, — могут ли из-за задержки остановиться рабочие процессы.
Выстроили ежедневный ритм работы с четкими правилами. Все договоренности согласованы с технологами — теперь взаимодействие стало предсказуемым и организованным.
Это позволило снизить среднее время реакции на срочные правки (время между моментом появления задачи и взятием ее в работу) почти до 5,5 часов. Раньше такие задачи нередко «подвисали» между отделами, теперь — нет. Есть дежурный и правила реакции на такие задачи.
В течение второй половины 2024 года мы снизили среднее время на решение задачи в 3 раза — до 2,5 дней. Это усредненное значение: срочные задачи решаются в день обращения, тогда как несрочные могут закрываться в течение 1–2 недель.

Метрики показали: документы стали появляться быстрее, число улучшений в документации — расти, а нагрузка — распределяться.
В итоге у нас появился измеримый процесс работы с срочными задачами — а значит, теперь мы можем его контролировать. Работа стала стабильнее, а число незакрытых или просроченных тикетов заметно сократилось.
Переворачиваем процессы на 180 градусов
Есть документы, которые нужно править несколько раз в день и делать это сразу, без ожидания. Например, технолог получает запрос от коллег и не может тратить время на создание задачи и сбор всей сопроводительной информации. Изменения нужны здесь и сейчас.
Чтобы понять, во что это обходится, давайте чуть подробнее разберемся, как у нас устроен стандартный процесс взаимодействия с производством. Ниже — шаги процесса, который мы выстроили и подробно замерили по времени:
Создать задачу в таск-менеджере (технолог) — 60-180 cекунд.
Отреагировать (техпис) — от одной минуты до в среднем 5,5 часов.
«Отколоть» и перейти в рабочую ветку (техпис) — 40-90 cекунд.
Добавить элемент списка в DITA-раздел (техпис) — 120-240 cекунд.
Создать pull request для слияния в master-ветку и собрать тестовый документ (техпис) — 360-720 cекунд.
Ждать просмотра правок и согласования технологом — неизмерима.
Добавить правки в master-ветку (техпис) — 60-90 cекунд.
Пересобрать документ (техпис) — 360-720 cекунд.
Закрыть задачу (техпис) — 10 cекунд.
Хотя мы не можем точно замерить весь цикл изменения документации, минимальное время измеряемых шагов — около 17 минут 20 секунд. При этом само полезное изменение для пользователя занимает всего 2–4 минуты.
В таких случаях мы сталкиваемся с так называемыми незначительными потерями — это ошибки, которые проще и дешевле сразу исправить, чем тратить время на их оформление и прохождение всего стандартного процесса.
Мы дали технологам упрощенную рабочую среду, в которой они самостоятельно могут вносить правки напрямую в исходниках документа. Процесс автоматизирован: при изменении автоматически создается ветка, открывается pull request и запускается согласование. Технические писатели при этом не переписывают документ заново, а лишь проверяют корректность изменений и наличие конфликтов.

Теперь процесс выглядит таким образом:
Открыть среду редактирования (технолог) — 10-30 секунд.
Добавить строку в таблицу в DITA-раздел (технолог) — 180-300 секунд.
Нажать кнопку Commit (технолог) — 2-5 секунд.
Проверить конфликты и обновить редакцию (техпис) — 180-300 секунд.
Отправить правки в master-ветку (техпис) — 60-90 секунд.
Обновить документ (техпис) — 360-720 секунд.
Сейчас весь процесс измерим, и он занимает от 13 до 24 минут.
Ранее даже самая простая правка могла «зависнуть» на дни. Все упиралось в ручные действия: создать задачу, сформировать ветку, дождаться свободного окна у техписа, пройти согласование. Эта цепочка превращала микрозадачи в полноценные бюрократические квесты.
Теперь у нас нет неизвестных переменных — а значит, процесс стал управляемым. Более того, в некоторых случаях, когда вносится одна-единственная правка, это даже стало немного дешевле.
Бережливая документация в деле: что мы получили на выходе
Когда мы только начали внедрять практики из бережливого производства в документацию, вопросов было много. Главный из них — не мешает ли это работать? Не превращает ли все в избыточную бюрократию? Не тратим ли мы больше времени на оптимизацию и рефакторинг, чем на сами документы?
Метрики говорят о том, что получилось. Но не стоит забывать: бережливо — это не про «меньше», а про «точнее». Это не про экономию на людях, а про бережное отношение ко времени — своему, коллег и пользователей документации. Мы начали с хаоса, шести человек на сотни документов, срочных задач и ручных процессов, в которых все держалось на личной инициативе и авральных включениях. Теперь у нас — структура, метрики эффективности, процессы и инструменты автоматизации. Все это ради скорости, предсказуемости и устойчивости.
При этом важное осталось на месте: ответственность. Технолог по-прежнему отвечает за содержание, даже если сам внес правку. Техпис отвечает за корректность, даже если он не автор. Мы не переложили ответственность за выполнение задач на других — мы облегчили путь их выполнения.
Потому что когда документ обновляется тогда, когда это нужно, а не когда до него «дойдут руки» — это уже не просто документ, а часть процесса. Живая, полезная, встроенная в работу, а не лежащая мертвым грузом на сервере. И именно такие документы нужны тем, кто работает с реальным железом и сроками.
Чтобы эти принципы можно было не только запомнить, но и использовать на практике, мы собрали их в короткий чек-лист. Его удобно сохранить в телефоне или распечатать и повесить рядом с рабочим местом.
Скачать чек-лист можно по ссылке →
Как будем развивать систему дальше
То, что мы внедрили, уже работает — и стабильно. Но это только начало. Бережливый подход основан на постоянном улучшении, поэтому важно не останавливаться и четко понимать, в каком направлении двигаться дальше.
Во-первых, мы планируем глубже измерять процессы. То, что у нас есть сейчас — хорошее начало, но пока это базовые метрики. Дальше хочется перейти к полноценной аналитике: сколько времени уходит на каждый тип задачи, на каком этапе теряется ритм, где остаются ручные фрагменты. Это позволит точнее выстраивать приоритеты и делать работу еще предсказуемее.
Во-вторых, мы хотим создавать шаблоны и полуавтоматические блоки, которые закроют до половины объема типовой документации. У нас уже есть первые успехи с автоконструктором, и мы видим потенциал в дальнейшем шаблонировании: это и про скорость, и про качество, и про снижение входного порога для новых сотрудников.
Третье направление — формализация взаимодействия с другими командами. Мы наладили ритм с производством и технологами, но теперь хочется выстроить такую же понятную и повторяемую схему с R&D, сервисной службой, логистикой. Так мы обеспечим прозрачность, границы ответственности и устойчивость на уровне всей организации, а не только внутри команды техписов.
Наконец, мы хотим масштабировать удачные практики на другие направления документации: пользовательскую, сервисную, сертификационную. Это потребует адаптации — где-то будет меньше автоматизации, где-то другие форматы, но общий принцип останется: сначала наводим порядок, потом по кругу: измеряем оптимизируем, соблюдаем порядок в нашем рабочем окружении.
Так что «дальше» — это не финал, а новая итерация. То, что уже работает, можно развивать. А то, что пока не работает — адаптировать и внедрить. Главное — не терять ориентацию на то, ради чего все это затевалось: меньше потерь времени, больше ценности для пользователей и документация, которая помогает, а не мешает.
Elpi
Вы, как я понял, редчайший подвид техписа - бывший производственник. Который изнутри понимает процессы. Это заставило меня внимательнее вчитаться в текст.
Практически все уже давно используется. Из-за большого объема вы пошли на автоматизацию. Не уверен, что это делает доки удобочитаемыми, но если необходимо.
Возникли вопросы, если позволите:
Вы упомянули о "плотности" изображения. Можно пояснить, что под этим понимается?
Упомянуто об ограничениях на размер иллюстрации. Какое это ограничение? чем вы снимаете скриншоты? И не увидел упоминания о том, что форму (окно) необходимо подготовить, сплошь и рядом там много "воды".
Наконец, о перспективах. Вы пишите "формализация взаимодействия". Это мечта любого начальника. Бюрократ полагает, что чем больше собирается данных (отчетности), тем будет лучше. Не факт, тут еще надо убедиться, что он сможет эти данные эффективно осмыслять. А пока врачи, учителя и ваши техписы тратят много времени. Можете подробнее пояснить, почему вы полагаете формализацию ключом к успеху?