На производстве документация важна не меньше, чем сборка, тестирование или упаковка. Когда завод работает в режиме 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, сервисной службой, логистикой. Так мы обеспечим прозрачность, границы ответственности и устойчивость на уровне всей организации, а не только внутри команды техписов.
Наконец, мы хотим масштабировать удачные практики на другие направления документации: пользовательскую, сервисную, сертификационную. Это потребует адаптации — где-то будет меньше автоматизации, где-то другие форматы, но общий принцип останется: сначала наводим порядок, потом по кругу: измеряем оптимизируем, соблюдаем порядок в нашем рабочем окружении.
Так что «дальше» — это не финал, а новая итерация. То, что уже работает, можно развивать. А то, что пока не работает — адаптировать и внедрить. Главное — не терять ориентацию на то, ради чего все это затевалось: меньше потерь времени, больше ценности для пользователей и документация, которая помогает, а не мешает.