Как готовить пользователей к релизам 1С, чтобы после обновления не начался пожар

Релиз поставили вечером. База открылась. Документы создаются. Форма не падает. Отчет формируется. В журнале регистрации ничего страшного не видно.

С технической стороны все выглядит спокойно.

А потом начинается рабочее утро.

• “Не могу провести документ”.
• “Где это теперь искать?”
• “А как это работает?”
• “Где инструкция?”
• “Раньше было по-другому”.
• “У нас все сломалось”.

И вот тут выясняется неприятная вещь: релиз может быть технически нормальным, но все равно превратиться в пожар. Не потому что разработчик плохо написал код. А потому что пользователи впервые увидели изменение уже в рабочей базе.

В реальной жизни это часто выглядит совсем просто. В документ добавили проверку: перед проведением теперь обязательно нужно заполнить поле “Ответственный”. Логика понятная: дальше от этого поля зависит маршрут согласования и контроль исполнения. На тестировании все прошло нормально, фокус-группа посмотрела, замечаний не дала.

Но после релиза обычные пользователи начали писать: “Не могу провести документ”. Для них ничего не “улучшилось”. Вчера документ проводился, сегодня не проводится. Текст ошибки есть, но человек не понимает, почему это появилось именно сейчас и что от него хотят. Первая линия поддержки тоже не была заранее подготовлена и сначала пересылала вопросы дальше.

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

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

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

Пожар после релиза не всегда означает плохой код

Когда после обновления начинают писать пользователи, легко подумать: “Опять что-то сломали”. Иногда действительно сломали. Бывают ошибки в коде, неожиданные данные, особенности старых документов, права, неучтенные сценарии.

Но отдельная категория релизных пожаров возникает не из-за ошибки, а из-за непонимания.

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

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

Команда видит причины этих изменений. Пользователь видит результат: раньше работало так, теперь работает иначе.

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

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

Что пользователь реально видит после обновления

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

Пользователь этого не видит.

Он видит рабочий экран и результат своего действия:

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

Поэтому при подготовке релиза нужно смотреть не только на измененные объекты, но и на измененный пользовательский маршрут.

Не “какой модуль мы поправили?”, а “что человек теперь сделает иначе?”. Не “какая роль изменилась?”, а “какая кнопка исчезнет у пользователя?”. Не “какой отчет доработали?”, а “какие цифры пользователь увидит другими и почему?”.

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

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

Чем плохая подготовка к релизу бьет по компании

Плохая подготовка к релизу стоит денег. Не в красивой презентации, а в обычных рабочих часах.

Когда пользователей не предупредили или предупредили плохо, компания платит за повторяющиеся обращения в поддержку, личные сообщения разработчикам и аналитикам, переключение специалистов с текущих задач, ручные объяснения одного и того же, простой пользователей и срочные созвоны “что случилось после обновления”.

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

Если час первой линии условно стоит 900 рублей, час разработчика — 2 000 рублей, а час пользователя — 700 рублей, то даже небольшой релизный хаос быстро превращается в десятки тысяч рублей. И это без учета задач, которые разработчик не сделал, потому что отвечал на одинаковые вопросы.

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

Если после обновления все пишут в личку, это не всегда признак плохого кода. Иногда это признак плохой подготовки.

Какие изменения нельзя выпускать молча

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

Но есть простое правило:

Если изменение хоть как-то затрагивает работу пользователя, его нужно объяснить.

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

Здесь не нужно писать пользователю техническую историю изменения. Ему нужно дать рабочий ответ: что теперь делать иначе.

Кого нужно готовить к релизу

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

Иногда это работает. Чаще — нет.

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

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

Конечные пользователи

Это главная группа риска. Именно они первыми сталкиваются с изменением в рабочем процессе.

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

Если пользователь задает вопрос “где это искать?”, значит, в подготовке не хватило простого навигационного объяснения.

Ключевые пользователи

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

Но у фокус-группы есть побочный эффект: команда начинает думать, что “пользователи в курсе”. На самом деле в курсе только те, кто участвовал в проверке.

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

Первая линия поддержки

Если поддержку не подготовить, разработчик после релиза отвечает не за код, а за навигацию по кнопкам и инструкциям.

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

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

Руководители и тимлиды

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

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

Для руководителя плохой релиз — это не только ошибка в 1С. Это еще и потеря управляемости: пользователи пишут куда попало, поддержка не знает ответов, разработчики отвлекаются, а бизнес получает ощущение, что “после обновления стало хуже”.

Нормальное сообщение о релизе: без технической простыни

Пользовательское сообщение о релизе должно быть коротким и полезным. Не нужно пересказывать задачу разработки, внутренние обсуждения и технические детали. Но нельзя ограничиваться фразой “сегодня обновление”.

Плохое сообщение:

Сегодня обновляем базу. Исправлены ошибки, добавлены проверки. Работаем как обычно.

Формально команда предупредила. По факту пользователь ничего не понял.

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

В хорошем сообщении нет лишней торжественности. Оно просто помогает человеку пережить изменение без гадания.

Инструкция на 30 страниц не спасает релиз

Отдельная боль — инструкции.

Команда может честно обновить инструкцию перед релизом. Но если инструкция большая, а изменение спрятано где-то внутри, пользователь все равно останется без ответа.

Типовая ситуация: есть инструкция на 30 страниц. В нее добавили две новые строки. Пользователям отправили ссылку. Формально все сделано правильно: инструкция актуальна.

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

Поэтому к большой инструкции нужен короткий релизный слой.

Что нужно добавить к инструкции

• Короткий список изменений: что именно поменялось.
• Ссылку на конкретный раздел: не просто “инструкция здесь”, а “раздел 3, шаги 4–6”.
• Формат “было / стало”: старое действие и новое действие.
• Скриншот или схему: если поменялось место поля, кнопки или статуса.
• Короткую памятку: если изменение затрагивает частый сценарий.

Хорошая инструкция после релиза не заставляет пользователя проходить квест. Она быстро отвечает на вопрос: “Что мне сейчас сделать, чтобы продолжить работу?”

Фокус-группа: полезно, но недостаточно

Привлечение фокус-групп перед релизом - это хорошая практика.

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

Но фокус-группа решает только часть задачи.

Она не отменяет массовую коммуникацию. Она не заменяет инструкцию. Она не делает автоматически подготовленными всех пользователей отдела.

Правильная логика такая:

1. Фокус-группа проверяет сценарий до релиза.
2. Команда собирает вопросы и непонятные места.
3. По итогам проверки обновляется инструкция.
4. Для остальных пользователей готовится короткое сообщение.
5. Поддержка получает чек-лист типовых вопросов.

Тогда фокус-группа действительно помогает. Если же команда после проверки говорит “ну пользователи же видели”, начинается самообман. Видели не все.

Как подготовить первую линию поддержки

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

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

Например, если после релиза появилась новая проверка при проведении документа, поддержка должна знать не только факт “добавлена проверка”. Ей нужно понимать, какое поле проверяется, что писать пользователю, где инструкция и когда это уже настоящая ошибка.

Такой чек-лист снижает количество лишних эскалаций. Разработчик подключается к ошибкам, а не к каждому вопросу “где теперь кнопка”.

Первые часы после релиза

Первые часы после обновления — это отдельный этап релиза.

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

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

Фраза “кто-нибудь посмотрит” не работает. Нужны конкретные ответственные.

Повторяющийся вопрос — это не раздражающий шум, а подсказка: вот здесь релиз объяснили плохо.

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

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

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

Как отличать ошибку от непонимания нового сценария

После релиза важно не спорить с пользователем фразой “у нас все работает”. Для пользователя действительно не работает привычный сценарий.

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

Такой разбор переводит разговор из эмоционального “все сломалось” в конкретное “что именно произошло”.

Последовательность подготовки к релизу

Подготовка пользователей к релизу не требует большой бюрократии. Нужна простая последовательность.

Шаг 1. Выделить пользовательские изменения

Сначала нужно посмотреть на релиз не как на список задач, а как на список изменений в работе людей.

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

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

Шаг 2. Определить, кого касается изменение

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

Например, новая проверка в документе касается не только тех, кто документ создает. Она может касаться согласующих, поддержки, руководителя процесса и администратора прав.

Чем точнее определена аудитория, тем меньше лишнего шума и меньше пропущенных людей.

Шаг 3. Описать “что было / что стало”

Это один из самых полезных форматов для пользователя.

Формат “было / стало” хорош тем, что не требует длинных объяснений. Пользователь сразу видит разницу.

Шаг 4. Обновить инструкцию так, чтобы ее реально прочитали

Если инструкция большая, нужно отдельно указать измененные разделы. Не просто “инструкция обновлена”, а “смотрите раздел 3, шаги 4–6”.

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

Шаг 5. Подготовить поддержку

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

Шаг 6. Предупредить пользователей заранее

Предупреждение после релиза — это уже не подготовка, а тушение пожара.

Пользователь должен узнать о важном изменении до того, как оно остановит его работу. Особенно если речь про проведение документов, отчеты, права, маршруты или инструкции.

Шаг 7. Проверить первые обращения после релиза

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

Иногда достаточно быстро обновить сообщение или инструкцию, чтобы остановить поток одинаковых обращений.

Шаблон сообщения пользователям о релизе

Ниже шаблон, который можно адаптировать под конкретный релиз в 1С.

Тема: Обновление 1С: что изменится с [дата]

Когда: [дата и время релиза]. В этот период возможна кратковременная недоступность базы или отдельных операций.

Кого касается: [подразделения, роли, пользователи, которые работают с документом, отчетом или процессом].

Что изменится:

• [изменение 1 простым языком];
• [изменение 2 простым языком];
• [изменение 3 простым языком].

Как теперь работать: [короткое описание нового действия или нового порядка работы].

Зачем это сделано: [причина изменения: контроль заполнения, корректный маршрут, единый порядок работы, правильный отчет, снижение ручных проверок].

Инструкция: [ссылка]. Важные изменения находятся в разделе [номер/название], шаги [номера].

Если возник вопрос: пишите в [канал поддержки / сервис-деск / почта]. В обращении укажите базу, документ, действие, текст ошибки и приложите скриншот.

Если работа заблокирована: укажите в обращении “блокирует работу” и добавьте пример документа.

Такое сообщение не делает релиз идеальным. Но оно убирает самый опасный вакуум: пользователи понимают, что произошло и куда идти с вопросами.

Чек-лист готовности пользователей к релизу

Если по нескольким пунктам нет ответа, релиз можно поставить технически, но риск пожара заметно выше.

Что не нужно делать

Подготовка пользователей к релизу не должна превращаться в отдельную бюрократическую систему.

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

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

Плохой подход:

• “Мы же отправляли ссылку”.
• “Пусть читают инструкцию”.
• “Там все написано”.
• “Это не ошибка, а новая логика”.

Лучший подход:

• объяснить изменение заранее;
• выделить важное в инструкции;
• подготовить поддержку;
• быстро обработать первые вопросы;
• доработать пояснения по повторяющимся обращениям.

Пользователь не всегда читает длинные инструкции. Это не новость и не повод обижаться. Значит, важные изменения нужно подавать так, чтобы их можно было быстро увидеть и применить.

Итог

Можно сделать правильную проверку, но получить волну обращений “не могу провести документ”. Можно обновить инструкцию, но спрятать важные две строки в документе на 30 страниц. Можно привлечь фокус-группу, но забыть предупредить остальных пользователей. Можно подготовить технически хороший релиз и все равно потратить день на одинаковые объяснения.

Хороший релиз — это не тот, после которого никто ничего не спрашивает. Вопросы все равно будут.

Хороший релиз — это тот, где пользователи понимают, что изменилось, поддержка знает, что отвечать, а разработчик не получает десятки личных сообщений с одинаковым “у нас все сломалось”.

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

Иначе команда платит за это утром: обращениями, личными сообщениями, потерянными часами и нервным отношением к следующему обновлению.

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