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

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

Представьте, что вы — российская IT-компания, которая хочет открыть свой офис в Америке и выйти на американский рынок. Какая первая локация приходит в голову? Кремниевая долина! Считается, что она просто создана для этого.

Но насколько это справедливо? Основатель Macroscop Артем Разумков посетил 11 технологических хабов в различных частях США, и теперь по ряду причин мы ставим под сомнение, что Кремниевая долина – идеальное место для любой IT-компании.

Очевидно, что лучше предотвратить болезнь, чем впоследствии ее лечить.

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

Наша техподдержка работает активно, очень активно. Она консультирует, помогает настроить и, конечно, решает проблемы в видеосистемах. Часто эти проблемы видны в среде ПО, но с Macroscop они не связаны. Видеосистема многокомпонентна, если что-то в ней ломается или просто не работает должным образом, пользователь не увидит, что какая-то часть испортилась. Он увидит, что в realtime-видео появились рывки, а в архиве – “дырки”. Значит ли это, что проблема в ПО? Часто причина совсем в другом.

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

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

Когда пользователь видит, что изображение не экране “дергается”, его мало волнует, чем это обусловлено. Причин же тому может быть много, так как видеосистема состоит из многих компонент, и софт — лишь одна из них. Но мы должны были сделать все, чтобы Macroscop со своей стороны отображал максимально плавно.

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

#спойлер

Раньше все свои интеллектуальные модули мы строили на традиционных алгоритмах видеоанализа (далее мы будем называть их «классическими»). О нейросетях мы, конечно, знали, и пробовали их применять еще в далеком 2008. В частности, сравнивать изображения людей по кластерам. Но результаты не были выдающимися (в том числе из-за невысокого уровня развития нейросетей). И мы на многие годы стали приверженцами «классики» машинного зрения. А все нейросети были у нас в головах :)

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

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

В предыдущей статье мы рассказывали о модернизации одной из самых популярных функций видеоанализа Macroscop – функции подсчета посетителей.

Мы решили сделать ее лучше, точнее и удобнее для пользователя. Оставался один небольшой вопрос: как это сделать? В нашем случае порядок действий был таким:

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

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

Давайте знакомиться

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

«Ближе к делу»

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

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

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

Превращаем планирование в точную науку

Как определить вектор развития продукта и совместить его полезность и инновационность? Для того, чтобы наши новые разработки с большей вероятностью «попали в цель», было принято решение провести глубокое исследование и на основе его результатов запланировать новую версию. Определением стратегии развития Macroscop занимается product-менеджер компании, и вот по какому алгоритму действовал он:

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

Удивительно, но сделать продукт простым для пользователя очень сложно. Мы поняли это на собственном опыте, когда столкнулись с вопросами, на которые не нашли однозначного ответа:
• что важнее, простота или функциональность?
• до какой степени нужно и можно упрощать продукт?
• и на кого ориентироваться в конечном счете при внесении изменений?

Простота – это сложно

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

Посмотрите, например, на Dropbox. Однажды гендиректор Macroscop Артем Разумков пообщался с одним из создателей этого сервиса. Тот рассказал, что идея хранения файлов в облаке была известна давно, и для этого надо было нажать на кнопку только 1 раз – загрузить файл. То, что придумали они – это просто переход от одного нажатию к нулю нажатий: человек просто помещает файл в обычную папку, и он загружается в облако автоматически. Кнопку «загрузить» вообще не надо нажимать! Эта простая идея перехода от 1 нажатия к 0 нажатий позволила им взлететь до невероятных высот. Вот она сила простоты!

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

Почему? Давайте разбираться.

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

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

В 2008 году у нас родилась идея максимально упростить процесс поиска в архивах видеосистем. Представьте среднего размера систему из 100 видеокамер и примерно 1000 часов видеозаписей, которые они оставили за сутки (обычно запись видео производится только когда есть активность в кадре). И вам нужно найти что-то в этих записях, но вы не знаете, где и когда это происходило. Вы будете просматривать записи час, второй, третий, и к моменту, когда найдете то, что нужно, проклянете все на свете.

Мы решили создать инструмент, который позволит искать по видео так же, как Google ищет по тексту: