Как мы сделали POS-систему для крупного ритейлера, которой пользуются в 400+ магазинах

Весной прошлого года наша команда в Украине начала разработку POS системы для крупного канадского ритейлера. На все про все у нас было полугода. Point-of-sale или точка продажи — система, с которой работают кассиры, пробивая товар покупателей. Работа над ней стартовала в конце весны 2016 года, а уже осенью клиент хотел получить готовый продукт. За пару месяцев нам пришлось нарастить команду с 15 до более 190 человек, провести веселое рабочее лето, но к Black Friday покупатели магазинов заказчика уже обслуживались с помощью системы, разработанной украинской командой EPAM.

Представьте себе рабочее место кассира. В нашем случае роль его основного терминала выполнял 15,5 — дюймовый Android-планшет. С ним был связан 10 — дюймовый экран для покупателей (в украинских супермаркетах эту роль обычно выполняет монохромный дисплей на длинной ножке, показывающий цену пробитого товара), сканер штрих-кодов, принтер для печати чека, ящик с наличными и терминал для банковских карт. Для всего этого нужно было написать программную часть и интегрировать ее с back-office клиента.

Когда рассчитываешься за покупки в магазине, не осознаешь всего, что стоит за пиликанием сканера штрих-кодов. Работа кассира в Канаде — не только пробитые товары, но и классическая «Охрана, отмена!», два типа возврата, учет различных акционных предложений и программ лояльности. Нашей команде нужно было описать большую матрицу прав разных категорий пользователей (кассир, администратор, охранник и другие) и налоговую сетку, которая отличается для магазинов в разных регионах, финотчеты при открытии и закрытии торгового дня. Интеграция с системой клиента осложнялась тем, что ее часть делала третья сторона. Это была индийская компания, которая систематически не укладывалась в сроки, от чего и нам приходилось корректировать свои планы.

Наращиваем команду

Discovery phase для нашей команды из 15 человек началась в апреле прошлого года. Около полутора месяцев ушло на разбор бизнес-требований и архитектуры. В мае-июне стартовала активная разработка, а в августе команда всего проекта состояла из более 190 человек. От каждого из них требовалось стопроцентное вовлечение и четкое понимание того, что делаешь, поскольку на команде лежала разработка продукта от А до Я. Ситуация из тех, что называют product development with short time to market.Учитывая рост на десятки человек в месяц, мы использовали не только внутренние ресурсы компании, но в большинстве нанимали новых людей. Их onboarding был непрерывным и быстрым потому, что мы не могли терять темп. Вся команда была распределена по трем офисам: Киев (45% сотрудников), Днепр (30%) и Харьков (25%).

Процессы мы строили на базе EPAM Agile практик, применяя лучшее из SAFe (Scaled Agile Framework), а в отношении структуры команды использовали подходы Spotify, которые немного доработали для своих нужд. Еще одним подходом, продиктованным быстрым ростом и жесткими требованиями по качеству продукта со стороны клиента, был trunk based development. Прежде, чем код попадал trunk, он проходил код ревью и автотесты. Все это помогло избежать конфликтов при интеграции.

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

Помимо этого в ход шли все средства общения: Skype, чаты, звонки, почта — не дошли разве что до почтовых голубей. Каждый должен был понимать, на какой стадии продукта мы находимся и как долго нам еще бежать для выхода в пилот. Хотя у нас была конкретная дата, не всегда сознавался оставшийся объем работ. Даже клиент не всегда успевал продуцировать бизнес-требования, поэтому, часто их приходилось подхватывать посреди спринта.

Доводим продукт до релиза

Самыми горячими месяцами были август и сентябрь. Приходилось выходить и в субботу, и в воскресенье несколько выходных подряд, но все понимали, что работают над одной целью. В начале октября команда доставила MVP. Он составлял от общего объема story points, сделанных в итоге. С минимальным жизнеспособным продуктом клиент запустил пилот в нескольких магазинах и мы начали получать фидбек от конечных пользователей. Он трансформировался в улучшения системы и теперь, все, что уходило в продакшн, уже попадало на рабочие места реального кассира.

После сдачи MVP и завершения активной фазы разработки мы перешли со Scrum на Kanban. Это упрощало работу со срочными исправлениями, которые были критичны для конечных пользователей. Иногда во время вечернего общения с заказчиком, он просил быстро исправить баг. За следующее утро мы устраняли проблему и к 16:00 (утро клиента) накатывали изменения. Они сразу проходили проверку UAT-QA заказчика и в тот же вечер уходили в продакшн. То есть, в некоторых случаях цикл от проблемы до ее фактического решения на терминале кассира занимал сутки. В Black Friday мы конечно же поддерживали систему 24/7. Рождественский период мы пережили с небольшими инцидентами, но в целом система выстояла и показала себя хорошо.

Для leadership-команды это был незабываемый опыт. Учитывая скорость, количество людей и объем коммуникации с ними, рабочий день часто начинался с 10 утра и длился до поздней ночи. По ходу команде удалось разобраться в том, как работает канадский ритейл, налогах в разных регионах страны и на каком уровне должна находиться клавиатура у кассира. Продукт поставили в срок и теперь покупатели канадских магазинов обслуживаются с помощью системы, разработанной в Украине.

Для нашей менеджмент команды это тоже был незабываемый опыт. Таких проектов пока не рынке Украины не так уж много, а Delivery Managers, которые участвовали в чем-то подобном — единицы. Нам приходилось очень детально смотреть на вещи которые могли задеть delivery. Ответственность за продукт end-to-end это: Architecture, Analysis, CI/CD, Development, Testing, UAT и, конечно же, управление командой. Все это только верхняя часть айсберга, с которой мы столкнулись. По ходу проекта приходилось обучаться на своих ошибках, на исправление которых времени было крайне мало. На рынке Украины все больше проектов, в работе над которыми можно развиваться и выходить на глобальный уровень. Именно это EPAM можем предложить людям, которые действительно ориентированы на результаты вне зависимости от текущих достижений.