Который может ускорить внутренние процессы компании в 145 раз
>> В этом абзаце мы обычно указываем ссылку на сайт проекта, но здесь её не будет, так как сама разработка находится под NDA <<
Из какой сферы наш заказчик
«Автодор» — государственная компания, занимающаяся строительством и ремонтом дорог с 2009 года. Под её управлением находится более 5000 километров дорог, по которым ежедневно проезжают тысячи машин.
В компании работают инженеры-проектировщики, которые разрабатывают планы строительства и ремонта дорог, и инженеры-строители, контролирующие качество работ и используемых материалов.
Также в «Автодоре» трудятся специалисты по документообороту. Они ведут учёт всей документации, включая договоры и платёжные поручения. Документооборот — важная составляющая процессов компании.
С какой задачей к нам пришли
Раньше для работы с документами в «Автодоре» использовали LanDocs. Но у программы были свои сложности:
1. Неочевидный user experience (пользовательский опыт);
3. Данные каждый раз приходилось вводить вручную;
4. На поиск нужной информации могло уходить много времени;
5. Подписывать документы можно было только от руки;
6. Иногда программа не выдерживала большого объёма данных и зависала;
7. Нельзя было напрямую отправлять документы в другие государственные организации.
В 2022 году в компании решили разработать собственный инструмент, в котором были бы только нужные функции и не мешало ничего лишнего. Цель простая — сделать работу сотрудников в разы быстрее и приятнее.
Мы поговорили с представителями разных отделов, чтобы узнать, чего им не хватает и что хотелось бы улучшить. Вот так в «Автодоре» видели сервис мечты:
1. Вся информация находится в едином онлайн-пространстве.
2. Система состоит из маленьких, независимых частей — микросервисов, которые работают слаженно, при этом каждый по отдельности микросервис можно изменять и улучшать.
3. Добавлять новые функции и автоматизировать разные задачи можно в пару кликов.
4. Пользоваться сервисом можно на любом устройстве.
Но самое главное, что хотела сделать компания — это настраивать и поддерживать систему самостоятельно, без помощи разработчиков.
Главная мысль
“ Любые устоявшиеся бизнес-процессы можно и нужно улучшать. Даже дорогая разработка может окупиться за короткое время, если сам продукт, словно недостающий пазл, будет идеально встроен в рабочий процесс. ”
Результат работы
Нас попросили учесть сложности при работе с прошлой программой, и наша команда это сделала.
Мы взяли наработки прошлого подрядчика, внимательно изучили требования и довели систему до ума, чтобы она смогла запуститься и работать так, как этого хотел «Автодор».
А именно:
— написали с нуля поисковой движок, который ускорил поиск до считанных секунд;
— добавили функцию редактирования документов по государственным стандартам;
— существенно переработали интерфейс с учётом нового взаимодействия пользователей с инструментом.
Проверка документов по заранее обозначенным шаблонам стала автоматической.
Благодаря переходу в новый инструмент в компании увидели значительные изменения: мы также внесли в это свой вклад
Создание документа ускорилось в 60 раз
2 часа → 2 минуты
Отправка документа ускорилась в 576 раз
2 дня → 5 минут
Изучить изменения в документе теперь можно быстрее в 96 раз
2 дня → 30 минут
Откликаться сервис стал быстрее в 8 раз
40 секунд → 5 секунд
Зачем нужен был собственный инструмент
Готовые решения «из коробки» (зашёл, скачал, установил) хороши, когда у вас малый и средний бизнес — в этом случае они идеально закроют ваши потребности.
Когда же потребности появляются у вас как у компании с десятком юрлиц сразу, коробочные решения никогда не смогут полностью вас удовлетворить. Собственный инструмент в этом же случае решит все вопросы разом — ведь он полностью разработан под вас.
В случае с «Автодором» это ещё и гибкий подход. Например, если выходит новый закон, админ, который отвечает за поддержку систему, по первому запросу сможет добавить новый признак в документ, чтобы сотрудники тут же могли его использовать в работе.
Как мы организовали работу над проектом
— Собрали пожелания. Сначала нам рассказали, какую в компании хотят решить задачу и как видят её решение. Затем это видение ответственные за проект со стороны «Автодора» зафиксировали в техническом задании и в приложении к договору. После этого мы посчитали объём работы и затраты на разработку и эту информацию понесли на согласование к заказчику. Вдумчивый подход к обсуждению и сбору требований позволил уменьшить количество недопониманий в работе в дальнейшем.
Кстати, мы умеем работать по-настоящему time&material (тайм-энд-материал — фактически затраченное время и реально использованные ресурсы). Это значит — никакой накрутки часов, а только конкретные объём задач и количество storypoint (сторипоинт — оценка сложности задач в разработке) на один sprint (спринт — фиксированный период времени на разработку).
Также перед началом следующего спринта мы берём один сторипоинт на оценку от команды. На встрече команда задаёт заказчику уточняющие вопросы и только потом формирует свои обязательства на будущую разработку.
— Назначили людей. Руководитель проекта собрал команду для разработки и на общей встрече рассказал, чем предстоит заниматься, а также каким продукт видит заказчик и что можем предложить мы. После согласования с заказчиком затрат по времени и деньгам наша команда включились в работу. Таким образом мы смогли быстрее включиться в проект, не тратя время на ожидание по согласованию.
— Определили формат приёмки-сдачи. Новые задачи сначала обсуждали на встречах — аналитики со стороны заказчика рассказывали о проблемах, с которыми обычно сталкиваются сотрудники при работе с документами, а после встречи формировали в задачи сначала в Битриксе, а в конце проекта в EvaTeam, которые мы уходили обсуждать с командой. Дальше мы распределяли задачи по спринту и в течение следующих двух недель работали над тем, что обсуждали ранее. Бэкенд и фронтенд работали одновременно, поэтому нам удавалось существенно уменьшать общее время разработки.
— Определили формат тестирования. По окончании спринта сначала наш тестировщик внимательно проверял выполненную работу, затем мы показывали заказчику то, что сделали за это время, не забывая при этом параллельно собирать обратную связь. А после этого, пока мы брали в работу новые задачи, аналитики и тестировщики «Автодора» сначала проверяли работоспособность уже реализованных функций, затем проверенную версию прежде загружали на тестовый прод, чтобы убедиться, что новые функции не будут конфликтовать с уже существующими и только потом всё новое мы переносили из тестового прода на демо-прод. Именно демо-продукт проверяли сотрудники «Автодора». Благодаря такому формату мы могли чётко понимать, сходится ли наше видение продукта с видением тех, кому этот продукт предстоит использовать непосредственно в работе.
Важная деталь любого проекта — это его менеджер, ведь он несёт ответственность за работу всей команды разработки. Он должен уметь многое: с умом тратить ресурсы проекта, постоянно поддерживать и вдохновлять команду, следить за производительностью и общим настроением на проекте. Но главная его задача — приходить к назначенным целям за короткое время и в рамках конкретного бюджета. Хороший менеджер — это большая ценность для компании. На нашем проекте таких было сразу двое.
Что уже было сделано до нас
В том же 2022 году, когда «Автодор» решил создать собственный инструмент, появился и первый исполнитель задачи — сторонняя компания, занимающаяся разработкой ПО на заказ.
Они разработали функцию управления документами и конструктор форм, загрузили в систему справочники и предложили свой вариант дизайна интерфейса для основных страниц сайта — «авторизация», «общий список документов» и «страница с открытым документом».
Так получился MVP (эмвэпи — минимально жизнеспособный продукт). После этого «Автодор» пригласил уже нас — в качестве внешних консультантов. Мы провели полный аудит и оформили его в подробный отчёт.
Затем «Автодор» подготовил для нашей команды техническое задание и в список работ добавил также надстройки к существующим функциям.
Сразу после этого начался процесс модернизации и доработки — и мы уже в качестве команды разработки помогли развернуть «Автодору» собственную микросервисную систему на его архитектуре.
В какой-то момент в работу над продуктом подключилась также и внутренняя команда «Автодора» — она отвечала за разработку раздела «Поручения».
Совместно с аналитиками со стороны заказчика мы работали как инхаус-команда: вместе строили процессы, составляли технические задания, делали аналитику и занимались разработкой.
Кстати, мы не только создаём продукты, но и помогаем их освоить. То есть, передаём готовое решение вместе с понятной инструкцией, которая поможет сотрудникам легко начать с ним работу.
Ключевые точки роста, которых мы достигли в работе над проектом
1. Детализация технического задания. Изначальное ТЗ было довольно общим, что дало нам возможность проявить себя: задавать больше открытых вопросов и подстраиваться под новые данные прямо во время работы над проектом.
2. Гибкость в работе с требованиями. Заказчик часто вносил изменения, что позволило нам продемонстрировать нашу адаптивность. Мы стали собирать обратную связь прямо во время демонстрации выполненной работы по окончании каждого спринта, что позволило нам оперативно реагировать на новые идеи и пожелания.
3. Больше внимания в подходящий момент. В гарантийный период коммуникация с заказчиком была менее интенсивной, что привело к некоторому недопониманию. Однако мы оперативно реагировали на запросы и дорабатывали функциональность, чтобы соответствовать ожиданиям.
4. Модернизация унаследованного кода. Нам пришлось переписать сервис авторизации, так как его изначальная реализация не соответствовала требованиям. Но мы не только исправили проблему, но и оптимизировали работу сервиса.
5. Эффективное распределение задач бэкенда. Позднее подключение бэкенд-разработчика немного увеличило сроки, но это стало для нас важным уроком. Теперь мы понимаем, как важно заранее планировать ресурсы, распределять задачи и не нагружать нашего архитектора.
6. Адаптация к изменениям в руководстве проекта. Смена руководителей дала нам возможность познакомиться с разными подходами к управлению. Мы создали подробную документацию по проекту, чтобы обеспечить преемственность.
7. Совершенствование процесса разработки. Настройка контуров CI/CD потребовала больше времени, чем ожидалось. А ещё первоначально и наши обновления, и обновления со стороны команды заказчика загружались в один контур, что вызывало конфликты в системе. Однако после выделения для нашей команды отдельного контура процесс стал более стабильным.
Всего было четыре контура: на первом тестирование проводили мы, на втором — аналитики «Автодора», на третьем — тестировщики «Автодора», на четвёртом — сотрудники компании.
8. Совершенствование процесса тестирования. Мы внедрили систему непрерывного тестирования, что позволило выявлять проблемы с юзабилити на ранних этапах и оперативно их решать.
9. Эффективное устранение багов. Работа над сложными багами в рамках гарантийных обязательств позволила нам углубить понимание системы. Мы планируем создать библиотеку типовых решений, чтобы ускорить процесс исправления подобных проблем в будущем.
Финальный результат: эти функции смогли преобразить продукт
Поиск по документам. Это, пожалуй, самая важная часть продукта, который мы разрабатывали. Благодаря этой функции сотрудники «Автодора» могут искать информацию по любому из атрибутов, которые мы предварительно загрузили в систему. Среди них имена, даты, проценты, простые и дробные числа и ещё 20+ других параметров.
При этом пользователи не могут редактировать атрибуты: менять их названия, тип и формат написания. Такая возможность есть только у суперадмина и админа — зайти в редактирование можно через раздел «Настройка базовых фильтров».
Ещё одна важная часть поиска — закреплённая информация. Туда можно добавлять какие-то отдельные документы или целые категории определённых документов, а также конкретные должности, авторов и ещё 50+ других загруженных категорий и атрибутов.
Функция форматно-логического контроля. Не менее полезная, чем возможность поиска. Благодаря этой функции при неправильном или не до конца заполненном поле в документе ФЛК автоматически обработает запросы и не только сообщит пользователю об ошибке, но и не даст ему пройти на следующий шаг.
Такая функция работает с помощью ElasticSearch — мощной системы для поиска и анализа больших объёмов данных. Она позволяет быстро находить нужную информацию среди миллионов записей, как если бы мы искали что-то в интернете, но только внутри нашей собственной базы данных.
Калькулятор внутри документа. Встроен в каждый из документов и позволяет прямо во время редактирования информации выводить на основе двух числовых значений третье. Например, если выделить бюджет за два предыдущих года, калькулятор добавит в третье поле общую сумму этих значений.
Страницы со списком документов и управления документами. Первая страница не просто выводит все документы, созданные пользователями, а позволяет показывать только необходимые по 11 параметрам: тип или номер документа, номер проекта, статус, автор, от кого, кому, дата создания с, дата создания по, дата регистрации с, дата регистрации по. В самой таблице показывает также краткое содержание документа.
Вторая страница показывается в табличном формате и может сортироваться по одному из значений в столбце. Имеет подразделы «Определение атрибутов», «Типы документов», «Регистрационные последовательности», «Статусы документов», «Предварительный просмотр документов», «Типы связей документов», «Реестр документов» и «План закупок».
Функция создания, редактирования и работы с типом «договор». Имеет минимум 30+ полей, среди которых: тип документа, статус, номер документа, номер проекта, автор, исполнитель, отправитель, ФИО исполнителя и отправителя, подразделение автора, исполнителя и подписанта, получатель, кому, от кого, способ получения, уровень доступа, наименование / ОГРН, контрольный документ, перенесен из Ландокса и восемь типов даты в формате «с» и «по» — создание, регистрация, срок исполнения и фактическая.
Дополнительно мы сделали ещё несколько полезных вещей.
Подготовили сравнительный анализ для улучшения. Создали таблицу, которая поможет технически, без сбоев, улучшить уже запущенную на продакшене систему, сделав её работу быстрее и эффективнее, если заказчику это понадобится в будущем.
Доработали аутентификацию и авторизацию. Увеличили размер кэша, чтобы хранить два токена вместо одного. Таким образом если пользователи перестают быть активны в аккаунте после 24 часов, при активности в следующий раз автоматически будет срабатывать второй токен авторизации, что для пользователя будет означать беспрерывную работу сервиса, а для нас — улучшение user experience.
Добавили три уровня доступа.
Суперадмин. Тот, который создаёт аккаунты пользователям и может ими управлять. Он же может добавлять в быстрый доступ популярные категории и атрибуты документов для всех пользователей.
Админ. Настраивает формы документов, прописывая правила для ФЛК и логику всего документа (обязательные или необязательные атрибуты, количество страниц в документе, разделы документа) — то, как будет выглядеть документ.
Пользователь. Может создавать и отправлять документы по загруженным в документ стандартам. Добавлять в быстрый доступ какие-то документы или их атрибуты может только для своего аккаунта.
Усовершенствовали систему входа. У заказчика было чёткое требование к нашей разработке — безупречное соблюдение информационной безопасности. А всё потому, что пользоваться сервисом должны только сотрудники компании. Мы сделали так, чтобы каждый из сотрудников мог войти в систему только через выданные компанией логин и пароль и только через подключенный VPN. При этом менять данные для входа могут только суперадмин и админ и только по запросу.
Что о продукте говорят в компании «Автодор»
Эркенова Виктория Вячеславовна
Заместитель председателя Правления Российских автомобильных дорог («Автодор»)
Что проект ждёт в будущем
Переход из одной системы в другую — это сложный процесс. В такой крупной компании как «Автодор» полный переход может занять от 3 до 5 лет.
И уже позади половина пути — на момент написания кейса в «Автодоре» запустили систему в опытную эксплуатацию и подключили первые отделы.
Считаем, что наша разработка обеспечила компании плавный старт и заложила основу для устойчивого развития собственной системы. В дальнейших планах «Автодора» — полностью перенести все документы из LanDocs и наладить документооборот с новым инструментом во всех подразделениях компании.
Команда
Боков Ахмад — руководитель проекта
Ребров Михаил — архитектор и тимлид
Новиков Николай — DevOps
Шарунов Андрей — фронтенд-разработчик
Ершов Валерий — фронтенд-разработчик
Черемшанцев Леонид — бэкенд-разработчик
Хвостиков Павел — бэкенд-разработчик
Огорелин Владислав — дизайнер
Савельев Вадим — дизайнер
Кочанов Андрей — тестировщик
Агаева Сабина — менеджер проекта
Вагапов Оскар — менеджер проекта
Кочанова Александра — автор кейса
22+ млн рублей
бюджет
2 года
срок работы
~ 48 000 часов
ушло на работу команды из 12 человек
До 10 000 сотрудников
могут одновременно пользоваться системой
> 100 000 документов
пропускная способность системы при плановой загрузке
