Я CTO в Арлифте — мы сдаём в аренду и продаём спецтехнику: подъёмники, мини-краны и вакуумные захваты. Наши машины работают на стройках Газпрома, Росатома, Сибура. Меняли стеклопакет на небоскрёбе Лахта весом в 2,1 тонны. Мы остекляли и помогали строить Москва-Сити. 25 городов, 3 страны, оборот 6 млрд в год и основной стек — платформа 1С и Битрикс24.

С 2021 года компания начала развивать новое направление — аренду AWP (самоходных подъёмных платформ для подъёма людей на высоту). Раньше такой техники на рынке почти не было, но она быстро стала востребованной в строительной отрасли. Арлифт начал импортировать AWP из Китая и за 5 лет сформировал собственный арендный парк более чем из 2000 машин. За последние три года оборот компании вырос в 10 раз!

Мы очень сильно и быстро выросли: компания открыла много новых филиалов, количество заказов увеличилось в 3 раза. И у меня, как у руководителя ИТ, возникли сложности:

— Мы жили в мире разработки 1С, где нет таких процессов, как оценка фичи, код-ревью, автоматизированное и регрессионное тестирование и так далее. Обычный процесс — заказчик принёс фичу, я или аналитик пишем ТЗ, а разработчик реализует задачу.

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

— Сроки реализации никто точно не знал. Это приводило к конфликтам с бизнесом: мы не могли ничего обещать и ответить на входе, сколько фича будет делаться. Говорили: «Как будет, так будет».

Чтобы хоть как-то управлять процессом, решили использовать модуль Скрам в нашей тикет-системе Битрикс24. Это позволило начать планирование спринтов, но я не чувствовал, что управляю бизнес-бэклогом. Да и что происходит в разработке, было непонятно.

В тот момент у меня возник синдром самозванца: я чувствовал себя скорее аналитиком и архитектором, чем руководителем отдела разработки.

Что делать? Для начала — то, что раньше держалось на негласных договорённостях, надо было приводить в порядок и делать управляемыми процессами.

За 2 года я пересобрал принципы работы, и получилось обещать и чётко выполнять сроки внутренним заказчикам, реалистично оценивать важность фичей, не пропускать стратегические вещи, контролировать, кто над чем и насколько эффективно работает, прямо реально видеть каждый статус каждой задачи. И бизнес, и я, и команда почувствовали, что стало понятнее и лучше.

Сейчас расскажу, как.

Что вообще за бизнес мы автоматизируем

Чтобы был понятен масштаб: у нас в собственности и управлении находится более 3000 единиц техники. Это огромный парк, который раскидан по 26 филиалам в 11 часовых поясах — от Калининграда до Камчатки, в Казахстане и Узбекистане. В каждом филиале — свой сервисный центр, инженеры и склад запчастей.

Техника у нас очень разная, дорогая и под сложные задачи. Есть ножничные подъёмники, которые поднимают платформу строго вверх. Есть телескопические и коленчатые подъёмники, работающие на высоте почти 60 метров, на уровне 20-этажного дома. Есть гусеничные мини-краны (краны-пауки), которые прошли все главные стройки страны — от реконструкции Петропавловской крепости и Эрмитажа до новых терминалов Шереметьево и промышленных гигантов. Есть вакуумные захваты ARLIFTER, которые мы создаём специально для работы в российских условиях. Мы крупнейший в РФ и СНГ производитель такого технологичного оборудования.

Главная экономическая идея такая: подъёмник дорого купить и ещё дороже содержать, а нужен он заказчику не постоянно. Строителю телескопический подъёмник на 40 метров требуется три недели на одном объекте, а потом полгода он будет просто стоять во дворе, занимать место и требовать ТО. Покупка такой машины замораживает миллионы в железе, если не пользоваться ей регулярно.

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

То есть нужна хорошая работа с документооборотом, деньгами, учётом ресурсов, расписанием и логистикой, сервисом, ремонтом и производством. И это всё собственное ПО на базе платформы 1С и Битрикс24, поэтому любое изменение — по сути, отдельная разработка.

Как я выстроил процесс разработки

Мир 1С-разработки — очень специфичный. Это касается и архитектуры, и инструментов, и подходов к CI/CD-пайплайнам. При этом кое-что остаётся стандартным для отрасли: взаимодействие с бизнесом, анализ требований, планирование и постановка задач. Они выстраиваются по стандартам продуктовой разработки и требуют прозрачной приоритизации, прописывания понятных требований и технических заданий. И чтобы никаких проблем не было с бэклогом и дорожными картами.

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

Сначала я сформировал две команды по компетенциям. Первая состояла из четырёх аналитиков, каждый со своим функциональным модулем. Вторая — из четырёх универсальных разработчиков 1C. Обе получили по своему лиду.

Аналитики обрабатывают входящие запросы на изменения системы, уточняют требования и оформляют технические задания. Делают они это в канбане — каждый запрос идёт по дорожке от «нового запроса» до «готово к планированию». Так мы формируем бизнес-бэклог, а аналитики готовят каждый запрос к передаче в разработку.

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

Мне очень хотелось автоматизировать всю эту ситуацию. Сначала я попробовал сделать это в Битрикс24 через модуль Скрам, но мы быстро упёрлись в технические ограничения. Простое добавление пользовательских полей на карточку или их вынос в интерфейс превратился в танцы с бубном, ещё и очень дорогие в доработке. С дашбордами в Битрикс24 тоже как-то не сложилось, настроить их под свои задачи было практически невозможно, можно было только добавить этапы в воронке.

И мы очутились на распутье между Jira и Кайтеном. Первую отмели быстро — её зарубила корпоративная политика безопасности.

В итоге мы остановились на Кайтене.

Как мы всё автоматизировали в Кайтене

Я начал с простого шага — описал идеальный процесс и перенёс его на доски.

В Кайтене команды работают в двух пространствах: «Аналитика» и «Разработка». В первом сидят только аналитики, здесь учитываются все задачи на изменение учётных систем 1С. Второе, соответственно, — для наших разработчиков.

Внутри пространства «Аналитика» настроена чёткая система дашбордов: на верхнем уровне — доска «Стратегические цели и проекты», где живут наши эпики.

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

Дальше карточка едет по конвейеру на доске «Аналитика, оценка и планирование».

Всего этапов у нас одиннадцать. Вот как они выглядят: «Анализ», «Оценка разработчиком», «Согласование архитектуры», «Написание ТЗ», «Готово к планированию», «Следующий спринт», «Бэклог», «Разработка», «Уход в релиз», «Обратная связь», «Готово».

В колонке «Анализ» аналитик связывается с заказчиком, уточняет требования и оценивает задачу по методу RICE. Мы смотрим на важность (Impact), уверенность (Confidence) и усилия (Effort): принесёт ли фича экономию человеко-часов, снизит ли количество ошибок. И главное — аналитик связывает задачу с эпиком. Если карточка бьётся в стратегическую цель (или пришла сверху с тегом «VIP»), она взлетает в приоритете.

Больше мы важные вещи не теряем.

Затем следуют колонки «Оценка разработчиком» и «Согласование архитектуры». На первом этапе лид разработчиков читает требования к изменению, предлагает варианты архитектуры решения и оценивает трудоёмкость задачи. На втором — архитектор рассматривает предложенное решение, вносит корректировки, если нужно, и утверждает архитектуру. Уже после этого аналитик подготавливает техническое задание и переводит задачу на этап «Готово к планированию».

В этой колонке у нас копятся оценённые задачи, которые полностью готовы к тому, чтобы уйти в разработку. Из них формируется следующий спринт разработчиков. В приоритете те, которые связаны с проектами и стратегическими целями. Потом в ход идёт RICE — у которых показатель выше, те и идут в работу. Поскольку все задачи оцениваются в человеко-часах и мы знаем ёмкость команды разработчиков, можно спокойно планировать объём работ на следующий спринт.

Дальше начинается интересное. Задача забирается на реализацию командой разработки, когда карточку в пространстве «Аналитика» переводят в колонку «Следующий спринт». В этот момент штатная подсистема автоматизации Кайтен создаёт дочернюю карточку в пространстве «Разработка», а исходная карточка остаётся в «Аналитике».

Пространство «Разработка» у нас разделено на три доски — «Бэклог», «Спринт» и «Баги».    Созданные из пространства «Аналитика» дочерние карточки автоматически попадают на доску «Бэклог». Во время планирования их распределяют между разработчиками и переносят на доску «Спринт». Задачи на доску «Баги» поступают от первой линии поддержки. 

Набор этапов на доске «Спринт» такой: «Бэклог спринта», «В разработке», «Готово к тестированию», «В тестировании», «Доработка», «Проверено», «Готово».

Программист ведёт дочернюю карточку по этапам процесса. Её переход в статус «В разработке» автоматически перемещает родительскую карточку из пространства «Аналитика» в колонку «Разработка», а переход в статус «Готово» — в колонку «Уходит в релиз».

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

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

Я не использую стандартные отчёты Кайтена — они не покрывают наши потребности. Встроенного конструктора отчётов в системе тоже нет. Так что я выгружаю сырые данные из Кайтена в Google Sheets с помощью скриптов и API, а все отчёты и разрезы строю уже в Yandex DataLens. Там я вижу всю аналитику и динамику.

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

К чему пришли

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

Во-вторых, с появлением метрик в DataLens управление стало менее интуитивным и более основанным на объективных данных. Теперь я вижу, справляется ли команда с потоком новых задач: сколько карточек приходит за период, сколько мы успеваем довести до релиза и растёт ли бизнес-бэклог.

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

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

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

И теперь, глядя, как вся эта машина работает, я ловлю себя на мысли: всё — я CTO, официально. Машинка едет, а я уже не просто аналитик, который пишет ТЗ и раздаёт поручения, а тот самый парень, который её запустил и уверенно ведёт.