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

Il y a de nombreux employés créatifs chez LANIT-Integration. Les idées de nouveaux produits et projets flottent littéralement dans l’air. Il peut parfois être très difficile d’identifier les plus intéressants. C’est pourquoi nous avons développé ensemble notre propre méthodologie. Lisez cet article pour savoir comment sélectionner les meilleurs projets et les mettre en œuvre.

En Russie et dans le monde dans son ensemble, un certain nombre de processus sont en cours qui conduisent à la transformation du marché informatique. Grâce à l’augmentation de la puissance de calcul et à l’émergence des technologies de serveurs, de réseaux et autres technologies de virtualisation, le marché n’a plus besoin d’une grande quantité de matériel. Les vendeurs préfèrent de plus en plus travailler directement avec les clients. Le marché informatique connaît un boom de l’externalisation sous toutes ses formes, de l’externalisation classique à la nouvelle vague d’infogérants – les « fournisseurs de cloud ». Les systèmes et éléments d’infrastructure deviennent beaucoup plus faciles à maintenir et à configurer. La qualité des logiciels augmente chaque année et les tâches de l'intégrateur se transforment.

Comment nous travaillons avec des idées

Direction de démarrage du produit dans "Intégrations LANIT" existe depuis plus d'un an. Notre objectif principal est de créer de nouveaux produits et de les mettre sur le marché. La première chose que nous avons commencée a été d'organiser le processus de création de produits. Nous avons étudié de nombreuses méthodologies, du classique au battage médiatique. Cependant, aucun d’entre eux ne répondait à nos besoins. Nous avons ensuite décidé de nous baser sur la méthodologie Lean Startup et de l'adapter à nos tâches. Le Lean Startup est une théorie de l'entrepreneuriat créée par Eric Ries. Il est basé sur les principes, les approches et les pratiques de concepts tels que la production allégée, le développement client et la méthodologie de développement flexible.

Quant à l'approche directe de la gestion du développement de produits : nous n'avons pas réinventé la roue, mais appliqué une méthodologie de développement déjà existante SCRUM, ajoutant de la créativité, et maintenant il peut être appelé en toute sécurité SCRUM-WATERFALL-BAN. SCRUM, malgré sa flexibilité, est un système très rigide et convient à la gestion d'une équipe responsable d'un seul produit/projet. Comme vous le comprenez, le métier « d'intégration » classique n'implique pas l'affectation de spécialistes techniques à temps plein pour travailler sur un projet (il y a des exceptions, mais extrêmement rarement), puisqu'en plus de travailler sur les produits, tout le monde est occupé par des projets en cours. De SCRUM, nous avons repris la division du travail en sprints, rapports quotidiens, rétrospectives et rôles. Nous avons choisi Kanban pour notre flux de tâches et il s'est bien intégré à notre système de suivi des tâches existant. Nous avons structuré notre travail en nous intégrant parfaitement à l’ordre des choses existant.
Avant d’entrer sur le marché, un produit passe par 5 étapes : idée, sélection, concept, MVP (plus de détails ci-dessous) et production.

Idée

A ce stade, il y a quelque chose d’éphémère : une idée. Idéalement, une idée pour résoudre un problème existant ou un problème client. Nous ne manquons pas d'idées. Selon le plan initial, ils devraient être générés par les employés des domaines techniques. Pour qu'une idée soit acceptée pour un développement ultérieur, l'auteur doit remplir le « Modèle de conception d'idée ». Il n'y a que quatre questions : Quoi ? Pour quoi? Qui a besoin de ça ? Et si ce n’est pas notre produit, alors quoi ?

Source

Sélection

Dès que le modèle complété nous parvient, la procédure de traitement et de sélection commence. L'étape de sélection est la plus laborieuse. A ce stade, se forment des hypothèses de problèmes (ce n'est pas pour rien que j'ai évoqué dans le paragraphe précédent qu'idéalement une idée devrait résoudre le problème d'un client) et de la valeur du produit. Une hypothèse d'échelle est formée, c'est-à-dire comment notre entreprise va croître et prospérer. Des entretiens de problèmes et d'experts sont menés avec des clients potentiels pour fournir une confirmation préliminaire que nous allons produire quelque chose dont nous avons besoin. Il faut au moins 10 à 15 entretiens pour tirer une conclusion sur la nécessité du produit.

Si les hypothèses se confirment, une analyse financière préliminaire est réalisée, le volume approximatif de l’investissement et les gains possibles de l’investisseur sont évalués. À l’issue de cette étape, un document appelé Lean Canvas est né et présenté à la direction.

Concept

A ce stade, environ 70 % des idées sont éliminées. Si le concept est approuvé, la phase de développement de l’idée commence. La fonctionnalité du futur produit est formée, les voies de mise en œuvre et les solutions techniques optimales sont déterminées et le plan d'affaires est mis à jour. Le résultat de cette étape est une spécification technique de développement et une analyse de rentabilisation détaillée. En cas de succès, on passe à l'étape MVP ou MVP.

MVP ou MVP

MVP est un produit minimum viable. Ceux. un produit qui n'est pas entièrement développé, mais qui peut déjà apporter de la valeur et remplir ses fonctionnalités. Il est impératif qu'à ce stade de développement, nous collections les commentaires des utilisateurs réels et apportions des modifications.

fabrication

Et la toute dernière étape est la production. Pas plus de 5 % des produits atteignent ce stade. Ces 5 % ne comprennent que les produits les plus importants, nécessaires, viables et fonctionnels.

Nous avons beaucoup d’idées et avons déjà constitué un portefeuille volumineux. Nous analysons chaque idée et faisons tout pour qu’elle atteigne la phase finale. Il est très agréable que nos collègues ne soient pas restés indifférents à notre direction R&D et participent activement au développement et à la mise en œuvre de produits et de solutions.

Comment nous avons créé LANBIX

Examinons la création d'un produit à l'aide d'un exemple réel : le produit LANBIX. Il s’agit d’un système logiciel et matériel « en boîte » conçu pour surveiller les petites infrastructures informatiques et alerter rapidement les décideurs et les utilisateurs professionnels des dysfonctionnements contrôlés via un chatbot. En plus de la fonction de surveillance, LANBIX inclut la fonctionnalité Help Desk. Ce produit est exclusif au segment de marché que nous ciblons. C'est à la fois notre avantage et notre douleur. Mais tout d’abord. Je dirai tout de suite que LANBIX est un produit vivant (c'est-à-dire qu'il n'est pas final dans son développement et est au prochain tour de MVP).

La première étape est donc l’idée. Pour qu'une idée naisse, il faut des problèmes, et nous les avons eu, ou plutôt pas nous, mais nos amis. Ci-dessous, nous examinerons plusieurs situations réelles survenues dans différents domaines d’activité.

Une petite société de gestion gère deux maisons dans la région de Moscou. Le personnel équipé d'ordinateurs est d'environ 15 personnes. L'administrateur système est un indépendant en visite (le fils intelligent de l'un des résidents attentionnés). Il semblerait que les activités de la société de gestion soient faiblement dépendantes de l'informatique, mais la particularité de cette activité est le reporting mensuel auprès de nombreuses autorités. Le disque système du chef d'entreprise (qui, comme d'habitude, cumule de nombreux rôles) n'a plus d'espace libre. Bien entendu, cela ne s'est pas produit soudainement : l'avertissement est resté en suspens pendant environ 2 mois et a été constamment ignoré. Mais une mise à jour est arrivée, le système d'exploitation a été mis à jour et, par hasard, il s'est figé au milieu de la mise à jour, se plaignant avant la « mort » d'un disque occupé. L'ordinateur a effectué un redémarrage cyclique. Pendant que nous résolvions le problème et obtenions des rapports, nous avons manqué la date limite de présentation des rapports. Il semblerait qu'un dysfonctionnement insignifiant ait provoqué divers problèmes : des pertes aux litiges et à la responsabilité administrative.

Source

Un incident similaire s'est produit dans une grande société holding, réunissant de nombreuses petites entreprises, avec un service d'assistance technique unique pour l'ensemble du bureau. Dans l'un des services, l'ordinateur du chef comptable est tombé en panne. On savait depuis longtemps qu'il pouvait tomber en panne (l'ordinateur ralentissait et chauffait désespérément), mais le chef comptable n'a jamais eu le temps d'envoyer une demande au support technique. Naturellement, il est tombé en panne exactement le jour de paie et les employés du département sont restés sans argent pendant plusieurs jours.

Une petite entreprise de petit commerce de gros possédait un site Internet de vente hébergé sur un site externe. Nous avons appris son indisponibilité par téléphone auprès d'un client régulier. Au moment de l'appel, le site était indisponible depuis environ trois heures. Il a fallu encore quelques heures pour trouver la personne responsable du site et deux autres pour résoudre le problème. En conséquence, le site est resté indisponible pendant presque toute la journée de travail. Selon le directeur commercial de l’entreprise, cette interruption leur a coûté environ 1 million de roubles.

J'ai moi-même rencontré une situation similaire lorsque je suis venu prendre rendez-vous à la clinique et que j'ai dû me rendre à l'inscription VHI. Ils n'ont pas pu m'envoyer chez le médecin pour une raison triviale : il y a eu une surtension le matin et après l'accident, leur service postal et un certain service de communication avec la compagnie d'assurance n'ont pas fonctionné. En réponse à ma question, où sont vos administrateurs, on m'a répondu que leur administrateur venait leur rendre visite une fois par semaine. Et maintenant (à ce moment-là il était déjà 16h00) il ne répond plus au téléphone. Pendant au moins 7 heures, la clinique a été coupée du monde extérieur et n'a pas pu fournir de services payants.

Quel est le point commun entre toutes ces affaires ? Absolument tous les problèmes auraient pu être évités à l’avance. Avec une réponse rapide des informaticiens, les dégâts auraient pu être réduits. Cela serait possible si les premiers symptômes étaient correctement interprétés par les utilisateurs.

Nous avons identifié des hypothèses problématiques :

des pertes monétaires et de réputation importantes dues à la faible rapidité de réponse aux pannes de l'infrastructure informatique ;
interprétation erronée des premiers symptômes d'un dysfonctionnement par les utilisateurs.

Que peut en faire le client et comment éviter des situations similaires à l’avenir ? Il n'y a pas beaucoup d'options :

embaucher un administrateur système hautement qualifié et le faire travailler consciencieusement ;
confier la maintenance informatique à une société de services spécialisée ;
mettre en œuvre de manière indépendante un système de surveillance et de rapport de pannes ;
fournir une formation aux utilisateurs/personnel de l’entreprise aux bases de l’informatique.

Arrêtons-nous sur la troisième option. Proposons un système de surveillance à ceux qui ne l'utilisent pas pour diverses raisons.

Digression lyrique. Divers systèmes de surveillance des services informatiques sur le marché des entreprises sont utilisés depuis longtemps et leurs avantages ne sont pas contestés. J'ai discuté avec des représentants de grandes entreprises, examiné comment se construisait la relation entre le business et l'informatique. Le directeur technique d'une grande entreprise de construction de machines a confié la maintenance de l'infrastructure informatique à une entreprise externe, mais il reste lui-même au courant de tout. Dans son bureau est accroché un grand écran de système de surveillance avec des indicateurs de l'état des services informatiques. Les plus critiques sont inclus dans le système. A tout moment, le directeur technique peut savoir quel est l'état de l'infrastructure, ce qui se passe, où se situe le problème, si les responsables ont été prévenus et si le problème est en train d'être résolu.

Les histoires énumérées ci-dessus ont amené notre équipe à réfléchir à la manière de créer un système de surveillance optimal pour les petites entreprises. C'est ainsi qu'est né LANBIX : un système de surveillance qui peut être déployé par absolument n'importe qui sans aucune connaissance en informatique. L'objectif principal du système est simple, comme tous les systèmes visant à augmenter la continuité et la disponibilité : réduire les pertes monétaires et autres en cas d'indisponibilité imprévue. L'appareil est conçu pour réduire au minimum le temps entre « quelque chose est cassé » et « le problème a été résolu ».

Pour confirmer les hypothèses, des entretiens problématiques ont été menés. Je ne pouvais pas imaginer tout ce que les gens seraient prêts à raconter sans essayer de leur vendre. Chaque conversation a duré au moins une heure et demie et nous avons reçu de nombreuses informations utiles pour le développement ultérieur.

Résumons les résultats de cette étape :

il y a une compréhension du problème,
compréhension de la valeur - il y a,
Il y a une idée de solution.

La deuxième étape était plus détaillée. Sur la base de ses résultats, nous avons dû présenter au management, qui joue essentiellement le rôle d'un investisseur, un business case (le même Lean Canvas) pour prendre une décision sur le sort futur du produit.

Nous avons commencé par des études de marché et des analyses concurrentielles afin de savoir qui, quoi et, surtout, comment ils se comportent sur ce marché.

Il s'est avéré ce qui suit.

Il n'existe pas de systèmes de surveillance en boîte prêts à l'emploi sur le marché pour notre segment (petites entreprises), à l'exception de quelques ou trois, dont je ne parlerai pas pour des raisons évidentes.
Curieusement, nos principaux concurrents sont des administrateurs système dotés de scripts écrits à la main et de « modules complémentaires » pour les systèmes de surveillance open source.
Il existe un problème évident avec l’utilisation de systèmes de surveillance open source. Il existe un système, il existe une énorme quantité d'informations sur la façon de travailler et de modifier le système en fonction de vos besoins. Parmi les administrateurs que j'ai interrogés, beaucoup ont admis qu'ils n'avaient pas suffisamment de compétences pour mettre en œuvre eux-mêmes leurs idées. Mais ils ne peuvent pas l'admettre à la direction, de peur d'être licenciés. Il s’avère que c’est un cercle vicieux.

Nous sommes ensuite passés à l’analyse des besoins de nos clients potentiels. Nous avons identifié nous-mêmes un segment de petites organisations qui, pour une raison quelconque, ne disposent pas de leur propre service informatique, où soit un nouvel administrateur système, un indépendant ou une société de services est responsable de l'informatique. Ce n'est pas le côté informatique qui a décidé d'entrer, mais le côté commercial, offrant aux fondateurs et aux propriétaires d'entreprise un outil pour améliorer la qualité du service d'infrastructure informatique. Un produit qui devrait 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 qui fournit aux entreprises un outil de suivi de la qualité du support informatique.

À la suite du traitement des données reçues, la première liste d'exigences (une sorte de backlog approximatif) pour le futur produit est née :

le système de surveillance doit être basé sur une solution open source et, par conséquent, bon marché ;
facile et rapide à installer ;
ne devrait pas nécessiter de connaissances spécifiques en informatique, même un comptable (je ne voulais en aucun cas offenser les représentants de cette profession) devrait être capable de déployer et de configurer le système ;
devrait détecter automatiquement les objets à surveiller sur le réseau ;
devrait installer automatiquement (et idéalement automatiquement) des agents de surveillance ;
doit être capable de surveiller des services externes, au moins un système CRM et un site Web de vente ;
doit informer à la fois l'entreprise et l'administrateur système des problèmes ;
le degré de profondeur et le « langage » des alertes doivent être différents pour l'administrateur et l'entreprise ;
le système doit être fourni sur son propre matériel ;
le fer doit être aussi accessible que possible ;
le système doit être aussi indépendant que possible des facteurs externes.

Ensuite, les investissements dans le développement de produits ont été calculés (y compris les coûts de main-d'œuvre pour les employés du service technique). Une esquisse du modèle commercial a été préparée et les paramètres économiques unitaires du produit ont été calculés.

Résultat de l'étape :

carnet de commandes de produits de haut niveau ;
un modèle commercial formulé ou une hypothèse d’échelle qui n’a pas encore été testée dans la pratique.

Passons à l'étape suivante : le concept. Ici, en tant qu'ingénieurs, nous nous retrouvons dans notre élément natif. Il existe des « wish lists » qui sont décomposées en composants/sous-systèmes/fonctionnalités, puis transformées en spécifications techniques/user stories, puis en projet, etc. Je ne m'étendrai pas en détail sur le processus de préparation d'un éventail d'options alternatives, passons directement aux exigences et aux méthodes choisies pour leur mise en œuvre.

Exigence
décision

Il devrait s'agir d'un système de surveillance ouvert ;

Nous prenons un système de surveillance open source.

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

Nous proposons un système installé pour que l'utilisateur n'ait qu'à allumer l'appareil et à le configurer un peu, comme un routeur.

Fermons l’interaction avec l’appareil à quelque chose de simple et compréhensible pour tout le monde.

Écrivons notre propre chatbot pour l'une des messageries instantanées les plus connues et transférons-y toutes les interactions avec le système.

Le système doit :

détecter automatiquement les objets nécessaires à la surveillance sur le réseau ;
installer automatiquement des agents de surveillance ;
Être capable de surveiller les services externes, au moins un système CRM et un site Web de vente.

Nous écrivons des modules complémentaires pour le système de surveillance pour :

détection automatique d'objets ;
installation automatique d'agents ;
surveiller la disponibilité des services externes.

Le système doit :

informer l'entreprise et l'administrateur système des problèmes ;
être capable de surveiller des services externes, au moins un système CRM et un site Web de vente. Le degré de profondeur et le « langage » des notifications doivent être différents pour l'administrateur et l'entreprise.
Le système ne devrait pas nécessiter de connaissances informatiques spécifiques ; 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. Ils diffèrent par leur hauteur et leur profondeur. Un utilisateur professionnel recevra des notifications du type « tout va bien, mais l’ordinateur d’Ivanov va bientôt mourir ». L'administrateur recevra un message complet sur l'erreur, qui, comment et ce qui s'est produit ou pourrait arriver.
Ajoutons la possibilité d'utiliser le mail d'un responsable supplémentaire, afin qu'en cas de panne il reçoive un message.
Ajoutons une interaction avec des prestataires de services externes basée sur l'envoi d'e-mails avec du texte préparé à l'avance, car C'est l'email qui est à l'origine de l'incident.
Toutes les interactions avec le système seront connectées à un chatbot ; la communication se déroulera dans un style de dialogue.

Supplément:

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

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

Prenons un ordinateur Raspberry PI prêt à l'emploi et bon marché.
Nous allons concevoir une carte d'alimentation sans interruption.
Ajoutons un modem pour être indépendant de l'état du réseau local.
Nous concevrons un beau bâtiment.

Nous disposons désormais de trois sous-systèmes avec leurs propres exigences et vision pour leur mise en œuvre :

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

Nous avons développé une conception préliminaire pour le sous-système matériel. Oui oui! Après avoir violé toutes les règles de l'Agile, nous avons élaboré un document, car les usines de fabrication travaillent avec des documents. Pour les sous-systèmes restants, nous avons identifié les utilisateurs (personnes), préparé des user stories et rédigé des tâches de développement.

Ceci conclut la phase de conception et le résultat est :

projet de plateforme matérielle ;
vision formulée sous forme de témoignages d'utilisateurs pour les deux sous-systèmes restants ;
un prototype de logiciel implémenté sous forme de machine virtuelle ;
un prototype du matériel, réalisé sous la forme d'un stand, où la résistance des solutions matérielles a été réellement testée ;
tests effectués par nos administrateurs.

Les problèmes à ce stade étaient pour la plupart organisationnels et liés au manque de connaissances du personnel d'ingénierie dans les aspects juridiques et comptables de la vente. Ceux. C'est une chose de savoir quoi et comment vendre, et une autre d'être confronté à une machine juridique impitoyable : brevets, tâches de développement, enregistrement, CLUF et bien plus encore dont nous, en tant que créatifs, n'avions pas pris en compte au départ.

Il n’y avait pas encore de problème, mais plutôt une difficulté liée à la conception des enceintes. Notre équipe est composée uniquement d'ingénieurs, c'est pourquoi la première version du boîtier a été « construite » en plexiglas par notre spécialiste en électronique.

Le corps semblait, pour le moins, controversé, surtout pour le public, gâché par la technologie moderne. Il y avait bien sûr des connaisseurs parmi l'ancienne génération de « Kulibins » - le bâtiment évoquait en eux des sentiments nostalgiques. Il a été décidé de fabriquer et de concevoir à nouveau le boîtier, car l'ancien, en plus des défauts esthétiques, présentait également des défauts structurels - le plexiglas ne tolérait pas bien le montage et le démontage de l'appareil et avait tendance à se fissurer. Je vous parlerai plus loin de la production de l'affaire.

Et maintenant, nous sommes proches de la ligne d'arrivée - MVP. Bien sûr, il ne s’agit pas encore d’un produit final, mais il est déjà utile et précieux. L’objectif principal de cette étape est de lancer le cycle « créer-évaluer-apprendre ». C’est exactement à ce stade que se trouve LANBIX.

Au stade « créer », nous avons créé un appareil qui exécute la fonctionnalité indiquée. Oui, ce n’est pas encore parfait et nous avons continué à y travailler.

Revenons à la fabrication du corps, c'est-à-dire à la tâche de transformer notre appareil de nostalgique à moderne. Au début, j'ai parcouru le marché à la recherche de fabricants d'armoires et de services de design industriel. Premièrement, il n'y a pas beaucoup d'entreprises produisant des boîtiers sur le marché russe, et deuxièmement, le coût du design industriel à ce stade est prohibitif, environ 1 million de roubles.

Ils ont contacté notre service marketing pour le design ; le jeune designer était prêt pour des expériences créatives. Nous avons exposé notre vision de la coque (après avoir étudié au préalable les meilleurs exemples de construction de coque), et il l'a à son tour transformée en œuvre d'art. Il ne reste plus qu'à le produire. Nous, fiers de notre conception, nous sommes tournés vers nos partenaires. Leur PDG a immédiatement brisé nos fantasmes en soulignant, tout à fait gratuitement, des choses qui ne pouvaient pas être produites de la manière que nous avions choisie. Le boîtier peut être produit, et il ne sera pas pire que celui d'Apple, mais le coût du boîtier sera trois à quatre fois plus cher que tous les composants électroniques. Après une série d'opérations et d'homologations, nous avons conçu un boîtier réalisable. Oui, ce n’est pas aussi beau que prévu, mais c’est idéal pour atteindre les objectifs actuels.

Résultat de l'étape : le premier lot d'appareils prêts au combat et aux tests.

Et maintenant, le plus difficile est l’étape « évaluer », et avec notre produit, nous en sommes exactement à ce stade. Nous ne pouvons évaluer que sur la base des résultats d'utilisation par de vrais clients et aucune hypothèse ne fonctionne ici. Nous avons besoin que ces « premiers utilisateurs » nous fournissent leurs commentaires et apportent les modifications réellement nécessaires au produit. La question se pose : où trouver les clients et comment les convaincre de participer à l’expérimentation ?

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

Le processus a déjà été lancé, mais il est trop tôt pour parler de résultats, même s'il y a déjà des réponses et que nous avons reçu la confirmation de plusieurs de nos hypothèses. Une agréable surprise a été la réaction des représentants de secteurs d'activité complètement différents, bien plus nombreux que ceux auxquels nous nous attendions. Il serait insensé d'ignorer les nouvelles introductions et, sur la base des résultats des entretiens, il a été décidé de lancer une ligne LANBIX parallèle appelée LANBIX Enterprise. Nous avons ajouté la prise en charge des infrastructures distribuées, la surveillance des réseaux Wi-Fi avec dépannage et localisation, et la surveillance de la qualité des canaux de communication. Les sociétés de services ont exprimé le plus grand intérêt pour la solution. Parallèlement, les appareils que nous avons déjà développés jouent un rôle important dans le fonctionnement des solutions.

Que va-t-il se passer ensuite

Ce qui se passera ensuite avec le LANBIX original deviendra clair en fonction des résultats de la campagne. Si nos hypothèses ne se confirment pas, selon la méthodologie Lean, nous nous en débarrasserons impitoyablement ou il sera transformé en quelque chose de nouveau, car il n'y a rien de pire que de fabriquer un produit dont personne n'a besoin. Mais maintenant, nous pouvons dire que le travail effectué n'a pas été vain et grâce à lui, toute une branche de produits parallèles est apparue, sur laquelle nous travaillons activement. En cas de succès, LANBIX passera du stade MVP au stade final et se développera selon les lois classiques compréhensibles du marketing produit.

Je le répète, nous voulons maintenant trouver des early adopters, des entreprises capables d'installer notre produit afin de recueillir des commentaires. Si vous souhaitez tester LANBIX, écrivez dans les commentaires ou dans les messages privés.

Source

Source: habr.com

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