Росэнергоатом — одна из самых крупных мировых энергетических корпораций, управляет 11-тью атомными станциями. Основное направление — производство электрической и тепловой энергии, а также управление ядерными материалами и радиоактивными веществами.

На станциях Корпорации установлено более 37 энергоблоков с общей мощностью более 29,5 ГВт. Доля выработки энергии — около 20% от объема выработки энергии в России.

Задача состояла в разработке решения для отображения ключевой информации, необходимой для топ-менеджмента АО «Концерн Росэнергоатом».

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

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

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

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

Новая система должна была решить проблемы предшественника и быть доступной руководителю, где бы он ни находился — в командировке, дома или на рабочем месте:

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

Разработка пришлась на то время, когда зарубежные сервисы уже не могли быть использованы, поэтому на середине проекта в срочном порядке мы меняли большое количество своих рабочих инструментов: самое яркое воспоминание — переезд с продуктов Atlassian на Yandex, а именно с Jira на Tracker.

Нужно было в срочном порядке переделать все настроенные рабочие процессы в новой инфраструктуре, перенести все задачи проекта без потерь статусов, комментариев и др., а также подстроиться под новые ограничения — всё-таки, в этот момент Tracker сильно уступал. В итоге, переезд состоялся достаточно безболезненно и уже через пару недель мы работали в новой инфраструктуре.

Старт проекта и архитектура

На старте мы расширили Техническое Задание, в котором было детально описано, как именно система должна обеспечивать описанные требования.

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

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

Подготовка от подписания контракта, до окончания проектирования и старта разработки, заняла около полутора календарных месяцев при учете, что старт проекта выпал на середину декабря и первые недели января никто не работал.

Персональные дашборды для топ-менеджеров

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

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

Гибкость настроек

Пользователь может вывести любой из доступных показателей на свой персональный дашборд, а также изменить его расположение относительно других показателей.

PUSH-уведомления об отклонениях


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

Для упрощения поиска показателей с отклонениями, на всех дашбордах есть фильтр по отклонениям.

Вход по пин-коду


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

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

Дашборды для подразделений

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

Чтобы еще быстрее найти нужный показатель, мы сделали дополнительное представление дашборда — вывод списком.

Мультиплатформенность

Мы разработали и адаптировали приложение для любого устройства. Сервис стал доступен в любом месте, в любое время, в любой ситуации.

Разрабатывали в формате MobileFirst, так как в приоритете мобильное приложение. Еще до старта разработки было понятно, что анализ показателей в смартфоне — будет самый часто используемый сценарий.

Адаптировано для планшетов

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

Десктопная версия

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

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

Проведение совещаний

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

Но никуда не деться от оперативных показателей, данные по которым еще не заведены в систему. Например, срочное совещания по новым обстоятельствам. Таким стало срочное совещание по заболеваемости коронавирусом. Для таких случаев на дашборд можно добавить изображение-слайд, который был отрисован в сторонних приложениях.

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

Offline-доступ к показателям

Пользователь не всегда может находиться в зоне wi-fi или даже в мобильной сети. Поэтому был предусмотрен механизм хранения данных и доступа к приложению в offline-режиме: где бы ты ни был — в самолёте или в лесу, ты всегда можешь посмотреть состояние показателей.

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

Полноценная панель управления

Управление настройками сервиса мы вынесли в административную панель, откуда можно управлять не только общими настройками (пользователи и контент), но и полностью настроить любой дашборд и показатель без привлечения разработчиков.

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

Группы показателей

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

Ответственный за группу показателей

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

Система мониторинга

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

Демонстрация и дополнительные требования

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

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

Смена концепции обработки данных

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

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

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

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

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

Это позволит сократить расходы заказчика на поддержку «зоопарка» сервисов и сфокусировать внимание внутренней команды разработки на единой системе.

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

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

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

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

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