🥇Comment nous travaillons avec les idées et comment LANBIX est né

Chez « ЛАНИТ-Интеграции », nous avons de nombreux employés créatifs. Les idées de nouveaux produits et projets flottent littéralement dans l'air. Les identifier parmi les plus intéressantes peut parfois être très difficile. C'est pourquoi nous avons développé ensemble notre propre méthodologie. Découvrez comment sélectionner les meilleurs projets et les réaliser dans cet article.

En Russie, ainsi que dans le monde en général, plusieurs processus se déroulent qui conduisent à la transformation du marché IT. Grâce à une augmentation des capacités de calcul et à l'émergence des technologies de virtualisation serveur, réseau et autres, le marché n'a plus besoin de tant de « matériel ». Les fournisseurs préfèrent de plus en plus travailler directement avec les clients. Le marché IT voit l'épanouissement de l'externalisation sous toutes ses formes, allant de l'externalisation classique aux nouvelles vagues de prestataires : les « fournisseurs de cloud ». Les systèmes d'infrastructure et leurs éléments deviennent beaucoup plus simples à entretenir et à configurer. La qualité logicielle s'améliore chaque année, entraînant une transformation des tâches des intégrateurs.

Comment nous travaillons avec les idées

La direction des startups produits chez « ЛАНИТ-Интеграции » existe depuis plus d'un an. Notre objectif principal est la création de nouveaux produits et leur mise sur le marché. La première étape que nous avons entreprise a été d'organiser le processus de création de produits. Nous avons étudié de nombreuses méthodologies, allant des classiques aux tendances actuelles. Cependant, aucune d'entre elles ne répondait à nos attentes. Nous avons donc décidé de prendre comme base la méthodologie Lean Startup et de l'adapter à nos besoins. Le « Lean Startup » est une théorie de l'entrepreneuriat créée par Eric Ries, fondée sur les principes, approches et pratiques de concepts tels que la production lean, le développement client et la méthodologie agile.

En ce qui concerne l'approche de gestion du développement produit : nous n'avons pas réinventé la roue, mais avons appliqué une méthodologie de développement existante. SCRUM, en ajoutant une touche créative, on peut maintenant l'appeler le SCRUM-WATERFALL-BAN. SCRUM, malgré sa flexibilité, est un système assez rigide et convient à la gestion d'une équipe responsable d'un seul produit/projet. Comme vous pouvez le comprendre, le business « intégrateur » classique ne prévoit pas de consacrer des spécialistes techniques à plein temps à un seul projet (des exceptions existent, mais elles sont extrêmement rares), car en plus de travailler sur les produits, tout le monde est occupé sur des projets en cours. Nous avons adopté de SCRUM la division du travail en sprints, les comptes rendus quotidiens, les rétrospectives et les rôles. Pour gérer le flux de tâches, nous avons choisi Kanban, qui s'est parfaitement intégré à notre système de suivi des tâches existant. Nous avons structuré notre travail en nous intégrant progressivement à l'ordre des choses existant.
Avant d'entrer sur le marché, un produit passe par 5 étapes : idée, sélection, conception, MVP (voir ci-dessous) et production.

Idée

À ce stade, il y a quelque chose d'éphémère : l'idée. Idéalement, c'est l'idée de résoudre un problème ou une tâche existante du client. Nous manquons certainement pas d'idées. Dans l'idée initiale, elles devraient être générées par les employés des départements techniques. Pour que l'idée soit acceptée pour un développement ultérieur, l'auteur doit remplir le « Modèle de présentation de l'idée ». Il y a seulement quatre questions : Quoi ? Pour quoi ? À qui cela sert-il ? Et si ce n'est pas notre produit, que devrait-il être ?

Source

Sélection

Une fois que le modèle rempli nous parvient, le processus de traitement et de sélection commence. L'étape de sélection est la plus laborieuse. À ce stade, des hypothèses sur les problèmes se forment (je n'ai pas mentionné par hasard dans le paragraphe précédent que l'idée devrait idéalement résoudre le problème du client) et la valeur du produit. Une hypothèse d'échelle est formée, c'est-à-dire comment notre entreprise prévoit de croître et de prospérer. Des entretiens de problématique et d'expertise sont menés avec des clients potentiels pour confirmer préliminairement que nous allons produire quelque chose d'utile. Il faut réaliser au moins 10 à 15 entretiens pour tirer des conclusions sur l'utilité du produit.

Si les hypothèses sont confirmées, une analyse financière préliminaire est effectuée, évaluant le montant approximatif des investissements et le potentiel de profit pour l'investisseur. À l'issue de cette étape, un document intitulé Lean Canvas est créé et présenté à la direction.

Concept

À ce stade, environ 70 % des idées sont écartées. Si le concept est approuvé, la phase de développement de l'idée commence. Les capacités fonctionnelles du futur produit sont formulées, les voies de mise en œuvre et les solutions techniques optimales sont déterminées, et le plan d'affaires est actualisé. Le résultat de cette étape est un cahier des charges pour le développement et un business case détaillé. En cas de succès, nous passons à l'étape MVP.

MVP

Le MVP est un produit minimum viable. C’est-à-dire un produit qui n'est pas complètement terminé, mais qui peut déjà apporter de la valeur et remplir sa fonction. À cette étape du développement, nous recueillons des retours d'utilisateurs réels et apportons des modifications.

Production

Et la toute dernière étape est la production. À ce stade, seuls 5 % des produits parviennent à cette étape. Ces 5 % regroupent uniquement les produits les plus importants, nécessaires, viables et fonctionnels.

Nous avons de nombreuses idées, et un portefeuille conséquent est déjà constitué. Nous examinons chaque idée et faisons tout pour qu'elle atteigne la phase finale. Il est très agréable de voir que nos collègues ont réagi avec intérêt à notre direction R&D et participent activement au développement, à la mise en œuvre des produits et des solutions.

Comment nous avons développé LANBIX

Examinons la création du produit à travers un exemple réel - le produit LANBIX. Il s'agit d'un complexe logiciel et matériel « prêt à l'emploi », destiné à surveiller de petites infrastructures informatiques et à alerter rapidement les personnes responsables et les utilisateurs métier des pannes via un chatbot. En plus de la fonction de surveillance, LANBIX comprend des fonctionnalités d'assistance technique. Ce produit est exclusif pour le segment de marché que nous visons. C'est à la fois notre avantage et notre douleur. Mais parlons de tout cela dans l'ordre. Je dirai tout de suite que LANBIX est un produit vivant (c'est-à-dire qu'il n'est pas définitif dans son développement et est en cours de version MVP).

Ainsi, la première étape est l'idée. Pour qu'une idée naisse, il faut des problèmes, et nous en avions, en fait, pas nous, mais nos connaissances. Examinons ci-dessous quelques situations réelles survenues dans différentes sphères d'activité.

Une petite société de gestion s'occupe de deux immeubles dans la région de Moscou. L'équipe, qui utilise des ordinateurs, compte environ 15 personnes. L'administrateur système est un freelance à temps partiel (le fils astucieux d'un résident concerné). Il semblerait que l'activité de la société de gestion dépende peu des technologies de l'information, mais une particularité de ce secteur est le rapport mensuel à transmettre à de nombreuses instances. L'espace libre sur le disque dur du directeur de l'entreprise (qui cumule généralement plusieurs rôles) était épuisé. Naturellement, cela ne s'est pas produit soudainement ; un avertissement pendant environ 2 mois a constamment été ignoré. Mais une mise à jour est arrivée, le système d'exploitation a été mis à jour et, avec malchance, s'est bloqué en milieu de processus, se plaignant devant la 'mort' d'un disque occupé. L'ordinateur est tombé en boucle de redémarrage. Pendant que nous résolvions le problème et récupérions les rapports, nous avons manqué la date limite de soumission. Il semblerait qu'une petite panne a causé divers désagréments : des pertes financières aux litiges juridiques et à la responsabilité administrative.

Source

Un cas similaire s'est produit dans un grand groupe rassemblant de nombreuses petites entreprises, avec un service d'assistance technique unique pour tout le bureau. Dans l'un des départements, l'ordinateur du comptable en chef est tombé en panne. Nous savions déjà qu'il allait tomber en panne (l'ordinateur était désespérément lent et surchauffait), mais le comptable n'a jamais eu le temps d'envoyer une demande au support technique. Naturellement, la panne est survenue précisément le jour du salaire, et les employés du département ont passé plusieurs jours sans argent.

Une petite entreprise de vente en gros a subi une panne de son site de vente, hébergé sur une plateforme externe. Ils ont pris connaissance de l'indisponibilité par téléphone d'un client régulier. Au moment de l'appel, le site était hors service depuis environ trois heures. La recherche de la personne en charge du site a pris encore quelques heures, et la résolution de la panne encore deux. En conséquence, le site a été inaccessible presque toute la journée de travail. Selon le directeur commercial de l'entreprise, ce temps d'arrêt leur a coûté environ 1 million de roubles.

J'ai moi-même été confronté à une situation similaire lorsque je me suis présenté à la clinique et que je devais me rendre à l'accueil de l'Assurance Maladie. Le médecin n'a pas pu m'envoyer pour une raison banale : le matin, il y a eu une coupure de courant, et après cet incident, leur service de messagerie et un certain service de communication avec l'assurance ne fonctionnaient plus. À ma question sur l'emplacement de leurs administrateurs, on m'a dit qu'ils n'avaient qu'un administrateur à mi-temps qui venait une fois par semaine. Et à ce moment-là (il était déjà 16h), il ne répondait pas au téléphone. Au minimum, la clinique a été coupée du monde extérieur pendant 7 heures et n'a pas pu fournir de services payants.

Qu'est-ce qui relie tous ces cas ? Absolument tous les problèmes auraient pu être évités à l'avance. Avec une réaction rapide de la part des personnes en charge de l'IT, il aurait été possible de réduire les dommages causés. Cela aurait également été feasible avec une interprétation correcte des premiers symptômes par les utilisateurs.

Nous avons identifié les hypothèses de problèmes :

pertes financières et réputationnelles significatives dues à une faible vitesse de réaction aux pannes dans l'infrastructure informatique ;
mauvaise interprétation des premiers symptômes de panne par les utilisateurs.

Que peut faire le client à ce sujet, et comment éviter des situations similaires à l'avenir ? Les options ne sont pas nombreuses :

embaucher un administrateur système hautement qualifié en permanence et s'assurer qu'il travaille consciencieusement ;
confier la gestion de l'informatique à une entreprise de services spécialisée ;
implémenter soi-même un système de surveillance et de notification des pannes ;
former les utilisateurs/le personnel administratif aux bases de l'informatique.

Nous allons nous concentrer sur la troisième option. Proposons un système de surveillance à ceux qui ne l'utilisent pas pour diverses raisons.

Une digression lyrique. Divers systèmes de surveillance des services informatiques sont utilisés depuis longtemps sur le marché des entreprises, et leur utilité ne fait pas débat. J'ai discuté avec des représentants de grandes entreprises, observé comment les relations entre les affaires et l'informatique sont établies. Le directeur technique d'une grande entreprise de mécanique a externalisé la gestion de l'infrastructure informatique à une société tierce, mais reste lui-même informé de tous les aspects. Il a un grand écran de surveillance affichant des indicateurs de l'état des services informatiques dans son bureau. Les systèmes critiques y sont enregistrés. À tout moment, le directeur technique peut savoir dans quel état se trouve l'infrastructure, ce qui se passe, où se situe le problème, si les personnes responsables ont été avisées et si le problème est en cours de résolution.

Ces histoires ont amené notre équipe à réfléchir à la manière de créer un système de surveillance optimal pour les petites entreprises. Cela a donné naissance à LANBIX — un système de surveillance que n'importe qui peut déployer sans connaissances en informatique. L'objectif principal du système est simple, comme c'est le cas pour tous les systèmes visant à améliorer la continuité et la disponibilité : réduire les pertes financières et autres en cas de pannes imprévues. L'appareil est conçu pour minimiser le temps entre « j'ai un problème » et « le problème est résolu ».

Pour confirmer nos hypothèses, des entretiens problématiques ont été conduits. Je ne pouvais pas imaginer combien de choses les gens étaient prêts à partager si on ne leur vendait rien. Chaque conversation durait au moins 1,5 heure, et nous avons recueilli une multitude d'informations utiles pour le développement futur.

Résumons le résultat de cette étape :

la compréhension du problème — est là,
la compréhension de la valeur — est là,
une idée de solution — est là.

La deuxième étape était plus détaillée. Sur la base de ses résultats, nous devions présenter à la direction, qui joue essentiellement le rôle d'investisseur, un business case (le fameux Lean Canvas) pour prendre une décision sur l'avenir du produit.

Nous avons commencé par une étude de marché et une analyse concurrentielle afin de déterminer qui, quoi et, surtout, comment cela se fait sur ce marché.

Les découvertes suivantes sont apparues.

Sur le marché, il n'existe pas de systèmes de surveillance box prêts à l'emploi pour notre segment (petites entreprises), à l'exception de quelques-uns dont je ne parlerai pas pour des raisons évidentes.
Nos principaux concurrents, étrangement, sont des administrateurs système avec des scripts personnalisés et des « améliorations » à des systèmes de surveillance open source.
Il y a un problème manifeste avec l'utilisation de systèmes de surveillance open source. Il existe un système, une énorme quantité d'informations sur le fonctionnement et l'adaptation du système à ses besoins. Parmi les administrateurs que j'ai interrogés, beaucoup ont avoué manquer de compétences pour réaliser leurs idées par eux-mêmes. Mais ils ne peuvent pas en parler à leur direction de peur d'être licenciés. Cela crée un cercle vicieux.

Nous avons ensuite procédé à l'analyse des besoins de nos clients potentiels. Nous avons identifié un segment de petites organisations, pour une raison quelconque sans service informatique interne, où l'informatique est gérée soit par un administrateur système externe, soit par un freelance, soit par une entreprise de services. Nous avons décidé d'approcher le problème non du côté informatique, mais du côté des affaires, en offrant aux fondateurs et aux propriétaires d'entreprise un outil pour améliorer la qualité de la gestion de l'infrastructure informatique. Un produit qui doit aider les propriétaires à sécuriser leur entreprise, mais qui, en même temps, ajoutera du travail aux personnes responsables de l'informatique. Un produit fournissant aux entreprises un outil de contrôle de la qualité de l'accompagnement informatique.

À la suite du traitement des données recueillies, une première liste de exigences (un certain backlog brut) pour le futur produit est née :

le système de surveillance devrait être basé sur une solution open source et, par conséquent, peu coûteuse ;
simple et rapide à installer ;
ne devrait pas exiger de connaissances spécifiques en informatique, même un comptable (je ne voudrais en aucun cas offenser les représentants de cette profession) devrait être en mesure de déployer et de configurer le système ;
devrait détecter automatiquement les objets à surveiller sur le réseau ;
devrait installer automatiquement (idéalement automatiquement) les agents de surveillance ;
devrait avoir la capacité de surveiller des services externes, au minimum un système CRM et un site de vente ;
devrait notifier à la fois l'entreprise et l'administrateur système en cas de problème ;
le degré de profondeur et le « langage » des notifications doivent varier pour l'administrateur et l'entreprise ;
le système doit être fourni sur du matériel dédié ;
le matériel doit être le plus accessible possible ;
Le système doit être aussi indépendant que possible des facteurs externes.

Ensuite, les investissements pour le développement du produit ont été calculés (y compris le temps de travail du personnel du département technique). Un esquisse du modèle commercial a été préparée et l'économie unitaire du produit a été évaluée.

Résultat de l'étape :

un backlog produit de haut niveau ;
un modèle commercial formulé ou une hypothèse de mise à l'échelle, qui devra encore être vérifiée en pratique.

Passons à la prochaine étape — la conception. Ici, nous, en tant qu'ingénieurs, entrons dans notre domaine de compétence. Il y a des « désirs » qui se décomposent en composants/sous-systèmes/fonctionnalités, puis ils se transforment en cahiers des charges/histoires utilisateurs, puis en projet, etc. Je ne vais pas m'attarder sur le processus de préparation d'un ensemble de variantes alternatives, passons directement aux exigences et aux méthodes choisies pour leur mise en œuvre.

Exigence
Solution

Cela doit être un système de surveillance ouvert ;

Prenons un système de surveillance à code source ouvert.

Le système doit être simple et rapide à installer ;
il ne doit pas nécessiter de connaissances spécifiques en informatique. Même un comptable devrait être capable de déployer et de configurer le système.

Nous proposons un système pré-installé, de sorte que l'utilisateur n'ait qu'à allumer l'appareil et à le configurer légèrement, comme pour un routeur.

Rendez l'interaction avec l'appareil simple et compréhensible pour tous.

Nous développerons notre propre chatbot pour l'une des messageries connues et gérerons toute l'interaction avec le système à travers lui.

Le système doit :

détecter automatiquement les objets à surveiller sur le réseau ;
installer automatiquement les agents de surveillance ;
Avoir la possibilité de surveiller des services externes, au minimum un système CRM et un site de vente.

Nous écrivons des compléments pour le système de surveillance sur :

la détection automatique des objets ;
l'installation automatique des agents ;
la surveillance de la disponibilité des services externes.

Le système doit :

alerter à propos des pannes tant pour l'entreprise que pour l'administrateur système ;
avoir la possibilité de surveiller des services externes, au minimum un système CRM et un site de vente. Le degré de profondeur et le « langage » des alertes doivent être différents pour l'administrateur et l'entreprise.
Le système ne doit pas nécessiter de connaissances spécifiques en informatique, même un comptable devrait être capable de déployer et de configurer le système.

Ajoutons différents types de notifications pour différents types d'utilisateurs. Elles varient selon la présentation et la profondeur. L'utilisateur professionnel recevra des notifications du type « tout va bien, mais l'ordinateur d'Ivanov va bientôt tomber en panne ». L'administrateur recevra un message d'erreur complet, indiquant qui, comment et ce qui s'est passé ou pourrait se produire.
Ajoutons la possibilité d'utiliser l'email d'une personne responsable supplémentaire, afin qu'en cas de panne, il reçoive une notification.
Ajoutons l'interaction avec des fournisseurs de services externes en envoyant un email avec un texte pré-rédigé, car c'est cet email qui constitue la base pour la création d'un incident.
Toutes les interactions avec le système seront centralisées autour d'un chatbot, la communication se fera dans un style dialogique.

La vulnérabilité a été confirmée dans de nombreuses images officielles Docker, y compris les images couchbase, elasticsearch, flink, solr, storm, etc.

Ajoutons la fonctionnalité « chat avec l'administrateur », permettant à l'utilisateur d'envoyer un message décrivant le problème directement à l'administrateur.

Le système doit être fourni sur du matériel propre.
Le matériel doit être accessible.
Le système doit être aussi indépendant que possible de l'environnement.

Prenons un ordinateur Raspberry PI, prêt à l'emploi et peu coûteux.
Concevons une carte de fourniture d'énergie sans interruption.
Ajoutons un modem pour l'indépendance de l'état du réseau local.
Concevons un boîtier élégant.

Nous avons trois sous-systèmes avec leurs propres exigences et visions de mise en œuvre :

sous-système matériel;
sous-système de surveillance;
sous-système d'interaction utilisateur.

Pour le sous-système matériel, nous avons élaboré un projet préliminaire. Oui, oui ! En enfreignant toutes les règles de l'agilité, nous avons rédigé un document, car les usines travaillent précisément avec des documents. Pour les deux autres sous-systèmes, nous avons identifié des utilisateurs (personas), préparé des histoires utilisateurs et rédigé des tâches de développement.

À ce stade, la phase de conception se termine, et ses résultats sont :

un projet sur la plateforme matérielle;
une vision formulée sous forme d'histoires utilisateurs pour les deux autres sous-systèmes;
un prototype de la partie logicielle, réalisé sous forme de machine virtuelle;
un prototype de la partie matérielle, réalisé sous forme de banc d'essai, où les solutions matérielles ont été testées pour leur robustesse;
des tests effectués par nos administrateurs.

Les problèmes à ce stade étaient essentiellement organisationnels et liés au manque de compétences des ingénieurs dans les aspects juridiques et comptables des ventes. C'est-à-dire qu'il ne suffit pas de concevoir ce qui et comment vendre, mais de se confronter à une machine juridique impitoyable : brevets, cahiers des charges, mise en balance, EULA et bien d'autres choses que nous, en tant que personnes créatives, n'avions pas envisagées au départ.

Ce n'était pas encore un problème, mais plutôt une difficulté liée à la conception des boîtiers. Dans notre équipe, nous n'avons que des ingénieurs, donc notre spécialiste en électronique a « façonné » le premier prototype du boîtier à partir de plexiglas.

Le boîtier avait, pour le dire poliment, un design controversé, surtout pour un public habitué à la technologie moderne. Bien sûr, il y avait des amateurs parmi les « bricoleurs » plus âgés - le boîtier leur évoquait des sentiments nostalgiques. Il a été décidé de fabriquer et de concevoir un nouveau boîtier, car l'ancien avait non seulement des défauts esthétiques mais aussi des défauts structurels - le plexiglas supportait mal le montage et le démontage de l'appareil et avait tendance à se fissurer. Je parlerai de la production du boîtier plus tard.

Et nous arrivons maintenant à la ligne d'arrivée - MVP. Bien sûr, ce n'est pas encore le produit final en série, mais il apporte déjà de la valeur et est utile. L'objectif principal de cette étape est de lancer le cycle « créer-évaluer-apprendre ». C'est exactement à ce stade que se trouve LANBIX.

À l'étape « créer », nous avons développé un appareil qui remplit les fonctions annoncées. Oui, il n'est pas encore parfait et nous avons continué à travailler dessus.

Revenons à la fabrication du boîtier, c'est-à-dire à la tâche de transformer notre appareil d'un objet évoquant des souvenirs nostalgiques en quelque chose de moderne. Au début, j'ai parcouru le marché à la recherche de fabricants de boîtiers et de services de design industriel. Tout d'abord, il n'y a pas beaucoup d'entreprises fabriquant des boîtiers sur le marché russe, et ensuite, le coût du design industriel à ce stade est démesuré, environ 1 million de roubles.

Nous avons fait appel à notre département marketing pour le design, un jeune designer était prêt pour des expérimentations créatives. Nous avons exposé notre vision du boîtier (après avoir étudié les meilleurs exemples de conception de boîtiers), et lui, à son tour, l’a transformé en une œuvre d'art. Il ne restait plus qu'à le produire. Fiers de notre design, nous nous sommes tournés vers nos partenaires. Leurs directeurs généraux ont instantanément détruit nos fantasmes en soulignant, sans frais, des éléments impossibles à produire de la manière que nous avions choisie. Le boîtier peut être fabriqué, et il ne sera pas moins beau que celui d'Apple, mais son coût sera trois à quatre fois supérieur à celui de toute l'électronique. Après une série d'opérations et d'approbations, nous avons conçu un boîtier qui peut être produit. Oui, il n'est plus aussi beau que nous l'avions prévu, mais il est idéal pour atteindre les objectifs actuels.

Résultat de la phase : premier lot d'appareils, prêts pour le combat et les tests.

Et maintenant, la partie la plus difficile — la phase d'évaluation, et avec notre produit, nous sommes précisément à ce stade. Nous ne pouvons évaluer que sur la base des résultats d'utilisation par de vrais clients, et aucune supposition ici ne fonctionne. Nous avons besoin de ces « premiers suiveurs » pour fournir des retours et apporter les modifications nécessaires au produit. La question se pose : comment trouver des clients et comment les convaincre de participer à l'expérience ?

Parmi toutes les options possibles, nous avons choisi un ensemble classique d'outils numériques : une landing page et une campagne publicitaire sur les réseaux sociaux.

Le processus est déjà en cours, mais il est encore trop tôt pour parler des résultats, bien que des retours aient déjà été reçus et que nous avons obtenu la confirmation de nombreuses hypothèses. La réaction de représentants de segments d'affaires complètement différents, bien plus importants que ceux sur lesquels nous comptions, a été une agréable surprise. Il serait stupide d'ignorer ces nouvelles données, et suite aux entretiens menés, la décision a été prise de lancer une gamme parallèle LANBIX sous le nom de LANBIX Enterprise. Nous avons ajouté le support des infrastructures distribuées, le suivi des réseaux Wi-Fi avec recherche et localisation des pannes, et le suivi de la qualité des canaux de communication. Les sociétés de services ont exprimé le plus grand intérêt pour la solution. Par ailleurs, les appareils que nous avons déjà développés jouent un rôle non négligeable dans le cadre de ces solutions.

Que va-t-il se passer ensuite

Ce qui va se passer ensuite avec LANBIX sera déterminé par les résultats de la campagne. Si nos hypothèses ne se confirment pas, conformément à la méthodologie Lean, nous nous en débarrasserons sans hésitation ou il se transformera en quelque chose de nouveau, car il n'y a rien de pire que de créer un produit dont personne n'a besoin. Mais dès maintenant, il est possible de dire que le travail accompli n'a pas été vain et qu'il a donné naissance à toute une gamme de produits parallèles, sur lesquels nous travaillons activement. En cas de succès, LANBIX passera de l'état MVP à l'état final et se développera selon des lois classiques de marketing produit.

Je répète, nous souhaitons actuellement trouver des premiers adeptes, des entreprises avec lesquelles nous pouvons installer notre produit dans le but de recueillir des retours. Si vous êtes intéressé par le test de LANBIX, écrivez dans les commentaires ou en messages personnels.

Source

Source : habr.com