Это история о том, как мы строили промышленный продукт из сферы Интернета вещей для морских портов, и какое-то время нам казалось, что главное — заставить его работать. Но оказалось, что иногда самая большая проблема не в коде, не в железе и даже не в отсутствии спроса.
В одну из питерских белых ночей я усердно работал на территории морского порта. Коллеги весь день монтировали наше оборудование на контейнерный перегружатель, и, несмотря на позднее время, мы решили не прерываться — нам не терпелось понять, будет ли все работать так, как мы планировали.
Внезапно в небе раздался резкий хлопок. Небо полыхнуло яркой вспышкой, и в нескольких сотнях метров от нас в воду начали падать горящие обломки.
— Оп-па! Это ПВО. Похоже, дрон сбили, — мрачно произнёс мой инженер-монтажник. — Наверное, придётся отложить все до завтра.
Мы ещё не понимали, что спешить с этим проектом нам скоро будет уже некуда.
За пару лет до этого я дни напролет сидел в офисе с паяльником, кучей электронных девайсов и попеременно читал то статьи о применении триггера Шмитта для борьбы с дребезгом контактов, то о специфике программирования микроконтроллеров и серверного бэкенда для проектов Интернета вещей. Мы делали систему для морских портов, которая должна была повысить производительность операций по перемещению контейнеров.
Идея такая: ричстакеры и краны оборудуются датчиками и камерами, которые отправляют на сервер данные о любых перемещениях грузов, а каждый водитель или крановщик работает в кабине с планшетом, который в режиме реального времени показывает, какой груз где находится, что нужно взять и куда переместить. Софтверная часть — Python-скрипт, управляющий оборудованием, FastAPI и React на сервере, дообученная модель YOLO для детекции номеров контейнера, нативное Kotlin-приложение для планшета. Все вместе — что-то вроде Яндекс Такси для спецтехники. Сокращаем время на поиск контейнеров, оптимизируем маршруты. Для терминалов, которые борются за скорость погрузки и разгрузки судов, — это важно.
Первый MVP обладал лишь одной функцией — подсчет количества выполняемых погрузочно-разгрузочных операций. Делал он это объективно плохо. В качестве источника сигнала для подсчета количества операций мы выбрали сигнальную лампочку, которая загоралась и гасла в зависимости от того, закрыты или открыты замки на стреле контейнерного перегружателя, — таким образом можно было понять, взят или поставлен контейнер. В теории.
На практике же мы столкнулись с тем, что система могла зарегистрировать кучу операций в течение нескольких секунд или, напротив, пропустить нужные. Огромное количество времени было потрачено, с одной стороны, на отладку схемотехники, с другой — кода. Предусмотреть все corner-кейсы, которые возможны в условиях реального порта, для покрытия тестами оказалось невозможно, живая работа в полях постоянно подкидывала новые сюрпризы вплоть до того, что вибрация на технике физически разрушала наше оборудование, вырывая с корнем USB-порты вместе с LTE-модемами из микрокомпьютера.
На тот момент у меня не было опыта управления технической командой инженеров, и я с удивлением открывал для себя, как позже выяснилось, характерные проблемы: люди были увлечены и работали не на страх, а на совесть, но, к сожалению, далеко не всегда над тем, что было нужно и важно. Электронщик периодически уходил в эксперименты с разработкой платы питания, хотя я приоритезировал решение вопросов с демпфированием, программист вместо работы над минимальной функциональностью бэкенд-сервиса для карты вдруг решал, что нам срочно необходимо заняться навороченной системой доставки кода через Ansible. Почему? А потому что интересно. Любознательность — это же вообще основа инженерной профессии. Приходилось, не затрагивая профессиональное самолюбие, аккуратно возвращать коллег к целям и задачам проекта.
Было ли все гладко с точки зрения продаж? Отношение к инновациям в запоминающейся, практически афористичной манере выразил главный инженер одной крупной и уважаемой транспортной корпорации. Мое выступление с презентацией о возможностях, которые дает наш продукт, он предварил фразой: “Нам, безусловно, нужны инновации. Но дешево. Лучше бесплатно”. Но решимость продолжать была непоколебимой. И мы нашли тех, кто увидел в этой истории потенциал.
Продажа инновационных систем предполагает проведение испытаний: нужно на практике доказать то, что она работает. И наша работала. Мы смонтировали по несколько комплектов оборудования в разных портах и контейнерных терминалах. Параллельно дорабатывали алгоритмы, собирали обратную связь и показывали заказчикам, насколько прозрачнее становится технологический процесс. Потихоньку копились отзывы и отчеты, а мы готовились к масштабированию системы.
Это был тот самый момент, ради которого всё и затевалось. Мы уже прошли технические сложности новой разработки, трудности в формировании коллектива, преодолели непонимание того, что нужно рынку, и нам казалось, что худшее позади. Но это были обычные проблемы стартапа: тяжёлые, неприятные, дорогие — но всё-таки решаемые. Главный удар был другого масштаба. Черный лебедь уже расправил крылья, но мы пока этого не видели.
Порты и контейнерные терминалы оказались в зоне риска. В ответ на новые угрозы появились средства радиообнаружения и радиоподавления. То, что для нас было просто инфраструктурой — связь, спутниковая навигация, стабильный радиоканал, — внезапно стало частью системы безопасности. Для нашей архитектуры это было фатально. Решение, завязанное на точные координаты техники через GNSS и передачу данных в реальном времени через LTE, за несколько месяцев утратило смысл.
Именно тогда та ночь в порту стала для нас понятной задним числом. С этого момента любые попытки доработки системы стали бесполезными. Нужно было менять сам принцип, но бюджета на это уже не было. Мы вложили в проект слишком много времени и денег и уже не могли позволить себе еще один год разработки.
Главный вывод из этой истории для меня оказался не в том, что промышленный IoT — это сложно. Это банальность. Гораздо важнее другое: любой технологический продукт строится на предположениях о мире, в котором он будет работать. Пока они верны, можно улучшать железо, оптимизировать код, работать с командой и убеждать заказчиков. Но если меняется сама среда, продукт может устареть не потому, что он плохо сделан, а потому что исчезает среда, для которой он был нужен.
Мы приехали проверить, заработает ли наша система. А увидели, что сам мир, для которого мы её задумывали, уже закончился.
ссылка на оригинал статьи https://habr.com/ru/articles/1053320/