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

Особый случай — федеральные сети. У них так много магазинов, что они не обслуживают кассы своими силами, а нанимают сервисные компании. Это посредники между торговыми сетями и «АТОЛ». 

«АТОЛ» развивает собственный интернет-сервис, который позволяет удаленно управлять устройствами. Специалист может обновить прошивку кассы в Новосибирске, сидя при этом, к примеру, в Нижнем Новгороде. 

 В интернет-сервисе управления кассами предусмотрены два личных кабинета: для владельцев кассовых аппаратов и для партнеров-сервисников. Они почти одинаковые, только у сервисников есть возможность вести несколько клиентов. 

Увы, картинки в кейсе же неактуальны — финальные интерфейсы выглядят по-другому. Но процесс разработки по ним отследить можно 

 

Менеджер начал работать над проектом в пятницу 30 декабря, в последний рабочий день 2017 года. А накануне, 29 декабря, у нас был корпоратив. 

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

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

Представитель заказчика пришел к нам за дизайном. От менеджмента и UX он отказался сразу, потому что сам хотел нарисовать прототипы. Впрочем, оказалось, не столько хотел, сколько был вынужден это делать. Часть прототипов у него уже была, и нам якобы оставалось их задизайнить. Но не тут-то было. Мы так не работаем, поэтому проектирование тоже взяли на себя. 

Клиент в это время делал UI-kit, который называл дизайн-системой. 

На новогодних каникулах представитель «АТОЛ» подготовил структуру сервиса с иерархией всех 66 страниц. Для каждой страницы описал назначение, цели и функции, а также назначил четырехзначные индексы. Это была полноценная информационная модель сервиса. Потянула бы даже на небольшую книгу. 

А вот прототипов сервиса на самом деле не было. Поэтому мы подключили к работе проектировщика. У него только на изучение инфомодели ушло два дня. 

При организации работ тоже пришлось отказаться от привычного порядка. Обычно после аналитики мы начинаем рисовать прототипы, которые в конце проекта передаем заказчику. Здесь все было иначе, потому что параллельно разработчики клиента пилили сам сервис. Поэтому мы работали так. 

1. По утрам менеджер созванивался с заказчиком, получал вводные и передавал их проектировщику. 

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

3. Правки отдавали проектировщику, а на следующее утро принимали новые вводные. 

4. Утвержденные прототипы сразу уходили дизайнеру. 

5. Клиент утверждал дизайн, забирал и передавал разработчикам. 

И так каждый день. 

Мы обрабатывали по пять страниц в день. Сперва выкладывали готовые прототипы в Moqups, но из-за сложной структуры сервиса «АТОЛ» было неудобно перемещаться по страницам. Попробовали InVison — там все плохо с комментированием. А вот Zeplin подошел идеально. Верстальщикам со стороны клиента он тоже понравился — они могли забирать прототипы сразу в разработку. 

Самый сложный сценарий в проекте — найти магазин. Мы считали, что иногда проще отыскать какую-нибудь «Пятерочку» через фильтры, чем выбирать из сотни одинаковых названий в списке. Но со стороны клиента с нами работал настоящий инженер, и он хотел структуру-дерево. Чтобы все строго по иерархии. Один из аргументов звучал так: проще выделить все кассы по городу и массово обновить прошивку, чем тыкать в фильтры. Не поспоришь. 

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

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

Из-за дефицита времени, как только мы утвердили концепцию прототипов, сразу же перешли к дизайну и попросили у клиента UI-kit, по которому будем рисовать красивые картинки. Оказалось, что у «АТОЛ» аж три версии оформления, и они долго выбирали, какую лучше использовать. Часть готового сервиса была в старом дизайне, только его использовать больше никто не хотел. Но и переделывать тоже было не с руки — сроки-то поджимают. В итоге мы начали рисовать по новому UI-kit'у — настолько новому, что им до нас никто не пользовался. Оказалось, в нем постоянно не хватало каких-то элементов. Их наш дизайнер дорисовывал сам. 

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

В какой-то момент проектировщик и дизайнер начали работать параллельно — нужно было успеть к апрелю. Cроки-то горели! Утренние прототипы во второй половине дня передавали дизайнеру. 

Вечерние созвоны отменили. Зато утренние стали длиться дольше. Обсуждали и прототипы, и дизайн. За один созвон — по семь-восемь страниц. 

Тексты для интерфейсов «АТОЛ» писали сами. Под конец проекта нам скинули буквы, мы их вставили в прототипы. Да и то не все — некоторые тексты разработчики решили поправить сами. 

У «АТОЛ» была внешняя команда верстальщиков. Они не всегда сразу понимали, что нужно сделать, как какие кнопки должны работать. За логику отвечал представитель клиента, но по возможности мы объясняли. Впрочем, обычное авторское сопровождение.

За месяц до релиза наш дизайнер ушел в отпуск. У менеджера началась паника. Но неожиданно стало проще — доделанный UI-kit со всеми иконками и контролами был у нас на руках, поэтому проектировщик начал рисовать прототипы сразу в дизайне и строго по сетке. Темп не снизили. Сроки по-прежнему горели.

Заказчиск хотел, чтобы мы прошлись по всем сверстанным экранам и протестировали все контролы и ссылки — правильно ли они работают. Но вообще-то это задача тестировщиков. Мы таким не занимаемся.

За две недели до релиза сроки гореть перестали. Оказалось, что мы вполне все успеваем. Все немного успокоились. Но ежедневные созвоны остались. 

К конференции клиент подготовил демоверсию с тремя основными сценариями. Все прошло гладко. Клиент рассказал, что на конференции люди оценили интерфейсы на 4 из 5. Мы — на 5. 

До июня компания выпустила еще два релиза — в них вошли функции, которые клиент решил не внедрять в MVP. Прототипы тоже делали мы. 

Вывод:  если нужно, работаем параллельно. Не только внутри компании, но и с внешними разработчиками. 

 

Подробнее на сайте.