Scrum, Kanban и другие «‎эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.

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

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

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

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

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

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

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

В 2019 году (кажется, целую вечность назад), мы начали эксперимент. Решили использовать наши знания в области нейронных сетей, чтобы создать продукт для многообещающей, как нам казалось, ниши. Целью было разработать аналитическую систему для застройщиков, которая с помощью камер и нейронных сетей следила бы за происходящим на строительных площадках. У нас была гипотеза. Мы изучили бизнесы, делающие подобную аналитику. Нашли несколько зарубежных стартапов, которые получили значительные инвестиции. Естественно, мы задались вопросом: «Почему мы не можем сделать то же самое?»

И что могло пойти не так?

В этом посте мы расскажем, как дошли до идеи отказа от использования радара при фотовидеофиксации нарушений. А также о том, как: подружили камеры с сверточными нейросетями, научили эту дружную «компанию» отличать грузовики от легковушек, точно фиксировать скорость и направление движения, а заодно засекать проезды на красный свет.

Привет, Хабр! Это команда дата-сайентистов Magnus Tech. В этом посте мы расскажем, как работали над одним общественно полезным проектом — алгоритмом, который распознает ДТП по видео с дорожных камер. Кейс будет интересен широкому кругу разработчиков, которые занимаются технологиями машинного зрения и обучения. В нем — наш долгий путь из множества попыток сделать точный алгоритм, несмотря на его настойчивые попытки быть неточным.

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