Как мы развиваем АСК Легарус: улыбаемся и пашем. Полгода спустя

Полгода назад я написал первую статью о том, как мы развиваем АСК Легарус, и закончил её словами, что постараюсь писать об этом регулярно.

Ну что же. Прошло ровно полгода.

Видимо, для меня это и есть регулярно 😊

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

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

Появился полноценный корпоративный чат и центр событий, отдельное мобильное приложение, свой push-сервис. Существенно вырос проектный блок, продолжил развиваться Service Desk, добавилось много AI-функций. Отдельная жизнь началась у документации.

В общем — улыбаемся и пашем.

Сначала немного цифр

Я не очень люблю измерять разработку количеством коммитов.

Можно сделать сто коммитов, перекладывая кнопки с места на место, а можно одним коммитом переделать половину бизнес-логики модуля. Поэтому как KPI разработчиков эта цифра почти бесполезна.

Но как способ посмотреть на общий темп — вполне.

С 25 марта по 25 сентября получилось примерно:

• 1606 коммитов во всех репозиториях;

• из них около 1488 — основная веб-платформа АСК;

• 53 — документация;

• 58 — мобильное приложение;

• 7 — новый сервис Push Gateway;

• около 320 уникальных задач.

Основную разработку при этом ведут два разработчика.

В среднем получается около 8–9 коммитов в день только в основном репозитории. Причём это средняя температура по больнице: например, в августе было больше 400 коммитов, потому что именно тогда мы активно запускали новый коммуникационный контур.

Но интереснее, конечно, не количество. Что за этими цифрами вообще произошло?

Весна. Service Desk должен быть удобен. Каждый день.

Весной основное внимание по-прежнему получал Service Desk.

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

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

Переделывали реестры и фильтры. Дорабатывали мобильное отображение заявок. Сделали нормальную работу с вложениями и их мгновенную загрузку. Появилось массовое и inline-редактирование задач внутри заявки.

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

Продолжали заниматься SLA, нагрузкой сотрудников, KPI. Появились новые возможности интеграции с Bitrix, Mattermost, MAX. Причём Mattermost теперь умеет не только получать информацию — из него можно создавать задачи.

Казалось бы — мелочь. Но моя позиция здесь с прошлой статьи не изменилась: хорошая корпоративная система не должна постоянно заставлять человека приходить к ней на поклон.

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

Не только Service Desk

Летом стало особенно заметно, что АСК постепенно перестаёт быть системой, которую можно описать словами «Service Desk плюс ещё несколько модулей».

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

Переделывали версии спецификаций, согласования, показатели, интерфейс работы с этапами, формирование PDF, НДС и ещё довольно много внутренней логики.

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

Последнее вообще относится к той категории разработки, которую обычный пользователь практически никогда не увидит. И это прекрасно.

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

AI. Не (зачеркнуто) волшебная кнопка

Отдельно продолжали заниматься искусственным интеллектом. Здесь у меня отношение довольно прагматичное. Добавлять в каждое окно кнопку «Спросить AI» просто потому, что сейчас так принято, большого смысла я не вижу. ИИ интересен там, где он действительно снимает с человека рутинную работу.

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

Развиваем AI-функции вокруг проектов — анализ сроков, трудозатрат, экономики проекта. Причём во многих местах специально придерживаемся принципа: ИИ предлагает, человек принимает решение. Получилась бомба! 💣

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

ИИ хорошо умеет убрать часть рутины, собрать информацию, обратить внимание на проблему, предложить вариант. А вот превращать его в бесконтрольного начальника проектов пока рановато 🙂

А потом мы сделали чат

Самая большая отдельная история последних месяцев — коммуникации.

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

Есть пользователи. Есть сообщения. Сделаем комнаты, отправку сообщений — готово.

Разумеется, всё оказалось немного интереснее. Потому что довольно быстро выясняется, что корпоративный чат — это не просто окно с сообщениями:

• Есть личные разговоры.

• Есть групповые.

• Есть каналы.

• Есть обсуждения конкретной заявки, задачи или проекта.

• Есть системные уведомления.

• Есть сообщения, на которые от человека требуется какое-то действие.

• Есть согласования.

• Есть упоминания, ветки, реакции, закреплённые сообщения, вложения.

И желательно, чтобы человек во всём этом не утонул.

В результате из идеи «давайте сделаем чат» постепенно вырос Центр коммуникаций — единый коммуникационный контур АСК.

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

Ценность появляется, когда разговор связан с тем, о чём люди разговаривают, — с заявкой, задачей, проектом, согласованием, документом. И когда из сообщения можно перейти к объекту, а из объекта — к его обсуждению.Именно эту связь мы сейчас постепенно выстраиваем.

Но если есть чат — нужна мобилка

Довольно быстро возник следующий очевидный вопрос.

Что толку от корпоративных коммуникаций, если они нормально работают только тогда, когда сотрудник сидит за компьютером?

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

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

Есть работа сразу с несколькими серверами АСК. Есть вход по биометрии. Тёмная тема и локализация. Из телефона можно поделиться файлом или другим содержимым прямо в АСК. Появилась первая версия работы с задачами.

Оказалось что Ru-Store так неторопливо аппрувит приложения, что нам приходится тормозить с выкладыванием новых релизов, так как старое еще не опубликовано 🤣

И, конечно, понадобились push-уведомления.

Push тоже решили сделать свой

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

Поэтому появился ещё один проект — собственный Push Gateway. Сейчас это отдельный сервис на Django + ntfy с поддержкой UnifiedPush и web push.

В результате схема получается довольно логичная:

АСК формирует событие > наш Push Gateway доставляет уведомление > мобильное приложение получает его > пользователь переходит прямо к нужному сообщению или объекту.

Без обязательной внешней облачной инфраструктуры. Конечно, ради семи коммитов можно было бы Push Gateway вообще не упоминать 😁 Но в данном случае важнее не размер репозитория, а то, зачем он появился.

Четыре репозитория вместо одного

Полгода назад разработка продукта для меня в основном ассоциировалась с одним большим репозиторием АСК.

Сейчас их фактически четыре:

• ASK — основная веб-платформа

• ASK Mobile — мобильное приложение

• Push Gateway — доставка уведомлений

• Документация — которая тоже давно перестала быть файлом README на полторы страницы.

Причём документация всё больше становится частью самого процесса разработки. Сделали OLA — надо описать. Изменили SLA — документация должна измениться вместе с системой. Появился чат — нужен отдельный раздел. Появилось мобильное приложение — нужен контракт взаимодействия мобильного клиента и сервера. Изменился nginx для websocket — это тоже должно быть зафиксировано.

Иначе через полгода никто уже не вспомнит, почему оно сделано именно так. В том числе мы сами.

А что в итоге?

Если посмотреть на эти полгода сверху, я бы разделил их на три этапа.

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

Летом начали сильнее расширять саму платформу: Trading, каталог услуг, OLA, AI, лицензирование, CMDB, проектные функции.

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

Появился собственный коммуникационный контур.

Потом мобильное приложение.

Потом push.

И это уже немного другая архитектура продукта.

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

• Где-то неправильно считался SLA

• Где-то неудобно отображалась карточка на телефоне

• Где-то надо было добавить один фильтр

• Где-то сообщение должно было прийти одному сотруднику, а приходило троим

• Где-то пользователь мог сделать действие, которое в данном статусе делать не должен

• Где-то после вставки из Outlook приезжало полстраницы ненужного HTML

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

И что дальше?

Работы меньше не стало. Скорее наоборот. Теперь недостаточно отдельно развивать Service Desk, отдельно проекты, отдельно чат или мобильное приложение.

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

Чтобы AI понимал контекст этих объектов, но не принимал за человека решения там, где этого делать не надо. Чтобы мобильное приложение было не уменьшенной копией сайта, а удобным инструментом для тех действий, которые действительно нужны с телефона.

Ну и Service Desk никто не отменял. Он как был одним из основных рабочих контуров продукта, так им и остаётся.

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

Если, конечно, моё понимание слова «регулярно» к тому времени не изменится 🤣

А пока — улыбаемся и пашем ✌️