Управление парком устройств

«АТОЛ» производит и продает контрольно-кассовую технику. Поправки в 54-ФЗ усложнили жизнь многим, но компания успешно помогает своим заказчикам соблюдать закон — среди ее клиентов федеральные сети «Ашан», «Фаберлик», Zenden и «Бристоль». Клиентов помельче у «АТОЛ» тысячи — по всей России. В 2017 году компания заняла 1-е место в рейтинге «Крупнейшие поставщики ИТ в рознице».

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

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

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

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

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

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

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

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

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

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

1. По утрам менеджер созванивался с заказчиком, получал вводные и передавал их проектировщику.
2. Проектировщик рисовал картинки, отдавал менеджеру, и в пять вечера мы уже обсуждали их с заказчиком.
3. Правки отдавали проектировщику, а на следующее утро принимали новые вводные.
4. Утвержденные прототипы сразу уходили дизайнеру.
5. Клиент утверждал дизайн, забирал и передавал разработчикам.

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

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

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

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

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

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

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

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

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

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

К конференции клиент подготовил демоверсию с тремя основными сценариями. Все прошло гладко.

Клиент рассказал, что на конференции люди оценили интерфейсы на 4 из 5. Мы — на 5.

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