Маятник выбора
Представим шкалу. На одном конце — Анархия изменений: частые выкатки (несколько раз в неделю, а то и день), низкая стабильность продуктивной системы, слабый фокус или даже полное отсутствие ключевых этапов тестирования; на другом — Бетонный саркофаг (система практически законсервирована, релизы – раз в месяц и реже, бизнесу приходится подолгу ждать изменений).
Наша задача — понять, где находится "золотая середина" для каждого этапа развития системы.
Критерии выбора:
1. Цена ошибки: Что будет, если мы уроним систему или вносимые доработки будут не соответствовать ожиданиям Заказчика? (Для УХ это часто не просто простой системы и бизнес-пользователей, а срыв процесса закрытия месяца, что для крупной публичной компании чревато несвоевременным предоставлением финансовой отчетности).
2. Цена задержки: Что будет, если мы НЕ сделаем изменение? (Бизнес потеряет деньги, понесет налоговые риски, бизнес-пользователи утонут в ручной работе и т.д).
3. Технический долг: Насколько сложно будет вносить изменения через полгода, если мы сделаем "быстрое решение" сейчас?
Этап 1: Внедрение и Опытно-промышленная эксплуатация (ОПЭ). Первые месяцы.
Мы ввязались в «борьбу за выживание», шок первых дней, регулярные заявления пользователей «у меня ничего не работает».
Стратегия: «Пожарный режим» Девиз: «Главное — чтобы система просто работала и считала базово правильно».
· Приоритет: Скорость на закрытие критических ошибок. Стабильность пока недостижима в принципе.
· Как мы действовали:
1. Мы сознательно разрешали "быстрые заплатки". Если бизнес-процесс (например, оплата поставщику) вставал колом, разработчик мог выкатить исправление хоть вечером пятницы, без полного цикла тестирования. Количество hot-fix на данном этапе: 3-4 в неделю.
2. Риск: Мы накапливали технический долг.
3. Инструмент: Мы завели «Красный бэклог» — список вещей, которые мы сломаем быстрыми правками. И обязались вернуться к нему через квартал/полгода для рефакторинга.
· Совет: На этом этапе не пытайтесь построить идеальный регламент. Ваша задача — доказать, что система ЖИВАЯ и решает задачи бизнеса. Критерий перехода к следующему этапу — количество "критических инцидентов" снизилось с 2-3 в неделю до 1-2 в месяц.
Этап 2: Стабилизация. Первые 3-6 месяцев после ОПЭ
Мы закрыли несколько периодов и полугодие. Основной функционал системы работает.
Стратегия: «Лечение ран» Девиз: «Чиним то, что сломали в спешке, и учимся работать по правилам».
Приоритет: Сдвиг в сторону стабильности. Мы намеренно снижаем скорость выкатки нового функционала. Мы говорим, основное горящее полечили, начинаем стабилизировать и развивать систему.
Как мы действовали:
1. Ввели "Режим тишины" перед закрытием периода. За 3-4 дня до закрытия месяца — "freeze" (заморозка) на выкатку любых изменений в продуктивную среду. Только горячие исправления (hot-fix) по согласованию с бизнес-владельцем системы и только по критически важным ошибкам. Новую функциональность не катим в Hot-fix в прицнипе.
2. Начали проводить code review, ввели этап обязательного тестирования влияния. Если на этапе ОПЭ мы могли смерджить код, просто бегло посмотрев, то теперь ввели чек-лист: "не сломают ли доработки продуктив?".
3. Инцидент-менеджмент только зарождается. На этом этапе всё еще достаточно много инцидентов, используем режим тушения пожаров. Начинаем писать Postmortem и устранять причины инциденты критического/блокирующего уровней (система упала сломался функционал целого блока).
Проблема: Бизнес уже привык, что вы "быстрые", и продолжает сыпать запросами на новый функционал.
Наше решение: Мы внедрили обязательную валидацию доработок бизнес-владельцем системы. Любая новая "фича" должна пройти через валидацию с бизнес-владельцем системы. Мы честно говорили: "Если мы сейчас начнем делать ваш отчет, мы не успеем починить обмен с банком, и завтра казначеи не увидят платежи". Выбор остается за бизнесом.
Этап 3: Промышленная эксплуатация (Регулярная работа). Спустя год после внедрения.
Итак, ура! Мы «выжили» и закрыли свой первый год в 1С УХ.
Стратегия: «Плановое хозяйство» Девиз: «Предсказуемость важнее героизма».
Приоритет: Стабильность. На этом этапе мы открыто говорим, что система достаточно стабильна что бы не катить доработки в режиме «ошпаренной кошки», все процессы работают, пускай некоторые и в недостаточной степени автоматизации. Скорость достигается за счет автоматизации процессов, а не за счет "пожарных" выкаток.
Как мы организовали процесс:
1. Регулярные релизы (Ритм): Мы перешли на более жесткий цикл - выкатка релизов 1 раз в неделю (изредка - 2) в заранее согласованное с Заказчиками "релизное окно". Все, что не успели в этот поезд — едет в следующем. Количество хот-фиксов минимально и только в исключительных случаях.
2. Регламентация процессов разработки и выкатки релизов. Сейчас уже не время бежать без оглядки, время взросления системы, необходимо жестко фиксировать требования.
3. Инцидент – менеджмент: Мы уже стараемся не просто тушить, а предотвращать пожары. Система обрастает алертингами. Каждый hot-fix разбирается в причинах. Пишутся и отрабатываются Postmortem не только критических инцидентов на системе, но и релизов. Предпринимаются меры по их недопущению.
4. Песочница (Dev/Test/Prod): Обязательное требование. Изменение проходит полный путь: Разработка -> Тестовый контур (с актуальными данными и интеграциями) -> Препрод контур (с тестированием бизнес-пользователями и приёмкой доработок)-> Продуктив.
5. Автоматизация тестирования: Мы начали писать автоматические тесты на основные операции. Чтобы убедиться, что после очередного релиза цифры в ОСВ не изменились.
Лайфхак: Мы ввели понятие "Технический долг" в бэклог как полноценную задачу. Например: "Спринт №15: 80% времени делаем задачи бизнеса, 20% времени переписываем кусок кода, который мы "костылями" затыкали год назад". Это позволяет не копить проблемы.
Этап 4: Развитие и Модернизация. 1,5 -2 года на УХе
Наша система стабильна, процессы отлажены, пора искать новые бизнес-процессы для автоматизации!
Стратегия: «Управляемая гибкость» Девиз: «Быстро, но безопасно».
Приоритет: Баланс. Мы накопили экспертизу, у нас хорошие тесты, мы можем позволить себе быть быстрее, но под контролем.
Как мы ускоряемся без потери качества:
1. Фиче-флаги (Функциональные переключатели): Мы можем выкатить код новой фичи в продуктив, но включить его только для ограниченного круга лиц (например, пилотной группы) для тестирования. Если что-то идет не так — выключаем одним флажком, не откатывая всю систему.
2. Расширения 1С: Практически не используем механизм расширений, все что делалось расширениями ранее перенесено в основную конфигурацию, что так же повышает стабильность системы (например, если в расширение добавить объекты, содержащие данные, отключение/удаление расширения приведет к потере данных). Но при этом расширения остаются хорошим инструментом для быстрой выкатки фич (с обязательным последующим переносом в основную конфигурацию в плановый релиз).
3. Автоматизированное тестирование: Система покрыта автоматизированными тестами на 90+% что позволяет сократить время релиза.
4. Автоматизированная выкатка релизов: Мы знаем что у нас стабильная система и достаточно алертингов, что бы выкатывать релиз автоматически скриптом без участия администраторов.
5. Внедрён Git + EDT: Внедрили Git и перешли на EDT, что позволило выстроить пайплайны с автоматизированным код ревью высокого качества. Дальнейшие планы – подключать AI (1С Напарник, MCP-сервера) для еще большего ускорения рутинной разработки.
Заключение: Советы для руководителя
Что в итоге мы вынесли из опыта с УХ:
1. Слушайте контекст: Если у вас закрытие полугодия — вы в стабилизации (этап 2), даже если вообще-то вы уже на этапе развития и внедрились 5 лет назад.
2. Договаривайтесь с бизнесом на берегу: Объясните, что стабильность — это тоже скорость. Но скорость не для вас, а для них. Потому что, если система ляжет в отчетный период, у всех будут проблемы.
3. Автоматизируйте контроль: Чем сложнее система, тем больше нужно автоматических проверок и алертингов, чтобы позволить себе быть быстрыми и не бояться сломать стабильность.
4. Автоматизируйте рутинные операции: Чем более зрелая система, тем больше ожидания бизнеса от вас как по скорости, так и по качеству. Автоматизируйте тестирование и код ревью – и ваши аналитики/разработчики освободятся для новых задач. Автоматизируйте выкатку релиза и пусть ваш администратор сфокусируется на задачах ОС и СУБД.
Мы не выбираем что-то одно. Мы выбираем стратегию под задачу. Где-то нужно включить режим "пожарного" и спасти ситуацию, а где-то — надеть "бетонный саркофаг", чтобы пережить сдачу отчетности.