Меня зовут Александр Бородавко, я тимлид одной из команд разработки 1С в компании Т-Банк. Моя команда занимается автоматизацией кадрового учета на базе 1С:ЗУП. В этой статье я расскажу, как мы прокачивали процессы и команду разработки в компании за последние 2 года.
Я занимаюсь 1С больше 15 лет. Начинал в 2007 году в маленькой фирме-франчайзи, когда про развитие говорили, что оно проходит по формуле «ноги–руки–голова»:
-
Ноги: установка коробок, обновлений.
-
Руки: программирование, настройки.
-
Голова: управление «ногами» и «руками».
Затем семь лет работал в крупной девелоперской фирме. Последние три года тружусь в Т-Банке и два из них – на позиции тимлида.
Статья написана для тех, кто:
-
Перерос модель «ноги–руки–голова».
-
Не считает, что 1С-ники – неправильные айтишники.
-
Не считает зазорным ориентироваться на другие команды разработки, которые не занимаются 1С.
-
Не боится экспериментов.
-
Является сторонником эволюционных изменений. То есть понимает, что развитие – это марафон, а не спринт. Результаты могут быть видны не сразу.
В 2022 году в банке была единая команда разработки ЗУП. В нашем управлении были три информационные базы ЗУП, расположенные на двух разных хранилищах (с разной кодовой базой). Рост команды и компании потребовал изменений. В результате мы разделили нашу команду 1С на три: платформенная, кадровая (моя) и расчетная.
Мы решили перенять модель зрелости с других команд.
Модель зрелости состоит из шести основных категорий:
-
разработка,
-
эксплуатация,
-
процессы,
-
people management,
-
вклад в комьюнити,
-
качество.
Каждая из этих категорий, как правило, состоит из трех уровней. Уровни подтверждаются артефактами – наличием практик, технологий. Возникает вопрос: как провести аттестацию на соответствие определенному уровню? Если команда достаточно зрелая, она может провести самооценку по описанным критериям и самостоятельно определить, на каком уровне она находится. Также существуют внутренние и внешние эксперты, которые могут провести эту оценку. С их помощью вы сможете увидеть свой текущий уровень и поймете, куда вам двигаться.
Два года назад мы провели такую самооценку. Из трех уровней, которые у нас были, мы недотягивали даже до первого.
Разработка
Мы уже пытались перейти на Git, но каждый раз это вызывало сопротивление внутри команды. Ни у кого из разработчиков не было опыта работы с Git, у нас не было единой кодовой базы (мы работали с двумя разными хранилищами). Была большая зона неопределенности: мы не знали, с какими изменениями в работе нам придется столкнуться и что нам это даст. Зато понимали, что время на разработку увеличится, так как придется делать дополнительные операции.
Сразу поясню, что с EDT мы не работали и даже не рассматривали этот вариант. Мы остались в конфигураторе и работали с Git через выгрузку в файлы.
Мы понимали, что с Git наша жизнь изменится, но не понимали насколько. В итоге первое, что мы сделали с тремя информационными базами и двумя хранилищами — привели нашу кодовую базу в единое состояние, чтобы у нас была одна общая конфигурация на все базы ЗУП. Коллеги DevOps-инженеры провели для нас серию обучений, написали инструкцию, как работать с Git, что нужно делать. Но это не имело никакого эффекта: мы не смогли начать с этим работать до тех пор, пока не поставили жесткие сроки и не обрисовали план, как мы будем это делать. Было решено поэтапно переходить на Git. Начали с версионирования внешних отчетов и обработок, которые у нас до этого не версионировались. Затем перешли к версионированию конфигурации и расширения.
Что нам дал переход на Git
На базе GitLab DevOps-инженеры настроили автоматизацию для удобства разработчиков. Это позволило нам раскатывать дополнительные отчеты и обработки прямо из merge request в продовые базы, одним нажатием кнопки. Мы настроили понятный процесс код-ревью, который до этого было невозможно проводить на хранилищах.
Сейчас мы активно пишем автотесты. Проверка тестов зашита в пайплайны. Также выполняется проверка с помощью SonarQube.
Регламент разработки. Это первое, с чем сталкивается новый разработчик, когда приходит к нам в компанию. Он составлен давно. Важно отметить, что это живой инструмент — мы постоянно его развиваем, дополняем. Он представляет собой свод правил со всеми стандартами и локализациями внутри компании, по которым нужно разрабатывать и писать код.
Синтетические базы. В целях информационной безопасности, чтобы у разработчиков не было доступа к реальным персональным данным сотрудников и продуктовым данным, были развернуты синтетические базы, которые очень похожи на продуктовые с точки зрения настроек, но при этом содержат сгенерированные персональные данные.
Технический долг. Была организована работа с техническим долгом, который собирался по двум критериям: вид технического долга (рефакторинг, написать автотест, сделать оптимизацию, написать документацию) и причина возникновения долга. Мы пришли к тому, что начали ежеквартально выделять 25% ресурсов на то, чтобы сжигать этот технический долг.
Эксплуатация
Поддержка. Мы хотели, чтобы разработчики тратили меньше времени на поддержку пользователей, но не знали, как этого добиться. Начали с того, что написали техническую документацию (раньше она была только по интеграциям с другими системами). Написали пользовательские инструкции, ввели runbook — короткие записки для консультантов, которые поясняли, как самостоятельно решить простую проблему (перезапустить фоновое задание или посмотреть результат выгрузки). Сделали дайджесты (обзор доработок, фичей). Их мы выкладывали в канале, в корпоративном мессенджере, чтобы сами пользователи (заказчики) и консультанты видели, что мы сделали. Благодаря этому у них возникало меньше вопросов. Так мы снизили потребность в поддержке пользователей через информирование.
Мониторинги. Нашей целью было узнавать о проблеме до того, как с ней придет пользователь.
Мы организовали мониторинги. Их внедрение можно разделить на три этапа:
-
Определение ключевых сервисов и операций, которые необходимо мониторить;
-
Определение SLA — соглашения о том, как это должно работать;
-
Настройка алертов при нарушении 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.
