На производстве документация важна не меньше, чем сборка, тестирование или упаковка. Когда завод работает в режиме 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 градусов

Есть документы, которые нужно править несколько раз в день и делать это сразу, без ожидания. Например, технолог получает запрос от коллег и не может тратить время на создание задачи и сбор всей сопроводительной информации. Изменения нужны здесь и сейчас.

Чтобы понять, во что это обходится, давайте чуть подробнее разберемся, как у нас устроен стандартный процесс взаимодействия с производством. Ниже — шаги процесса, который мы выстроили и подробно замерили по времени:

1. Создать задачу в таск-менеджере (технолог) — 60-180 cекунд.

2. Отреагировать (техпис) — от одной минуты до в среднем 5,5 часов.

3. «Отколоть» и перейти в рабочую ветку (техпис) — 40-90 cекунд.

4. Добавить элемент списка в DITA-раздел (техпис) — 120-240 cекунд.

5. Создать pull request для слияния в master-ветку и собрать тестовый документ (техпис) — 360-720 cекунд.

6. Ждать просмотра правок и согласования технологом — неизмерима.

7. Добавить правки в master-ветку (техпис) — 60-90 cекунд.

8. Пересобрать документ (техпис) — 360-720 cекунд.

9. Закрыть задачу (техпис) — 10 cекунд.

Хотя мы не можем точно замерить весь цикл изменения документации, минимальное время измеряемых шагов — около 17 минут 20 секунд. При этом само полезное изменение для пользователя занимает всего 2–4 минуты.

В таких случаях мы сталкиваемся с так называемыми незначительными потерями — это ошибки, которые проще и дешевле сразу исправить, чем тратить время на их оформление и прохождение всего стандартного процесса.

Мы дали технологам упрощенную рабочую среду, в которой они самостоятельно могут вносить правки напрямую в исходниках документа. Процесс автоматизирован: при изменении автоматически создается ветка, открывается pull request и запускается согласование. Технические писатели при этом не переписывают документ заново, а лишь проверяют корректность изменений и наличие конфликтов.

Теперь процесс выглядит таким образом: 

1. Открыть среду редактирования (технолог) — 10-30 секунд.

2. Добавить строку в таблицу в DITA-раздел (технолог) — 180-300 секунд.

3. Нажать кнопку Commit (технолог) — 2-5 секунд.

4. Проверить конфликты и обновить редакцию (техпис) — 180-300 секунд.

5. Отправить правки в master-ветку (техпис) — 60-90 секунд.

6. Обновить документ (техпис) — 360-720 секунд.

Сейчас весь процесс измерим, и он занимает от 13 до 24 минут. 

Ранее даже самая простая правка могла «зависнуть» на дни. Все упиралось в ручные действия: создать задачу, сформировать ветку, дождаться свободного окна у техписа, пройти согласование. Эта цепочка превращала микрозадачи в полноценные бюрократические квесты.

Теперь у нас нет неизвестных переменных — а значит, процесс стал управляемым. Более того, в некоторых случаях, когда вносится одна-единственная правка, это даже стало немного дешевле.

Бережливая документация в деле: что мы получили на выходе

Когда мы только начали внедрять практики из бережливого производства в документацию, вопросов было много. Главный из них — не мешает ли это работать? Не превращает ли все в избыточную бюрократию? Не тратим ли мы больше времени на оптимизацию и рефакторинг, чем на сами документы?

Метрики говорят о том, что получилось. Но не стоит забывать: бережливо — это не про «меньше», а про «точнее». Это не про экономию на людях, а про бережное отношение ко времени — своему, коллег и пользователей документации. Мы начали с хаоса, шести человек на сотни документов, срочных задач и ручных процессов, в которых все держалось на личной инициативе и авральных включениях. Теперь у нас — структура, метрики эффективности, процессы и инструменты автоматизации. Все это ради скорости, предсказуемости и устойчивости.

При этом важное осталось на месте: ответственность. Технолог по-прежнему отвечает за содержание, даже если сам внес правку. Техпис отвечает за корректность, даже если он не автор. Мы не переложили ответственность за выполнение задач на других — мы облегчили путь их выполнения.

Потому что когда документ обновляется тогда, когда это нужно, а не когда до него «дойдут руки» — это уже не просто документ, а часть процесса. Живая, полезная, встроенная в работу, а не лежащая мертвым грузом на сервере. И именно такие документы нужны тем, кто работает с реальным железом и сроками.

Чтобы эти принципы можно было не только запомнить, но и использовать на практике, мы собрали их в короткий чек-лист. Его удобно сохранить в телефоне или распечатать и повесить рядом с рабочим местом.

Скачать чек-лист можно по ссылке →

Как будем развивать систему дальше

То, что мы внедрили, уже работает — и стабильно. Но это только начало. Бережливый подход основан на постоянном улучшении, поэтому важно не останавливаться и четко понимать, в каком направлении двигаться дальше.

Во-первых, мы планируем глубже измерять процессы. То, что у нас есть сейчас — хорошее начало, но пока это базовые метрики. Дальше хочется перейти к полноценной аналитике: сколько времени уходит на каждый тип задачи, на каком этапе теряется ритм, где остаются ручные фрагменты. Это позволит точнее выстраивать приоритеты и делать работу еще предсказуемее.

Во-вторых, мы хотим создавать шаблоны и полуавтоматические блоки, которые закроют до половины объема типовой документации. У нас уже есть первые успехи с автоконструктором, и мы видим потенциал в дальнейшем шаблонировании: это и про скорость, и про качество, и про снижение входного порога для новых сотрудников.

Третье направление — формализация взаимодействия с другими командами. Мы наладили ритм с производством и технологами, но теперь хочется выстроить такую же понятную и повторяемую схему с R&D, сервисной службой, логистикой. Так мы обеспечим прозрачность, границы ответственности и устойчивость на уровне всей организации, а не только внутри команды техписов.

Наконец, мы хотим масштабировать удачные практики на другие направления документации: пользовательскую, сервисную, сертификационную. Это потребует адаптации — где-то будет меньше автоматизации, где-то другие форматы, но общий принцип останется: сначала наводим порядок, потом по кругу: измеряем оптимизируем, соблюдаем порядок в нашем рабочем окружении.

Так что «дальше» — это не финал, а новая итерация. То, что уже работает, можно развивать. А то, что пока не работает — адаптировать и внедрить. Главное — не терять ориентацию на то, ради чего все это затевалось: меньше потерь времени, больше ценности для пользователей и документация, которая помогает, а не мешает.