Come lavoriamo con le idee e come è nato LANBIX.

In "LANIT-Integration" ci sono molti dipendenti creativi. Le idee sui nuovi prodotti e progetti letteralmente nell'aria. A volte è molto difficile identificare le più interessanti. Per questo motivo, abbiamo sviluppato insieme la nostra metodologia. Come selezionare i migliori progetti e realizzarli, leggi in questo articolo.

In Russia, e nel mondo in generale, stanno avvenendo una serie di processi che portano alla trasformazione del mercato IT. Grazie all'aumento delle capacità di calcolo e all'emergere di tecnologie di virtualizzazione server, di rete e altre, il mercato ha smesso di avere bisogno di un gran numero di "hardware". I vendor sempre più spesso preferiscono lavorare direttamente con i clienti. Nel mercato IT c'è un fiorire dell'outsourcing in tutte le sue forme, partendo dall'outsourcing classico fino agli outsourcer di nuova generazione - i "fornitori cloud". I sistemi e gli elementi infrastrutturali diventano sostanzialmente più semplici da mantenere e configurare. La qualità del software cresce di anno in anno e le sfide per gli integratori si trasformano.

Come lavoriamo con le idee

Il settore delle startup di prodotto in "LANIT-Integration" esiste da più di un anno. Il nostro obiettivo principale è la creazione di nuovi prodotti e il loro lancio sul mercato. La prima cosa che abbiamo fatto è stata organizzare il processo di creazione dei prodotti. Abbiamo studiato molte metodologie, dalle classiche a quelle di moda. Tuttavia, nessuna di esse rispondeva alle nostre esigenze. Allora abbiamo deciso di adottare la metodologia Lean Startup e adattarla ai nostri compiti. "Lean Startup" è una teoria imprenditoriale creata da Eric Ries. Alla base vi sono 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 inventato la ruota, ma abbiamo applicato una metodologia di sviluppo già esistente SCRUM, aggiungendo creatività, e ora può essere audacemente chiamata SCRUM-WATERFALL-BAN. SCRUM, nonostante la sua flessibilità, è un sistema molto rigido e adatto alla gestione di un team responsabile di un solo prodotto/progetto. Come sapete, un classico business «integratore» non prevede l'assegnazione di specialisti tecnici a tempo pieno per lavorare su un progetto (ci sono eccezioni, ma sono estremamente rare), poiché oltre a lavorare sui prodotti, tutti sono impegnati nei progetti attuali. Da SCRUM abbiamo preso la divisione del lavoro in sprint, la reportistica quotidiana, le retrospettive e i ruoli. Per gestire il flusso di compiti abbiamo scelto il Kanban, che si è integrato perfettamente nel nostro sistema di tracciamento delle attività esistente. Abbiamo organizzato il lavoro, integrandoci senza soluzione di continuità nell'ordine delle cose già esistente.
Prima di entrare nel mercato, il prodotto passa attraverso 5 fasi: idea, selezione, concetto, MЖП (per ulteriori dettagli, vedere sotto) e produzione.

Idea

In questa fase c'è qualcosa di efemerico - l'idea. Idealmente, è un'idea per risolvere un'esistente problematica o compito del cliente. Non ci mancano le idee. Inizialmente, dovrebbero essere generate dai membri del personale tecnico. Affinché l'idea sia approvata per ulteriore sviluppo, l'autore deve compilare il «Modello di presentazione dell'idea». Ci sono solo quattro domande: Cosa? Perché? A chi serve? E se non è il nostro prodotto, cosa?

Fonte

Selezione

Non appena il modello completato arriva a noi, inizia la procedura di elaborazione e selezione. La fase di selezione è la più laboriosa. In questa fase avviene la formazione delle ipotesi sui problemi (non è un caso che nel paragrafo precedente abbia indicato che l'idea dovrebbe risolvere un problema del cliente) e il valore del prodotto. Si sviluppa un'ipotesi di scala, ovvero come la nostra azienda prevede di crescere e prosperare. Vengono condotte interviste problematiche e di esperti con potenziali clienti per confermare preliminarmente che stiamo per produrre qualcosa di necessario. Sono necessarie almeno 10-15 interviste per trarre conclusioni sulla necessità del prodotto.

Se le ipotesi vengono confermate, viene effettuata un'analisi finanziaria preliminare, viene valutato il volume approssimativo degli investimenti e il possibile guadagno per l'investitore. Da questo stadio nasce un documento chiamato Lean Canvas, che viene presentato alla direzione.

Concetto

In questa fase vengono scartati circa il 70% delle idee. Se il concetto viene approvato, inizia la fase di elaborazione dell'idea. Vengono definite le funzionalità del futuro prodotto, si stabiliscono le vie di realizzazione e le soluzioni tecniche ottimali, viene aggiornato il piano aziendale. Il risultato di questa fase è un documento tecnico per lo sviluppo e un dettagliato business case. In caso di successo, passiamo alla fase MVP o MZP.

MVP o MZP

MZP è un prodotto minimalmente vitale. Cioè, è un prodotto che non è stato completamente sviluppato, ma che può già portare valore e svolge la sua funzionalità. È fondamentale, in questa fase di sviluppo, raccogliere feedback da utenti reali e apportare modifiche.

Produzione

E l'ultima fase è la produzione. Solo il 5% dei prodotti arriva a questa fase. Questo 5% comprende solo i prodotti più importanti, necessari, vitali e funzionali.

Abbiamo molte idee e già un ampio portafoglio. Esaminiamo ogni idea e facciamo di tutto per farla arrivare alla fase finale. È molto gratificante che i colleghi non siano rimasti indifferenti alla nostra direzione R&D e partecipino attivamente allo sviluppo e all'implementazione di prodotti e soluzioni.

Come abbiamo realizzato LANBIX

Consideriamo la creazione di un prodotto attraverso un esempio reale: il prodotto LANBIX. Si tratta di un complesso software-hardware "in scatola", progettato per il monitoraggio di piccole infrastrutture IT e per avvisare rapidamente le persone responsabili e gli utenti aziendali di eventuali malfunzionamenti, gestendo il tutto tramite un chatbot. Oltre alla funzione di monitoraggio, LANBIX include anche le funzionalità di Help Desk. Questo prodotto è esclusivo per il segmento di mercato su cui ci siamo fissati. Questo rappresenta sia un nostro vantaggio che una nostra difficoltà. Ma andiamo con ordine. Direi subito che LANBIX è un prodotto in continua evoluzione (cioè non è definitivo nel suo sviluppo e si trova in un'altra fase MVP).

Quindi, la prima fase è l'idea. Per generare un'idea, sono necessarie delle problematiche, e queste noi le avevamo, o meglio, le avevano i nostri conoscenti. Di seguito esamineremo alcune situazioni reali che si sono verificate in vari settori del business.

Una piccola società di gestione si occupa di due edifici nella regione di Mosca. Il personale, dotato di PC, è di circa 15 persone. L'amministratore di sistema è un freelancer esterno (un ragazzo sveglio, figlio di uno dei residenti impegnati). Apparentemente, l'attività della società di gestione non dipende molto dall'IT, ma la peculiarità di questo business è la rendicontazione mensile verso numerosi enti. Sul disco rigido del capo dell'azienda (che, come al solito, unisce molteplici ruoli) è finito lo spazio libero. Naturalmente, ciò non è avvenuto improvvisamente, la segnalazione era visibile da circa 2 mesi e costantemente ignorata. Ma è arrivato un aggiornamento, il sistema operativo è stato aggiornato e, per sfortuna, si è bloccato a metà aggiornamento, lamentandosi prima di "morire" per il disco pieno. Il computer è andato in un ciclo di riavvio. Mentre si cercava di risolvere il problema e si recuperavano i report, hanno perso la scadenza per la presentazione delle rendicontazioni. Sembrava un guasto insignificante, ma ha causato vari problemi: dalle perdite a controversie legali e responsabilità amministrative.

Fonte   

Un caso simile si è verificato 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 è guastato. Era già risaputo che potesse rompersi (il computer rallentava disperatamente e si surriscaldava), ma il capo contabile non è mai riuscito a inviare una richiesta di supporto tecnico. Naturalmente, si è rotto il giorno della paga, e i dipendenti del dipartimento sono rimasti senza soldi per diversi giorni.

Un piccolo business nel commercio all'ingrosso ha perso l'accesso al sito di vendita, ospitato su una piattaforma esterna. Ne sono stati informati telefonicamente da un cliente abituale. Al momento della telefonata, il sito era giù da circa tre ore. Cercare la persona responsabile del sito ha richiesto ulteriori paio d'ore, e la risoluzione del problema altre due. Di conseguenza, il sito è stato inaccessibile per quasi tutta la giornata lavorativa. Secondo le parole del direttore commerciale dell'azienda, questo inattività è costata circa 1 milione di rubli.

Mi sono trovato in una situazione simile quando sono andato all'ambulatorio e dovevo recarmi alla reception del DMS. Non potevano mandarmi dal medico per una banale ragione: al mattino c'era stata una fluttuazione della tensione e, dopo l'incidente, il loro servizio postale e un certo servizio di contatto con l'assicurazione non funzionavano. Alla mia domanda su dove fossero i vostri amministratori, mi è stato risposto che l'amministratore è un collaboratore esterno che li visita una volta alla settimana. E ora (in quel momento erano già le 16:00) non rispondeva al telefono. Per almeno 7 ore, l'ambulatorio è stato isolato dal mondo esterno e non poteva fornire servizi a pagamento.

Cosa unisce tutti questi casi? Assolutamente tutti i problemi avrebbero potuto essere prevenuti in anticipo. Con una reazione tempestiva da parte delle persone che gestiscono l'IT, sarebbe stato possibile ridurre i danni causati. Questo sarebbe stato possibile anche con una corretta interpretazione dei sintomi iniziali da parte degli utenti.

Abbiamo identificato le ipotesi sui problemi:

• perdite significative economiche e reputazionali a causa della bassa velocità di reazione alle anomalie nell'infrastruttura IT;
• errata interpretazione dei sintomi iniziali di guasto da parte degli utenti.

Cosa può fare il cliente per evitare situazioni simili in futuro? Le opzioni non sono molte:

1. assumere un amministratore di sistema altamente qualificato e costringerlo a lavorare con diligenza;
2. affidare la gestione IT a una società di servizi specializzata;
3. implementare autonomamente un sistema di monitoraggio e allerta sui guasti;
4. condurre corsi di formazione per utenti/personale aziendale sui principi di alfabetizzazione informatica.

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

Riflessione lirica. Vari sistemi di monitoraggio dei servizi IT nel mercato enterprise sono in uso da tempo, e il loro valore è indiscutibile. Ho parlato con rappresentanti di grandi aziende, osservando come vengono costruite le relazioni tra business e IT. Il direttore tecnico di una grande azienda di ingegneria meccanica ha esternalizzato la manutenzione dell'infrastruttura IT a un'impresa esterna, ma rimane sempre informato su tutto. Nel suo ufficio c'è un grande schermo del sistema di monitoraggio con indicatori dello stato dei servizi IT. I sistemi più critici sono stati inseriti. In qualsiasi momento, il direttore tecnico può verificare lo stato dell'infrastruttura, cosa sta succedendo, dove si trova il problema, se le persone responsabili sono state avvisate e se il problema è in fase di risoluzione.

Le storie sopra menzionate hanno portato il nostro team a riflettere su come creare un sistema di monitoraggio ottimale per le piccole aziende. Da questa riflessione è nato LANBIX, un sistema di monitoraggio che può essere implementato da chiunque senza competenze specifiche in IT. L'obiettivo principale del sistema è semplice, come in tutti i sistemi destinati a migliorare la continuità e la disponibilità: ridurre perdite economiche e altre in caso di inattività non pianificate. L'apparecchiatura mira a ridurre al minimo il tempo tra 'ho un problema' e 'il problema è risolto'.

Per confermare l'ipotesi sono state condotte interviste problematiche. Non avrei mai immaginato quanto le persone siano disposte a raccontare se non si cerca di vendere loro qualcosa. Ogni conversazione è durata almeno un'ora e mezza, e abbiamo ottenuto una grande quantità di informazioni utili per lo sviluppo futuro.

Riassumiamo il risultato di questo primo passo:

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

La seconda fase è stata più dettagliata. A seguito di essa, avremmo dovuto presentare alla direzione, che in sostanza svolge il ruolo di investitore, un business case (il Lean Canvas) per prendere decisioni sul futuro del prodotto.

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

Ecco cosa è emerso.

1. Nel mercato non ci sono sistemi di monitoraggio confezionati pronti per il nostro segmento (piccole aziende), a eccezione di un paio di casi, di cui per ovvi motivi non parlerò.
2. I nostri principali concorrenti, strano ma vero, sono gli amministratori di sistema con script personalizzati e "modifiche" ai sistemi di monitoraggio a codice sorgente aperto.
3. È evidente un problema nell'uso dei sistemi di monitoraggio a codice sorgente aperto. Esiste un sistema, c'è una grande quantità di informazioni sulla funzionalità e sull'adattamento del sistema alle proprie esigenze. Molti degli amministratori che ho intervistato hanno ammesso di non avere le competenze per realizzare le loro idee da soli. E non possono ammetterlo ai loro superiori per paura di essere licenziati. Si crea così un circolo vizioso.

Successivamente, abbiamo iniziato ad analizzare le esigenze dei nostri potenziali clienti. Abbiamo identificato un segmento di piccole organizzazioni che, per vari motivi, non hanno 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 non dal lato IT, ma dal lato del business, offrendo agli imprenditori e ai proprietari uno strumento per migliorare la qualità del servizio dell'infrastruttura IT. Un prodotto che dovrebbe aiutare i proprietari a proteggere la propria attività, ma al contempo aumenterà il lavoro per chi si occupa di IT. Un prodotto che fornisca all'azienda uno strumento per monitorare la qualità del supporto IT.

A seguito dell'elaborazione dei dati raccolti, è nato il primo elenco di requisiti (una sorta di backlog grezzo) per il futuro prodotto:

• il sistema di monitoraggio deve essere basato su una soluzione a codice sorgente aperto e, di conseguenza, economica;
• deve essere semplice e rapida da installare;
• non deve richiedere conoscenze specifiche in IT; perfino un contabile (non ho intenzione di offendere i rappresentanti di questa professione) deve essere in grado di installare e configurare il sistema;
• deve rilevare automaticamente gli oggetti da monitorare in rete;
• deve installare automaticamente (idealmente in modo automatico) gli agenti di monitoraggio;
• deve avere la possibilità di monitorare servizi esterni, almeno un sistema CRM e un sito web di vendita;
• deve avvisare sia il business che l'amministratore di sistema in caso di problemi;
• il livello di dettaglio e il "linguaggio" delle notifiche devono essere diversi per l'amministratore e per il business;
• il sistema deve essere fornito su hardware dedicato;
• l'hardware deve essere il più accessibile possibile;
• il sistema deve essere il più indipendente possibile da fattori esterni.

Successivamente sono stati calcolati gli investimenti per lo sviluppo del prodotto (inclusi i costi lavorativi del personale del dipartimento tecnico). È stato preparato uno schema del modello di business e calcolata l'economia del prodotto.

Risultato della fase:

• backlog del prodotto ad alto livello;
• modello di business formulato o ipotesi di scalabilità, che deve ancora essere verificata nella pratica.

Passiamo alla fase successiva — la concezione. Qui come ingegneri entriamo nel nostro elemento. Ci sono 'desideri' che vengono scomposti in componenti/sottosistemi/feature, che poi si trasformano in requisiti/epiche utenti, poi in progetto e così via. Non entrerò nei dettagli del processo di preparazione di un insieme di alternative, andiamo direttamente ai requisiti e ai metodi selezionati per la loro attuazione.

Requisito
Soluzione

• Deve essere un sistema di monitoraggio aperto;

Prendiamo un sistema di monitoraggio con codice sorgente aperto.

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

Proponiamo un sistema preinstallato, affinché all'utente rimanga solo da accendere il dispositivo e configurarlo un po', analogamente a un router.

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

Scriveremo il nostro chatbot per uno dei noti messaggeri e porteremo tutta l'interazione con il sistema su di esso.

Il sistema deve:

• scoprire automaticamente gli oggetti da monitorare in rete;
• installare automaticamente gli agenti di monitoraggio;
• Avere la possibilità di monitorare servizi esterni, almeno un sistema CRM e un sito web di vendita.

Scriviamo estensioni per il sistema di monitoraggio su:

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

Il sistema deve:

• avvisare sia l'azienda che l'amministratore di sistema di eventuali problemi;
• avere la possibilità di monitorare servizi esterni, almeno un sistema CRM e un sito web di vendita. Il livello di dettaglio e il 'linguaggio' delle notifiche devono essere diversi per l'amministratore e l'azienda.
• Il sistema non deve richiedere conoscenze specifiche in IT, anche un contabile dovrebbe essere in grado di installare e configurare il sistema.

• Aggiungeremo diversi tipi di notifiche per diversi tipi di utenti. Queste differiscono per presentazione e profondità. L'utente business riceverà notifiche del tipo "tutto bene, ma il computer di Ivanov sta per morire". 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 il messaggio.
• Aggiungeremo interazioni con fornitori esterni di servizi basati sull'invio di email con testo già preparato, poiché è proprio l'email che dà avvio alla registrazione di un incidente.
• Tutte le interazioni con il sistema saranno gestite tramite un chatbot, in uno stile dialogico.

Supplemento:

• Aggiungeremo la funzionalità di "chat con l'amministratore", affinché l'utente possa inviare direttamente un messaggio all'amministratore descrivendo il problema.

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

• Prenderemo un computer Raspberry PI economico e pronto all'uso.
• Progetteremo una scheda di alimentazione senza interruzioni.
• Aggiungeremo un modem per la disponibilità indipendente dalle condizioni della rete locale.
• Progetteremo un case elegante.

Abbiamo tre sottosistemi con i propri requisiti e visioni per la loro realizzazione:

• sottosistema hardware;
• sottosistema di monitoraggio;
• sottosistema di interazione utente.

Per il sottosistema hardware abbiamo sviluppato un progetto bozza. Sì, sì! Violando tutte le regole di agile abbiamo redatto un documento, poiché i produttori lavorano proprio con documenti. Per gli altri sottosistemi abbiamo identificato gli utenti (persone), preparato le storie degli utenti e redatto i compiti per lo sviluppo.

A questo punto, la fase concettuale termina e i suoi risultati sono:

• progetto per la piattaforma hardware;
• visione formulata sotto forma di storie degli utenti per gli altri due sottosistemi;
• prototipo della parte software, realizzato sotto forma di virtual machine;
• prototipo della parte hardware, realizzato sotto forma di un banco di prova, dove sono stati testati in effetti le soluzioni hardware;
• test condotto dai nostri amministratori.

I problemi in questa fase erano per lo più di natura organizzativa e legati a una scarsa preparazione del personale ingegneristico sugli aspetti legali e contabili delle vendite. Cioè, un conto è inventare cosa e come vendere e un altro è affrontare una macchina legale spietata: brevetti, incarichi di sviluppo, bilanciamento, EULA e molto altro che noi, come persone creative, non avevamo considerato fin dall'inizio.

Non era ancora un problema, ma piuttosto una difficoltà legata alla progettazione dei corpi. Nella nostra squadra ci sono solo ingegneri, quindi il primo modello del corpo è stato "realizzato" con un foglio di plexiglass dal nostro specialista in elettronica.

Il corpo era, per dirla con delicatezza, discutibile, specialmente per un pubblico abituato alla tecnologia moderna. Certo, ci sono stati estimatori tra i "cittadini" della generazione senior — il corpo ha suscitato in loro sentimenti di nostalgia. È stato deciso di realizzare e progettare nuovamente il corpo, poiché quello vecchio, oltre ai difetti estetici, presentava anche problematiche strutturali — il plexiglass resisteva male al montaggio e smontaggio del dispositivo e tendeva a rompersi. Parlerò più avanti della produzione del corpo.

E ora ci siamo avvicinati al traguardo — MVP. Certo, non è ancora il prodotto finale in serie, ma già porta valore e utilità. L'obiettivo principale di questa fase è avviare il ciclo "crea-valuta-impara". LANBIX si trova esattamente in questa fase.

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

Torniamo alla produzione del corpo, cioè alla sfida di trasformare il nostro dispositivo da evocativo di sentimenti nostalgici a moderno. Inizialmente, ho esaminato il mercato per trovare produttori di corpi e servizi di design industriale. Innanzitutto, ci sono poche aziende in Russland che producono corpi, e in secondo luogo, il costo del design industriale in questa fase è eccessivo, circa 1 milione di rubli.

Ci siamo rivolti al nostro dipartimento marketing per il design, un giovane designer era pronto a esperimenti creativi. Abbiamo esposto la nostra visione del case (dopo aver studiato i migliori esempi di casing), e lui a sua volta l'ha trasformata in un'opera d'arte. Resta solo da produrlo. Noi, orgogliosi del nostro design, ci siamo rivolti ai partner. Il loro amministratore delegato ha immediatamente distrutto le nostre fantasie, sottolineando gratuitamente le cose che non possono essere prodotte nel modo che abbiamo scelto. Il case può essere prodotto, e sarà non peggio di quello di Apple, ma il costo del case sarà tre o quattro volte superiore all'intera elettronica. Dopo una serie di operazioni e approvazioni, abbiamo progettato un case che può essere prodotto. Sì, non è così bello come avevamo pianificato, ma è ideale per raggiungere gli obiettivi attuali.

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

E ora arriviamo alla parte più difficile: la fase «valutare», e con il nostro prodotto ci troviamo proprio in questo punto. Possiamo valutare solo in base ai risultati dell'uso da parte dei veri clienti, e nessuna supposizione funziona qui. Abbiamo bisogno di quei «primi seguaci» per fornire feedback e apportare le modifiche al prodotto che sono realmente necessarie. Si pone la domanda: dove trovare i 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à avviato, ma è ancora presto per parlare dei risultati, anche se ci sono già stati dei feedback 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 di quelli su cui contavamo. Sarebbe stato stupido ignorare questi nuovi input, e sulla base dei risultati delle interviste condotte è stata presa la decisione di avviare una linea parallela di LANBIX chiamata LANBIX Enterprise. Abbiamo aggiunto supporto per infrastrutture distribuite, monitoraggio delle reti Wi-Fi con ricerca e localizzazione dei guasti, monitoraggio della qualità delle linee di comunicazione. Le aziende di servizi hanno mostrato il maggior interesse per la soluzione. Inoltre, i dispositivi già sviluppati da noi giocano un ruolo non trascurabile nel funzionamento delle soluzioni.

Cosa succederà dopo

Cosa accadrà ora con il LANBIX originale sarà chiaro dai risultati della campagna. In caso di mancata conferma delle nostre ipotesi, secondo la metodologia Lean, ci sbarazzeremo spietatamente di esso oppure si trasformerà in qualcosa di nuovo, poiché non c'è nulla di peggio che realizzare un prodotto che nessuno desidera. Già adesso possiamo dire che il lavoro svolto non è stato vano e grazie a esso è emersa una 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 chiare leggi classiche del marketing di prodotto.

Ripeto, ora vogliamo trovare i primi sostenitori, aziende a cui poter installare il nostro prodotto con l'obiettivo di raccogliere feedback. Se siete interessati a testare LANBIX, scrivete nei commenti o nei messaggi privati.

Fonte

Fonte: habr.com