Tómelo y hágalo: por qué a veces es útil calificar para el análisis y simplemente desarrollar

Hemos estado desarrollando Macroscop durante casi una década. Y durante este tiempo, se ha desarrollado un enfoque muy completo y serio para la creación de nuevas funciones en el desarrollo de módulos inteligentes. Por un lado, esto es muy bueno. Intento serio se acerca con un producto de alta calidad. Pero al mismo tiempo, la minuciosidad puede rozar la lentitud y la inoperancia del proceso.

Hace solo un par de años, cuando recibimos solicitudes de los usuarios para desarrollar algo nuevo (no incluido en el plan maestro para el desarrollo de productos), tuvimos un pronóstico a largo plazo, evaluando la versatilidad y relevancia de la función entre una amplia gama de usuarios. Y a menudo rechazaron o evaluaron el tiempo de implementación como muy largo. Pero una vez que recibimos una solicitud para un gran proyecto. En el caso de la implementación exitosa y rápida de las funciones de usuario faltantes, las perspectivas y la escala de la implementación de Macroscop fueron muy buenas. ¡Y empezamos a intentarlo! Teníamos un marco de tiempo ajustado, un usuario atento y servicial y una completa libertad de acción.



Y ... ¡todo salió bien!

Creamos una nueva función en poco tiempo. Además, ella era precisa y rápida. Todos estaban satisfechos: el usuario recibió el codiciado módulo intelectual, los desarrolladores obtuvieron una experiencia genial, la empresa - ventas.
Esta práctica marcó el comienzo de un nuevo enfoque para el desarrollo de funciones inteligentes en Macroscop: nos hemos vuelto cada vez más fáciles de conocer a nuestros usuarios. Y da sus resultados.

Lo más importante es identificar la necesidad real del usuario y formular la tarea claramente con él. Cuando se trata del desarrollo rápido de funciones personalizadas (las llamaremos funciones rápidas a continuación), es imprescindible especificar los requisitos: lo que el usuario quiere ver al final, en qué centrarse. Porque, condicionalmente, uno debe trabajar primero con seguridad, el otro para que se vea genial. Cuando adoptamos una función rápida, no estamos hablando del hecho de que al final funcionará en cualquier condición con una precisión del 100%. Nos comprometemos a probar la idea en sí misma y tratar de crear para empezar algo que funcione adecuadamente y sea aceptable para su uso en un objeto específico. Y solo entonces, si tiene éxito, refinamos y traemos un producto universal con buen rendimiento.

Cuando los objetivos y prioridades son claros, emprendemos el desarrollo. En poco tiempo, desarrollamos un prototipo que el usuario ya puede evaluar. Y lo damos a prueba. Si lo que hemos hecho se correlaciona con lo que el usuario necesita, y en general le gusta, y el método que utilizamos en el desarrollo aún no se ha agotado y tiene perspectivas de mejorar la función, vamos más allá. Si resultó ser completamente incorrecto y completamente incorrecto, cerramos el proyecto. Y como esto sucede en una etapa temprana, no perdemos casi nada.

Con este enfoque, los desarrolladores y usuarios deben ir lo más lejos posible el uno hacia el otro. También se requiere que el usuario sea incluido en el proceso: es necesario probar cuidadosamente el prototipo en diferentes cámaras y en diferentes condiciones, probar diferentes configuraciones y presionar diferentes botones, dar retroalimentación exhaustiva: lo que es conveniente, lo que no es conveniente, lo que no funciona de la forma en que evalúa la precisión, cuánto carga el servidor, etc.

Inicialmente, satisfacemos la necesidad de un cliente específico, pero incluso antes de comenzar a trabajar, estimamos cuán universal puede ser esta función en el futuro, a cuántas personas puede ayudar a resolver sus problemas. Y en el futuro, adaptamos la función rápida para que sea útil y aplicable en tantos sistemas de video como sea posible.

¿Recuerdas cómo empezó todo? .. (c)

La primera función rápida para nosotros fue el módulo de conteo de colas . En general, lo teníamos antes, pero las condiciones de aplicabilidad eran limitadas: el módulo funcionaba solo en una proyección, cuando la cámara miraba estrictamente de arriba a abajo. Una vez nos contactó un usuario que necesitaba contar personas en una cola bajo condiciones fundamentalmente diferentes, cuando la cámara mira la cola en diagonal (directamente y ligeramente arriba).


desde esta perspectiva, el módulo Macroscop podría contar


y en esto - aprendido

A todos les gustaba Macroscop, pero carecía de la preciada función. El proyecto fue muy prometedor, y el usuario estaba listo para cooperar con nosotros en todos los sentidos, si solo apareciera dicho módulo, y el software pudiera instalarse en el objeto. Decidimos no perder la oportunidad y comenzamos a desarrollarnos.

En la última variación del módulo, la tarea de contar personas se resolvió mediante métodos clásicos de visión por computadora, que impusieron serias restricciones a las condiciones de uso. Pero en el marco de la nueva tarea, el módulo tuvo que aprender a contar personas en condiciones fundamentalmente diferentes y mucho más difíciles.

El grupo de desarrollo de funciones intelectuales se dividió en 3 subgrupos, y cada uno comenzó a probar su propio método. Todos ellos se basaron en el uso de redes neuronales.
El primero que traté de transferir al módulo para contar personas en las filas de la infraestructura del detector de cascos que desarrollamos (vea el artículo sobre cómo tratamos de usar tecnologías modernas de redes neuronales para encontrar cascos en la cabeza de las personas ). Este enfoque parecía muy lógico: el detector de cascos en una determinada etapa de trabajo resuelve un problema similar.

El segundo grupo intentó aplicar una red neuronal de regresión . Ella cuenta el número de personas en la imagen, pero no selecciona objetos específicos, lo que dificulta su control. Cuando se entrena en una red neuronal de regresión, se envía una imagen y se indica el número de personas que están presentes, y la red neuronal proporciona un número: cuántas personas encontró. Al llenar la muestra con nuevas imágenes, buscamos entrenarla para que cuente correctamente.

Desafortunadamente, rechazamos ambos métodos, ya que la precisión del contador creado sobre su base era baja.

El tercer grupo probó un detector de uso general bastante conocido, que puede detectar una variedad de objetos en tiempo real. Él sabe cómo buscar miles de tipos de objetos diferentes, pero no resuelve nuestro problema con todas sus características. Finalizamos este detector, lo capacitamos en nuestra propia muestra extensa y creamos un resultado bastante bueno: un contador de personas con una precisión aceptable. Lo mejoraron con nuevas selecciones, y finalmente obtuvieron un prototipo, que ya no era una pena darle al usuario una prueba. Y su evaluación fue ... ¡positiva! Dijo que, en general, la solución ya es competitiva , pero la precisión aún no ha sido alta, solo 60-70%.

La primera versión del contador de cola se creó principalmente utilizando clips de este usuario. Resolvimos el problema, para trabajar específicamente con él , pero entendimos que si entrenamos la red neuronal y creamos un módulo para un proyecto específico, no podría haber más escalas. Por lo tanto, se realizó una capacitación adicional en una muestra más universal, lo que condujo a un aumento en la precisión incluso sin mejoras internas globales. Luego comenzamos a trabajar en el empaque del módulo: mejoré la interfaz, atornillé varias configuraciones, llamé la atención sobre la usabilidad y la lógica. Paralelamente, solucionamos una serie de errores en nuestro prototipo (por cierto, uno de ellos aceleró inesperadamente el módulo 7 veces), descubrimos cómo reducir el consumo de CPU, conectamos el trabajo en la tarjeta de video. Como resultado, obtuvimos un módulo objetivamente funcional y fácil de administrar que analizó rápidamente, produjo resultados precisos, sabía cómo trabajar en una tarjeta de video sin cargar el procesador.
¡Nuestro usuario estaba feliz! Fue a poner la nueva versión en sus tiendas y confirmó que en la práctica todo funciona bien. Logramos alcanzar un 85-90% de precisión (para situaciones en las que las personas en la cola no se superponen por completo, y se pueden distinguir).

Por supuesto, durante el proceso de desarrollo, no todo salió bien y, por ejemplo, entre el primer prototipo y la solución que ahora está instalada en el sitio, hubo una versión fallida que funcionó peor que la anterior. Pero por su experiencia, nos dimos cuenta de qué buscar al realizar las pruebas, aprendimos una serie de características de los marcos utilizados. Y dado esto, creamos un módulo final genial, y luego nos basamos en él, otra función rápida.

Final feliz

Ahora la aplicación del módulo para contar personas en la cola de la nueva versión se está expandiendo a otras tiendas de este usuario. Y la versión final, entró en producción y entró en la versión de Macroscop, que se está preparando para su lanzamiento. Por cierto, el usuario estaba tan satisfecho con el resultado y la forma general de trabajar que llegó otra solicitud: hacer un detector de estante vacío . Y lo tomamos nuevamente, y lo hicimos nuevamente (pero esta es una historia completamente diferente).

Para resumir, para comparar: el desarrollo y el refinamiento de la versión anterior del módulo para contar personas en la cola (hace 4 años) tomó alrededor de 8 meses . Creamos el nuevo módulo en 2 meses (el primer prototipo funcional fue entregado al usuario en 2-3 semanas).

Hasta ahora, esto es solo una prueba de la pluma y solo dentro del marco de una dirección: el desarrollo de funciones intelectuales. En general, nos adherimos a un enfoque más riguroso y exhaustivo para el desarrollo de productos, con planificación, numerosas validaciones de ideas, análisis de demanda y pruebas exhaustivas. Lo que permanece sin cambios es la práctica de crear Macroscop (ya sea el desarrollo de un núcleo o módulos de análisis de video) en estrecha colaboración con los usuarios.
No hay certeza de que el enfoque de las funciones rápidas deba aplicarse de manera continua y en todo el departamento, pero ahora estamos obteniendo una experiencia real de desarrollo rápido, y los usuarios para quienes esto se hace son beneficios reales del producto.

En cualquier caso, para nosotros, hemos creado varias reglas, cuyo cumplimiento es la mitad del éxito del desarrollo de funciones rápidas:

• Trate de conocer al usuario, pero no se olvide de sus propios objetivos: asuma proyectos que puedan escalarse, invierta en algo que sea útil a largo plazo.
• Llegue al fondo de las verdaderas tareas y necesidades del usuario, identifique las prioridades.
• Alistar soporte al usuario. Si está listo para comunicarse activamente, probar, dar retroalimentación y proporcionar los datos necesarios (video de un objeto real, por ejemplo), entonces hay todas las posibilidades de desarrollarse bien y rápidamente.
• No tenga miedo al fracaso y trátelo como uno de los posibles resultados.
• No intente desarrollar algo único desde cero, pero use la experiencia existente si es posible: en nuestro caso, intente usar partes de los algoritmos de módulos ya implementados. E incluso si la solución resultante resulta ser viable, dedique tiempo a la investigación y personalización.