Привет, Хабр. Меня зовут Марат Мустафин, я архитектор стрима 1С в МТС. В крупных компаниях сегодня модно измерять технологическую зрелость команд по единым чек-листам и общим методологиям. Из-за этого команды 1С каждый раз оказываются в проигрышной позиции.
Реальные достижения — отказоустойчивые кластеры, еженедельные релизы через CI/CD, мониторинг бизнес-логики в Grafana — растворяются в общих формулировках вроде «У вас есть автоматизация тестирования?». А специфичные для платформы практики, такие как работа с хранилищем через gitsync, нагрузочное тестирование типовых операций, управление техническим долгом в конфигурации, просто не попадают в поле зрения.
В итоге сильная 1С-команда может получить средний балл, потому что ее инструменты незнакомы валидаторам оценки, а слабая — завышенный, потому что формально использует Jira. Под катом расскажу, почему общие модели зрелости плохо работают для 1С и какую модель оценки я предлагаю сообществу — с конкретными капабилити, практиками и открытыми инструментами.
С этой проблемой столкнулась и команда 1С в МТС. Корпоративная модель зрелости у нас есть, мы по ней проходим оценку и никуда от нее не деваемся. Но каждый раз при прохождении я видел одно и то же: реальные инженерные достижения команды не укладываются в общие формулировки, а специфичные для платформы практики просто выпадают из оценки.
Это натолкнуло меня на мысль: сообществу 1С нужен собственный инструмент — не замена корпоративным стандартам, а дополнение, которое говорит на языке платформы. Так появилась двухуровневая модель оценки для команд 1С, в которой важен не факт наличия процессов, а то, как именно они устроены и насколько осмысленно применяются. Она позволяет оценивать не только соответствие чек-листу, но и глубину инженерной культуры.
Уровень 1. Философия команды
В основе модели — пять ступеней, где каждая описывает качественный скачок в мышлении команды. Переход между уровнями здесь связан не с внедрением очередного инструмента, а со сменой самого подхода.
№ | Уровень зрелости | Оценка | Типичное отношение команды | Ограничения уровня |
1 | Отсутствует | Реактивная, героическая | «А зачем нам это? Когда прижмет — разберемся» | Катастрофа при уходе ключевого человека |
2 | Хаотичный | «У нас есть Петя, он это умеет» | «Делаем, но только когда не в отпуске и не завалены» | Непредсказуемость качества, скрытый техдолг |
3 | Повторяемый | «У нас есть процесс» | Нового сотрудника обучают по инструкции | Процесс становится ритуалом, теряется эффективность |
4 | Управляемый | «Управляем на основе данных» | На планерках оперируют метриками (lead time, количество багов) | Аналитический паралич, оптимизация ради метрик |
5 | Эталонный | «Предвосхищаем проблемы, инвестируем в будущее» | Ретроспективы процессов и инструментов, эксперименты | Нет реакции |
На первом уровне процессы отсутствуют. Работа строится реактивно, многое держится на ручном управлении и личной инициативе отдельных людей. Если выпадает ключевой специалист, команда становится неэффективной.
На втором уровне уже появляются отдельные практики, но они остаются несистемными. Что-то в команде уже делают правильно, но это еще не стало общим рабочим способом. Обычно в таких случаях есть конкретный человек, который умеет работать с определенным контуром, знает, как собрать релиз, где смотреть проблему или как обойти ограничения платформы. Пока он на месте, процесс работает, но как только уходит в отпуск, переключается на другой приоритет или просто выбывает из потока, начинаются проблемы.
На третьем уровне процессы уже есть, и команда может на них опираться в повседневной работе. Новый сотрудник не собирает картину по обрывкам из чатов и чужой памяти, а понимает контекст через правила, инструкции и привычный порядок действий. Но здесь появляется другая проблема — процесс может сохраниться как форма, а не как инструмент. Команда будет следовать ему по инерции, не задаваясь вопросом о том, помогает ли он сейчас.
На четвертом уровне команда начинает управлять своей работой на основе данных. Появляются метрики, по которым видно, где замедляется работа, на каких этапах копятся дефекты, где процесс перегружен ручными действиями, а где уже можно что-то менять. На планерках в такой модели обсуждают не только задачи, но оперируют временем выполнения (lead time) и количеством багов.
Пятый уровень — это состояние, в котором команда не только поддерживает работающие процессы, но и умеет пересматривать их заранее. Здесь уже есть привычка регулярно смотреть на инструменты, обсуждать ограничения, проводить эксперименты и вкладываться в то, что даст эффект не сразу, а через несколько месяцев. Это уровень, на котором инженерная культура становится эталонной.
Уровень 2. Капабилити и практики
Одной шкалы уровней для оценки недостаточно. Чтобы оценить, насколько команда зрелая (уровень 1), нужно понять, в чем она сильна. Для этого я определил 8 капабилити — ключевых направлений, которые должна развивать современная команда 1С:
управление кодом и разработка — контроль над исходным кодом, качеством и жизненным циклом изменений;
надежность и наблюдаемость — технический мониторинг, бизнес-мониторинг, алертинг, управление инцидентами;
релизы и развертывание — автоматизация сборки, стратегии релиза, управление зависимостями, безопасность доставки;
тестирование — unit-тесты, интеграционные тесты, нагрузочное тестирование, регрессионное тестирование;
архитектура и данные — внутренняя библиотека, интеграционная архитектура, управление данными, архитектурная документация;
инфраструктура и безопасность — инфраструктура как код, разделение ответственности, безопасность приложений, резервирование и disaster recovery;
продуктовый подход и процессы — планирование, внутрикомандные процессы, управление знаниями, культура улучшений;
искусственный интеллект и автоматизация знаний — AI-ассистирование разработки, AI в тестировании, AI в анализе и поддержке, AI-стратегия и инфраструктура.
Каждая из них реализуется через 32 конкретные практики, которые и считаются критериями оценки.
Для меня было важно уйти от логики «есть или нет» — для точной оценки этого недостаточно. Значение в модели имеет не сам факт наличия практики, а то, как именно она устроена, насколько последовательно применяется и какую пользу дает команде. Например, покажет: «У вас отлично с автоматизацией сборки (4), но катастрофа с безопасностью доставки (1) — вот ваша главная точка роста».
Капабилити «Управление кодом и разработка»
Для понимания объясню модель на примере капабилити «Управление кодом и разработка». Внутри нее я выделил четыре практики:
система контроля версий — как команда работает с Git;
качество кода — есть ли стандарты и как управляется технический долг;
сode review — как проверяется код и как через ревью передаются знания;
жизненный цикл задачи — связаны ли изменения в коде с задачами в трекере.
Одна из самых показательных практик здесь — жизненный цикл задачи. Возвращаясь к нашей таблице, можно отследить уровни ее зрелости. Например, на первом уровне системы управления задачами нет вовсе либо она используется формально. Связь между задачей и кодом не выстроена. После релиза трудно быстро понять, какие изменения реально вошли в поставку и откуда появился конкретный дефект.
На третьем уровне уже появляется правило о том, что каждый коммит должен ссылаться на ID задачи. Значит, между Git и трекером настроена интеграция (автоматическое изменение статуса задачи и ссылки), а для релиза формируется базовый чейнджлог на основе закрытых задач. Это еще не полная трассируемость, но команда уже лучше видит свой поток изменений.
На пятом уровне здесь появляется сквозная связка между кодом, задачей, требованием и релизом, а изменения можно проследить от бизнес-запроса до конкретной поставки. Релиз-ноты формируются автоматически, а данные из Git и трекера уже используются не только для учета, но и для анализа процесса. Например, для оценки lead time, deployment frequency и других метрик, по которым видно, насколько стабильно и предсказуемо работает команда. Процесс становится прозрачным для всех стейкхолдеров.
Капабилити «Архитектура и данные»
Также по ключевым уровням разберу практику «Архитектурная документация и решения» в капабилити «Архитектура и данные»:
Уровень 1. Архитектурные решения принимаются по ситуации и остаются в голове у ключевого разработчика. Пока команда небольшая, это не вызывает проблем, но как только меняется состав или появляется новый контур, отсутствие зафиксированных решений начинает тормозить работу.
Уровень 3. Ключевые архитектурные решения и схема системы уже зафиксированы в одном месте, например в вики, диаграммах PlantUML или репозитории. Документация на этом уровне обновляется при значимых изменениях и постоянно используется в работе.
Уровень 5. Тут архитектурная документация уже перестает быть набором файлов «для порядка» — ADR становятся инструментом, решения регулярно пересматриваются, а принципы применяются в ежедневной работе. Они используются в онбординге, обсуждении изменений и коммуникации со стейкхолдерами. Сами принципы, например работа интеграций через асинхронную шину, уже не просто декларируются, а реально проверяются в проектировании и ревью.
Я считаю второй уровень ключевым, потому что он переводит разговор о зрелости из общих формулировок в предметный разбор. В этом случае абстрактный «Уровень 3 по коду» становится планом действий — настроить политику ветвления, обязать code review и прописать стандарты.
Капабилити «Искусственный интеллект и автоматизация знаний»
В 2026 году тему зрелости команды уже трудно рассматривать без AI-практик, поэтому эта капабилити тоже вошла в модель.
У нас генеративные модели уже помогают в разработке, разборе легаси, подготовке тестов и в поддержке пользователей. Но сам по себе доступ к таким инструментам еще ничего не значит, важно, чтобы их использование не оставалось набором экспериментов, а становилось управляемой частью командной работы. Эта капабилити как раз и позволяет оценить, где команда находится сейчас.
Например, если оценивать практику «AI-ассистирование разработки», то на первом уровне AI просто не используется и весь код команда пишет вручную. На третьем уровне появляются корпоративные ассистенты, которые помогают в рутинных задачах — готовят шаблоны, генерируют комментарии, оформляют черновики документации или ускоряют типовой кусок кода. На пятом уровне AI становится уже частью инженерного процесса. Он помогает с предварительным разбором решений, подсказывает варианты реализации, генерирует unit-тесты и участвует в первичной проверке изменений. Если у компании есть внутренний кодовый контекст, то модели могут дообучаться и на нем.
Похожая логика и по практике «AI в тестировании»:
На первом уровне все сценарии по-прежнему пишутся вручную.
На третьем AI уже используют для генерации тестовых данных и черновиков простых сценариев — в случае с 1С это может быть, например, подготовка заготовок для Vanessa-Automation по описанию бизнес-процесса.
На пятом уровне такие инструменты уже встроены в CI/CD-контур — система помогает подбирать тесты под конкретное изменение, расставлять приоритеты по рискам и доучивается на результатах предыдущих прогонов.
Показательна модель и по практике «AI в анализе и поддержке». На первом уровне поддержка целиком остается ручной. На третьем появляются AI-боты первой линии, которые отвечают на типовые вопросы по базе знаний и снимают часть однотипной нагрузки. На пятом уровне AI уже работает не только в ответ на проблему, но и на опережение. Он анализирует логи, метрики и историю обращений, чтобы заранее подсветить возможные сбои или деградацию.
Как и в других капабилити, здесь важен не столько набор инструментов, сколько культура и системность. Зрелая команда не просто использует AI, а управляет этим использованием — оценивает безопасность, считает ROI, экспериментирует и делится опытом.
Как использовать модель
Для прохождения самооценки я сделал открытый инструмент.
Веб-версия на GitHub — интерактивный чек-лист по всем 32 практикам, который можно пройти без установки чего-либо и встроить в свои процессы.
Для того чтобы использовать модель, откройте веб-версию, соберите ключевых членов команды (тимлид, разработчики и аналитики), пройдитесь по всем критериям и поставьте честные баллы от 1 до 5, а после обсудите получившийся профиль — это ваша карта роста.
Эта картина — лучший аргумент для обоснования инвестиций в инструменты или обучение. Когда все капабилити и практики собраны в одном месте, сразу видны сильные и слабые стороны, а также векторы для роста в следующем квартале.
Пока мы будем пытаться вписаться в общие рамки, нас будут считать «особенными» в плохом смысле. Пора перестать адаптироваться и начать задавать стандарты, потому что разработка на 1С давно уже не сводится к работе с конфигурацией. Это такой же инженерный контур, где важна автоматизация, предсказуемость изменений, наблюдаемость, архитектурная целостность и нормальная связка с продуктовыми задачами. И оценивать ее нужно соответствующим образом.
То же самое и со зрелостью — она определяется не количеством освоенных возможностей платформы. Гораздо важнее, насколько команда смогла убрать лишнюю ручную нагрузку, привести повторяющиеся решения к общему стандарту, аккуратно встроить новые инструменты, включая AI, и освободить разработчиков от постоянного переключения между технической рутиной. В этом состоянии команда тратит меньше сил на обслуживание среды и больше на бизнес-задачи.
Эта модель — мой вклад в профессиональное сообщество. Но ее настоящая ценность появится, когда вы примените ее, доработаете под свой контекст и поделитесь обратной связью.
Готов обсудить ваши кейсы. Критика и идеи приветствуются.
