Система учета обедов сотрудников LunchBox
Техническое задание
Компания обеспечивает своих сотрудников обедами. У компании есть несколько филиалов в разных городах, в каждом городе может быть несколько заведений общепита, в котором могут обедать сотрудники. Каждое кафе/ресторан предоставляет меню на неделю вперед, где указан набор подаваемых блюд, а также их категория (вегетарианское, кошерное, рыбное и проч.). Сотрудник вправе выбирать себе обед в любом заведении в пределах филиала, или же в другом филиале, если он находится в командировке, а также может отказаться от обеда.
Задача: вести учет обедов сотрудников, обеспечить каждого сотрудника полноценным обедом в рабочие дни, своевременно предоставлять ресторанам и кафе актуальную информацию о количестве требуемые блюд.
Основными проблемами, которые должна решить система, являются:
- несвоевременное заполнение сотрудником выбора меню,
- постоянное напоминание сотрудникам о необходимости выбрать меню,
- забывчивость своего выбора сотрудником и как следствие поглощение чужой порции обеда,
- сложность в изменении своего выбора,
- сложность в отказе от обеда и как следствие потеря денег компанией из-за оплаты лишней порции обеда.
Разработка системы
Так как пользователи данной системы имеют разные роли, то логично было бы для каждой роли описать отдельно функционал.
Роли пользователей:
- администратор компании, управляющий офисами и сотрудниками
- администратор филиала компании, управляющий заказами и организацией обедов
- администратор ресторана/кафе, в котором обедают сотрудники компании
- сотрудник компании
Роль: администратор компании
Он управляет списком пользователей и офисов, т. е. добавляет/редактирует; также определяет пользователя как прикрепленного к определенному офису, от чего будет зависеть его набор ресторанов и меню.
Для него было бы удобно пользовать веб-приложением, которое можно было бы интегрировать с другими внутренними сервисами, например, начислением з/п, учетом больничных и отпускных.
Роль: администратор филиала компании
Для него также было бы удобно пользоваться веб-приложением, так как он оперирует таблицами обедов, управляет списком ресторанов для данного филиала и их меню, может вносить корректировки, отмечать дни, в которе заведение общепита не работает.
На главном экране своего приложения он должен видеть статистику выбора обедов на неделю и список пользователей, кто где отметил обед, а также тех, кто еще не сделал свой выбор. Может вручную менять выбор каждого пользователя по просьбе пользователя в случаях, если тот не может это сделать сам.
Также администратор филиала отправляет список обедающих в каждый ресторан: может делать это вручную или же автоматически, выставив время (например, 10:00 утра), в которое общий заказ для всех сотрудников на обед будет отправляться в каждый ресторан выбранным способом: емэйл, смс, телеграм-бот, прочее.
При отсутствии роли ресторана в системе, заполняет меню обедов для каждого ресторана вручную.
Роль: администратор ресторана/кафе
Предполагается, что через веб-приложение он может зайти под своим логином на сайт, загрузить фото ресторана, поменять название, указать адрес и схему проезда, дать краткое описание заведения, подготовить меню на неделю.Он занимается заполнением меню на неделю вперед с указанием блюд и возможностью загрузить фото готового блюда, указывает выходные или нерабочие дни для заведения. При фиксированном наборе блюд для ресторана заполняет справочную таблицу блюд с описанием, выставляет предоставляемые категории блюд: вегетарианское, мясное, рыбное, диетическое и проч. Он также указывает дополнительные опции ресторана: наличие доставки, возможна ли упаковка обеда на вынос и ее стоимость.
Роль: сотрудник компании
Двумя основными проблемами правильного указания обеда со стороны сотрудника является:
- не указание обеда на текущий день, что приведет к тому, что он останется без обеда,
- не указание отмены обеда в случае внезапного больничного или других причин.
В первом случае можно и нужно организовать напоминания (push notifications) о необходимости совершить какие-то действия. Поэтому оптимальным выбором будет разработка мобильного приложения на Android/iOS, так как сегодня у всех есть телефон. Если же разрабатывать веб-версию приложения, будет невозможно оперативно напомнить ему о необходимости выставить обед.
Так как все сотрудники принадлежат одной компании, то нет необходимости в регистрации, вход только по корпоративному емэйлу. При первом логине предлагается выбрать меню, которое он желает получить
каждый день, так называемый дефолтный выбор пользователя. Этот шаг можно пропустить (его можно заполнить позже в настройках). Под меню имеется в
виду определенный набор блюд, сгруппированных как “обычное”, “диета”,
“рыбное” и т. п., он привязывается в конкретному ресторану.
Дашборд приложения показывает текущую неделю, начиная с текущего дня; здесь пользователь может изменить свой выбор на каждый конкретный день, а также определить как еду на вынос, если такая опция есть у конкретного ресторана. Кроме того для каждого отдельного дня недели можно запомнить выбор и сделать его по умолчанию всех последующих таких дней (например, для всех понедельников).
После определенного админом времени, например, 10 часов утра, состояние выбора пользователя фиксируется и не подлежит изменению пользователем (эти поля может изменять только администратор филиала). А после обеда появляется доступ к голосованию за выбранный обед, т. е. выставления оценки. Голосование можно пропустить и/или отключить.
В меню пользователя есть еще пункты:
- календарь, который позволяет посмотреть статистику по обедам и голосованию;
- аккаунт, где можно изменить язык приложения, отредактировать профиль;
- настройки (это настройки меню), здесь можно выставить дефолтный выбор меню как для каждого дня, так и на всю неделю с выбором на вынос или нет и установкой нотифицаии-напоминания об обеде;
- logout - выход из приложения.
Так же предполагается система нотификаций всем сотрудникам о важных событиях, например, о том, что в какие-то дни определенный ресторан не работает или об изменении времени обеда в какие-то дни. Это новости позже можно просмотреть в списке новостей.
Выводы
Для разработки описанной выше системы понадобятся следующие разработчики: дизайнер, бэкенд-, веб- и мобильные разработчики, тестировщик. Минимальное время разработки - полтора месяца полнорабочего времени для каждого из разработчиков. Максимальное время определяется в зависимости от дополнительного функционала.
В текущей ситуации, когда не всегда есть возможность обедать в заведении и большинство сотрудников работают из дома или удаленно, систему можно было бы расширить интеграцией с сервисами доставки еды и/или организованной доставкой обедов на дом или коворкинг.
Комментарии