🥇Come lavoriamo con le idee e come è nata LANBIX

Ci sono molti dipendenti creativi in LANIT-Integration. Le idee per nuovi prodotti e progetti sono letteralmente sospese nell'aria. A volte può essere molto difficile individuare quelli più interessanti. Pertanto, insieme abbiamo sviluppato la nostra metodologia. Leggi questo articolo su come selezionare i migliori progetti e realizzarli.

In Russia, e nel mondo nel suo insieme, si stanno verificando numerosi processi che portano alla trasformazione del mercato IT. Grazie all’aumento della potenza di calcolo e all’emergere di server, reti e altre tecnologie di virtualizzazione, il mercato non ha più bisogno di grandi quantità di hardware. I venditori preferiscono sempre più lavorare direttamente con i clienti. Il mercato IT sta vivendo un boom dell’outsourcing in tutte le sue forme, dall’outsourcing classico alla nuova ondata di outsourcer – “fornitori di cloud”. I sistemi e gli elementi dell'infrastruttura diventano molto più facili da mantenere e configurare. La qualità del software cresce ogni anno e i compiti dell'integratore si trasformano.

Come lavoriamo con le idee

Direzione di avvio del prodotto in "Integrazione LANIT" è in circolazione da più di un anno. Il nostro obiettivo principale è creare nuovi prodotti e portarli sul mercato. La prima cosa da cui abbiamo iniziato è stata organizzare il processo di creazione dei prodotti. Abbiamo studiato tante metodologie, dal classico all'hype. Tuttavia, nessuno di loro ha soddisfatto le nostre esigenze. Quindi abbiamo deciso di prendere come base la metodologia Lean Startup e di adattarla ai nostri compiti. La Lean Startup è una teoria dell'imprenditorialità creata da Eric Ries. Si basa sui principi, approcci e pratiche di concetti quali produzione snella, sviluppo del cliente e metodologia di sviluppo flessibile.

Per quanto riguarda l'approccio diretto alla gestione dello sviluppo prodotto: non abbiamo reinventato la ruota, ma abbiamo applicato una metodologia di sviluppo già esistente MISCHIA, aggiungendo creatività, e ora può tranquillamente essere chiamato SCRUM-WATERFALL-BAN. SCRUM, nonostante la sua flessibilità, è un sistema molto rigido ed è adatto a gestire un team responsabile di un solo prodotto/progetto. Come capisci, la classica attività di "integrazione" non prevede l'assegnazione di specialisti tecnici a tempo pieno a lavorare su un progetto (ci sono eccezioni, ma estremamente raramente), poiché oltre a lavorare sui prodotti, tutti sono impegnati con i progetti attuali. Da SCRUM abbiamo preso la divisione del lavoro in sprint, reporting quotidiano, retrospettive e ruoli. Abbiamo scelto Kanban per il nostro flusso di attività e si è integrato bene nel nostro sistema di tracciamento delle attività esistente. Abbiamo strutturato il nostro lavoro integrandoci perfettamente nell’ordine esistente delle cose.
Prima di entrare nel mercato, un prodotto attraversa 5 fasi: idea, selezione, concept, MVP (maggiori dettagli di seguito) e produzione.

Idea

In questa fase c'è qualcosa di effimero: un'idea. Idealmente, un'idea per risolvere un problema esistente o un problema del cliente. Le idee non ci mancano. Secondo il piano iniziale, dovrebbero essere generati dai dipendenti delle aree tecniche. Affinché un'idea possa essere accettata per un ulteriore sviluppo, l'autore deve compilare il “Modello di progettazione dell'idea”. Ci sono solo quattro domande: cosa? Per quello? Chi ne ha bisogno? E se non il nostro prodotto, allora cosa?

Fonte

squadra

Non appena il modello completato ci arriva, inizia la procedura di elaborazione e selezione. La fase di selezione è quella più laboriosa. In questa fase si formano le ipotesi del problema (non per niente ho detto nel paragrafo precedente che idealmente un’idea dovrebbe risolvere il problema del cliente) e il valore del prodotto. Si forma un'ipotesi di scala, cioè come la nostra attività crescerà e prospererà. Vengono condotte interviste sui problemi e sugli esperti con potenziali clienti per fornire la conferma preliminare che produrremo qualcosa di necessario. Sono necessarie almeno 10-15 interviste per trarre una conclusione sulla necessità del prodotto.

Se le ipotesi vengono confermate, viene effettuata un’analisi finanziaria preliminare, viene valutato il volume approssimativo dell’investimento e i possibili guadagni dell’investitore. Come risultato di questa fase, nasce e viene presentato al management un documento chiamato Lean Canvas.

Concetto

In questa fase circa il 70% delle idee vengono eliminate. Se il concept viene approvato, inizia la fase di sviluppo dell'idea. Si forma la funzionalità del prodotto futuro, si determinano i percorsi di implementazione e le soluzioni tecniche ottimali e si aggiorna il piano aziendale. Il risultato di questa fase è una specifica tecnica per lo sviluppo e un business case dettagliato. In caso di successo, si passa alla fase MVP o MVP.

MVP o MVP

MVP è un prodotto minimo vitale. Quelli. un prodotto che non è completamente sviluppato, ma può già apportare valore e svolgere le sue funzionalità. È fondamentale che in questa fase di sviluppo raccogliamo feedback da utenti reali e apportiamo modifiche.

Produzione

E l'ultima fase è la produzione. Non più del 5% dei prodotti raggiunge questa fase. Questo 5% comprende solo i prodotti più importanti, necessari, fattibili e funzionali.

Abbiamo molte idee e abbiamo già messo insieme un voluminoso portfolio. Analizziamo ogni idea e facciamo di tutto affinché raggiunga la fase finale. È molto piacevole che i nostri colleghi non siano rimasti indifferenti alla nostra direzione di ricerca e sviluppo e abbiano preso parte attiva allo sviluppo e all'implementazione di prodotti e soluzioni.

Come abbiamo realizzato LANBIX

Diamo un'occhiata alla creazione di un prodotto utilizzando un esempio reale: il prodotto LANBIX. Si tratta di un sistema software e hardware “boxed” progettato per monitorare piccole infrastrutture IT e allertare tempestivamente decisori e utenti aziendali in caso di malfunzionamenti controllati tramite chatbot. Oltre alla funzione di monitoraggio, LANBIX include funzionalità di Help Desk. Questo prodotto è esclusivo per il segmento di mercato a cui ci rivolgiamo. Questo è sia il nostro vantaggio che il nostro dolore. Ma prima le cose principali. Dirò subito che LANBIX è un prodotto vivo (cioè non è definitivo nel suo sviluppo ed è al prossimo round di MVP).

Quindi, la prima fase è l’idea. Perché un'idea nasca ci vogliono problemi, e noi li abbiamo avuti, anzi non noi, ma i nostri amici. Di seguito esamineremo alcune situazioni reali verificatesi in diverse aree di business.

Una piccola società di gestione gestisce due case nella regione di Mosca. Il personale dotato di PC è di circa 15 persone. L'amministratore di sistema è un libero professionista in visita (il figlio intelligente di uno dei residenti premurosi). Sembrerebbe che le attività della società di gestione dipendano debolmente dall'IT, ma la particolarità di questa attività è la rendicontazione mensile a molte autorità. Il disco di sistema del capo dell'azienda (che, come al solito, combina molti ruoli) ha esaurito lo spazio libero. Naturalmente ciò non è avvenuto all'improvviso: l'avvertimento è rimasto in vigore per circa 2 mesi ed è stato costantemente ignorato. Ma è arrivato un aggiornamento, il sistema operativo è stato aggiornato e, per fortuna, si è bloccato nel bel mezzo dell'aggiornamento, lamentandosi prima della “morte” per un disco occupato. Il computer è stato riavviato ciclicamente. Mentre stavamo risolvendo il problema e ricevendo segnalazioni, non abbiamo rispettato la scadenza per la segnalazione. Sembrerebbe che un banale malfunzionamento abbia causato diversi guai: dalle perdite al contenzioso e alla responsabilità amministrativa.

Fonte

Un incidente simile si è verificato in una grande holding, che unisce 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. Si sapeva da tempo che poteva rompersi (il computer rallentava e si surriscaldava disperatamente), ma il capo contabile non è mai riuscito a inviare una richiesta al supporto tecnico. Naturalmente si è rotto proprio il giorno della paga e i dipendenti del dipartimento sono rimasti senza soldi per diversi giorni.

Una piccola impresa di commercio all'ingrosso aveva un sito web di vendita ospitato su un sito esterno. Abbiamo appreso della sua indisponibilità telefonicamente da un cliente abituale. Al momento della chiamata il sito era inattivo da circa tre ore. Ci sono volute un altro paio d'ore per trovare la persona responsabile del sito e altre due per risolvere il problema. Di conseguenza, il sito è rimasto indisponibile per quasi tutta la giornata lavorativa. Secondo il direttore commerciale dell’azienda, questo fermo macchina è costato circa 1 milione di rubli.

Io stesso ho riscontrato una situazione simile quando sono venuto per un appuntamento in clinica e sono dovuto andare alla registrazione VHI. Non potevano mandarmi dal medico per un motivo banale: al mattino c'era uno sbalzo di corrente e dopo l'incidente il loro servizio postale e un certo servizio di comunicazione con la compagnia assicurativa non funzionavano. In risposta alla mia domanda, dove sono i vostri amministratori, mi è stato detto che il loro amministratore viene a trovarli una volta alla settimana. E adesso (a quell'ora erano già le 16:00) non risponde al telefono. Per almeno 7 ore la clinica è stata isolata dal mondo esterno e non ha potuto fornire servizi a pagamento.

Cosa hanno in comune tutti questi casi? Assolutamente tutti i problemi avrebbero potuto essere prevenuti in anticipo. Con una risposta tempestiva da parte del personale IT, il danno avrebbe potuto essere ridotto. Ciò sarebbe possibile se i primi sintomi fossero interpretati correttamente dagli utenti.

Abbiamo identificato le ipotesi problematiche:

significative perdite monetarie e reputazionali dovute alla bassa velocità di risposta ai guasti nell’infrastruttura IT;
interpretazione errata dei primi sintomi di un malfunzionamento da parte degli utenti.

Cosa può fare il cliente con loro e come evitare situazioni simili in futuro? Non ci sono molte opzioni:

assumere un amministratore di sistema altamente qualificato e farlo lavorare coscienziosamente;
esternalizzare la manutenzione IT a una società di servizi specializzata;
implementare autonomamente un sistema di monitoraggio e segnalazione dei guasti;
fornire formazione agli utenti/personale aziendale sui fondamenti dell'alfabetizzazione informatica.

Accordiamoci sulla terza opzione. Offriamo un sistema di monitoraggio a chi non lo utilizza per vari motivi.

Digressione lirica. Diversi sistemi per il monitoraggio dei servizi IT nel mercato aziendale vengono utilizzati da molto tempo ed i loro vantaggi non sono in discussione. Ho parlato con rappresentanti di grandi aziende, ho osservato come è stato costruito il rapporto tra business e IT. Il direttore tecnico di una grande azienda costruttrice di macchine ha affidato la manutenzione dell'infrastruttura IT a un'azienda esterna, ma lui stesso rimane al corrente di tutte le questioni. Nel suo ufficio è appeso un grande schermo del sistema di monitoraggio con indicatori dello stato dei servizi IT. Quelli più critici sono inclusi nel sistema. In ogni momento il direttore tecnico può sapere qual è lo stato dell'infrastruttura, cosa sta succedendo, dov'è il problema, se i responsabili sono stati avvisati e se il problema è in via di risoluzione.

Le storie sopra elencate hanno spinto il nostro team a riflettere su come creare un sistema di monitoraggio ottimale per le piccole imprese. Di conseguenza è nato LANBIX, un sistema di monitoraggio che può essere implementato da chiunque senza alcuna conoscenza IT. L'obiettivo principale del sistema è semplice, come tutti i sistemi volti ad aumentare la continuità e la disponibilità, riducendo le perdite monetarie e di altro tipo in caso di tempi di inattività non pianificati. Il dispositivo è progettato per ridurre al minimo il tempo che intercorre tra “qualcosa è rotto” e “il problema è stato risolto”.

Per confermare le ipotesi sono state condotte interviste problematiche. Non potevo immaginare quante persone sarebbero disposte a raccontare senza cercare di venderglielo. Ogni conversazione è durata almeno 1,5 ore e abbiamo ricevuto molte informazioni utili per ulteriori sviluppi.

Riassumiamo i risultati di questa fase:

c'è una comprensione del problema,
comprensione del valore: c'è,
C'è un'idea per una soluzione.

La seconda fase è stata più dettagliata. Sulla base dei risultati, abbiamo dovuto presentare al management, che svolge essenzialmente il ruolo di investitore, un business case (lo stesso Lean Canvas) per prendere una decisione sul destino futuro del prodotto.

Abbiamo iniziato con ricerche di mercato e analisi della concorrenza per scoprire chi, cosa e, soprattutto, come si stanno comportando in questo mercato.

Si è scoperto quanto segue.

Sul mercato per il nostro segmento (piccole imprese) non esistono sistemi di monitoraggio box già pronti, ad eccezione di un paio o tre, di cui non parlerò per ovvi motivi.
I nostri principali concorrenti, stranamente, sono amministratori di sistema con script scritti in casa e “componenti aggiuntivi” per sistemi di monitoraggio open source.
Esiste un chiaro problema con l’utilizzo di sistemi di monitoraggio open source. C'è un sistema, c'è un'enorme quantità di informazioni su come lavorare e modificare il sistema in base alle proprie esigenze. Tra gli amministratori che ho intervistato, molti hanno ammesso di non avere abbastanza competenze per realizzare da soli le proprie idee. Ma non possono ammetterlo alla direzione per paura del licenziamento. Risulta essere un circolo vizioso.

Siamo poi passati ad analizzare le esigenze dei nostri potenziali clienti. Abbiamo identificato per noi stessi un segmento di piccole organizzazioni che per qualche motivo non dispongono di un proprio servizio IT, dove l'IT è responsabile dell'amministratore di sistema in arrivo, di un libero professionista o di una società di servizi. Non è stato il lato IT a decidere di entrare, ma il lato business, offrendo ai fondatori e agli imprenditori uno strumento per migliorare la qualità del servizio dell'infrastruttura IT. Un prodotto che dovrebbe aiutare i proprietari a proteggere la propria attività, ma allo stesso tempo aggiungerà lavoro alle persone responsabili dell'IT. Un prodotto che fornisce alle aziende uno strumento per monitorare la qualità del supporto IT.

Come risultato dell'elaborazione dei dati ricevuti, è nato il primo elenco di requisiti (una sorta di arretrato approssimativo) per il prodotto futuro:

il sistema di monitoraggio deve essere basato su una soluzione open source e, di conseguenza, economica;
facile e veloce da installare;
non dovrebbe richiedere conoscenze specifiche in ambito IT, anche un contabile (non volevo in alcun modo offendere i rappresentanti di questa professione) dovrebbe essere in grado di implementare e configurare il sistema;
dovrebbe rilevare automaticamente gli oggetti da monitorare sulla rete;
dovrebbe installare automaticamente (e idealmente automaticamente) gli agenti di monitoraggio;
deve essere in grado di monitorare servizi esterni, almeno un sistema CRM e un sito web di vendita;
dovrebbe avvisare sia l'azienda che l'amministratore di sistema dei problemi;
il grado di profondità e il “linguaggio” degli avvisi dovrebbero essere diversi per l'amministratore e l'azienda;
il sistema deve essere alimentato con il proprio hardware;
il ferro dovrebbe essere il più accessibile possibile;
il sistema dovrebbe essere il più indipendente possibile da fattori esterni.

Successivamente sono stati calcolati gli investimenti nello sviluppo del prodotto (compresi i costi del lavoro per i dipendenti dell'ufficio tecnico). È stato preparato uno schizzo del modello di business e sono stati calcolati gli aspetti economici unitari del prodotto.

Risultato della fase:

portafoglio prodotti di 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 noi, come ingegneri, ci troviamo nel nostro elemento nativo. Esistono delle “liste dei desideri” che vengono scomposte in componenti/sottosistemi/caratteristiche, poi vengono trasformate in specifiche tecniche/storie di utenti, poi in un progetto, ecc. Non mi soffermerò nel dettaglio sul processo di preparazione di una serie di opzioni alternative; passiamo direttamente ai requisiti e ai metodi scelti per la loro attuazione.

requisito
Soluzione

Dovrebbe essere un sistema di monitoraggio aperto;

Prendiamo un sistema di monitoraggio open source.

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

Offriamo un sistema installato in modo che l'utente debba solo accendere il dispositivo e configurarlo un po', come un router.

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

Scriviamo il nostro chatbot per uno dei famosi servizi di messaggistica istantanea e trasferiamo su di esso tutte le interazioni con il sistema.

Il sistema dovrebbe:

rilevare automaticamente gli oggetti necessari per il monitoraggio sulla rete;
installare automaticamente gli agenti di monitoraggio;
Essere in grado di monitorare servizi esterni, almeno un sistema CRM e un sito web di vendita.

Scriviamo componenti aggiuntivi per il sistema di monitoraggio per:

rilevamento automatico degli oggetti;
installazione automatica di agenti;
monitorare la disponibilità dei servizi esterni.

Il sistema dovrebbe:

avvisare sia l'azienda che l'amministratore di sistema dei problemi;
essere in grado di monitorare servizi esterni, almeno un sistema CRM e un sito web di vendita. Il grado di profondità e il “linguaggio” delle notifiche dovrebbero essere diversi per l'amministratore e l'azienda.
Il sistema non dovrebbe richiedere conoscenze IT specifiche; anche un contabile dovrebbe essere in grado di implementare e configurare il sistema.

Aggiungiamo diversi tipi di notifiche per diversi tipi di utenti. Differiscono in tono e profondità. Un utente aziendale riceverà notifiche del tipo “va tutto bene, ma il computer di Ivanov morirà presto”. L'amministratore riceverà un messaggio completo sull'errore, chi, come e cosa è successo o potrebbe succedere.
Aggiungiamo la possibilità di utilizzare la posta di un'ulteriore persona responsabile, in modo che in caso di guasto riceva un messaggio.
Aggiungiamo l'interazione con fornitori di servizi esterni basata sull'invio di e-mail con testo pre-preparato, perché È proprio l'e-mail a dare origine all'incidente.
Tutta l'interazione con il sistema sarà collegata a un chatbot; la comunicazione è condotta in stile dialogo.

integrare:

Aggiungiamo la funzionalità di “chat con l'amministratore” in modo che l'utente possa inviare direttamente all'amministratore un messaggio descrivendo il problema.

Il sistema deve essere fornito con il proprio hardware.
Il ferro deve essere disponibile.
Il sistema dovrebbe essere il più indipendente possibile dall’ambiente.

Prendiamo un computer Raspberry PI già pronto ed economico.
Progetteremo una scheda di alimentazione continua.
Aggiungiamo un modem per essere indipendenti dallo stato della rete locale.
Progetteremo un bellissimo edificio.

Ora disponiamo di tre sottosistemi con i propri requisiti e visione per la loro implementazione:

sottosistema hardware;
sottosistema di monitoraggio;
sottosistema di interazione dell'utente.

Abbiamo sviluppato un progetto preliminare per il sottosistema hardware. Si si! Avendo violato tutte le regole dell'agile, abbiamo sviluppato un documento, perché gli stabilimenti di produzione lavorano con i documenti. Per i restanti sottosistemi, abbiamo identificato gli utenti (persone), preparato le storie degli utenti e scritto le attività per lo sviluppo.

Questo conclude la fase concettuale e il risultato è:

progetto per una piattaforma hardware;
visione formulata sotto forma di storie di utenti per i restanti due sottosistemi;
un prototipo software implementato come macchina virtuale;
un prototipo dell'hardware, realizzato sotto forma di supporto, dove è stata effettivamente testata la resistenza delle soluzioni hardware;
test effettuati dai nostri amministratori.

I problemi in questa fase erano soprattutto organizzativi e legati alla scarsa conoscenza da parte del personale tecnico degli aspetti legali e contabili delle vendite. Quelli. Una cosa è capire cosa e come vendere, un'altra è trovarsi di fronte a una macchina legale spietata: brevetti, compiti di sviluppo, registrazione, EULA e molto altro di cui noi, come persone creative, inizialmente non avevamo preso in considerazione.

Non c'era ancora un problema, ma piuttosto una difficoltà legata alla progettazione delle recinzioni. Il nostro team è composto solo da ingegneri, quindi la prima versione della custodia è stata "costruita" in plexiglass dal nostro specialista di elettronica.

Il corpo sembrava, per usare un eufemismo, controverso, soprattutto per il pubblico, rovinato dalla tecnologia moderna. Naturalmente c'erano degli intenditori tra la vecchia generazione di "Kulibins": l'edificio evocava in loro sentimenti nostalgici. Si è deciso di produrre e progettare di nuovo la custodia, poiché quella vecchia, oltre ai difetti estetici, presentava anche quelli strutturali: il plexiglass non tollerava bene il montaggio e lo smontaggio del dispositivo e tendeva a rompersi. Ti parlerò ulteriormente della produzione del caso.

E ora siamo vicini al traguardo: MVP. Naturalmente questo non è ancora un prodotto di produzione finale, ma è già utile e prezioso. L’obiettivo principale di questa fase è avviare il ciclo “crea-valuta-impara”. Questa è esattamente la fase in cui si trova LANBIX.

Nella fase di "creazione", abbiamo creato un dispositivo che esegue la funzionalità dichiarata. Sì, non è ancora perfetto e abbiamo continuato a lavorarci.

Torniamo alla fabbricazione del corpo, ad es. al compito di trasformare il nostro dispositivo da nostalgico a moderno. All'inizio ho esplorato il mercato alla ricerca di produttori di mobili e servizi di progettazione industriale. In primo luogo, non sono molte le aziende che producono custodie sul mercato russo e, in secondo luogo, il costo del design industriale in questa fase è proibitivo, circa 1 milione di rubli.

Hanno contattato il nostro reparto marketing per il design; il giovane designer era pronto per esperimenti creativi. Abbiamo delineato la nostra visione dello scafo (dopo aver studiato in precedenza i migliori esempi di costruzione dello scafo) e lui, a sua volta, l'ha trasformata in un'opera d'arte. Non resta che produrlo. Noi, orgogliosi del nostro design, ci siamo rivolti ai nostri partner. Il loro CEO ha immediatamente stroncato le nostre fantasie segnalandoci, in modo del tutto gratuito, cose che non potevano essere prodotte nel modo da noi scelto. Il case può essere prodotto e non sarà peggiore di quello di Apple, ma il suo costo sarà da tre a quattro volte più alto di quello di tutti i componenti elettronici. Dopo una serie di operazioni e approvazioni, abbiamo progettato un involucro producibile. Sì, non è bello come avevamo previsto, ma è l’ideale per raggiungere gli obiettivi attuali.

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

E adesso la cosa più difficile è la fase di “valutazione”, e con il nostro prodotto siamo esattamente a questo punto. Possiamo valutare solo in base ai risultati di utilizzo da parte di clienti reali e nessuna ipotesi funziona qui. Abbiamo bisogno che questi “early adopter” forniscano feedback e apportino le modifiche al prodotto realmente necessarie. La domanda sorge spontanea: dove trovare i clienti e come convincerli a prendere parte all'esperimento?

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

Il processo è già stato avviato, ma è troppo presto per parlare di risultati, anche se le risposte ci sono già e abbiamo avuto conferma di molte delle nostre ipotesi. Una piacevole sorpresa è stata la reazione dei rappresentanti di segmenti di business completamente diversi, molto più ampi di quelli che ci aspettavamo. Sarebbe sciocco ignorare le novità e, sulla base dei risultati delle interviste, si è deciso di lanciare una linea LANBIX parallela denominata LANBIX Enterprise. Abbiamo aggiunto il supporto per le infrastrutture distribuite, il monitoraggio delle reti Wi-Fi con risoluzione dei problemi e localizzazione e il monitoraggio della qualità dei canali di comunicazione. Le società di servizi hanno espresso il massimo interesse per la soluzione. Allo stesso tempo, i dispositivi che abbiamo già sviluppato svolgono un ruolo importante nel funzionamento delle soluzioni.

Cosa succederà dopo?

Ciò che accadrà dopo con il LANBIX originale diventerà chiaro in base ai risultati della campagna. Se le nostre ipotesi non verranno confermate, secondo la metodologia Lean, ce ne libereremo spietatamente oppure verrà trasformato in qualcosa di nuovo, perché non c'è niente di peggio che realizzare un prodotto di cui nessuno ha bisogno. Ma ora possiamo dire che il lavoro svolto non è stato vano e grazie ad esso è apparso un intero ramo di prodotti paralleli, sui quali stiamo lavorando attivamente. In caso di successo, LANBIX passerà dalla fase MVP alla fase finale e si svilupperà secondo le comprensibili leggi classiche del marketing del prodotto.

Ripeto, ora vogliamo trovare gli early adopter, aziende che possano installare il nostro prodotto per raccogliere feedback. Se sei interessato a testare LANBIX, scrivi nei commenti o nei messaggi privati.

Fonte

Fonte: habr.com

Come lavoriamo con le idee e come è nata LANBIX