Nous développons Macroscop depuis près d'une décennie. Et pendant ce temps, une approche très approfondie et sérieuse de la création de nouvelles fonctions s'est développée dans le développement de modules intelligents. D'une part, c'est très bien. L'intention sérieuse va de pair avec un produit de haute qualité. Mais en même temps, la rigueur peut frôler la lenteur et l'inopérabilité du processus.
Il y a seulement quelques années, lorsque nous avons reçu des demandes d'utilisateurs pour développer quelque chose de nouveau (non inclus dans le plan directeur pour le développement de produits), nous avions une longue prévision, évaluant la polyvalence et la pertinence de la fonction parmi un large éventail d'utilisateurs. Et souvent, ils refusaient ou évaluaient le temps de mise en œuvre comme très long. Mais une fois que nous avons reçu une demande pour un grand projet. Dans le cas d'une mise en œuvre réussie et rapide des fonctions utilisateur manquantes, les perspectives et l'ampleur de la mise en œuvre de Macroscop étaient très bonnes. Et nous avons commencé à essayer! Nous avons eu un calendrier serré, un utilisateur réactif et serviable et une totale liberté d'action.
Et ... tout a fonctionné!
Nous avons créé une nouvelle fonctionnalité en peu de temps. De plus, elle était précise et rapide. Tout le monde était satisfait: l'utilisateur a reçu le module intellectuel convoité, les développeurs ont eu une expérience cool, l'entreprise - les ventes.
Cette pratique a marqué le début d'une
nouvelle approche du développement des fonctions intelligentes en Macroscop: nous sommes devenus de plus en plus faciles à rencontrer nos utilisateurs. Et ça donne ses résultats.
Le plus important est d'identifier le vrai besoin de l'utilisateur et de formuler clairement la tâche avec lui. En ce qui concerne le développement rapide de fonctions sur mesure (nous les appellerons fonctions rapides dans ce qui suit), il est impératif de spécifier les exigences: ce que l'utilisateur veut voir au final, sur quoi se concentrer. Parce que, conditionnellement, l'un doit d'abord fonctionner à coup sûr, l'autre pour le rendre cool. Lorsque nous prenons une fonction rapide, nous ne parlons pas du fait qu'au final, cela fonctionnera dans toutes les conditions avec une précision de 100%. Nous nous
engageons à tester l'idée elle -
même et à essayer de créer pour commencer quelque chose qui fonctionne correctement et acceptable pour une utilisation sur un objet spécifique. Et alors seulement, en cas de succès, nous affinons et apportons un produit universel avec de bonnes performances.
Lorsque les objectifs et les priorités sont clairs, nous reprenons le développement. En peu de temps, nous développons un prototype que l'utilisateur peut déjà évaluer. Et nous le mettons à l'épreuve. Si ce que nous avons fait est en corrélation avec les besoins de l'utilisateur, et en général il aime, et que la méthode que nous avons utilisée dans le développement ne s'est pas encore épuisée et a des perspectives d'amélioration de la fonction, nous allons plus loin. S'il s'avérait être complètement faux et complètement faux, nous clôturons le projet. Et puisque cela se produit à un stade précoce, nous ne perdons presque rien.
Avec cette approche, les développeurs et les utilisateurs devraient
aller le plus loin possible l'un vers l'autre. L'utilisateur doit également être inclus dans le processus: il est nécessaire de tester soigneusement le prototype sur différentes caméras et dans différentes conditions, essayer différents paramètres et appuyer sur différents boutons, donner des commentaires exhaustifs: ce qui est pratique, ce qui ne convient pas, ce qui ne fonctionne pas de la manière dont il évalue la précision, combien le serveur charge, etc.
Au départ, nous répondons aux besoins d'un client spécifique, mais avant même de commencer à travailler,
nous estimons à
quel point cette fonction peut devenir
universelle à l'avenir, combien de personnes elle peut aider à résoudre leurs problèmes. Et à l'avenir, nous adapterons la fonction rapide afin qu'elle soit utile et applicable dans le plus grand nombre de systèmes vidéo possible.
Vous rappelez-vous comment tout a commencé? .. (c)
La première fonction rapide pour nous a été le
module de comptage des files d'attente . En général, nous l'avions avant, mais les conditions d'applicabilité étaient limitées: le module ne fonctionnait que dans une seule projection, lorsque la caméra regardait strictement de haut en bas. Une fois, nous avons été approchés par un utilisateur qui avait besoin de compter les personnes dans une file d'attente dans des conditions fondamentalement différentes - lorsque la caméra regarde la file d'attente en diagonale (directement et légèrement au-dessus).
de ce point de vue, le module Macroscop pourrait compter
et en cela - apprisIl aimait tous Macroscop, mais n'avait pas la fonction chérie. Le projet était très prometteur, et l'utilisateur était prêt à
coopérer avec nous de toutes les manières, si seulement un tel module apparaissait, et le logiciel pouvait être installé sur l'objet. Nous avons décidé de ne pas rater l'occasion et avons commencé à nous développer.
Dans la dernière variante du module, la tâche de compter les personnes a été résolue par des méthodes classiques de vision par ordinateur, qui ont imposé de sérieuses restrictions sur les conditions d'utilisation. Mais dans le cadre de la nouvelle tâche, le module a dû apprendre à compter des personnes dans des conditions fondamentalement différentes, beaucoup plus difficiles.
Le groupe de développement des fonctions intellectuelles a été divisé en 3 sous-groupes, et chacun a commencé à essayer sa propre méthode. Tous étaient basés sur l'utilisation de réseaux de neurones.
Le premier que j'ai essayé de transférer dans le module de comptage des personnes dans les files d'attente à l'infrastructure du
détecteur que nous avons développé pour
manquer de casques (voir l'
article sur la façon dont nous avons essayé d'utiliser les technologies de réseaux neuronaux modernes pour trouver des casques sur la tête des gens ). Cette approche semblait très logique: le détecteur de casques à un certain stade de travail résout un problème similaire.
Le deuxième groupe a tenté d'appliquer un
réseau neuronal de régression . Elle compte le nombre de personnes dans l'image, mais ne sélectionne pas d'objets spécifiques, ce qui la rend difficile à contrôler. Lors de la formation sur un réseau de neurones de régression, une image est soumise et le nombre de personnes présentes est indiqué, et le réseau de neurones donne un numéro - combien de personnes il a trouvé. En remplissant l'échantillon avec de nouvelles images, nous avons cherché à le former à compter correctement.
Malheureusement, nous avons rejeté les deux méthodes, car la précision du compteur créé sur leur base était faible.
Le troisième groupe a testé un
détecteur à usage général assez bien connu, qui peut détecter une variété d'objets en temps réel. Il sait comment rechercher mille sortes d'objets différents, mais pas résoudre notre problème avec toutes ses fonctionnalités. Nous avons finalisé ce détecteur, l'avons formé sur notre propre échantillon étendu et avons créé un assez bon résultat - un compteur de personnes avec une précision acceptable. Ils l'ont amélioré avec de nouvelles sélections et ont finalement obtenu un prototype, ce qui n'était déjà pas dommage de donner à l'utilisateur un test. Et son évaluation était ... positive! Il a dit qu'en général, la
solution est déjà compétitive , mais la précision n'est pas encore élevée - seulement 60-70%.
La première version du compteur de files d'attente a été créée principalement à l'aide de clips de cet utilisateur. Nous avons résolu le problème - pour
travailler spécifiquement avec lui - mais nous avons compris que si nous formions le réseau neuronal et réalisions un module pour un projet spécifique, il ne pourrait plus y avoir de mise à l'échelle. Par conséquent, une formation supplémentaire a été menée sur un échantillon plus universel, ce qui a conduit à une augmentation de la précision même sans améliorations internes globales. Ensuite, nous avons commencé à travailler sur l'emballage du module - amélioré l'interface, bousillé divers paramètres, attiré l'attention sur la convivialité et la logique. En parallèle, nous avons corrigé un certain nombre de bugs dans notre prototype (en passant, l'un d'eux a accéléré le module de façon inattendue de 7 fois), trouvé un moyen de réduire la consommation CPU, connecté le travail sur la carte vidéo. En conséquence, nous avons obtenu un module objectivement fonctionnel et facile à gérer qui analysait rapidement, produisait des résultats précis, savait comment travailler sur une carte vidéo sans charger le processeur.
Notre utilisateur était tout simplement heureux! Il est allé mettre la nouvelle version dans ses magasins et a confirmé qu'en pratique tout fonctionnait bien. Nous avons réussi à atteindre une précision de 85 à 90% (pour les situations où les personnes dans la file d'attente ne se chevauchent pas complètement et peuvent être distinguées).
Bien sûr, au cours du processus de développement, tout ne s'est pas bien passé, et, par exemple, entre le premier prototype et la solution qui est maintenant installée sur le site, il y avait une version défaillante qui fonctionnait moins bien que la précédente. Mais d'après son expérience, nous avons réalisé ce qu'il fallait rechercher lors des tests, appris un certain nombre de fonctionnalités des frameworks utilisés. Et étant donné cela, nous avons créé un module final cool, puis basé sur lui - une autre fonction rapide.
Fin heureuse
Maintenant, l'application du module de comptage de personnes dans la file d'attente de la nouvelle version s'étend à d'autres magasins de cet utilisateur. Et la version finale - est entrée en production et est entrée dans la version de Macroscop, qui est en cours de préparation pour la sortie. Soit dit en passant, l'utilisateur était tellement satisfait du résultat et de la manière globale de travailler qu'une autre demande est arrivée - faire
un détecteur d'étagère vide . Et nous l'avons repris, et l'avons refait (mais c'est une histoire complètement différente).
Si pour résumer, alors à titre de comparaison: le développement et le raffinement de l'ancienne version du module de comptage des personnes en file d'attente (il y a 4 ans) a pris environ
8 mois . Nous avons fabriqué le nouveau module en
2 mois (le premier prototype fonctionnel a été remis à l'utilisateur en 2-3 semaines).
Jusqu'à présent, ce n'est qu'un test de la plume et uniquement dans le cadre d'une direction - le développement des fonctions intellectuelles. En général, nous adhérons à une approche plus rigoureuse et approfondie du développement de produits - avec planification, nombreuses validations d'idées, analyse de la demande et tests approfondis. Ce qui reste inchangé, c'est la pratique de créer Macroscop (qu'il s'agisse du développement d'un noyau ou de modules d'analyse vidéo) en étroite collaboration avec les utilisateurs.
Il n'y a aucune certitude que l'approche des fonctions rapides doit être appliquée de manière continue et au sein de l'ensemble du département, mais maintenant nous acquérons une réelle expérience de développement rapide, et les utilisateurs pour qui cela est fait sont de réels avantages du produit.
En tout cas, pour nous-mêmes, nous avons élaboré plusieurs règles dont le respect représente la moitié du succès du développement de fonctions rapides:
- Essayez de rencontrer l'utilisateur, mais n'oubliez pas vos propres objectifs: entreprendre des projets évolutifs, investir dans quelque chose qui sera utile à long terme.
- Aller au fond des vraies tâches et besoins de l'utilisateur, identifier les priorités.
- Demandez l'assistance des utilisateurs. S'il est prêt à communiquer activement, à tester, à donner son avis et à fournir les données nécessaires (vidéo à partir d'un objet réel, par exemple), alors il y a toutes les chances de bien se développer et rapidement.
- N'ayez pas peur de l'échec et considérez-le comme l'un des résultats possibles.
- N'essayez pas de développer quelque chose d'unique à partir de zéro, mais utilisez si possible l'expérience existante: dans notre cas, essayez d'utiliser des parties des algorithmes à partir de modules déjà implémentés. Et même si la solution résultante s'avère viable - consacrez du temps à la recherche et à la personnalisation.