Как организовать порядок в документации по философии Lean: чек-лист для техписа

Термин «бережливая разработка документации» я придумал при подготовке этой темы к выступлению на TechWriters Days. Это попытка связать практики бережливого производства (Lean Manufacturing) с процессами работы над технической документацией.

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

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

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

Мы стали искать подход, чтобы выпускать документацию быстрее, не снижая ее качества. Так и появилась идея «бережливой документации». Чтобы сделать работу с документацией устойчивой, быстрой и прозрачной, мы адаптировали принципы производственной методологии 5S под задачи технических писателей.

Прежде чем наводить порядок, мы создали и перенесли документы в отдельный репозиторий.

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

• Ввели единый стиль оформления задач, документов и исходников.
• Определили правила именования файлов, веток, структуры репозитория.
• Согласовали формат взаимодействия внутри команды.

В команде разработали и зафиксировали внутренний стайлгайд, который (важно!) мы постоянно изменяем, если правки снижают наши потери.

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

Стандарты позволили работать в одном ритме, сократили число недопониманий и ошибок. Команда начала говорить «на одном языке». Это дало прирост скорости, упростило делегирование и уравняло качество и содержание документов для разных процессов производства и продуктов.

Большие изображения могут замедлять загрузку инструкции, например у сборщика. А это уже прямые потери времени на производстве, где каждая секунда — деньги. Кроме того, неоднородная композиция изображений портила читаемость и замедляла восприятие информации. Мы убрали визуальный шум и ускорили работу:

• Ввели правила обработки изображений: набор фиксированных размеров, формат, плотность.
• Стандартизировали визуальный стиль (рамки, шрифты, композиция).
• Удалили лишние детали — обесцветили яркие элементы и расфокусировали то, что не должно отвлекать внимание.

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

Раньше каждый новый технический писатель вникал в процессы в ходе работы. Это было неустойчиво: занятость или отпуск одного куратора могли тормозить онбординг новичка. Мы сделали процессы независимыми от людей:

• Зафиксировали архитектуру репозитория и описали, как он устроен.
• Подготовили подробные инструкции для новых участников.
• Внесли эти знания в базу: гайды, онбординг-документы.

В итоге обеспечили преемственность и обмен знаниями между сотрудниками. Процесс стал независимым от конкретных людей. Новички начали быстрее включаться в работу. Команда больше не зависела от «устной памяти» и не боялась отпусков и ротаций. Знания — формализованы и доступны.

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

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

Среда техписов, работающих с производственной документацией стала чистой, прозрачной и предсказуемой. Теперь каждое изменение — под контролем, структура логична, ничего не теряется и не ломается. Это стало прочной базой для автоматизации.

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

• Настроили процесс отслеживания неактуальных документов.
• Ввели регулярную проверку на востребованность контента.
  

Репозиторий стал контролируемым, а его структура еще более понятной, сборка документов ускорилась, техписам стало проще ориентироваться в рабочем пространстве.

Мы устроили документацию так, чтобы с ней было легче работать не только вручную, но и автоматически. Структура стала предсказуемой, правила — прозрачными, а логика — формализованной.

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

Мы добавили инструменты, которые позволяют отслеживать задачи в разных статусах («ожидание», «в работе», «согласование» и т. д.), собрали статистику и получили 16,5 часов времени реагирования. Это много с учетом того, что мы имеем задачи, которые необходимо выполнить в день их появления. Чтобы сократить время, создали систему приоритизации задач:

• Ввели ротацию дежурного техписа для оперативного реагирования на критичные задачи. Дежурства прохоядт ежедневно: с 10:00 до 19:00 техписы должны быть на связи — это активное время для заводов. Если от технолога поступает задача с высоким приоритетом, дежурный берет ее в работу немедленно. Каждый производственный техпис дежурит один день в неделю по расписанию. У меня, например, — вторник.
• Вместе с технологами мы договорились, какие задачи нужно делать в первую очередь — все зависит от того, как сильно они влияют на производство и могут ли из-за задержки остановиться рабочие процессы.
• Выстроили ежедневный ритм работы с четкими правилами. Все договоренности согласованы с технологами — теперь взаимодействие стало предсказуемым и организованным.

Это позволило снизить среднее время реакции (время между моментом появления задачи и взятием ее в работу) на срочные правки почти до 5,5 часов. Раньше такие задачи нередко «подвисали» между отделами, теперь — нет. Есть дежурный и правила реакции на такие задачи, есть правила, есть реакция.

В течение второй половины 2024 года мы снизили среднее время на решение задачи в 3 раза — до 2,5 дней. Это усредненное значение: срочные задачи решаются в день обращения, тогда как несрочные могут закрываться в течение 1−2 недель.

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

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

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

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

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

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

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