Коротко
Что устаревает быстрее всего?
Случай, после которого я поменял подход к материалам обучения.
Веду занятие, показываю на экране нужный раздел. Ученик смотрит в мою же презентацию и говорит: у тебя тут написано одно, а на экране другое. За один этот эфир нашлось два расхождения: пункт настройки переименовали, а команда, которую я показывал вживую, в материалах не описана вообще - она появилась после того, как материалы были собраны.
Второй клиент, другая программа, тот же эффект. Стало ясно, что это не случайность, а свойство: интерфейсы сервисов меняются чаще, чем обновляются документы про них.
Разложим по скорости устаревания:
| Что описано | Живёт | Пример |
|---|---|---|
| Расположение кнопки и вид экрана | недели | «нажми в правом верхнем углу» |
| Название пункта меню | месяцы | раздел переименовали одним обновлением |
| Порядок шагов | год и больше | сначала настроить, потом подключить |
| Принцип выбора | годы | что отдавать агенту, а что делать руками |
Отсюда простое следствие: если инструкция состоит в основном из первых двух строк таблицы, она обречена. Не потому что написана плохо, а потому что описывает самое подвижное.
Почему это не лечится «обновлять чаще»
Первая реакция на проблему всегда одинаковая: назначим ответственного, будем обновлять раз в месяц.
На практике это не работает по трём причинам.
- Изменения приходят пачками и без предупреждения. Обновление сервиса выходит тогда, когда выходит, а не по твоему графику.
- Обновление документа стоит дороже, чем кажется. Переснять скриншоты, проверить каждый шаг, согласовать - это часы, а не минуты.
- Устаревшую версию продолжают читать. У людей на руках скачанный файл, распечатка, копия в мессенджере. Обновление центральной версии их не догоняет.
Вывод, к которому я пришёл: бороться надо не за свежесть, а за устойчивость. То есть писать так, чтобы устаревало меньше.
Кстати, ровно тот же принцип я держу в статьях: где тема протухающая - цены, тарифы, ограничения сервисов, - стоит блок «актуально на дату» и обязательство сверять раз в квартал. Читатель видит дату сразу и понимает, чему верить. Пример такой темы - разбор про то, какую нейросеть выбрать под задачу: состав сервисов там меняется каждые несколько месяцев.
Как писать инструкцию, чтобы она жила дольше?
Приём, который я применяю ко всем материалам.
Сначала цель шага
«Нужно разрешить агенту работать без подтверждения каждого действия». Человек понимает, что он делает и зачем, даже если экран выглядит иначе.
Потом путь, словами
«Это в настройках, в разделе про разрешения». Название раздела может измениться, но смысл поиска сохранится.
Потом картинка, отдельно
Скриншот идёт последним и подписывается датой. Когда он устареет, шаг всё ещё останется выполнимым.
И признак успеха
«После этого агент перестанет спрашивать разрешение на каждый файл». Человек проверяет результат, а не совпадение с картинкой.
Четвёртый пункт спасает чаще остальных. Если интерфейс изменился, но признак успеха описан, человек доходит до цели своим путём и не застревает на несовпадении.
Есть и приём для совсем подвижных мест: не описывать их вообще, а отдавать агенту вопросом. «Подскажи, где сейчас в этом сервисе настройка такая-то» - ответ будет актуальнее любого документа. Про то, как вообще формулировать такие запросы, разбирал в материале про то, когда с агентом говорят командой, а когда обычной речью.
Дата рядом с разделом и её эффект
Мелочь, которая меняет поведение читателя.
Документ без даты воспринимается как истина. Наткнувшись на несовпадение, человек думает одно из двух: либо инструкция врёт целиком, либо он всё делает не так. Оба вывода плохие.
Документ с датой воспринимается как снимок. Расхождение перестаёт быть катастрофой: понятно, что раздел написан в марте, а на дворе сентябрь, и надо просто поискать чуть иначе.
Что стоит датировать:
- Разделы про интерфейсы внешних сервисов.
- Всё, где есть цены, тарифы и лимиты.
- Списки инструментов и их возможностей.
- Скриншоты, каждый по отдельности.
Правило, которое я держу в своих проектах: меняющиеся значения не вписываются в текст вручную. Цены, лимиты, названия тарифов живут в одном месте, откуда их берут все документы. Тогда обновление делается однажды, а не поиском по десяти файлам.
Что делать, когда человек пришёл с расхождением?
Самое дорогое в устаревшей инструкции - не сама ошибка, а реакция человека на неё.
Наблюдение с обучений: ученик, наткнувшийся на несовпадение, по умолчанию винит себя. Он не пишет «у вас ошибка в материалах», он думает «я что-то делаю не так» и идёт разбираться в одиночку. Иногда возвращается через неделю с фразой «а вот этого в инструкции не было».
«Сервисы меняются. Если экран выглядит иначе, чем на картинке, - это нормально, напиши мне, поправлю. Ориентируйся на цель шага, она указана первой строкой».
Порядок работы с расхождениями:
- Записать в одно место - список несоответствий, а не переписка в чате.
- Поправить текст сразу, если правка на одну строку.
- Пересъёмку картинок копить и делать пачкой раз в период.
- Сказать людям, что поправлено. Иначе в следующий раз промолчат.
Барьер тут не технический, а человеческий, и он из того же ряда, что и другие барьеры внедрения: люди не сообщают о проблемах, пока не уверены, что это не их вина. Разбирал эту механику в материале про три барьера внедрения ИИ в команде.
Ритм пересмотра: раз в квартал и по событию
Календарный ритм нужен, чтобы документ не гнил незаметно. Событийный - чтобы не ждать три месяца, когда всё уже сломалось.
Квартальный проход занимает у меня около часа на документ и выглядит так: читаю целиком, проверяю шаги руками там, где они завязаны на внешние сервисы, обновляю даты, выкидываю то, что перестало быть нужным.
Второй триггер важнее первого. Одно сообщение о расхождении может быть частным случаем, второе о том же месте - точная гарантия, что там сломано. Пороговое правило простое: два обращения об одном и том же означают, что чинить надо не человека, а текст.
И последнее наблюдение. Материал, вырезанный из инструкции после того, как его показали вживую, находится людьми обязательно. Человек помнит, что видел приём на занятии, ищет его в тексте, не находит и делает вывод, что упустил сам. Если что-то убрал - скажи, что убрал и почему. Это дешевле, чем разбираться с недоверием к документу целиком. Тот же принцип работает и с файлом-памятью проекта, где устаревшая строка живёт до тех пор, пока её не удалят руками: что писать в файл-память.
Частые вопросы
Частые вопросы
Главный вывод
Запомнить стоит одно: скриншот - расходник, смысл действия - актив. Расходники планируют и списывают, активы поддерживают.
Практический минимум на сегодня: открой свою рабочую инструкцию и посмотри, с чего начинается каждый шаг. Если с описания экрана, а не с цели, - вот и вся причина, по которой её приходится переписывать каждый квартал.
А сколько людей в твоей команде уже споткнулись об устаревший пункт и решили, что дело в них?