Как навести порядок в 1С-разработке после быстрого роста компании: опыт Арлифта
Блог Kaiten ·
Какие изменения помогают разобраться с растущим бэклогом, приоритетами и неопределенными сроками
Рост компании редко ломает внутренние процессы в один день. Сначала становится сложнее назвать срок по новой задаче, затем в бэклоге копится все больше запросов, а руководителю приходится вручную выяснять, что сейчас происходит в разработке.
В Арлифте этот момент наступил на фоне быстрого роста бизнеса: количество заказов увеличилось втрое, компания открывала новые филиалы, а оборот за последние три года вырос в десять раз. CTO Арлифта пришлось заново собрать весь процесс разработки, чтобы связать запросы бизнеса с приоритетами команды и заранее понимать, какой объем работы она может взять.
О том, как это происходило, рассказал Илья Никулов, технический директор в Арлифте.
Арлифт работает со спецтехникой для строительства и промышленности: продает и предоставляет в аренду подъемники, мини-краны и вакуумные захваты и не только. Технику компании использовали на объектах Газпрома, Росатома и Сибура, при строительстве Москва-Сити. А, например, на небоскребе Лахта с ее помощью заменили стеклопакет массой 2,1 тонны.
Еще у компании есть отдельное направление с AWP , которое появилось в 2021 году. Арлифт начал ввозить из Китая самоходные подъемные платформы, на которых люди могут работать на высоте. За следующие пять лет парк такой техники вырос до более чем 2 000 машин. Всего компания управляет парком свыше 3 000 единиц, размещенных в 26 филиалах. География охватывает 11 часовых поясов: от Калининграда до Камчатки, а также Казахстан и Узбекистан.
Экономика аренды зависит от того, сколько времени техника работает у заказчиков. Подъемник дорого покупать и содержать, при этом на конкретном объекте он может понадобиться всего на несколько недель. После окончания работ собственная машина может долго простаивать и продолжать требовать обслуживания. Поэтому ключевая метрика бизнеса — утилизация парка, то есть доля техники, которая сейчас находится в аренде.
Чтобы поддерживать работу такого парка, компании нужно планировать логистику и расписание, вести учет ресурсов и документов, организовывать сервис, ремонт и производство. Эти процессы поддерживает собственное ПО на базе платформы 1С и Битрикс24, поэтому изменения в работе бизнеса регулярно превращаются в новые задачи для ИТ-команды.
Пока поток запросов оставался небольшим, команда справлялась с ним привычным способом. Внутренний заказчик приносил новую фичу, CTO или аналитик описывал требования и готовил техническое задание, после чего разработчик приступал к работе.
С ростом компании эта схема начала давать сбои. Запросов становилось все больше, а единого способа расставлять их по важности еще не было. Аналитики сами выбирали следующие задачи и могли ориентироваться на собственный интерес или отношения с заказчиком, поэтому место запроса в очереди не всегда отражало его значение для бизнеса.
Еще сильнее проблема проявлялась в сроках. Когда заказчик приносил новую задачу, ИТ-команда часто не могла заранее оценить, сколько времени займет разработка и в какой релиз попадет результат. Из-за этой неопределенности разговоры о сроках регулярно становились источником конфликтов.
Чтобы упорядочить работу, команда попробовала модуль «Скрам» в Битрикс24 и начала планировать задачи спринтами. Это помогло организовать работу на коротких отрезках, однако общей картины бизнес-бэклога у CTO все еще не было: оставалось непонятно, какие задачи действительно важны, что происходит внутри разработки и на какие сроки можно ориентировать бизнес.
На этом фоне CTO Арлифта стал иначе смотреть и на собственную роль. Значительная часть его работы по-прежнему уходила на анализ требований, архитектуру и подготовку технических заданий:
В итоге CTO Арлифта решил основательно пересмотреть работу отдела. Процессы, которые раньше во многом держались на негласных договоренностях, нужно было описать и сделать управляемыми. С этого началась перестройка подхода к разработке.
В Арлифте исторически сложилось примерно одинаковое количество аналитиков и разработчиков. Аналитики общаются с внутренними заказчиками, уточняют требования, готовят технические задания, тестируют доработки и пишут инструкции. Разработчики отвечают за техническую часть задачи.
Чтобы упорядочить этот процесс, CTO разделил специалистов на две команды по компетенциям. В первую вошли четыре аналитика, за каждым из которых закрепили свой функциональный модуль. Вторую сформировали из четырех универсальных разработчиков 1С. У обеих команд также появился свой лид.
Для аналитиков выстроили канбан-процесс. Они принимают входящий запрос, уточняют требования и постепенно доводят карточку до состояния, когда разработчики уже могут оценить задачу и включить ее в план. За счет этого бизнес-бэклог формируется из подготовленных запросов, по которым команда понимает суть будущей работы.
Разработчики работают недельными Scrum-спринтами. Каждую задачу они оценивают в часах: сторипоинты команда пробовала, но этот подход у нее не прижился. При планировании учитывают трудоемкость карточек и доступное время разработчиков, поэтому объем спринта связан с реальной емкостью команды.
Когда сам процесс приобрел понятную структуру, его нужно было перенести в рабочую систему.
Сначала новый подход продолжили развивать в Битрикс24. Команда уже использовала там модуль «Скрам», поэтому логично было попробовать собрать весь процесс в знакомой системе.
На практике настройка быстро начала требовать отдельных доработок:
С дашбордами возникла похожая проблема: возможностей системы не хватало, чтобы собрать представление работы под задачи отдела.
Ограничения Битрикс24 подтолкнули CTO искать систему, которую можно было настроить под уже описанный процесс. Он рассматривал Jira и Кайтен. Jira исключили из-за корпоративной политики безопасности, поэтому команда остановилась на Кайтене и начала переносить на доски новую схему работы.
В Кайтене команда использует два пространства: «Аналитика» и «Разработка». В первом аналитики работают с запросами на изменение учетных систем 1С, второе нужно для задач разработчиков, которые уже вошли в спринт. Сначала разберем, как устроено пространство аналитиков.
Пространство аналитиков состоит из нескольких досок:
На верхнем уровне находится «Стратегические цели и проекты» с эпиками. Конкретные запросы команда ведет на доске «Аналитика, оценка и планирование», где карточка проходит путь от разбора требований до релиза и завершения работы.
Каждый новый запрос проходит одну и ту же последовательность этапов:
Запрос попадает к аналитикам. Внутренние заказчики не заходят в Кайтен: для обращений в ИТ-службу в Арлифте используют 1С:ITILIUM. Сотрудник оставляет заявку там, первая линия поддержки разбирает ее и, если запрос связан с новой функциональностью, отправляет карточку в Кайтен на доску инициатив.
У каждого аналитика свой функциональный модуль: коммерция, финансы, аренда, сервис и другие направления. Новые карточки команда разбирает в течение одного дня. Если запрос остается неразобранным, лид контролирует срок регистрации и вручную назначает аналитика.
Аналитик разбирает запрос и определяет его приоритет. Карточка переходит на доску «Аналитика, оценка и планирование» в колонку «Анализ». Здесь специалист связывается с заказчиком, уточняет требования и разбирается, что именно нужно изменить.
Затем аналитик оценивает задачу по RICE — методу приоритизации. В Арлифте учитывают Impact (влияние), Confidence (уверенность в оценке), Effort (необходимые усилия). Например, смотрят, поможет ли изменение сэкономить человеко-часы или сократить количество ошибок.
На этом же этапе карточку связывают с эпиком на доске «Стратегические цели и проекты». 
Такая связь тоже влияет на место задачи в очереди:
Разработчики оценивают техническую часть. Лид разработчиков изучает требования, предлагает вариант архитектуры и оценивает трудоемкость задачи. Затем архитектор проверяет решение и при необходимости корректирует его. На основе согласованного варианта аналитик готовит техническое задание.
Подготовленная задача попадает в очередь на разработку. Аналитик переводит карточку в «Готово к планированию». В этой колонке собираются уже оцененные задачи, по которым закончили подготовительную работу и которые можно включать в следующий спринт.
Команда формирует спринт. В первую очередь учитывают задачи, связанные с проектами и стратегическими целями, затем смотрят на оценку RICE. Поскольку трудоемкость каждой карточки уже известна в человеко-часах, а емкость команды понятна заранее, можно рассчитать объем работы на следующий спринт.
Передача задачи разработчикам начинается еще в пространстве «Аналитика». Когда подготовленную карточку включают в план и переводят в «Следующий спринт», автоматизация Кайтена создает для нее дочернюю карточку в пространстве «Разработка». Исходная при этом остается у аналитиков и продолжает двигаться по их процессу.
Само пространство «Разработка» состоит из трех досок: «Бэклог», «Спринт», «Баги»:
На доску бэклога автоматически поступают дочерние карточки из пространства аналитики, которые распределяют между разработчиками и переносят на доску «Спринт». В карточке также указывают размер и тип задачи, инициатора и метки, подробности фиксируют в описании, а детали обсуждают в комментариях и там же прикладывают нужные файлы.
На ней каждая карточка проходит семь этапов: «Бэклог спринта», «В разработке», «Готово к тестированию», «В тестировании», «Доработка», «Проверено» и «Готово».
Когда разработчик переводит дочернюю карточку из одной колонки в другую, срабатывает настройка автоматизации, которая  обновляет состояние исходного запроса в пространстве аналитиков.
Так один бизнес-запрос остается связан с двумя частями процесса. Аналитики продолжают работать с исходной карточкой, а разработчики ведут отдельную задачу по своему спринту. Связь между ними сохраняется через родительскую и дочернюю карточки и настроенные переходы статусов.
Еще одна доска, которая помогает организовать работу — «Баги». Это отдельная доска для ошибок, куда задачи приходят от первой линии поддержки.
Готовые доработки в Арлифте тестируют аналитики, и именно этот этап оказался узким местом процесса: задачи могли зависать и накапливаться. Поэтому команде понадобился отдельный контроль за тем, сколько карточек находится на тестировании и как долго они там остаются.
Для этого в Кайтене аналитики получают уведомления, когда карточка переходит на тестирование. Кайтен показывает, сколько времени задача находится на этом этапе, и предупреждает о превышении WIP-лимита. Так можно заметить растущую очередь до того, как она станет постоянной проблемой.
Отдельно разработчики фиксируют фактические затраты времени. Каждый день они отмечают в карточках, сколько работали над задачей, а при изменении кода 1С указывают номер тикета. По нему можно восстановить историю правок и контекст задачи.
Для управленческой аналитики CTO выгружает сырые данные из Кайтена через скрипты и API в Google Sheets, а отчеты и нужные разрезы строит в Yandex DataLens. Стандартных отчетов Кайтена для задач Арлифта оказалось недостаточно, встроенного конструктора отчетов в системе нет.
По этим данным руководитель видит, где задерживаются карточки, у кого из аналитиков накапливаются задачи и как меняется скорость команды. Информацию из Кайтена также используют для автоматического формирования описаний релизов и запуска опросов по оценке качества выполненных работ. В итоге CTO получает общую картину процесса и может быстрее замечать перегрузки и узкие места.
После перестройки процесса сроки стали предсказуемее. Средняя оценка задач в часах на спринт близко совпадает с фактическими затратами, поэтому команда может заранее ориентировать внутренних заказчиков по срокам выхода доработок.
Метрики в DataLens дают CTO данные по всему потоку разработки. Он видит, сколько новых карточек приходит за период, сколько команда доводит до релиза и как меняется бизнес-бэклог. Там же можно отслеживать задержки на отдельных этапах, накопление задач у аналитиков, превышение WIP-лимитов и динамику скорости команды.
Эти данные помогают понять, где именно возникло ограничение и что на него повлияло: загрузка сотрудников, неготовые требования, приоритизация или другая часть процесса. Руководитель может оценивать состояние разработки по конкретным показателям и раньше замечать места, где работа начинает замедляться.
За два года Арлифт пришел к процессу, в котором задачи проходят понятный путь от запроса до релиза, стратегические инициативы остаются в поле зрения команды, а проблемы становятся заметны раньше. Бизнес получает более понятные сроки, CTO видит состояние разработки и планирует работу команды на основе фактических данных.