Программисты — удалённая работа в Москве

Решение проекта по обучению. Пожелания и особенности: Решение проекта: Задание Представьте, что вы работаете в крупном дейтинговом приложении. Помимо базовых функций, в приложении также имеется премиум-подписка, которая дает доступ к ряду важных дополнительных возможностей. Был проведен A/B тест, в рамках которого для новых пользователей из нескольких стран была изменена стоимость премиум-подписки* при покупке через две новые платежные системы. При этом стоимость пробного периода оставалась прежней. Проверьте: Был ли эксперимент успешен в целом. *Деньги за подписку списываются ежемесячно до тех пор, пока пользователь её не отменит. Важно: это задание наиболее приближено к работе с реальными данными, и в реальных данных часто бывают ошибки и подвохи. Будьте аккуратны и не торопитесь при анализе — уделите как можно больше внимания этим данным. Данные: Всего есть три группы: тестовая (test), контрольная 1 (control_1) и контрольная 2 (control_2). Для каждой из них: users_*.csv – информация о пользователях: uid – идентификатор пользователя age – возраст attraction_coeff – коэффициент привлекательности (от 0 до 1000, \frac{лайки}{просмотры}*1000 просмотры лайки ? ?1000) coins – число монеток (внутренняя валюта) country – страна visit_days – в какие дни после регистрации пользователь посещал приложение (напр. в 1, затем в 7) gender – пол age_filter_start – фильтр поиска, мин. значение age_filter_end – фильтр поиска, макс. значение views_count – число полученных оценок was_premium – был ли когда-либо премиум (либо пробный период премиум-статуса, либо купленный за деньги) is_premium – является ли премиум total_revenue – нормированная выручка transactions_*.csv – информация о платежах пользователей: uid – идентификатор пользователя country – страна joined_at – дата и время регистрации paid_at – дата и время покупки revenue – нормированная выручка payment_id – идентификатор платежа from_page – откуда пользователь перешел на страницу оплаты product_type – тип продукта (trial_premium – пробная премиум-подписка, premium_no_trial – премиум-подписка без пробной, coins – подписка за внутреннюю валюту, other_type – другое) Файлы: users_test – информация о пользователях в тестовой группе. users_control_1 – информация о пользователях в первой контрольной группе. users_control_2 – информация о пользователях во второй контрольной группе . transactions_test – информация о платежах пользователей в тестовой группе. transactions_control_1 – информация о платежах пользователей в первой контрольной группе. transactions_control_2 – информация о платежах пользователей во второй контрольной группе. Файлы будут направлены по почте после договоренности.

Задачи чат-бота: ответы на типовые вопросы, игра крокодил. Платформа: WhatsApp. Продукт: Чат общение. Техзадания нет. Бот должен приветствовать новых участников и материться.

проблема с картой в апп стои. Настройка. Была привязана кыргызская карта, но теперь там висит долг и карта не работает.

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

Создать с нуля. Функционал сайта: Онлайн консультация. Контент есть.

Пожелания и особенности: Ссылку на таблицу скину что он должен делать.

Веб-разработка. Разработка с нуля, тестирование, настройка, доработка существующего продукта. Пожелания и особенности: Разработка встроенного чата для социальной платформы 1. О проекте Разрабатывается социальная платформа, в которой пользователи создают профили, публикуют контент, собирают списки и рекомендации, общаются с другими участниками и взаимодействуют со встроенным ИИ-помощником. Необходимо разработать систему личных сообщений внутри существующей веб-платформы. Речь идёт не о создании отдельного мессенджера с нуля, а о добавлении раздела «Чаты» в уже работающий продукт. 2. Цель задачи Пользователь должен иметь возможность: • открыть раздел с чатами; • увидеть список своих диалогов; • начать новый диалог с другим пользователем; • отправлять и получать текстовые сообщения; • отправлять и получать фотографии и файлы; • видеть новые и непрочитанные сообщения; • продолжать переписку после обновления страницы или повторного входа; • общаться в отдельном закреплённом чате с системным ИИ-помощником. Интерфейс должен быть простым и привычным, по логике современных мессенджеров и чатов внутри банковских приложений. 3. Основной пользовательский сценарий 1. Пользователь открывает раздел «Чаты». 2. Видит список существующих диалогов. 3. В верхней части списка постоянно отображается закреплённый системный чат платформы. 4. Пользователь выбирает существующий диалог либо нажимает кнопку «Новый чат». 5. Через поиск выбирает зарегистрированного пользователя. 6. Открывается окно переписки. 7. Пользователь отправляет сообщение, фотографию или файл. 8. Получатель видит новое сообщение и отметку о непрочитанном диалоге. 9. После открытия чата сообщение отмечается как прочитанное. 10. Вся история переписки сохраняется и остаётся доступной после повторного входа. 4. Функционал MVP 4.1. Список чатов В списке каждого диалога отображаются: • аватар пользователя; • имя; • текст последнего сообщения либо обозначение отправленного файла или фотографии; • время последнего сообщения; • индикатор непрочитанных сообщений; • сортировка диалогов по времени последнего сообщения. Системный чат платформы должен всегда находиться сверху и визуально отличаться от обычных пользовательских чатов. При получении нового сообщения соответствующий диалог должен подниматься в верхнюю часть списка, кроме закреплённого системного чата. 4.2. Новый чат В верхней части раздела должна находиться заметная кнопка «Новый чат». После нажатия пользователь: • видит строку поиска; • может найти человека по имени или username; • видит результаты с аватаром и именем пользователя; • выбирает пользователя; • переходит в новый или уже существующий диалог с ним. Нельзя создавать несколько отдельных личных диалогов между одной и той же парой пользователей. Пользователь не должен иметь возможности начать диалог с самим собой. 4.3. Окно переписки Внутри диалога необходимо реализовать: • имя и аватар собеседника; • переход в профиль собеседника; • историю сообщений; • поле ввода текста; • кнопку отправки; • отправку сообщения по Enter; • перенос строки с помощью Shift + Enter; • поддержку текста в несколько строк; • дату и время сообщений; • визуальное разделение входящих и исходящих сообщений; • автоматическую прокрутку к последнему сообщению; • загрузку более ранних сообщений при прокрутке вверх; • разделители сообщений по датам; • корректное отображение длинных сообщений; • корректное отображение ссылок в сообщениях. 4.4. Отправка фотографий Пользователь должен иметь возможность: • выбрать фотографию на устройстве; • увидеть предпросмотр перед отправкой; • отменить выбранную фотографию; • добавить текст к фотографии; • отправить фотографию; • видеть процесс загрузки; • повторить отправку при ошибке. Фотографии должны отображаться непосредственно внутри переписки. По нажатию фотография должна открываться в увеличенном виде. Необходимо предусмотреть ограничения по допустимым форматам и максимальному размеру изображения. Допустимые форматы и ограничения должны быть согласованы до начала разработки. 4.5. Отправка файлов Пользователь должен иметь возможность: • выбрать файл на устройстве; • увидеть название, формат и размер файла до отправки; • отменить выбранный файл; • отправить файл; • видеть процесс загрузки; • повторить отправку при ошибке; • открыть или скачать полученный файл. В переписке должны отображаться: • название файла; • формат; • размер; • статус загрузки; • кнопка открытия или скачивания. Необходимо предусмотреть ограничения по допустимым форматам и максимальному размеру файла. Исполнитель должен предложить решение для хранения фотографий и файлов, а также описать возможные расходы на хранение при росте количества пользователей. 4.6. Статусы сообщений Необходимо реализовать следующие состояния: • сообщение отправляется; • сообщение успешно отправлено; • сообщение доставлено; • сообщение прочитано получателем; • ошибка отправки. При ошибке пользователь должен иметь возможность повторить отправку сообщения, фотографии или файла. Сообщение, которое находится в процессе отправки, должно визуально отличаться от успешно отправленного. 4.7. Непрочитанные сообщения Необходимо реализовать: • счётчик непрочитанных сообщений рядом с каждым диалогом; • общий индикатор новых сообщений у раздела «Чаты»; • автоматическую отметку сообщений как прочитанных после открытия диалога; • обновление списка чатов при появлении нового сообщения; • визуальное обозначение непрочитанных диалогов; • сохранение корректного количества непрочитанных сообщений после обновления страницы и повторного входа. 4.8. Системный чат с ИИ-помощником У каждого пользователя автоматически создаётся системный чат с ИИ-помощником платформы. Он должен: • всегда отображаться в верхней части списка; • иметь отдельный системный аватар и название; • визуально отличаться от обычных пользовательских чатов; • внешне работать как обычный диалог; • принимать текстовые сообщения пользователя; • получать ответы от существующего API платформы или ИИ-сервиса; • сохранять историю общения. Саму логику ИИ разрабатывать не требуется. От исполнителя требуется подготовить чат к подключению предоставленного API и реализовать отображение ответов внутри переписки. 4.9. Обновление сообщений в реальном времени Новые сообщения должны появляться без ручного обновления страницы. Необходимо обеспечить: • получение новых сообщений в открытом диалоге; • обновление текста последнего сообщения в списке чатов; • обновление времени последнего сообщения; • изменение количества непрочитанных сообщений; • обновление статусов отправки, доставки и прочтения. Исполнитель должен предложить подходящий способ реализации с учётом текущей архитектуры проекта. Решение должно предусматривать дальнейший рост количества пользователей и диалогов. 5. Уведомления На первом этапе необходимо реализовать уведомления внутри платформы: • индикатор новых сообщений у раздела «Чаты»; • счётчик непрочитанных сообщений; • визуальное выделение диалога с новым сообщением. Системные push-уведомления и уведомления по электронной почте в первоначальный объём работ не входят. 6. Адаптивность Чат должен корректно работать: • на компьютере; • на планшете; • на мобильном экране; • внутри мобильного браузера. На компьютере интерфейс может состоять из двух колонок: • список чатов; • открытый диалог. На мобильном устройстве список чатов и конкретный диалог должны открываться как отдельные экраны. Необходимо предусмотреть: • удобную кнопку возврата к списку чатов; • корректную работу экранной клавиатуры; • сохранение доступа к полю ввода при открытой клавиатуре; • удобный выбор фотографий и файлов; • корректное отображение длинных сообщений; • корректное открытие фотографий и файлов. 7. Состояния интерфейса Необходимо предусмотреть следующие состояния: • у пользователя ещё нет диалогов; • поиск пользователей не дал результатов; • переписка пока пустая; • сообщения загружаются; • загружается история предыдущих сообщений; • произошла ошибка загрузки; • пропало интернет-соединение; • соединение восстановлено; • собеседник удалён; • собеседник заблокирован или недоступен; • сообщение не удалось отправить; • фотография не загрузилась; • файл не загрузился; • выбран неподдерживаемый формат; • файл превышает допустимый размер; • большое количество непрочитанных сообщений; • история сообщений закончилась; • ИИ-помощник временно недоступен. Для ошибок должны быть предусмотрены понятные сообщения и кнопка повторного действия там, где это возможно. 8. Безопасность и доступ Необходимо обеспечить: • доступ к диалогу только его участникам; • проверку прав пользователя при загрузке истории сообщений; • защиту загрузки файлов от неподдерживаемых и потенциально опасных форматов; • невозможность получить доступ к чужой переписке через изменение адреса страницы или параметров запроса; • безопасное хранение ссылок на фотографии и файлы; • использование существующей системы авторизации; • корректную обработку удалённых и заблокированных пользователей. 9. Что не входит в MVP На первом этапе не требуется: • групповые чаты; • каналы; • аудио- и видеозвонки; • голосовые сообщения; • видеосообщения; • исчезающие сообщения; • реакции на сообщения; • пересылка сообщений; • ответы на отдельные сообщения; • редактирование сообщений; • удаление сообщений; • поиск по истории переписки; • закрепление пользовательских диалогов; • архив чатов; • блокировка пользователей из интерфейса чата; • индикатор набора текста; • статус нахождения пользователя онлайн; • сложная система статусов присутствия; • push-уведомления; • уведомления по электронной почте; • полноценное сквозное шифрование; • отдельное мобильное приложение. Перечисленные функции не должны входить в первоначальную оценку без отдельного согласования. 10. Требования к исполнителю Исполнитель должен: • изучить существующий проект; • встроить чат в текущую архитектуру; • не создавать отдельное приложение; • использовать существующую авторизацию; • использовать существующие профили пользователей; • не переделывать без необходимости уже работающие разделы; • сохранить текущий визуальный стиль платформы; • написать понятный и поддерживаемый код; • разместить результат в существующем репозитории; • описать порядок запуска и подключения; • предоставить список добавленных компонентов и изменений; • устранить обнаруженные ошибки перед сдачей; • предоставить краткую документацию для дальнейшей поддержки; • предупредить о необходимых сторонних сервисах и возможных регулярных расходах. 11. Этапы работы Предлагаемый порядок работы: 1. Изучение существующего проекта. 2. Оценка текущей архитектуры и способов интеграции. 3. Согласование пользовательских сценариев и экранов. 4. Разработка списка диалогов. 5. Разработка поиска пользователей и создания нового чата. 6. Разработка личной переписки. 7. Реализация отправки фотографий. 8. Реализация отправки файлов. 9. Реализация хранения фотографий и файлов. 10. Реализация непрочитанных сообщений. 11. Реализация статусов сообщений. 12. Реализация получения сообщений без обновления страницы. 13. Подключение системного чата с ИИ-помощником. 14. Адаптация под мобильные устройства. 15. Тестирование. 16. Размещение на тестовом сервере. 17. Исправление обнаруженных ошибок. 18. Перенос в основную версию проекта. 19. Передача документации. 12. Требования к тестированию Перед сдачей необходимо проверить: • создание нового диалога; • невозможность создания дублирующего диалога; • отправку и получение текстовых сообщений; • отправку и получение фотографий; • отправку и получение файлов; • повторную отправку при ошибке; • статусы доставки и прочтения; • счётчики непрочитанных сообщений; • сохранение истории после выхода и повторного входа; • работу при медленном интернет-соединении; • восстановление после временной потери соединения; • загрузку длинной истории сообщений; • работу на компьютере; • работу на мобильном устройстве; • работу в актуальных версиях основных браузеров; • защиту от доступа к чужим диалогам; • работу системного чата с тестовым API. 13. Результат работы Готовый результат должен позволять двум зарегистрированным пользователям: • найти друг друга; • начать личную переписку; • отправлять и получать текстовые сообщения; • отправлять и получать фотографии; • отправлять и получать файлы; • получать сообщения без обновления страницы; • видеть статусы сообщений; • видеть непрочитанные сообщения; • вернуться к истории переписки после повторного входа. Также каждый пользователь должен иметь доступ к закреплённому системному чату с ИИ-помощником. Чат должен быть полностью встроен в существующую платформу, работать на компьютере и мобильных устройствах и соответствовать текущему стилю интерфейса. 14. Что указать в отклике В отклике необходимо указать: 1. Опыт разработки чатов или систем личных сообщений. 2. Примеры аналогичных работ. 3. Предлагаемый технический подход. 4. Способ получения сообщений без обновления страницы. 5. Способ хранения фотографий и файлов. 6. Какие изменения потребуются в существующем проекте. 7. Стоимость разработки всего MVP. 8. Разбивку стоимости по основным этапам. 9. Отдельную стоимость функций, не входящих в MVP. 10. Предполагаемый срок выполнения. 11. Какие риски могут повлиять на стоимость и сроки. 12. Что потребуется от нашей команды. 13. Как будет организовано тестирование. 14. Какой срок гарантии предоставляется на исправление ошибок после сдачи. 15. Готовность продолжить поддержку и развитие раздела после запуска. Отклики без оценки структуры задачи и с формальным сообщением «готов выполнить» рассматриваться не будут. Перед окончательной оценкой исполнителю будет предоставлен доступ к коду, тестовой версии и текущему интерфейсу платформы Рассмотрим как долгосрочное сотрудничество, так и проектную работу. Готовы купить уже готовое решение и адаптировать под наши задачи.