Разработка мобильных приложений в Астане для сервиса с несколькими ролями начинается с участников процесса. Клиент, исполнитель и администратор могут работать с одним заказом, но видеть разные сведения и действия. Запишите полномочия каждого и попросите команду разобрать передачу заявки между ними. Тогда сравнивать предложения можно по правилам взаимодействия, а не по условному количеству экранов.
Выберите один пример: клиент отправляет обращение, сотрудник принимает его, а администратор решает спорный вопрос. Уточните, какие статусы нужны и кто имеет право менять каждый из них. Если действие отклонено, участник должен понимать дальнейший шаг. Не оставляйте такие правила на усмотрение дизайнера во время рисования макетов: они влияют и на интерфейс, и на серверную логику, и на проверку результата.
Попросите кандидатов определить границы первой версии. Иногда для старта достаточно приложения клиента и рабочего кабинета сотрудника, а отдельное приложение исполнителя можно обсудить позже. Сравните варианты по полноценности основного процесса, удобству управления и стоимости сопровождения. Число самостоятельных приложений не должно становиться признаком качества без объяснения, кому и для чего они нужны.
Уточните, как роли проверяются на сервере, а не только скрываются на экране. Если сотрудник не должен открывать чужую заявку, одного отсутствия кнопки недостаточно: правила доступа нужны и при обмене через API. Попросите разработчика объяснить схему на двух тестовых учётных записях. В первой версии согласуйте минимальный набор полномочий, чтобы новая роль позднее не потребовала пересмотра всего процесса.
Обсудите платформы для каждого участника. Клиенту может быть нужно приложение на iOS и Android, а администратору — рабочий кабинет в браузере; это следует из вашего процесса, а не из готового пакета подрядчика. Для проекта в Астане попросите оценить эти части отдельно и показать, как они используют общие статусы заказа. Так станет понятнее, за что вы платите и какие интерфейсы команда действительно разрабатывает.
Разбирая примеры работ компании, уточняйте именно опыт многоролевых сценариев. Кто проектировал права, реализовывал сервер и согласовывал переходы между статусами? Наличие приложения в портфолио не означает, что подрядчик выполнял все эти части. Попросите показать свой вклад на допустимом к раскрытию примере и объяснить, как проверялось отсутствие лишних действий у разных участников.
В коммерческом предложении ищите отдельное описание административной части. Кто создаёт сотрудников, отключает доступ, исправляет ошибочное назначение и просматривает историю обращения? Если это относится к другой системе, нужны явные границы интеграции и ответственный за изменения. Уточните состав передаваемых данных и порядок тестового обмена до окончательного согласования стоимости, чтобы не оценивать неизвестную работу как готовую функцию.
При демонстрациях попросите использовать разные учётные записи. Пусть команда последовательно пройдёт один заказ с позиции клиента и сотрудника, затем покажет действие администратора. Добавьте отмену, повторное назначение и попытку открыть недоступные сведения. Для заказчика это способ проверить согласованное поведение, а не самостоятельный технический аудит защиты; профильные проверки нужно отдельно включить в объём работ.
Сравните подход к уведомлениям. Сообщение о новой заявке и сам статус заявки — разные элементы процесса. Уточните, где участник проверит состояние, если уведомление не прочитано, и как интерфейс исключает двусмысленность. Попросите описать обработку прерванного соединения и повторной отправки. Такие вопросы помогают оценить завершённость сценария без обещаний о безошибочной работе любого приложения.
В завершение сравните передачу исходного кода, аккаунтов, схемы ролей и инструкции администратора. Выясните, кто отвечает на обращения после запуска и как оценивается добавление новой функции. При чтении отзывов ищите описание согласований и поддержки, затем проверяйте эти темы в собственном договоре. Предпочтение стоит отдавать предложению, в котором ясно описаны действия участников и обязательства команды на всём пути заявки.