Практически все компании, которые занимаются разработкой модулей видеоанализа делают это, исходя из экстраполяции собственной инженерной мысли. Компания думает: «Мы сможем разработать функцию, которая, например, будет обнаруживать оставленные предметы, или детектировать огонь, или считать людей на кассах магазинов и т.п.». И делает это. Решение о том, какой модуль создать принимается в большинстве случаев исходя из возможностей разработчиков и ресурсов компании. В результате часто модули, которые получаются, становятся своего рода техническими экспериментами. И когда их покупают заказчики, внедряют в действующие системы видеонаблюдения и начинают применять на практике, оказывается, что реальной пользы они не несут.
Получается разработка ради разработки, а не ради решения наболевших проблем. А это неправильно и невыгодно. Дело в том, что разработка функции не заканчивается ее созданием. Функция входит в состав программного продукта, который постоянно обновляется, соответственно, и она должна постоянно поддерживаться, меняться, выстраиваясь в новые версии. А на это требуются ресурсы и время разработчиков. Каждая новая итерация функции должна проверяться на этапе тестирования продукта, а это ресурсы и время группы качества.
В добавок ко всему нагромождение в продукте лишних, неполезных, невостребованных на практике функций приводит к общему его захламлению и усложнению (см. статью «На пути к простоте: как сложно она дается разработчикам»).
Значит, надо стремиться разрабатывать только то, что реально будет полезно и применимо на практике большим количеством людей. Но как найти такую функцию?
В решении этого вопроса мы сделали ставку на customer development. По определению custdev — это тестирование идеи или прототипа будущего продукта на потенциальных потребителях.
Этот метод предполагает, что мы сколько угодно можем генерировать идеи и гипотезы о том, какой должна быть искомая функция (основываясь на своих возможностях или фантазии – не важно), но потом их нужно будет валидировать.
Практически все разработки в области видеоанализа сегодня– это результат реализации неотвалидированных, непроверенных гипотез. Разработчики предполагают, что придуманная ими функция кому-то будет нужна. Предполагают, что она будет нести пользу, если будет сделана именно так, а не иначе. Но мировой опыт custdev показывает, что большинство гипотез оказываются неверными.
Мы начали генерировать идеи. Для этого мы штурмовали самостоятельно, спрашивали текущих и потенциальных пользователей видеосистем, чего им не хватает, вспоминали, с чем мы сталкивались и о чем слышали от участников выставок, семинаров и т.п. В итоге у нас появилось 115 гипотез. Это идеи ценности, которая может быть перенесена пользователю через модуль видеоанализа.
Так выглядела одна из наших рабочих таблиц с гипотезами для валидации
Далее гипотезы нужно было отвалидировать. Для этого мы ходили и выезжали к реальным пользователям на разные реальные объекты, на которых прямо сейчас используется система видеонаблюдения, и проводили с ними «проблемные» интервью. Мы спрашивали их о прошлом пользовательском опыте, выясняли, какая у них в течение последнего месяца была проблема, которая потенциально могла бы быть решена с помощью какого-то модуля видеоанализа. И готовы ли они купить за конкретную цену функцию для решения этой проблемы, когда она будет нами разработана.
На этом этапе мы провели 124 таких интервью и с удивлением обнаружили, что такую проверку прошли всего лишь 5 из 115 наших гипотез. Всего 4%! Это уже стало для нас очень показательным.
После того, как мы отобрали претендентов в разработку, необходимо было понять, как это делать. По каждому модулю мы составили варианты реализации, и снова пошли к тем же самым пользователям с вопросом, а то ли они хотят увидеть.
И в большинстве случаев наши предположения вновь оказались ошибочными. Удобство работы с одной и той же функцией для разработчика, который ее создает, и для пользователя, который ее эксплуатирует, выглядит абсолютно по-разному. Поэтому методом custdev мы искали не только «что», но и «как». Только несколько предположений о том, как выбранные функции должны работать, подтвердились словами пользователей.
Одну из найденных 5 идей мы реализовали осенью 2017 года. Это модуль, позволяющий контролировать соблюдение техники безопасности на производстве и стройках, — детектор отсутствия каски на голове человека.
Пользователи принимали непосредственное участие не только в выборе и форме реализации функции, но и в ее разработке. Используя подход deep learning, разработчики в процессе создания модуля обучали детектор на реальных видеороликах с реальных объектов: строек, промышленных предприятий, электростанций. Что-то нам присылали пользователи; что-то мы получали сами, выезжая на объекты; что-то снимали, когда попадались стройки или ремонтные зоны; что-то брали из свободных источников интернетовских онлайн-трансляций.
Мы прекрасно понимаем, что функция, которая нужна пользователям, по их словам, и функция, которую они покупают и реально используют – это не всегда одно и то же. За первые 1,5 месяца продаж детектора отсутствия касок его приобрели в 5 стран, и этот результат мы оцениваем хорошо. Но в будущем надо продолжать оценивать востребованность и реальную полезность модуля: отслеживать повторные приобретения детектора у тех, кто уже начал его использовать; выяснять конкретные результаты от внедрения функции в структуру видеосистемы; отслеживать, есть ли обращения в техподдержку по работе модуля и т.п. И в случае, если на практике потребность и реальное использование модуля не подтвердится, иметь смелость попрощаться с ним. Как когда-то мы сделали с модулем интерактивного поиска (см. статью «Разработка в собственном соку или как мы поняли, что занимаемся не тем, что нужно пользователям»).
Способ разработки с применением методик customer development не является единственно верным. Но, по нашему убеждению, он позволяет сделать модули видеоанализа не инженерными разработками, а функциями, которые дают реальную пользу реальным людям.
Получается разработка ради разработки, а не ради решения наболевших проблем. А это неправильно и невыгодно. Дело в том, что разработка функции не заканчивается ее созданием. Функция входит в состав программного продукта, который постоянно обновляется, соответственно, и она должна постоянно поддерживаться, меняться, выстраиваясь в новые версии. А на это требуются ресурсы и время разработчиков. Каждая новая итерация функции должна проверяться на этапе тестирования продукта, а это ресурсы и время группы качества.
В добавок ко всему нагромождение в продукте лишних, неполезных, невостребованных на практике функций приводит к общему его захламлению и усложнению (см. статью «На пути к простоте: как сложно она дается разработчикам»).
Значит, надо стремиться разрабатывать только то, что реально будет полезно и применимо на практике большим количеством людей. Но как найти такую функцию?
Это страшное слово custdev
В решении этого вопроса мы сделали ставку на customer development. По определению custdev — это тестирование идеи или прототипа будущего продукта на потенциальных потребителях.
Этот метод предполагает, что мы сколько угодно можем генерировать идеи и гипотезы о том, какой должна быть искомая функция (основываясь на своих возможностях или фантазии – не важно), но потом их нужно будет валидировать.
Практически все разработки в области видеоанализа сегодня– это результат реализации неотвалидированных, непроверенных гипотез. Разработчики предполагают, что придуманная ими функция кому-то будет нужна. Предполагают, что она будет нести пользу, если будет сделана именно так, а не иначе. Но мировой опыт custdev показывает, что большинство гипотез оказываются неверными.
Мы начали генерировать идеи. Для этого мы штурмовали самостоятельно, спрашивали текущих и потенциальных пользователей видеосистем, чего им не хватает, вспоминали, с чем мы сталкивались и о чем слышали от участников выставок, семинаров и т.п. В итоге у нас появилось 115 гипотез. Это идеи ценности, которая может быть перенесена пользователю через модуль видеоанализа.
Так выглядела одна из наших рабочих таблиц с гипотезами для валидации
Далее гипотезы нужно было отвалидировать. Для этого мы ходили и выезжали к реальным пользователям на разные реальные объекты, на которых прямо сейчас используется система видеонаблюдения, и проводили с ними «проблемные» интервью. Мы спрашивали их о прошлом пользовательском опыте, выясняли, какая у них в течение последнего месяца была проблема, которая потенциально могла бы быть решена с помощью какого-то модуля видеоанализа. И готовы ли они купить за конкретную цену функцию для решения этой проблемы, когда она будет нами разработана.
На этом этапе мы провели 124 таких интервью и с удивлением обнаружили, что такую проверку прошли всего лишь 5 из 115 наших гипотез. Всего 4%! Это уже стало для нас очень показательным.
После того, как мы отобрали претендентов в разработку, необходимо было понять, как это делать. По каждому модулю мы составили варианты реализации, и снова пошли к тем же самым пользователям с вопросом, а то ли они хотят увидеть.
И в большинстве случаев наши предположения вновь оказались ошибочными. Удобство работы с одной и той же функцией для разработчика, который ее создает, и для пользователя, который ее эксплуатирует, выглядит абсолютно по-разному. Поэтому методом custdev мы искали не только «что», но и «как». Только несколько предположений о том, как выбранные функции должны работать, подтвердились словами пользователей.
От слов к разработке
Одну из найденных 5 идей мы реализовали осенью 2017 года. Это модуль, позволяющий контролировать соблюдение техники безопасности на производстве и стройках, — детектор отсутствия каски на голове человека.
Пользователи принимали непосредственное участие не только в выборе и форме реализации функции, но и в ее разработке. Используя подход deep learning, разработчики в процессе создания модуля обучали детектор на реальных видеороликах с реальных объектов: строек, промышленных предприятий, электростанций. Что-то нам присылали пользователи; что-то мы получали сами, выезжая на объекты; что-то снимали, когда попадались стройки или ремонтные зоны; что-то брали из свободных источников интернетовских онлайн-трансляций.
Это победа? Не так быстро…
Мы прекрасно понимаем, что функция, которая нужна пользователям, по их словам, и функция, которую они покупают и реально используют – это не всегда одно и то же. За первые 1,5 месяца продаж детектора отсутствия касок его приобрели в 5 стран, и этот результат мы оцениваем хорошо. Но в будущем надо продолжать оценивать востребованность и реальную полезность модуля: отслеживать повторные приобретения детектора у тех, кто уже начал его использовать; выяснять конкретные результаты от внедрения функции в структуру видеосистемы; отслеживать, есть ли обращения в техподдержку по работе модуля и т.п. И в случае, если на практике потребность и реальное использование модуля не подтвердится, иметь смелость попрощаться с ним. Как когда-то мы сделали с модулем интерактивного поиска (см. статью «Разработка в собственном соку или как мы поняли, что занимаемся не тем, что нужно пользователям»).
Способ разработки с применением методик customer development не является единственно верным. Но, по нашему убеждению, он позволяет сделать модули видеоанализа не инженерными разработками, а функциями, которые дают реальную пользу реальным людям.