Эволюция зрелости: как мы прокачивали команды и процессы разработки в Т-Банке

30.06.25

Программная инженерия - Тестирование

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

Меня зовут Александр Бородавко, я тимлид одной из команд разработки 1С в компании Т-Банк. Моя команда занимается автоматизацией кадрового учета на базе 1С:ЗУП. В этой статье я расскажу, как мы прокачивали процессы и команду разработки в компании за последние 2 года.

Я занимаюсь 1С больше 15 лет. Начинал в 2007 году в маленькой фирме-франчайзи, когда про развитие говорили, что оно проходит по формуле «ноги–руки–голова»:

  • Ноги: установка коробок, обновлений.

  • Руки: программирование, настройки.

  • Голова: управление «ногами» и «руками».

Затем семь лет работал в крупной девелоперской фирме. Последние три года тружусь в Т-Банке и два из них – на позиции тимлида.

Статья написана для тех, кто:

  • Перерос модель «ноги–руки–голова».

  • Не считает, что 1С-ники – неправильные айтишники.

  • Не считает зазорным ориентироваться на другие команды разработки, которые не занимаются 1С.

  • Не боится экспериментов.

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

В 2022 году в банке была единая команда разработки ЗУП. В нашем управлении были три информационные базы ЗУП, расположенные на двух разных хранилищах (с разной кодовой базой). Рост команды и компании потребовал изменений. В результате мы разделили нашу команду 1С на три: платформенная, кадровая (моя) и расчетная.

Мы решили перенять модель зрелости с других команд.

 

Модель зрелости состоит из шести основных категорий:

  1. разработка,

  2. эксплуатация,

  3. процессы,

  4. people management,

  5. вклад в комьюнити,

  6. качество.

Каждая из этих категорий, как правило, состоит из трех уровней. Уровни подтверждаются артефактами – наличием практик, технологий. Возникает вопрос: как провести аттестацию на соответствие определенному уровню? Если команда достаточно зрелая, она может провести самооценку по описанным критериям и самостоятельно определить, на каком уровне она находится. Также существуют внутренние и внешние эксперты, которые могут провести эту оценку. С их помощью вы сможете увидеть свой текущий уровень и поймете, куда вам двигаться.

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

 

Разработка

 

Мы уже пытались перейти на Git, но каждый раз это вызывало сопротивление внутри команды. Ни у кого из разработчиков не было опыта работы с Git, у нас не было единой кодовой базы (мы работали с двумя разными хранилищами). Была большая зона неопределенности: мы не знали, с какими изменениями в работе нам придется столкнуться и что нам это даст. Зато понимали, что время на разработку увеличится, так как придется делать дополнительные операции.

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

 

Мы понимали, что с Git наша жизнь изменится, но не понимали насколько. В итоге первое, что мы сделали с тремя информационными базами и двумя хранилищами — привели нашу кодовую базу в единое состояние, чтобы у нас была одна общая конфигурация на все базы ЗУП. Коллеги DevOps-инженеры провели для нас серию обучений, написали инструкцию, как работать с Git, что нужно делать. Но это не имело никакого эффекта: мы не смогли начать с этим работать до тех пор, пока не поставили жесткие сроки и не обрисовали план, как мы будем это делать. Было решено поэтапно переходить на Git. Начали с версионирования внешних отчетов и обработок, которые у нас до этого не версионировались. Затем перешли к версионированию конфигурации и расширения.

Что нам дал переход на Git

На базе GitLab DevOps-инженеры настроили автоматизацию для удобства разработчиков. Это позволило нам раскатывать дополнительные отчеты и обработки прямо из merge request в продовые базы, одним нажатием кнопки. Мы настроили понятный процесс код-ревью, который до этого было невозможно проводить на хранилищах.

Сейчас мы активно пишем автотесты. Проверка тестов зашита в пайплайны. Также выполняется проверка с помощью SonarQube.

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

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

Технический долг. Была организована работа с техническим долгом, который собирался по двум критериям: вид технического долга (рефакторинг, написать автотест, сделать оптимизацию, написать документацию) и причина возникновения долга. Мы пришли к тому, что начали ежеквартально выделять 25% ресурсов на то, чтобы сжигать этот технический долг.

 

Эксплуатация

 

Поддержка. Мы хотели, чтобы разработчики тратили меньше времени на поддержку пользователей, но не знали, как этого добиться. Начали с того, что написали техническую документацию (раньше она была только по интеграциям с другими системами). Написали пользовательские инструкции, ввели runbook — короткие записки для консультантов, которые поясняли, как самостоятельно решить простую проблему (перезапустить фоновое задание или посмотреть результат выгрузки). Сделали дайджесты (обзор доработок, фичей). Их мы выкладывали в канале, в корпоративном мессенджере, чтобы сами пользователи (заказчики) и консультанты видели, что мы сделали. Благодаря этому у них возникало меньше вопросов. Так мы снизили потребность в поддержке пользователей через информирование.

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

Мы организовали мониторинги. Их внедрение можно разделить на три этапа:

  1. Определение ключевых сервисов и операций, которые необходимо мониторить;

  2. Определение SLA — соглашения о том, как это должно работать;

  3. Настройка алертов при нарушении SLA.

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

Например, проведение кадрового перевода до этого длилось 40 секунд. При проведении выполнялась куча проверок, операций. Заказчики попросили сократить это время до 20 секунд. Мы ставим техническую задачу, проводим оптимизацию, доводим до максимального ускорения и ускоряем обработку более чем в 2 раза. Предоставляем заказчикам новые показатели SLA и согласовываем их. С помощью внутрибанковской системы мы настроили алерты: если, например, документ проводится дольше 20 секунд (скажем, 21 секунду), в нашем корпоративном мессенджере срабатывает алерт. У нас в офисе для менеджеров висят большие экраны, на которых название нашего сервиса загорается красным, что означает наличие проблемы. Мы начинаем на нее реагировать. Пользователь при этом еще не знает о том, что есть проблема, так как для него операция пока не завершилась.

Работа со сбоями. Когда что-то случалось на стороне 1С или на стороне другой системы и это влияло на наших пользователей, никто об этом не знал. Информация передавалась по сарафанному радио. Мы ввели в свою работу взаимодействие с системами, которые позволяют делать внутрибанковские оповещения. Для этого мы научились фиксировать сбои. Теперь оповещение идет на все зависимые системы, в том числе и пользователям. Если уровень сбоя критичен, мы пишем Postmortem. Postmortem – это разбор полетов, а именно: что случилось, включая определение action points, т.е. что нужно сделать для того, чтобы впредь этого не случалось. Эти задачи имеют приоритет в виде технического долга и их тоже нужно решить.

Автоматизация деплоя. DevOps-инженеры создали пайплайны, которые осуществляют сборку и развертывание баз на продовый контур.

 

Процессы

 

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

 

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

Мы выстроили систему планирования с нуля. Начали с того, что подробно рассчитали ресурсную емкость (количество рабочих дней). Рассчитали время на поддержку. Причем считали постфактум: учитывали отпуска, закладывали риски на больничные, проведение собеседований и так далее. Рассчитали и получили чистое время — ту ресурсную емкость, которую можно потратить на задачи. Затем мы оценивали сами задачи и набирали такое их количество, которое соответствуют ресурсной емкости.

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

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

Доверительное общение с заказчиками. Два года назад у нас были токсичные отношения с заказчиками. Они не понимали, что мы делали, поэтому были недовольны. Нам не хватало прозрачности в отношениях с ними. Мы стали проводить еженедельные встречи, где отчитывались о том, что сделали и что планируем сделать в дальнейшем, отвечали на вопросы. Когда мы ввели планирование и показали расчет ресурсной емкости, вопросов стало гораздо меньше. Сейчас у нас доверительное, конструктивное общение. Это мотивирует делать нашу работу лучше.

Ревью сервиса поставки. Мы определили список ключевых метрик, таких как Lead Time (время от commitment до вывода задачи в прод) и Time to Build (время от попадания задачи в бэклог до вывода ее на прод). Начали их мониторить и поставили себе цель сократить эти метрики. За полтора года удалось сократить Lead Time более чем в 2 раза.

 

People Management

 

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

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

 

Performance Review. Это оценка вклада конкретного разработчика в результаты команды. Раньше мы проводили оценку постфактум: человек что-то делал в течение квартала, а мы ставили оценку. После того, как была введена система планирования, мы внесли в нее задачи команды. Каждый разработчик вносит свои конкретные цели на квартал, которые должны быть сопряжены с командными целями, а также цели на развитие. Например: изучить новый инструмент написания автотестов, научиться работать с мониторингом, с внутренним сервисом.

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

«1-2-1». У нас принято проводить «1-2-1», это полезнейший инструмент для тимлидов. Крайне важно искать формат общения с коллегами, который будет эффективен для всех. Экспериментируйте с форматами: с кем-то надо встречаться чаще, с кем-то реже, а с кем-то можно просто поиграть в настольный теннис.

 

Вклад в комьюнити

 

Найм и развитие 1С-разработчиков. Более двух лет назад в компании была одна большая команда с одним тимлидом, который брал на себя все собесы. Когда мы начали расти, он понял, что не вывозит, и начал подключать других людей. Тут выяснилось, что каждый проводит собеседования по-своему и нет общих критериев оценки. В итоге мы с нуля проработали секцию найма: вопросы, ответы, критерии оценок.

 

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

Важный момент: в нашу матрицу компетенций в хард-скиллы, помимо навыков 1С, мы добавили общетехнические навыки, такие как работа с базами данных, работа с брокерами сообщений, знание пирамид тестирования. Мы считаем, что 1С-никам, как и всем IT-шникам, нужно это знать.

Также мы стараемся развивать свое комьюнити, проводим внутренние встречи, пишем статьи, выступаем на конференциях.

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

У нас проводятся общебанковские DemoDay, где любой сотрудник может выступить, рассказать про какой-то интересный сервис или разработку, которую сделал. Бывают как внешние, так и внутренние митапы, где также можно выступить.

 

Наш путь к системному QA

 

На данный момент повышение качества — наш главный вызов.

 

Исторически у нас было много багов. До этого момента не было автотестов, так как мы не понимали, что тестировать и как тестировать. Работали по простому флоу: разработчик что-то сделал, протестировал и отдал пользователю. Потом оказывалось, что сделали что-то не то или не так.

 

Что сделали

 

Сформулировали тестовую стратегию. На текущий момент у нас нет своих 1C QA-инженеров, однако есть богатое QA-комьюнити внутри компании среди других направлений. Мы привлекли QA-инженеров из других направлений для того, чтобы прокачивать QA у нас. Потому что подходы, на самом деле, у всех одни. Они помогли нам сформулировать тестовую стратегию: как и что тестировать, на каком этапе и так далее.

Определили DoR и DoD — критерии передачи задач в разработку и приемки задач пользователями.

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

Начали писать автотесты. Мы определили два инструмента, которые используем: YAxUnit для модульных тестов и Vanessa Automation для сценарных.

 

Что планируем сделать

 

Писать тесты на каждую фичу, а лучше – на каждый мердж-реквест.

Применять практики shift left testing. Это практики тестирования, согласно которым тестирование нужно сдвигать влево (до этапа разработки), пока это еще дешево. Плохо, если баги обнаруживаются уже после этапа разработки, во время тестирования пользователями, когда мы потратили деньги на аналитику и разработку, и только потом выявили проблему.

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

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

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.

См. также

Коммуникации Бесплатно (free)

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

03.07.2025    334    0    DuyunElena    0    

1

Сопровождение Внедрение изменений Бесплатно (free)

Рост обращений в техподдержку, очереди, перегруженные сотрудники, задержки в ответах на простые вопросы — знакомые реалии для многих компаний. Традиционные решения (базы знаний, контекстные подсказки) часто не справляются с объемом или слишком дороги в разработке и поддержке. К счастью, современные большие языковые модели предлагают мощный инструмент для автоматизации этого пласта работы. Можно ли применить их к специфике платформы 1С? Давайте разберемся.

02.07.2025    466    0    Vaslot    1    

4

Коммуникации Руководитель проекта Бесплатно (free)

В статье рассматривается феномен «эксперта с руками» — уникального специалиста, на котором держится вся система, и от услуг которого невозможно отказаться без риска для компании. Как формируется такая зависимость, в чём её опасность, какие сигналы указывают на проблему, и главное — как спокойно и эффективно перестроить работу команды, чтобы знания и ответственность стали распределёнными, а не копились в голове одного человек? Если вы — руководитель проекта, бизнес-аналитик, архитектор, ИТ-директор или просто человек, у которого есть «тот самый эксперт», – эта статья для вас.

26.06.2025    1210    0    Boris_Pulin    10    

11

Коммуникации Личная эффективность Бесплатно (free)

Работа 1С-специалиста часто ассоциируется с конкретными техническими заданиями, строгими регламентами и минимальной необходимостью в общении. Но в современном IT-мире одних технических навыков становится недостаточно – всё большее значение приобретают soft skills, или «мягкие навыки»: коммуникация, критическое мышление, гибкость, умение работать с людьми. В этой статье рассказывается, как прокачивать «мягкие навыки» прямо в рамках типовой 1С-рутины, на обычных задачах и в общении с заказчиком.

23.06.2025    562    0    user2151211    1    

3

Коммуникации Бесплатно (free)

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

16.06.2025    412    0    Ликреонский    1    

2

Коммуникации Бесплатно (free)

В разработке программного обеспечения командное взаимодействие играет ключевую роль. Однако многие разработчики скептически относятся к регулярным встречам – дейли-митингам, ретроспективам и другим форматам, считая их пустой тратой времени. Почему же возникает это непонимание? Как сделать встречи действительно полезными для всех участников? И какую роль в этом играет модерация и позиция руководства? Разбираемся в статье.

03.06.2025    383    0    Subnak    0    

2

Работа с требованиями Надежность и безопасность Тестирование Бесплатно (free)

В двадцатом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, какие стратегии тестирования применяются для монолита и микросервисов, и как архитектура влияет на выбор стратегии.

03.06.2025    359    0    Radio_Analyst    0    

1

Коммуникации Бесплатно (free)

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

03.06.2025    482    0    klimdw    0    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1627869 02.07.25 04:00 Сейчас в теме
Подскажите почему используете синтетические базы а не e1cib/app/Обработка.СкрытиеКонфиденциальнойИнформации ?
2. a_borodavko 4 02.07.25 17:32 Сейчас в теме
(1)
Обработка.СкрытиеКонфиденциальнойИнформации

Мы сначала пробовали маскирование, но выявили несколько узких мест. Если не маскировать вообще всё, в т.ч. суммы, то всё равно можно идентифицировать отдельных сотрудников по дополнительным показателям, GUID, универсальным внутрибаковским кодам сотрудников (аналог таб номера, но в разрезе всех внутренних систем). Если маскировать и суммы, то как быть с расчётами, накопленными итогами? Это же всё будет абсолютно некорректным. В чём толк от такой базы? Плюс, она ещё и очень большая по размеру. Мы рассматривали и варианты шифрования, но эта идея показалась очень дорогой.
Синтетика же предоставляет нам возможность сделай фактический аналог прода, реализовать сквозной тестовый контур с другими системами, завязывать на эти данные свои автотесты, шарить на подрядчиков, проводить нагрузочные тесты (если нагенерить очень много сотрудников).
Оставьте свое сообщение