Как мы разрабатывали ЭДО для «Автодора»

С потенциалом ускорения внутренних процессов в 145 раз

>> В этом абзаце мы обычно указываем ссылку на сайт проекта, но здесь её не будет, так как сама разработка находится под NDA <<

Из какой сферы наш заказчик

«Автодор» — государственная компания, занимающаяся строительством и ремонтом дорог с 2009 года. Под её управлением находится более 5000 километров дорог, по которым ежедневно проезжают тысячи машин.

В компании работают инженеры-проектировщики, которые разрабатывают планы строительства и ремонта дорог, и инженеры-строители, контролирующие качество работ и используемых материалов.

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

С какой задачей к нам пришли

Раньше для работы с документами в «Автодоре» использовали другую систему документооборота. Но у программы были свои сложности:

1.  Неочевидный user experience (пользовательский опыт);

2. Данные каждый раз приходилось вводить вручную;

3. На поиск нужной информации могло уходить много времени;

4. Подписывать документы можно было только от руки;

5. Иногда программа не выдерживала большого объёма данных и зависала;

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

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

Мы поговорили с представителями разных отделов, чтобы узнать, чего им не хватает и что хотелось бы улучшить. Вот так в «Автодоре» видели сервис мечты:

1. Вся информация находится в едином онлайн-пространстве.

2. Система состоит из маленьких, независимых частей — микросервисов, которые работают слаженно, при этом каждый по отдельности микросервис можно изменять и улучшать.

3. Добавлять новые функции и автоматизировать разные задачи можно в пару кликов.

4. Пользоваться сервисом можно на любом устройстве.

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

Результат работы

Нас попросили учесть сложности при работе с прошлой программой, и наша команда это сделала.

Мы внимательно изучили требования, чтобы разработать инструмент с учётом всех пожеланий «Автодора».

Что мы сделали:

— написали с нуля поисковой движок, который ускорил поиск до считанных секунд; 

— добавили функцию редактирования документов по государственным стандартам;

— существенно переработали интерфейс с учётом нового взаимодействия пользователей с инструментом.

Проверка документов по заранее обозначенным шаблонам стала автоматической.

Благодаря переходу в новый инструмент в компании увидели значительные изменения: мы также внесли в это свой вклад

Создание документа ускорилось в 60 раз

2 часа → 2 минуты

Отправка документа ускорилась в 576 раз

2 дня → 5 минут

Изучить изменения в документе теперь можно быстрее в 96 раз

2 дня → 30 минут

Откликаться сервис стал быстрее в 8 раз

40 секунд → 5 секунд

Зачем нужен был собственный инструмент

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

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

В случае с «Автодором» это ещё и гибкий подход. Например, если выходит новый закон, админ, который отвечает за поддержку систему, по первому запросу сможет добавить новый признак в документ, чтобы сотрудники тут же могли его использовать в работе.

Как мы организовали работу над проектом

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

Кстати, мы умеем работать по-настоящему time&material (тайм-энд-материал — фактически затраченное время и реально использованные ресурсы). Это значит — никакой накрутки часов, а только конкретные объём задач и количество storypoint (сторипоинт — оценка сложности задач в разработке) на один sprint (спринт — фиксированный период времени на разработку).

 

Также перед началом следующего спринта мы берём один сторипоинт на оценку от команды. На встрече команда задаёт заказчику уточняющие вопросы и только потом формирует свои обязательства на будущую разработку.

— Назначили людей. Руководитель проекта собрал команду для разработки и на общей встрече рассказал, чем предстоит заниматься, а также каким продукт видит заказчик и что можем предложить мы. После согласования с заказчиком затрат по времени и деньгам наша команда включились в работу. Таким образом мы смогли быстрее включиться в проект, не тратя время на ожидание по согласованию.

— Определили формат приёмки-сдачи. Новые задачи сначала обсуждали на встречах — аналитики со стороны заказчика рассказывали о проблемах, с которыми обычно сталкиваются сотрудники при работе с документами, а после встречи формировали в задачи сначала в Битриксе, а в конце проекта в EvaTeam, которые мы уходили обсуждать с командой. Дальше мы распределяли задачи по спринту и в течение следующих двух недель работали над тем, что обсуждали ранее. Бэкенд и фронтенд работали одновременно, поэтому нам удавалось существенно уменьшать общее время разработки.

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

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

Дружная команда

В какой-то момент в работу над продуктом подключилась также и внутренняя команда «Автодора» — она отвечала за разработку раздела «Поручения».

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

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

Ключевые точки роста, которых мы достигли в работе над проектом

1. Детализация технического задания. Изначальное ТЗ было довольно общим, что дало нам возможность проявить себя: задавать больше открытых вопросов и подстраиваться под новые данные прямо во время работы над проектом.

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

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

4. Эффективное распределение задач бэкенда. Позднее подключение бэкенд-разработчика немного увеличило сроки, но это стало для нас важным уроком. Теперь мы понимаем, как важно заранее планировать ресурсы, распределять задачи и не нагружать нашего архитектора.

5. Адаптация к изменениям в руководстве проекта. Смена руководителей дала нам возможность познакомиться с разными подходами к управлению. Мы создали подробную документацию по проекту, чтобы обеспечить преемственность.

6. Совершенствование процесса разработки. Настройка контуров CI/CD потребовала больше времени, чем ожидалось. А ещё первоначально и наши обновления, и обновления со стороны команды заказчика загружались в один контур, что вызывало конфликты в системе. Однако после выделения для нашей команды отдельного контура процесс стал более стабильным.

Всего было четыре контура: на первом тестирование проводили мы, на втором — аналитики «Автодора», на третьем — тестировщики «Автодора», на четвёртом — сотрудники компании.

7. Совершенствование процесса тестирования. Мы внедрили систему непрерывного тестирования, что позволило выявлять проблемы с юзабилити на ранних этапах и оперативно их решать.

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

Финальный результат: эти функции смогли преобразить продукт

Поиск по документам. Это, пожалуй, самая важная часть продукта, который мы разрабатывали. Благодаря этой функции сотрудники «Автодора» могут искать информацию по любому из атрибутов, которые мы предварительно загрузили в систему. Среди них имена, даты, проценты, простые и дробные числа и ещё 20+ других параметров.

При этом пользователи не могут редактировать атрибуты: менять их названия, тип и формат написания. Такая возможность есть только у суперадмина и админа — зайти в редактирование можно через раздел «Настройка базовых фильтров».

Ещё одна важная часть поиска — закреплённая информация. Туда можно добавлять какие-то отдельные документы или целые категории определённых документов, а также конкретные должности, авторов и ещё 50+ других загруженных категорий и атрибутов.

Функция форматно-логического контроля. Не менее полезная, чем возможность поиска. Благодаря этой функции при неправильном или не до конца заполненном поле в документе ФЛК автоматически обработает запросы и не только сообщит пользователю об ошибке, но и не даст ему пройти на следующий шаг. 

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

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

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

Вторая страница показывается в табличном формате и может сортироваться по одному из значений в столбце. Имеет подразделы «Определение атрибутов», «Типы документов», «Регистрационные последовательности», «Статусы документов», «Предварительный просмотр документов», «Типы связей документов», «Реестр документов» и «План закупок».

Функция создания, редактирования и работы с типом «договор». Имеет минимум 30+ полей, среди которых: тип документа, статус, номер документа, номер проекта, автор, исполнитель, отправитель, ФИО исполнителя и отправителя, подразделение автора, исполнителя и подписанта, получатель, кому, от кого, способ получения, уровень доступа, наименование / ОГРН, контрольный документ, перенесен из прошлого инструмента и восемь типов даты в формате «с» и «по» — создание, регистрация, срок исполнения и фактическая.

Дополнительно мы сделали ещё несколько полезных вещей.

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

Доработали аутентификацию и авторизацию. Увеличили размер кэша, чтобы хранить два токена вместо одного. Таким образом если пользователи перестают быть активны в аккаунте после 24 часов, при активности в следующий раз автоматически будет срабатывать второй токен авторизации, что для пользователя будет означать беспрерывную работу сервиса, а для нас — улучшение user experience. 

Добавили три уровня доступа. 

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

Админ. Настраивает формы документов, прописывая правила для ФЛК и логику всего документа (обязательные или необязательные атрибуты, количество страниц в документе, разделы документа) — то, как будет выглядеть документ.

Пользователь. Может создавать и отправлять документы по загруженным в документ стандартам. Добавлять в быстрый доступ какие-то документы или их атрибуты может только для своего аккаунта.

Усовершенствовали систему входа. У заказчика было чёткое требование к нашей разработке — безупречное соблюдение информационной безопасности. А всё потому, что пользоваться сервисом должны только сотрудники компании. Мы сделали так, чтобы каждый из сотрудников мог войти в систему только через выданные компанией логин и пароль и только через подключенный VPN. При этом менять данные для входа могут только суперадмин и админ и только по запросу.

Что проект ждёт в будущем

Переход из одной системы в другую — это сложный процесс. В такой крупной компании как «Автодор» полный переход может занять от 3 до 5 лет. 

И уже позади половина пути — на момент написания кейса в «Автодоре» запустили систему в опытную эксплуатацию и подключили первые отделы.

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

Команда

Боков Ахмад — руководитель проекта

Ребров Михаил — архитектор и тимлид

Новиков Николай — DevOps

Шарунов Андрей — фронтенд-разработчик

Ершов Валерий — фронтенд-разработчик

Черемшанцев Леонид — бэкенд-разработчик

Хвостиков Павел — бэкенд-разработчик

Огорелин Владислав — дизайнер

Савельев Вадим — дизайнер

Кочанов Андрей — тестировщик

Агаева Сабина — менеджер проекта

Вагапов Оскар — менеджер проекта

Кочанова Александра — автор кейса

22+ млн рублей

бюджет

2 года

срок работы

~ 48 000 часов

ушло на работу команды из 12 человек

До 10 000 сотрудников

могут одновременно пользоваться системой

> 100 000 документов

пропускная способность системы при плановой загрузке