Come lavoriamo con le idee e come è nato LANBIX

In «Lanit-Integrations» there are many creative employees. Ideas for new products and projects literally fill the air. Sometimes it can be very difficult to identify the most interesting ones. That’s why we developed our methodology together. Read this article to learn how to select the best projects and implement them.

In Russia, and indeed in the world as a whole, a number of processes are occurring that are transforming the IT market. Thanks to the increase in computing power and the emergence of server, network, and other virtualization technologies, the market no longer requires a large amount of hardware. Vendors increasingly prefer to work directly with clients. The IT market is experiencing a bloom of outsourcing in all its forms, from classic outsourcing to the new wave of providers known as 'cloud providers'. Infrastructure systems and elements are becoming significantly easier to maintain and configure. Software quality improves each year, and the integrator's tasks are evolving.

How we work with ideas

Product startup direction in «Lanit-Integrations» esiste da più di un anno. Il nostro obiettivo principale è la creazione di nuovi prodotti e il loro lancio sul mercato. Per iniziare, abbiamo organizzato il processo di creazione dei prodotti. Abbiamo studiato numerose metodologie, dalle classiche alle più alla moda. Tuttavia, nessuna di esse soddisfava le nostre esigenze. Così abbiamo deciso di adottare la metodologia Lean Startup e adattarla ai nostri obiettivi. "Lean Startup" è una teoria imprenditoriale creata da Eric Ries. Essa si basa su principi, approcci e pratiche di concetti come la produzione snella, lo sviluppo del cliente e la metodologia agile.

Per quanto riguarda l'approccio alla gestione dello sviluppo del prodotto: non abbiamo reinventato la ruota, ma abbiamo applicato una metodologia di sviluppo esistente. SCRUM, aggiungendo creatività, ora può essere tranquillamente definita SCRUM-WATERFALL-BAN. SCRUM, nonostante la sua flessibilità, è un sistema molto rigido e si adatta alla gestione di un team responsabile di un solo prodotto/progetto. Come sapete, il classico business "integratore" non prevede l’assegnazione di specialisti tecnici a tempo pieno per lavorare su un singolo progetto (eccezioni si verificano, ma sono estremamente rare), poiché oltre a lavorare sui prodotti, tutti sono impegnati nei progetti attuali. Da SCRUM abbiamo preso la suddivisione del lavoro in sprint, rapporti quotidiani, retrospettive e ruoli. Per lavorare con il flusso di compiti abbiamo scelto Kanban, che si è integrato perfettamente nel nostro sistema di monitoraggio esistente. Abbiamo organizzato il lavoro, integrandoci senza problemi nell'ordine già stabilito.
Prima di entrare nel mercato, un prodotto passa attraverso 5 fasi: idea, selezione, concetto, MVP (di seguito ulteriori dettagli) e produzione.

Idea

In questa fase c'è qualcosa di effimero: un'idea. Idealmente, è l'idea di una soluzione a un problema o a un bisogno del cliente. Non ci mancano idee. Secondo il progetto iniziale, dovrebbero essere generate dai membri dei reparti tecnici. Perché un'idea venga accettata per ulteriore sviluppo, l'autore deve compilare il «Modulo di presentazione dell'idea». Ci sono solo quattro domande: Che cosa? A cosa serve? A chi serve? E se non è il nostro prodotto, allora cos'altro?

Fonte

Selezione

Non appena il modulo compilato arriva a noi, inizia la procedura di elaborazione e selezione. La fase di selezione è la più laboriosa. In questo stadio si formulano ipotesi sui problemi (non ho menzionato per caso nel paragrafo precedente che, idealmente, l'idea dovrebbe risolvere un problema del cliente) e sul valore del prodotto. Si forma l'ipotesi della scala, ovvero come la nostra azienda intende crescere e prosperare. Vengono condotte interviste tematiche ed esperte con potenziali clienti per confermare preliminarmente che intendiamo produrre qualcosa di utile. Sono necessarie almeno 10-15 interviste per trarre conclusioni sull'utilità del prodotto.

Se le ipotesi vengono confermate, viene effettuata un'analisi finanziaria preliminare, valutando l'ammontare degli investimenti e il guadagno potenziale dell'investitore. Il risultato di questa fase è un documento chiamato Lean Canvas, presentato alla direzione.

Concetto

In questa fase vengono scartate circa il 70% delle idee. Se il concetto è approvato, inizia la fase di sviluppo dell'idea. Vengono definite le funzionalità del futuro prodotto, individuati i modi di attuazione e le soluzioni tecniche ottimali, aggiornato il business plan. Il risultato di questa fase è il documento tecnico per lo sviluppo e un dettagliato business case. In caso di successo, si passa alla fase MЖP o MVP.

MЖP o MVP

MЖP è un prodotto minimo vitale. Cioè, un prodotto che non è completamente sviluppato, ma può già offrire valore e svolgere le proprie funzionalità. In questa fase di sviluppo è fondamentale raccogliere feedback da parte degli utenti reali e apportare modifiche.

Produzione

E l'ultima fase è la produzione. Solo il 5% dei prodotti raggiunge questa fase. In questo 5% rientrano solo i prodotti più importanti, necessari, fattibili e funzionali.

Abbiamo molte idee e abbiamo già creato un ampio portfolio. Esaminiamo ogni idea e facciamo tutto il possibile affinché raggiunga la fase finale. È molto gratificante che i colleghi non siano rimasti indifferenti al nostro ambito R&D e partecipino attivamente allo sviluppo e alla realizzazione di prodotti e soluzioni.

Come abbiamo realizzato LANBIX

Consideriamo la creazione del prodotto con un esempio reale: il prodotto LANBIX. Si tratta di un complesso software e hardware, destinato al monitoraggio di piccole infrastrutture IT e al tempestivo avviso delle persone responsabili e degli utenti aziendali riguardo a malfunzionamenti, gestito tramite un chatbot. Oltre alla funzione di monitoraggio, LANBIX include anche funzionalità di Help Desk. Questo prodotto è esclusivo per il segmento di mercato a cui ci stiamo rivolgendo. È sia il nostro vantaggio sia il nostro dolore. Ma andiamo con ordine. Dico subito che LANBIX è un prodotto vivo (cioè non è definitivo nel suo sviluppo e si trova in un'altra fase di MVP).

Quindi, la prima fase è l'idea. Per far nascere un'idea, servono problemi, e noi ne avevamo, o meglio, i nostri conoscenti ne avevano. Di seguito analizzeremo alcune situazioni reali accadute in diversi ambiti aziendali.

Una piccola società di gestione gestisce due edifici nella regione di Mosca. Il personale con computer è di circa 15 persone. L'amministratore di sistema è un freelance occasionale (il figlio intraprendente di uno dei residenti attenti). A prima vista, l'attività della società di gestione potrebbe sembrare poco dipendente dall'IT, ma la peculiarità di questo business è la rendicontazione mensile a numerosi enti. Sul disco di sistema del capo della società (che, come al solito, svolge molteplici ruoli) è finito lo spazio disponibile. Naturalmente, questo non è successo all'improvviso; l'avviso era visibile da circa 2 mesi ed è stato costantemente ignorato. Ma è arrivato un aggiornamento, il sistema operativo si è aggiornato e, sfortunatamente, si è bloccato a metà dell'aggiornamento, lamentandosi prima della 'morte' per il disco pieno. Il computer è andato in un ciclo di riavvio. Mentre cercavamo di risolvere il problema e recuperare i report, abbiamo perso la scadenza per la presentazione della documentazione. Quella che sembrava un'inconveniente banale è diventata la causa di vari problemi: perdite finanziarie, contenziosi e responsabilità amministrativa.

Fonte   

Un caso simile è avvenuto in un grande gruppo che riunisce molte piccole aziende, con un unico servizio di supporto tecnico per l'intero ufficio. In uno dei dipartimenti, il computer del capo contabile si è rotto. Era già noto da tempo che potesse guastarsi (il computer rallentava disperatamente e si surriscaldava), ma il capo contabile non aveva mai trovato il tempo per inviare una richiesta al supporto tecnico. Naturalmente, si è rotto proprio il giorno della paga, e i dipendenti del dipartimento sono rimasti senza stipendio per diversi giorni.

Una piccola azienda di commercio all'ingrosso aveva un sito web di vendita ospitato su una piattaforma esterna. Hanno scoperto la sua inaccessibilità tramite una telefonata da un cliente abituale. Al momento della chiamata, il sito era già giù da circa tre ore. La ricerca della persona responsabile del sito è durata altre due ore, per risolvere il problema altrettanto. Pertanto, il sito è stato inattivo per praticamente tutta la giornata lavorativa. Secondo il direttore commerciale dell'azienda, questo inattivo è costato loro circa 1 milione di rubli.

Anch'io ho affrontato una situazione simile quando sono andato in ambulatorio e dovevo recarmi all'ufficio registrazioni DMS. Non potevano mandarmi dal medico per una ragione banale: al mattino c'era stata un' oscillazione di tensione, e dopo l'incidente il loro servizio postale e un certo servizio di comunicazione con l'assicurazione non funzionavano. Alla mia domanda su dove fossero i loro amministratori, mi è stato detto che l'amministratore passa da loro una volta alla settimana. E adesso (allora era già le 16:00) non rispondeva al telefono. Per almeno 7 ore, l'ambulatorio è stato tagliato fuori dal mondo esterno e non ha potuto fornire servizi a pagamento.

Cosa collega tutti questi casi? Tutti i problemi avrebbero potuto essere prevenuti in anticipo. Con una tempestiva reazione da parte delle persone che gestiscono l'IT, avrebbero potuto ridurre il danno causato. Questo sarebbe stato possibile anche con una corretta interpretazione dei primi sintomi da parte degli utenti.

Abbiamo identificato le ipotesi sui problemi:

• significative perdite finanziarie e di reputazione a causa di una bassa velocità di reazione ai guasti nell'infrastruttura IT;
• errata interpretazione dei primi sintomi di guasto da parte degli utenti.

Cosa può fare un cliente e come evitare situazioni simili in futuro? Le opzioni non sono molte:

1. assumere un amministratore di sistema altamente qualificato e costringerlo a lavorare con impegno;
2. affidare la manutenzione IT a una società di servizi specializzata;
3. implementare autonomamente un sistema di monitoraggio e avviso sui guasti;
4. formare gli utenti/personale aziendale alle basi dell'informatica.

Ci fermiamo sulla terza opzione. Offriamo un sistema di monitoraggio a coloro che non lo utilizzano per vari motivi.

Un'analisi approfondita. I vari sistemi di monitoraggio dei servizi IT sono stati utilizzati da tempo nel mercato enterprise e il loro valore è indiscutibile. Ho parlato con rappresentanti di grandi aziende, osservando come siano strutturate le relazioni tra business e IT. Il direttore tecnico di una grande azienda di ingegneria meccanica ha esternalizzato la gestione dell'infrastruttura IT a un'azienda esterna, ma rimane comunque aggiornato su tutte le attività. Nella sua stanza c'è un grande schermo del sistema di monitoraggio con indicatori dello stato dei servizi IT. Sono registrati i servizi più critici. In qualsiasi momento, il direttore tecnico può scoprire in quale stato si trova l'infrastruttura, cosa sta accadendo, dove si trova il problema, se le persone responsabili sono state avvisate e se il problema è in fase di risoluzione.

Le storie descritte hanno spinto il nostro team a riflettere su come sviluppare un sistema di monitoraggio ottimale per piccole aziende. Così è nato LANBIX: un sistema di monitoraggio che può essere implementato da chiunque, senza conoscenze IT. L'obiettivo del sistema è semplice, come quello di tutti i sistemi volti a garantire continuità e disponibilità: ridurre le perdite economiche e di altro tipo in caso di interruzioni impreviste. È progettato per minimizzare il tempo che intercorre tra il "ho qualcosa che non funziona" e il "problema risolto."

Per confermare le ipotesi sono state condotte interviste problematiche. Non avrei mai immaginato quanto le persone siano disposte a condividere se non si sta cercando di vender loro qualcosa. Ogni conversazione è durata almeno 1,5 ore e abbiamo ottenuto una vasta quantità di informazioni utili per lo sviluppo futuro.

Riassumiamo il risultato di questa fase:

1. comprensione del problema — presente,
2. comprensione del valore — presente,
3. idea per la soluzione — presente.

Il secondo passo è stato più dettagliato. In base ai risultati, dovevamo presentare alla direzione, che sostanzialmente funge da investitore, un business case (quello famoso Lean Canvas) per prendere una decisione sul futuro del prodotto.

Abbiamo iniziato con un'analisi di mercato e della concorrenza per capire chi, cosa e, soprattutto, come opera in questo mercato.

Ecco cosa è emerso.

1. Nel mercato non ci sono sistemi di monitoraggio pronti all'uso per il nostro segmento (piccole imprese), eccetto per un paio di soluzioni delle quali non posso parlare per motivi ovvi.
2. I nostri principali concorrenti, stranamente, sono gli amministratori di sistema con script personalizzati e "aggiustamenti" ai sistemi di monitoraggio open source.
3. C'è un chiaro problema nell'uso dei sistemi di monitoraggio open source. Esiste un sistema e c'è un'enorme quantità di informazioni su come lavorare e adattare il sistema alle proprie esigenze. Molti degli amministratori che ho intervistato hanno ammesso di non avere le competenze necessarie per realizzare le loro idee da soli. Ma non possono ammetterlo alla direzione per paura di essere licenziati. Risultato: un circolo vizioso.

Successivamente, abbiamo iniziato ad analizzare le esigenze dei nostri potenziali clienti. Abbiamo individuato il segmento delle piccole organizzazioni, che per vari motivi non dispongono di un proprio servizio IT, dove la gestione IT è affidata a un amministratore di sistema esterno, a un freelance o a una società di servizi. Abbiamo deciso di entrare nel mercato non dal lato IT, ma da quello del business, offrendo ai fondatori e ai proprietari uno strumento per migliorare la qualità del servizio dell'infrastruttura IT. Un prodotto che deve aiutare i proprietari a proteggere la propria attività, ma allo stesso tempo aumenterà il carico di lavoro per coloro che si occupano dell'IT. Un prodotto che fornisce al business uno strumento di controllo sulla qualità del supporto IT.

Come risultato dell'elaborazione dei dati ottenuti, è nato il primo elenco dei requisiti (un certo backlog grezzo) per il futuro prodotto:

• il sistema di monitoraggio deve basarsi su una soluzione open source e quindi essere economico;
• deve essere semplice e veloce da installare;
• non dovrebbe richiedere conoscenze specifiche in IT; anche un contabile (in nessun caso intendo offendere i rappresentanti di questa professione) dovrebbe essere in grado di avviare e configurare il sistema;
• deve rilevare automaticamente gli oggetti da monitorare nella rete;
• deve installare automaticamente (idealmente in modo automatizzato) gli agenti di monitoraggio;
• deve avere la capacità di monitorare i servizi esterni, come minimo un sistema CRM e un sito di vendita;
• deve avvisare sia il business che l'amministratore di sistema in caso di guasti;
• il livello di dettaglio e il 'linguaggio' delle notifiche devono essere diversi per l'amministratore e il business;
• il sistema deve essere fornito su hardware proprietario;
• l'hardware deve essere il più accessibile possibile;
• il sistema deve essere il più indipendente possibile da fattori esterni.

In seguito sono stati calcolati gli investimenti per lo sviluppo del prodotto (incluso il lavoro del personale del dipartimento tecnico). È stato preparato uno schizzo del modello di business e calcolata l'economia unitaria del prodotto.

Risultato della fase:

• backlog del prodotto ad alto livello;
• un modello di business formulato o un'ipotesi di scala che deve ancora essere testata nella pratica.

Passiamo alla fase successiva: il concetto. Qui come ingegneri entriamo nel nostro elemento. Ci sono desideri che vengono scomposti in componenti/sotto-sistemi/funzionalità, poi trasformati in requisiti/storie utente, quindi in progetto, e così via. Non entrerò nei dettagli del processo di preparazione di un insieme di varianti alternative; passeremo direttamente ai requisiti e ai metodi scelti per la loro attuazione.

Requisito
Soluzione

• Deve essere un sistema di monitoraggio aperto;

Prendiamo un sistema di monitoraggio open source.

• Il sistema deve essere semplice e veloce da installare;
• non deve richiedere conoscenze specifiche in IT. Anche un contabile deve essere in grado di installare e configurare il sistema.

Offriamo un sistema già installato, in modo che l'utente debba solo accendere il dispositivo e apportare alcune impostazioni, in modo simile a un router.

Colleghiamo l'interazione con il dispositivo a qualcosa di semplice e comprensibile per tutti.

Creeremo un chatbot per uno dei più noti messenger e gestiremo tutte le interazioni con il sistema tramite esso.

Il sistema deve:

• rilevare automaticamente gli oggetti da monitorare nella rete;
• installare automaticamente gli agenti di monitoraggio;
• Essere in grado di monitorare servizi esterni, almeno il CRM e il sito di vendita.

Scriviamo aggiunte per il sistema di monitoraggio riguardo:

• rilevamento automatico degli oggetti;
• installazione automatica degli agenti;
• monitoraggio della disponibilità dei servizi esterni.

Il sistema deve:

• notificare sia l'azienda che l'amministratore di sistema in caso di problemi;
• essere in grado di monitorare servizi esterni, almeno il CRM e il sito di vendita. La profondità e il tipo di notifiche devono essere diversi per l'amministratore e l'azienda.
• Il sistema non deve richiedere conoscenze IT specifiche, anche un contabile deve essere in grado di installare e configurare il sistema.

• Aggiungeremo diversi tipi di notifiche per diversi tipi di utenti. Queste differiscono per modalità e profondità. Un utente aziendale riceverà notifiche del tipo "tutto bene, ma il computer di Ivanov potrebbe spegnersi presto". L'amministratore riceverà un messaggio completo di errore, indicando chi, come e cosa è successo o potrebbe succedere.
• Aggiungeremo la possibilità di utilizzare l'email di un responsabile aggiuntivo, in modo che, in caso di guasto, riceva la notifica.
• Aggiungeremo l'interazione con fornitori esterni di servizi basata sull'invio di email con testo predefinito, poiché proprio l'email fornisce la base per l'apertura di un incidente.
• Tutta l'interazione con il sistema sarà centralizzata su una chatbot, con la comunicazione che avviene in uno stile dialogico.

Supplement:

• Aggiungeremo la funzionalità di "chatta con l'amministratore", consentendo all'utente di inviare messaggi direttamente all'amministratore con la descrizione del problema.

• Il sistema deve essere fornito su hardware proprietario.
• L'hardware deve essere accessibile.
• Il sistema deve essere il più indipendente possibile dall'ambiente.

• Utilizzeremo un computer Raspberry PI economico e già pronto.
• Progetteremo una scheda per l'alimentazione ininterrotta.
• Aggiungeremo un modem per avere indipendenza dallo stato della rete locale.
• Progetteremo un case elegante.

Abbiamo identificato tre subsistemi con i propri requisiti e visioni su come realizzarli:

• subsistema hardware;
• subsystem di monitoraggio;
• subsystem di interazione con l'utente.

Per il subsistema hardware abbiamo sviluppato un progetto preliminare. Sì, esatto! Violando tutte le regole dell'agile, abbiamo creato un documento, perché i produttori lavorano proprio con documenti. Per gli altri subsistemi abbiamo identificato gli utenti (personas), preparato storie utente e redatto compiti per lo sviluppo.

Con questo termina la fase di concetto, e i risultati sono stati:

• progetto sulla piattaforma hardware;
• vision formulato sotto forma di storie utente per le altre due subsistemi;
• prototipo della parte software, realizzato come una macchina virtuale;
• prototipo della parte hardware, implementato come un banco di prova, dove sono stati testati le soluzioni hardware;
• test eseguiti dai nostri amministratori.

I problemi in questa fase erano per lo più organizzativi e legati alla scarsa preparazione del nostro team tecnico sugli aspetti legali e contabili delle vendite. Cioè, è una cosa pensare a cosa e come vendere, e un'altra interagire con una macchina legale spietata: brevetti, compiti di sviluppo, bilanciamento, EULA e molto altro che noi, in quanto persone creative, non avevamo inizialmente considerato.

Non era ancora un problema, quanto piuttosto una difficoltà legata alla progettazione dei case. Nella nostra squadra ci sono solo ingegneri, quindi il primo prototipo del case è stato realizzato in plexiglass dal nostro specialista in elettronica.

Il case, per dirla in modo gentile, era discutibile, soprattutto per un pubblico abituato alla tecnologia moderna. Naturalmente, ci sono stati estimatori tra i 'cucitori' della generazione più anziana — il case ha suscitato in loro sentimenti nostalgici. È stato deciso di realizzare e progettare il case da capo, poiché il vecchio, oltre ai difetti estetici, presentava anche problemi strutturali: il plexiglass non sopportava bene il montaggio e lo smontaggio del dispositivo e tendeva a creparsi. Parlerò di più sulla produzione del case in seguito.

E ora siamo arrivati alla fase finale — il MVP. Certo, non è ancora il prodotto finale, ma è già utile e presenta valore. L'obiettivo principale di questa fase è avviare il ciclo "creare-valutare-apprendere". È proprio in questa fase che si trova LANBIX.

Nella fase "creare", abbiamo sviluppato un dispositivo che svolge le funzioni dichiarate. Sì, non è ancora perfetto e abbiamo continuato a lavorarci.

Tornando alla creazione del case, ossia al compito di trasformare il nostro dispositivo da evocativo di nostalgie a moderno. Inizialmente, ho esaminato il mercato alla ricerca di produttori di case e servizi di design industriale. Da un lato, le aziende che producono case sul mercato russo sono piuttosto poche, dall'altro, il costo del design industriale in questa fase è indesideratamente alto, circa 1 milione di rubli.

Ci siamo rivolti al nostro dipartimento marketing per il design; un giovane designer era pronto a esperimenti creativi. Abbiamo condiviso la nostra visione del case (dopo aver studiato i migliori esempi di costruzione di case), e lui, a sua volta, l'ha trasformata in un'opera d'arte. Resta solo da produrlo. Orgogliosi del nostro design, ci siamo rivolti ai partner. Il loro CEO ha subito distrutto le nostre fantasie, indicando gratuitamente i punti critici che rendevano impossibile produrre nel modo che avevamo scelto. Il case può essere prodotto e sarà all'altezza di quelli di Apple, ma il costo sarà da tre a quattro volte superiore rispetto all'intera elettronica. Dopo una serie di operazioni e approvazioni, abbiamo progettato un case che può essere realizzato. Sì, non è più bello come lo avevamo pianificato, ma è perfetto per raggiungere gli obiettivi attuali.

Risultato della fase: il primo lotto di dispositivi, pronti per le prove e i test.

Ora arriva la parte più difficile: la fase di 'valutazione'. Con il nostro prodotto siamo proprio a questo punto. Possiamo valutare solo in base ai risultati reali ottenuti dagli utenti e nessuna supposizione funziona qui. Abbiamo bisogno di veri 'early adopters' per fornire feedback e apportare le modifiche necessarie al prodotto. La domanda sorge spontanea: come trovare clienti e come convincerli a partecipare all'esperimento?

Tra tutte le opzioni possibili, abbiamo scelto un classico insieme di strumenti digitali: una landing page e una campagna pubblicitaria sui social media.

Il processo è già in corso, ma è troppo presto per parlare dei risultati, sebbene ci siano già delle risposte e abbiamo ricevuto conferma di molte delle nostre ipotesi. Una piacevole sorpresa è stata la reazione di rappresentanti di segmenti di business completamente diversi, molto più grandi rispetto a quelli su cui ci aspettavamo. Sarebbe stato sciocco ignorare queste nuove informazioni, e a seguito delle interviste condotte abbiamo deciso di lanciare una linea parallela di LANBIX chiamata LANBIX Enterprise. Abbiamo aggiunto il supporto per infrastrutture distribuite, monitoraggio delle reti Wi-Fi con ricerca e localizzazione dei guasti e monitoraggio della qualità delle connessioni. Le aziende di servizi hanno mostrato il maggiore interesse per questa soluzione. Nel contempo, i dispositivi da noi già sviluppati giocano un ruolo importante nelle soluzioni.

Cosa succede dopo

Cosa succederà con l'originale LANBIX sarà chiaro dai risultati della campagna. Se le nostre ipotesi non verranno confermate, secondo la metodologia Lean, ce ne libereremo senza pietà o si trasformerà in qualcos'altro, poiché non c'è nulla di peggio che creare un prodotto di cui nessuno ha bisogno. Ma già adesso possiamo dire che il lavoro svolto non è stato vano e grazie a esso è nata una intera serie di prodotti paralleli, su cui stiamo lavorando attivamente. In caso di successo, LANBIX passerà dalla fase MVP alla fase finale e si svilupperà secondo le leggi classiche del marketing di prodotto.

Ribadisco, ora vogliamo trovare sostenitori precoci, aziende a cui possiamo installare il nostro prodotto per raccogliere feedback. Se sei interessato a testare LANBIX, scrivi nei commenti o nei messaggi privati.

Fonte

Fonte: habr.com