Привет, Хабр!

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

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

Робот-доставщик

Модель выполнена в виде настоящего ровера 3 от Яндекса в масштабе 1/64. Инерционный механизм делает из него небольшую игрушку, работающую по принципу детских машинок, которые были, вероятнее всего, у каждого в прекрасные времена более голубого неба и самой зеленой травы.

Также внутри робота расположены светодиоды для подсветки его «глаз» и периметра контейнера, который, к слову, открывается. Работает все великолепие на 3 батарейках типа LR44.

В общем ровер милый, выполнен неплохо и тут можно было бы остановиться, но в моей голове промелькнула одна мысль…

А может сделать его управляемым?

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

На самом деле, все просто. Примерно так же, как из инерционной машинки сделать радиоуправляемую. Только зачем радиоуправление, если можно написать мобильное приложение и управлять ей с телефона?

В итоге решил делать следующее:

1. Управление ровером должно быть реализовано с помощью мобильного приложения на iOS, которое я напишу на Flutter (про мой первый опыт работы с этим фреймворком можно прочитать в статье про Smart Connect)

2. Беспроводная передача данных будет производиться с помощью BLE, потому что ранее я имел с ним дело (можете ознакомиться со статьями про SmartLight и SmartPulse) и я считаю его идеальным под подобные проекты (имхо)

3. Ровер должен ездить вперед, назад, поворачивать влево и вправо, а также включать подсветку по кнопке в мобильном приложении

Далее я решил разобрать робота, чтобы понять, каким объемом пространства внутри него я могу располагать.

Места оказалось не особо много, но если выпилить некоторые ненужные в рамках проекта крепления, его должно хватить, чтобы разместить все необходимые электронные компоненты. Кстати о них.

Что по начинке?

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

Для управления моторчиками нужен драйвер. Естественно, так как мы имеем дело с небольшим корпусом игрушки, то все платы надо было подобрать так же миниатюрные. Сказано — сделано, и драйвер L298N mini уже был у меня. На него сразу можно было припаять два моторчика, чему я был несказанно рад.

Родных батареек ровера на два маленьких мотора с высоким крутящим моментом было бы недостаточно (я проверил это в том числе экспериментально), поэтому решил использовать аккумулятор на 350 mAh и зарядную плату к нему. По моей задумке, это все должно было располагаться на месте батарейного отсека ровера — в его голове. Там было достаточно места для размещения аккумулятора, а также можно было спокойно получить доступ к его зарядной плате через крышку отсека, чтобы в дальнейшем заряжать робота.

А что будет всем этим управлять? Для работы с BLE существует крайне удачная линейка ESP32 контроллеров с различными модификациями. Так как в этом проекте мы ограничиваемся сравнительно небольшим пространством для монтажа плат внутрь устройства, я выбрал ESP32-C3 SuperMini, которая по своим размерам не больше зарядной платы аккумулятора.

Чтобы нормально проверить все модули и протестировать будущий код прошивки, я реализовал схему подключения электронных компонентов. В дальнейшем пайка компонентов будет вестись в соответствии с данной схемой.

Прошивка робота

Перейдем к прошивке ровера, полная версия которой лежит у меня в репозитории на GitHub (всегда рад гостям).

По сути все, что нам нужно для реализации передачи данных на ровер, это поднять BLE-сервер и определить сервис и характеристику, в которую мы будем отправлять значения для включения и выключения моторчиков. Я писал код в Arduino IDE с использованием библиотек BLEDevice.h, BLEUtils.h и BLEServer.h

Инициализируем работу с BLE посредством следующего кода:

BLEDevice::init("Yandex Delivery Robot");
pServer = BLEDevice::createServer();
pServer->setCallbacks(new MyServerCallbacks());
BLEService* pMoveService = pServer->createService(BLEUUID((uint16_t)0x170D));
pMoveCharacteristic = pMoveService->createCharacteristic(BLEUUID((uint16_t)0x2A60), BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_WRITE);
pMoveCharacteristic->setCallbacks(new MoveCharacteristicCallbacks());
pMoveService->start();
BLEAdvertising* pAdvertising = pServer->getAdvertising();
pAdvertising->addServiceUUID(pMoveService->getUUID());
pAdvertising->setScanResponse(false);
pAdvertising->setMinPreferred(0x06);
pAdvertising->setMinPreferred(0x12);
BLEDevice::startAdvertising();

Здесь мы определяем наименование устройства, а также присваиваем UUID нашему сервису и характеристике pMoveCharacteristic

Запись в характеристики производится с помощью MoveCharacteristicCallbacks, в которой я реализовал switch-case конструкцию. Внизу прикреплен урезанный фрагмент.

class MoveCharacteristicCallbacks : public BLECharacteristicCallbacks {
    void onWrite(BLECharacteristic* pCharacteristic) {
        std::string value = pCharacteristic->getValue();
        if (value.length() > 0) {
            switch (value[0]) {
                case 0x01: // Поворот ровера влево
                    ledcWrite(CHANNEL_IN1, 255);
                    ledcWrite(CHANNEL_IN2, 0);
                    ledcWrite(CHANNEL_IN3, 255);
                    ledcWrite(CHANNEL_IN4, 0);
                    break;
                case 0x02: // Поворот ровера вправо
                    ledcWrite(CHANNEL_IN1, 0);
                    ledcWrite(CHANNEL_IN2, 255);
                    ledcWrite(CHANNEL_IN3, 0);
                    ledcWrite(CHANNEL_IN4, 255);
                    break;
            }
        }
    }
}

Мобильное приложение

Не будем далеко отходить от кода, поэтому перейдем к написанию мобильного приложения на Flutter. В репозитории на GitHub я выложил его полную версию, а тут расскажу про основные вещи.

Логика работы кода мобильного приложения также как и в случае с кодом прошивки построена на switch-case конструкции. Я решил расположить на странице управления ровером кнопки в виде стрелок направления (вперед, назад, влево, вправо) и кнопку включения/выключения подсветки в виде горящей лампочки. Когда пользователь нажимает на любую из кнопок направления, в BLE-характеристику подключенного устройства записывается соответствующее значение (к примеру, для поворота ровера влево — 0x01, для правого поворота — 0x02 и тд.).

Positioned(
  bottom: 160,
  left: 80,
  child: controlButton(Icons.arrow_back, 0x01, "Left"),
),
Positioned(
  bottom: 160,
  right: 80,
  child: controlButton(Icons.arrow_forward, 0x02, "Right"),
)

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

onPointerDown: (_) => sendCommand(command),
onPointerUp: (_) => sendCommand(0)

Подсветка включается при одинарном нажатии на кнопку с лампочкой. При повторном нажатии на нее, подсветка будет отключена. По сути это просто кнопка с запоминанием своего состояния.

Positioned(
  bottom: 40,
  right: 20,
  child: FloatingActionButton(
    onPressed: () {
      setState(() {
        toggleState = !toggleState;
        sendCommand(toggleState ? 3 : 6);
      });
    },
    child: Icon(
      toggleState ? Icons.lightbulb_outline : Icons.lightbulb,
      color: Color.fromRGBO(255, 53, 63, 1),
    ),
    backgroundColor: Colors.white,
  ),
)

Чтобы работать с BLE, я подключил flutter_blue: ^0.8.0 , а сам процесс подключения к устройству построен на определении рассылки от конкретного BLE-сервера по его названию. Запись значений производится по UUID сервиса и характеристики ровера.

List<BluetoothService> services = await widget.device.discoverServices();
var targetService = services.firstWhere((service) =>
    service.uuid == Guid('0000170D-0000-1000-8000-00805f9b34fb'));
var targetCharacteristic = targetService.characteristics.firstWhere(
    (characteristic) =>
        characteristic.uuid ==
        Guid('00002A60-0000-1000-8000-00805f9b34fb'));
await targetCharacteristic.write(value);

После того, как я протестировал работоспособность приложения с микроконтроллером, мне захотелось как-то «довести до ума», чтобы как минимум приложение выглядело чуть более симпатично. На странице управления ровером были только четыре кнопки управления моторами и одна кнопка для подсветки. Это выглядело скучновато, поэтому мне захотелось добавить динамики. Решил изобразить в Adobe Illustrator модельки с направлением ровера.

Реализовал обновление картинок по нажатию на соответствующие кнопки управления ровером также через switch по отправляемому с кнопки значению.

setState(() {
  switch (command) {
    case 0x01:
      currentImage = 'assets/Влево.png';
      break;
    case 0x02:
      currentImage = 'assets/Вправо.png';
      break;
    case 0x05:
      currentImage = 'assets/Вперед.png';
      break;
    case 0x04:
      currentImage = 'assets/Назад.png';
      break;
    default:
      break;
  }
});

Далее подобрал для интерфейса оригинальный красный цвет Яндекса и нарисовал иконку приложения, чтобы завершить разработку мобильного приложения и переключиться на монтаж всей электроники внутрь ровера.

Собираем приложение в Xcode, устанавливаем его на мобильное устройство (в моем случае это iPhone 12 Pro Max) и запускаем его для тестирования его работоспособности. В итоге мобильное приложение получило следующий внешний вид:

Пайка, флюс, два колеса

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

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

Чтобы получить возможность зарядки аккумулятора без разбора всего робота (потому что это садизм), я отпилил батарейный блок. В этом месте я расположу зарядную плату аккумулятора так, чтобы порт USB Type-C выходил на крышку бывшего батарейного блока. В таком случае для зарядки ровера нужно будет только снять эту крышку и подключить кабель к зарядной плате. Также я выпилил места под моторы, потому что места оказалось недостаточно, а мне не хотелось, чтобы их работе что-либо мешало.

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

В итоге не без проблем, но у меня получилось разместить все компоненты внутри ровера. Зарядка устройства производится со стороны нижней части корпуса. Это напоминает мне подключение Magic Mouse, но только я это сделал за неимением других вариантов, а не потому что не люблю людей. Можно было бы расположить зарядную плату как-то иначе, но я не хотел портить внешний вид ровера (днище не считается, потому что его не видно).

Поехали!

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

В качестве демонстрации управления ровером я записал небольшое видео:

Большое спасибо всем, кто прочитал эту статью!

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

Если у вас есть идеи или предложения, можете написать в комментариях, какие еще игрушки или вещи можно было бы модифицировать, и рано или поздно я сделаю это)

P.S. По поводу данной статьи я писал в отдел по связям с общественностью Яндекса, чтобы избежать претензий с их стороны, если кто-то решит, что модификация их официальной игрушки — это что-то уничижительное и негативное для репутации компании. К сожалению, меня проигнорировали, поэтому я считаю нужным упомянуть это здесь.

ДИСКЛЕЙМЕР: Статья написана автором блога на основе интервью с владельцем швейного производства в Подмосковье Евгением Апачевым.

11 лет мое производство шьет спецодежду для врачей и стюардесс, жилеты для неотапливаемых складов Вайлдберриз, и другую униформу. 10 человек на 150 кв.м в Подмосковье отшивают одежды на 1,5 млн в месяц. Сегодня мы переживаем не самые лучшие времена, как и вся отрасль, и вот почему.

В статье расскажу, как я не понял языка откатов, чем страшен женский алкоголизм, сколько можно заработать, когда одеваешь завод, и какие проблемы вас ждут на швейном производстве, если вы не Коко Шанель.

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

Швейное производство с нуля

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

На старте швейного производства можно обойтись оборудованием на 1,3 млн ₽. Оборудования немало, потому что даже, чтобы сшить обычный свитшот вам понадобится 3 машинки. Прямострочка сшивает, распошивалка вшивает манжеты и воротник, а оверлок делает боковые швы и сшивает рукав.

А полный перечень для начала своего производства можно посмотреть ниже.

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

Сбыт

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

Закупщики

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

В закупках крупных компаний все очень консервативно, они не склонны к резким поворотам. Это на WB мы смотрим и: «О, беру!». Закупщики стараются работать годами, потому что их задача достигать цели и если фирма выполняет обязательства, то менять такого контрагента они будут крайне нехотя.

Мы можем уже не работать с заказчиком, а нам до сих пор звонят по запросам:

– А вот перчатки вы делаете? Можете нам продать срочно? А то у нас нету.

– Не, мы перчатки не производим.

– Но, может вы знаете, где достать?

Откаты

Закупщики сами строят отношения, им важно, чтобы их работа хорошо выполнялась, чтобы их внутренние клиенты были довольны. Намеки на откаты я почти не встречаю.

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

Возможно, я пропускаю мимо ушей фразу: «Знаете, я уже 2 года не могу купить себе новую машину..». Возможно, мир на самом деле устроен по-другому.

Госзакупки

Как только в госзакупках появился критерий самое дешевое – самое лучшее, стало возможно шить из мусора и побеждать в тендере. Или сажать людей в подвале, обманывать с зарплатой, выгонять, и поэтому побеждать в тендере, и как-то на этом зарабатывать.

Есть авантюристы, которые выигрывают тендеры без швейных производств, а потом бегают по рынку и пытаются продать. Ко мне прибегают и говорят:

– Сошьете медицинскую куртку за 650 рублей вместе с тканью?

– А ее невозможно сшить за 650. Не сошьем, до свидания.

Были истории, где до тендера 3 посредника, а в конце бедные люди на производстве не справляются и работают в минус.

Реклама

Рекламируемся мы в Яндекс.Директ и на картах, запрос «спецодежда на заказ».

Иногда оттуда приходят стартаперы или дизайнеры, которые хотят сшить 500 лётных комбинезонов для перепродажи.

На WB выходить неинтересно, потому что невозможно конкурировать с ребятами, которые в черную привезли одежду из Китая.

Мы шьем много видов изделий. Но оборудование покупали аккуратно.

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

Сколько стоит 1 изделие?

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

Найти тех, кто организует процесс гораздо легче, чем швею, которая будет делать руками вперед-назад 8 часов 5 дней в неделю.

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

Мы шьем то, что не купить в магазине. На WB можно купить медкуртку за 600 ₽, сделано в Китае из какой-то ткани, не хочу плохо говорить.

Обычно себестоимость по нашим изделиям выглядит так:

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

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

Расходы швейного производства

Аренда – 70 000 ₽

Сейчас конкуренция за швей такая, что некоторые швейные производства открываются в торговых центрах. Снаружи висят красивые тряпки, а внутри швеи в тапках и трениках. Женщины часто без машин, поэтому расположение сильно влияет, пойдут ли они к вам работать. В подвалах уже даже иностранцы могут согласиться работать только за большие деньги.

Зарплаты – 700 000 ₽

В нише есть 2 способа оплачивать работу: сделка и зарплата. Сделку у нас в городе очень любят собственницы, которые шьют сами. Они берут интересные заказы, созывают подружек с призывом: «Девочки, шьем!», месяц плотно работают, зарабатывают по 100к, следующий месяц отходят.

А второй тип — это завод, как у нас. Есть зарплата, есть премиальная часть.

Есть заказ или нет, уже никого не волнует, люди ходят на работу по расписанию, а я беру риски на себя. Никого не интересует, как дальше извернусь, зарплату 1-го и 15-го без задержек.

Мастер — это самая опытная швея, она разбирает ситуации, выясняет почему так, она же следит за качеством.

На производстве работает 10 человек. Меньше всех зарабатывают упаковщицы (30к), потом идут швеи (40к), потом мастер и вышивальщица, потом закройщица, потом начальник производства. Кадры, охрана труда и бухгалтерия на аутсорсе, их работу тоже считаю в зарплатный фонд.

Потери – 10 000 ₽.

Обычно брак – это неумышленное действие, это недостаток обучения, оснастки. Человек не хочет производить брак. У нас действует правило: не принимать брак, не производить брак, не передавать брак. Если в коллективе нормальная атмосфера, а за брак не штрафуют, когда девушки видят, что получили брак, не передают его дальше. Нам этих правил хватает, чтобы в коробке получать минимум брака.

А полный расходник выглядит так:

Сколько можно заработать на швейном производстве?

Обычно считается, что треть от продажной цены изделия – это материалы, еще треть – это постоянные расходы, а последняя треть – это налоги, потери, маркетинг и прибыль. Но из-за описанных кадровых проблем у нас на обороте в 1,5 млн на постоянные расходы уходит 790к, вместо 500к. Поэтому в месяц с нашим средним оборотом в 1,5 млн в месяц чистыми остается порядка 100-120к. На двоих партнеров.

Так выглядят текущие фин. итоги:

А почему так? Нужно ответить на вопрос из заголовка.

Проблемы швейного производства

Швея – непрестижная профессия

Самая большая боль швейного производства – это люди. Из 30 выпускниц швейного техникума, только 2 девушки идут работать швеей. Я помогал одному такому техникуму и когда я сказал: «У меня есть вакансия!» это не волновало абсолютно никого. Работать швеёй на производстве не престижно. Девушки быстрее идут пилить маникюр или делать ресницы.

Швея – это рабочая специальность. Ты 8 часов 5 дней в неделю делаешь движения вперед-назад.

Это механический, тяжелый, очень скучный труд. В этом нет творчества. Каждый день ты повторяешь одно и то же. Ногти сделал, можешь запилить селфачок в нельзяграм, какой прекрасный человек, в красивом наряде, красивые ногти, цвета, вроде красивая жизнь в красивом месте.

А швейное предприятие – это шумно, мусор, обед по расписанию.

Работу можно сравнить со сбором урожая. Сложно ли собирать морковку? Несложно. Выдернул, отряхнул землю, убрал в ящик. Но это всегда в позе, спина затекает, мозг свободен, нужно выполнять план.

Поэтому в условиях кадрового голода мы рады необразованным и хотя бы немного умеющим шить женщинам.

Курс доллара

Все держалось на иностранной рабочей силе. Но с изменением курса доллара у мигрантов перестала сходиться математика проживания в России. Теперь приезжие просят очень заметные зарплаты (70-80к для начала, но потом хотят больше).

Борьба за кадры

Мы конкурируем за кадры с:

– Пятерочкой и Вайлдберриз. Где, как и у нас на производстве, платят рабочему по 40к.

– С Москвой. От Ступино до столицы – 100 км. В Москве платят 70-80к швеям.

Женский алкоголизм

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

Люди не выходят на смены, уходят в запои, пьют на рабочем месте, выходят пьяными, кодируются, все понимают, хотят вернуться, но у них уже зависимость. Говорят: «Я все, завязала», но работать не могут, не потому что похмелье, а потому что после запоев нервная система уже не справляется и руки трясутся.

Берешь непьющую, а она начинает пить. На пьющих уже глаз наметан, их просто не нанимаешь.

Ты разговариваешь с ней: «Так, какой у тебя дальше план? Ты прекращаешь? или дальше не сможешь здесь работать».

А расставаться всегда сложно, только обучение нового сотрудника 2-3 месяца, плюс потери из-за простоя.

Чтобы справляться, мы используем все, что можно. Если можно задержать сроки – задерживаем, если можно попросить сотрудников задержаться – просим. Так выглядит обычный день начальника производства: «Да е-мае, Наташа в запое, как сегодня будем решать эту ситуацию?»

Маркировка

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

Проблема не только в разовых затратах, проблема в том, что внутри бизнеса появляется еще один бизнес-процесс. Сам код недорого стоит, но систему надо поддерживать, швея это делать не может, и как будто на это должен появиться отдельный человек. А новая область требует постоянного контроля. Бухгалтер перегружен и новую задачу возьмет только за еще +5к к зарплате. Ведь раньше этих действий не было, а теперь это появилось.

Финал

Если что я не жалуюсь, мы работаем, в этом месяце покупаем новую швейную машинку за 300к.

P.S Швейный бизнес-план для гаража Стива Джобса

В 2021-м мы думали о покупке доли на чулочно-носочной фабрике. И посчитали бизнес-план.

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

Потом другая машина их зашивает. Еще одна машина и оснастка помогает гладить и упаковывать. Всё очень просто. В условном гараже Стива Джобса, это все вполне поместится и можно производить носки.

Титры

ДИСКЛЕЙМЕР: Статья написана автором блога “упал, поднялся” на основе интервью с владельцем швейного производства Евгением Апачевым.

Я веду блог «упал, поднялся» с историями про реальный бизнес, а не этот ваш успешный успех.

Вы прочитаете: как я открыл и развалил сеть ночных клубов, как правильно склеить картон, чтобы продать его на маркетплейсах на 50 млн в год, как фермер потратил 250 млн в деревне, почему умирает производство пельменей в провинции, почему таксопарк на 300 водителей и 40 машин больше не бизнес, как технарь отреставрировал советский лагерь, но улетел в кассовый разрыв на 60 млн и другие истории

Привет! Это Даша, проектировщик из Selectel. Сегодня хочу поделиться своим опытом проведения UX-аудита — неоднократно я приходила в новый продукт и передо мной вставала такая задача.

Я успела набить шишек, перерыть половину рунета и в итоге на практике получить ценный опыт.

Эта статья родилась из желания помочь читателям избежать ошибок, которые совершила я (например, с головой уйти в анализ размера кнопок вместо изучения основных пользовательских сценариев), и при этом поделиться инструментами, которые помогли мне провести UX-аудит, будучи новичком в сложном продукте. Кроме того, я собрала полезный шаблон в Miro для динамичной и наглядной презентации результатов аудита команде.

Все подробности — под катом.

Используйте навигацию, если не хотите читать текст полностью:

→ Что такое UX-аудит
→ Когда UX-аудит нужен, а когда нет
→ Шаг 1: Определите основные цели продукта, а также ожидаемый от него результат
→ Шаг 2: Проанализируйте данные о продукте и фиче
→ Шаг 3: Оцените поведение интерфейса
→ Шаг 4: Подготовьте отчет для команды
→ Ура, вы закончили! А что дальше?

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

Перед тем, как перейти к конкретным шагам аудита, расскажу о моем опыте.

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

Учитывая, что каждый из продуктов был в специфических сферах (HR-консалтинг, телефония, IT-инфраструктура), задача для меня звучала примерно как: «Мы тут год назад построили мост, оцени, пожалуйста, насколько он надежен». И все бы ничего, вот только я ничего не знаю про мосты, кроме того, что в Петербурге их около 300 🙂

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

Главная ловушка на старте — из-за недостатка знаний о сфере, продукте и основных пользовательских кейсах скатиться в оценку UI.

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

И чтобы дойти до его основания и провести качественный UX-аудит, нужно это делать поэтапно:

1. изучить бизнес-цели продукта и понять, насколько они закрываются теми фичами, которые уже есть в продукте;
2. изучить потребности пользователей и проанализировать, насколько продукт помогает пользователю решить его задачи;
3. оценить данные (количественные и качественные) о текущем поведении пользователей;
4. проверить, насколько интерфейс предсказуемо ведет себя для пользователя (и вот тут уже спрятан кусочек для анализа UI).

В этом тексте вас ждет подробная инструкция по каждому шагу. А пока разберемся, в каких ситуациях нужен UX-аудит, а когда его можно не делать.

UX-аудит будет полезен, если:

1. Продукт уже устоялся и надо оценить его работоспособность, соответствие ожиданиям рынка и пользователей.
2. Продукт уже устоялся настолько, что пора делать редизайн. Чтобы его сделать осмысленно, стоит провести «ревизию» продукта. Также в этом случае полезно «замерить» на метриках состояние до редизайна. Это потом поможет оценить эффективность ваших действий.
3. Основные метрики, по которым вы отслеживали эффективность всего продукта и отдельных фичей, стали снижаться по показателям. Это тоже весомая причина, чтобы провести анализ текущей ситуации и выявить причины, по которым происходит падение показателей.
4. Никаких метрик по отслеживанию удовлетворенности пользователей или бизнес-показателей нет. Соответственно, нет понимания, где продукт находится сейчас. В таком случае, самое время провести аудит. И даже больше — вместе с владельцем продукта определить основные бизнес-показатели, которые вы начнете отслеживать.

UX-аудит можно пропустить, если:

1. Вы пришли в стартап, который ракетит на рынке, активно привлекает пользователей и инвестиции. Это важный момент роста, который нельзя упустить, чтобы дойти до стадии «снятия сливок» (вот здесь можно почитать про стадии развития продукта подробнее). В таком случае лучше сфокусироваться на развитии новых фич, которые помогут продукту укорениться на рынке, и сборе обратной связи от пользователей.
2. В команде настроен регулярный процесс отслеживаний UX- и бизнес-метрик, которые показывают, что в продукте полный порядок. Тогда с чистой совестью можно окунаться в бэклог, уходить в исследование и проектирование новых фичей.

По этой схеме можно свериться, нужно ли вам в текущей ситуации проводить аудит.

Итак, вы обнаружили свой кейс в первом списке и уже заряжены проводить аудит.

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

Четыре основных шага аудита:

1. Определите основные цели и ожидаемые результаты продукта для пользователя и бизнеса.
2. Изучите имеющуюся аналитику на предмет актуальности и достоверности. Спойлер: если кажется, что у вас нет аналитики, вам кажется.
3. Проанализируйте основные состояния интерфейса (рабочее, пустое, ошибочное), или, при отсутствии выделенного времени, проведите более упрощенный анализ на основе UX-эвристик.
4. Опишите в понятной форме результаты аудита и список улучшений.

Приготовьтесь к погружению — далее мы рассмотрим каждый шаг подробно и разберем конкретные примеры.

Зачем это нужно?

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

Первый вариант дает только поверхностное знакомство с UI. Второй может запутать большим количеством информации.

Поэтому в начале аудита я рекомендую четко зафиксировать, какие у продукта основные цели: как для пользователя, так и для бизнеса.

Как это сделать?

Есть такое понятие, как UX Value Loop — это похожий на восьмерку концепт, который помогает осознать важные составляющие продукта. Он показывает, что если не удовлетворить каждую сторону, то продукт провалится.

Работа с пользователями

Чтобы разобраться в основных пользовательских задачах, проведите качественные исследования с реальными пользователями. Но если на это нет времени, изучите другие источники знаний:

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

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

Работа с целями бизнеса

Для изучения бизнес-целей также рекомендую поставить встречу с владельцем продукта или бизнес-аналитиком в команде. Во время встречи проверяйте, попадают ли названные цели в одну из категорий (если нет – конкретизируйте до тех пор, пока не попадет, в противном случае это будет не цель, а лишь видение):

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

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

Важно: в рамках UX-аудита сосредоточьтесь на тех фичах, которые одновременно решают пользовательские задачи и закрывают бизнес-цели – именно они в долгосрочной перспективе обеспечивают успех продукта.

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

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

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

На что смотреть, когда системы веб-аналитики работают

Вот какие данные я рекомендую собрать на этом этапе UX-аудита.

Конверсия в завершение сценария

Самый интересный показатель. У любого сценария есть стартовая точка — когда пользователь начинает решать свою задачу, и финальная — выполнение целевого действия. Между этими точками есть шаги, которые пользователь должен пройти. Конверсия позволяет оценить, сколько пользователей доходит до конца, совершая целевое действие, и посмотреть пути тех, кто все же не доходит до финиша. А после — сформулировать гипотезы, почему так происходит.

Время решения задачи

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

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

Поисковые запросы

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

Если же система не выдает список поисковых запросов, аналогичный можно составить, просмотрев скринкасты по разным страницам продукта — такая возможность есть в Яндекс Метрике и Posthog.

Сообщения об ошибках

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

Какие устройства наиболее популярны — десктопные или смартфоны?

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

DAU и MAU

• DAU — число уникальных пользователей, использовавших продукт в течение календарных суток.
• MAU — число уникальных пользователей, использовавших продукт в течение календарного месяца.

Чтобы лучше разобраться в метриках, советую к прочтению текст по ссылке.

Что делать, если подключенных систем веб-аналитики нет

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

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

В качестве примера приведу метрики, которые я собирала при аудите сценария «Добавление пользователя в систему в панели my.selectel.ru».

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

Эвристика — это рекомендация, правило или суждение эксперта, которое принято считать верным. Самые популярные эвристики в UX: Нильсена Нормана, Бена Шнейдермана, Вайншенка и Баркера, Иэн Коннелл.

Выполняя эвристическую оценку, вы изучаете интерфейс на предмет выполнения этих эвристик в интерфейсе.

Как не похоронить себя за пикселями, когда в продукте много фич

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

1. Сверьтесь со списком основных фичей продукта. Он должен был у вас появиться после прохождения шагов выше.
2. Вместе с продактом выделите те, которые лучше всего перформят для бизнеса.
3. Выберите среди них 3-5 самых востребованных для пользователей и проводите оценку этих фичей.
4. Не забудьте про те фичи, в которых по результатам анализа ключевых метрик стало ясно, что там что-то «болеет» по цифрам. Возможно, вы сможете на этапе эвристического анализа поставить диагноз.

Почему именно эвристическая оценка? Я рекомендую использовать эту методику, поскольку она одновременно позволяет проверить:

• отвечает ли система требованиям пользователя: насколько качественно продуман UX,
• не упустить из виду эстетический аспект анализа: тот самый UI, до которого мы с вами дошло только на этом шаге.

Если пока звучит сложно, сейчас станет проще: рассмотрим, как это работает на примере двух эвристик (остальные вы найдете в шаблоне чуть дальше). За основу возьмем эвристики Нильсена Нормана (вы вольны выбрать эвристики того эксперта, к кому вы испытываете большею симпатию, но для меня это всегда будет Нильсен Норман).

Пояснения к эвристикам взяты из статьи-перевода описания эвристик по Нильсену Норману.

Такую оценку лучше проводить по каждой фиче отдельно. По каждой эвристике вы представляете в двоичной системе, выполняется ли она или нет: 0 или 1. В итоге у вас получится понятная оценка юзабилити по 10 балльной шкале с четким пониманием, какие проблемные места требует внимания дизайнера для доработки или редизайна.

Для удобства я сложила готовый шаблон в таблицу – копируйте себе и берите в работу.

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

К финальному этапу у нас собралось уже ну очееень много материала, который надо емко и коротко показать команде.

Самый оптимальный способ — собрать презентацию с выводами по каждому шагу. При этом я рекомендую показывать результаты не просто демонстрируя выводы в Power Point, а проводя демо на интерактивной доске.

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

На моей практике презентация отчета команде никогда не укладывалась в одну часовую встречу, поэтому рекомендую заложить на это серию встреч (в зависимости от объема вашего отчета).

Чтобы ничего из вашего отчета с результатами UX-аудита не покрылось слоем пыли и не осталось в летописи работы команды, рекомендую сделать следующее:

1. По всем доработкам, которые вы обсудили с командой, завести эпики в таск-трекере. На данном этапе более детальная декомпозиция не понадобится — к этому можно приступить в момент, когда на командном планировании вы определите, что скоро возьмете эпик в работу.
2. Если эти доработки достаточно масштабы, вместе с продактом актуализируйте дорожную карту развития продукта (если в команде ее нет — заведите!).
3. Если видите, что по мере дальнейшей работы команды эти доработки теряются из виду — напоминайте на командных встречах, что они важный и аргументируйте, почему их надо взять в работу.

Совет напоследок: есть вероятность, что в процессе аудита вы что-то упустите. Это нормально — особенно в тех случаях, когда вы приходите проводить оценку в устоявшийся продукт с большим легаси.

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