Разработка веб-сервисов и личных кабинетов

Системы, в которых люди работают под своими аккаунтами: подают заявки, откликаются, следят за статусом, а сотрудники обрабатывают их в админке.

Обсудить проектПосмотреть кейсы

Проекты

  • Сервис вакансий и стажировок

    Карьерный портал РУК

    Студенты ищут стажировки и откликаются, работодатели публикуют вакансии и смотрят кандидатов.

  • Цифровая экосистема кооперации

    COOPHUB

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

Один процесс — несколько ролей

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

  1. 1Пользователь

    Заполняет заявку и прикладывает документы

    Статус: Отправлена
  2. 2Сотрудник

    Получает её в админке, проверяет и принимает решение

    Статус: На рассмотрении
  3. 3Система

    Сохраняет решение и историю, отправляет уведомление

    Статус: Одобрена
  4. 4Пользователь

    Видит результат и историю в личном кабинете

    Статус: Одобрена

Пример сценария. Роли, статусы и уведомления проектируем под ваш процесс.

Что разрабатываем

Что решаем до дизайна

Интерфейс сервиса рисуют последним. Сначала отвечаем на вопросы о процессе — ответы превращаются в схему данных и список сценариев, по ним мы оцениваем работу.

Роли
Кто входит в систему и что может делать. Видит ли работодатель контакты кандидата до отклика? Кто вправе вернуть заявку на доработку?
Данные и статусы
Из каких записей состоит процесс и через какие состояния проходит каждая. Что происходит с откликами, если вакансию закрыли?
Исключения
Пользователь бросил анкету и вернулся через неделю. Два сотрудника открыли одну заявку. Внешняя система не ответила.
Интеграции
Нужны документированный способ обмена данными и доступ к нему. Если внутренняя система закрыта для подрядчиков, подключение делаем вместе с ИТ-отделом заказчика.

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

От чего зависит стоимость

  • число ролей и сценариев;
  • сложность правил и статусов;
  • объём админки;
  • качество документации внешних систем, с которыми нужна интеграция.

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

Что понадобится от вас

Описание процесса как он есть сейчас, со всеми исключениями, которые знают только ваши сотрудники; человек, который принимает решения по процессу; документация и тестовый доступ к системам для интеграции или контакт ИТ-отдела, который ими управляет.

Описать процесс

Частые вопросы

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

Если у неё есть API и к нему можно получить доступ — как правило, да. Насколько это сложно, становится понятно после изучения документации, поэтому смотрим её до оценки.

Если сервис хранит персональные данные, на него распространяются требования 152-ФЗ. От них зависят выбор сервера и порядок доступа сотрудников к данным, поэтому этот вопрос решаем до разработки, а не после запуска.

Опишите процесс, который хотите перенести в сервис

Кто в нём участвует, что делает каждый и на каком шаге сейчас чаще всего возникают задержки.

Обсудить веб-сервисПосмотреть кейсы