Краткая повесть о том как рождаются монстры

Каждый хоть раз в жизни сталкивался с софтом, у которого так много бесполезных функций, что непонятно как его использовать. Мы невольно виним разработчиков в отсутствии логики, сложной подачи и т.д. Часто - Это происходит по двум причинам. Первая - невозможность технически разделить продукты. Второе - отсутствие позиционирования. Иногда звёзды сходятся и случается комбо. Об одном из них хочу рассказать.

Краткая повесть о том как рождаются монстры

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

Подобная система должна работать на нескольких уровнях: Город, район, объект. Для сбора данных с камер, срабатывания SOS кнопок делались специальные системы, закладывались кластеры под масштабирование и увеличение скорости обработки данных. Мы делали упор на real-time мониторинг, чтобы вытаскивать как можно больше полезной информации. Спустя год проект был запилотирован в нескольких городах и успешно сдан. Так вышло, что система обладала очень богатым функционалом именно в администраторской панели, что заинтересовало софт другое подразделение на стороне клиента.

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

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

Спустя всё это время продукт до сих пор живёт вполне успешно с коммерческой точки зрения. Однако, с точки зрения кода там настоящий легаси и ад. Я искренне считаю, что у каждого продукта должно быть понятное позиционирование, в противном случае расфокус приводит к повышенным костам, текучки разработчиков из-за огромного легаси и неопределённости. Тем не менее, это характерный пример появления Франкенштейна из-за отсутствия своевременных управленческих решений. Agile сулит быть гибкими и адаптироваться под рынок, но нужно не забывать о том как и кто дальше будет поддерживать этих монстров.

Пара слов об авторе статьи

Запуск любого продукта - всегда боль. Баги, рефакторинг, вечная доработка, нарушение сроков и бюджетов. У этих проблем, как правило, 2 причины: Первая это отсутствие экспертизы, а второе надёжного СТО, который мыслит бизнес метриками.

Меня зовут Виталий, я в ИТ 10 лет. На самом старте карьеры мне довелось запустить на свифте первый велокаршеринг в стране. Он ко всему прочему взял золото на премии “приложение года”. 6 лет назад мы запустили программу цифровизации в крупном энтерпрайзе, 120 разработчиков, свыше 20 проектов и огромный legacy. После побывал в шкуре СТО в спортивной отрасли.

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

Подписывайте на мой телеграмм канал Цифровые Зарубы, всё об IT для предпринимателей

11
3 комментария

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

Ответить

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

1
Ответить