Назад

Как реализовать сложные «хотелки» на проектах?

Время чтения: 5 минут

Содержание

На примере event-приложения WRISTBAND рассказываю о том, как прокачать hard-скилы разработчиков и безболезненно потестить новые фишки (feature request) прямо на «боевых» проектах. 

В попытках облегчить себе жизнь проектную работу и прокачать скилы разработчики по полной обкладываются полезными инструментами: фреймворками, библиотеками, мануалами. На деле имеем следующее: задачи «без ответа» не кончаются, а наращивание экспертизы становится ежедневной рутиной. Поменять ситуацию радикально нельзя. Да и вряд ли есть смысл. Давайте посмотрим, как ее можно оптимизировать.

Как? Давайте разбираться вместе. 

Как не утонуть в информационном хаосе

Feature request от клиентов — бывают ли сложными? Да, конечно! Чтобы уметь справляться с такого рода задачами, некоторые работодатели предпочитают брать обучение ИТ-команды в свои руки, скупая билеты на разные курсы, конференции и хакатоны. Помогает ли такой подход наращивать экспертизу? Скорее всего, да. Есть ли альтернатива? Наш опыт показывает, что есть.

Для прокачки скилов команды мы выбрали демократичный подход: каждый сам для себя решает, чему и в каком темпе ему обучаться. Такой подход предполагает, что скилы разработчиков — это зона ответственности самих же разработчиков. Это сильно экономит время, так как в первую очередь прокачиваются именно те навыки, которые можно сразу же протестить на реальном проекте.

ЧИТАЙТЕ ТАКЖЕ  SCRUM, щеночки и 5 000+ скачиваний в Google Play: как мы делали немецкое приложение для владельцев домашних животных

Если заказчики просят реализовать незнакомую для нас технологию, мы действуем по заранее разработанному сценарию. Объясню на примере небольшого пропускного приложения для event-индустрии.

Feature request от заказчика — то, что мы никогда не делали

История такая: нам прилетело ТЗ на разработку мобильного приложения от стартаперов из Нового Орлеана, которые продают ИТ-решения для организаторов мероприятий. Задача — сделать сервис для охранников, который сократит очереди на входе и позволит пропускать гостей на мероприятия по браслетам с RFID-метками.

Интерфейс мини-приложения — буквально три экрана, но его работоспособность должна обеспечиваться технологиями, в которых мы не были до конца уверены. В частности, это касалось RFID-меток. На момент реализации проекта мы с этим не работали, а поиск в интернете не дал четкого ответа на вопрос, есть ли библиотеки, которые умеют нормально их читать.

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

Первый этап: оценка сложностей

Один из главных челленджей проекта — его сроки (на одних сложных feature request все, разумеется, не кончается). На все про все у нас было меньше месяца. Помимо времени, ситуация усугублялась и тем, что сервис должен был использоваться на достаточно редкой модели телефона, которую нельзя было получить для тестирования.

ЧИТАЙТЕ ТАКЖЕ  Как мы готовили захват рынка фриланс поваров России. Кейс Purrweb

Еще один нюанс: приложение должно было стабильно работать в офлайне. На мероприятиях, особенно под открытым небом, часто бывают проблемы с интернетом, но плохой сигнал не должен был тормозить работу охранников. При любой удобной возможности, то есть при наличии стабильного интернет-соединения, приложение должно было синхронизироваться с сервером. Вдруг кто-то из гостей купит билет в последний момент или после начала мероприятия?

Данный функционал (feature request) не вызывал особых вопросов, но его нужно было сделать безукоризненно. Лаги и провисания были недопустимы, так как на пропуск каждого человека закладывалось не более 2 секунд.

Второй этап: реализация и тестирование

Так как на проект было заложено меньше месяца, план действий выглядел следующим образом: 2 дня тестируем самый проблемный функционал, и, если находим решение, продолжаем работу. Клиента такой подход устроил, и мы приступили к разработке.

В первую очередь, мы досконально изучили RFID-метки, после подобрали несколько библиотек, которые потенциально могли закрыть эту задачу. Выяснилось, что RFID-метка — это старший брат NFC-технологии, а значит, в теории любой телефон с модулем для чтения NFC должен был «понимать» информацию в браслете.

В результате мы сделали технический прототип и протестировали необходимый функционал, используя собственные телефоны и кредитные карты. Изначально поставленная гипотеза подтвердилась, и библиотека не подвела. Так как у нас не было возможности протестировать работу этого функционала на нужной модели, мы отправили технический прототип заказчику. Все сработало как нужно, и мы по-быстрому переключились на другие задачи (feature request) — те, которые не представляли особых трудностей.

ЧИТАЙТЕ ТАКЖЕ  Особенности разработки мобильного приложения для службы доставки: кейс B2B-сервиса Cargo

По итогу получился минималистичный дизайн с традиционными «светофорными» цветами: красный, если у гостя нет доступа к данной зоне, и желтый, есть этап check-in’а был пройден ранее. Также работа приложения сопровождалась соответствующими звуковыми сигналами, которые помогали дополнительно снизить время прохождения человека через пункт контроля.

Третий этап: закрепление знаний

Рабочий способ освоить новую фишку и справиться со сложными запросами от клиентов (feature request): рассказать об этом коллегам. В отличие от посещения конференций, эта практика — обязательный и регулярный ритуал, который у нас в команде случается несколько раз в месяц. Никаких прелюдий и формальностей — вполне достаточно короткого выступления минут на 30.

В рамках корпоративного митапа мы обсуждаем не только фишки, но и процесс решения задач (feature request). Иногда на финише рождается подробный гайд — это работает в тех случаях, когда команда будет неоднократно использовать ту или иную технологию (например, FaceID).

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

Выводы

Браслет в сочетании с приложением успешно отработал на нескольких мероприятиях, сейчас проект активно развивается. Что про нас: мы заканчиваем работать над функционалом бесконтактной оплаты. Это значит, что браслет будет содержать не только информацию о доступе в конкретные зоны, но и превратится в электронный кошелек, который можно использовать для транзакций на мероприятии.

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

Насколько публикация полезна?

Оцени эту статью!

14 оценок, среднее 4.9 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной...

Подписывайтесь на нас в соцсетях!

Share