Кейс: корпоративное in-house приложение в помощь PM

Сегодня мы решили поделиться нашим опытом разработки in-house приложения для внутреннего использования. Не все прошло гладко, но мы довольны результатом и успешно избавили наших PMов от пары-тройки поводов для головной боли.

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

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

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

Мы объединили функционал сразу нескольких разрозненных внутренних сервисов:

• История посещения офиса — сколько времени ты провел в офисе и кто там есть на данный момент;
• Сервис уведомлений всех необходимых сотрудников о твоем отсутствии/опоздании;
• Сервис просмотра выделенной аллокации на проектах.

А еще:

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

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

Основными критериями при создании приложения для нас были скорость разработки под разные мобильные платформы и качество продукта. Мы с самого начала склонялись к решению написать унифицированное веб-приложение, а тут как раз в компании появились свободные ресурсы в новом на тот момент направлении - Flutter. На нем можно было сделать UI, универсальный для обеих платформ, получив, при этом, приемлемую производительность. Подкупает и наличие в фреймворке библиотек, которые позволяют следовать UI гайдлайнам каждой из систем (material design и iOS-style).

Flutter не только позволяет использовать «нативные» (native like) виджеты для iOS и Android, но и создавать свои, причем он отрисовывает их сам, а не выступает в качестве прослойки между системными виджетами и кодом. Это дает высокую скорость работы и отзывчивость интерфейса.

Еще нам очень пригодилась горячая перезагрузка Hot reload. Это просто незаменимая вещь во Frontend разработке, когда в ходе горячих сражений с дизайнерами можно быстро внести изменения, посмотреть на результат и прийти к консенсусу.

Главная проблема проекта была в том, что он внутренний. А значит, во-первых, более низкий приоритет по сравнению с коммерческими проектами и, во-вторых, неполная команда: никаких менеджеров, аналитиков, тестировщиков. Обязанности отсутствующих участников команды делили самые инициативные.

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

Flutter тут подошел идеально. Мы использовали готовые решения, изменяя только внешний вид. А из возможностей оставляли самые нужные, откладывая расширение функций на последующие версии.

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

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

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

Статью написала Даша Маллер, собирали информацию и помогали Леша Строганов, Глеб Красильников, Антон Урывский и Денис Луханин.