Miten työskentelemme ideoiden kanssa ja miten LANBIX syntyi

LANIT-Integrationilla on paljon luovia työntekijöitä. Ideoita uusiin tuotteisiin ja projekteihin roikkuu kirjaimellisesti ilmassa. Joskus voi olla hyvin vaikeaa tunnistaa kiinnostavimpia. Siksi kehitimme yhdessä oman menetelmämme. Lue tästä artikkelista, kuinka voit valita parhaat projektit ja toteuttaa ne.

Venäjällä ja koko maailmassa on meneillään useita prosesseja, jotka johtavat IT-markkinoiden muutokseen. Laskentatehon kasvun ja palvelin-, verkko- ja muiden virtualisointiteknologioiden ilmaantumisen ansiosta markkinat eivät enää tarvitse suuria määriä laitteistoja. Myyjät haluavat yhä enemmän työskennellä suoraan asiakkaiden kanssa. IT-markkinat kokevat ulkoistamisbuumia kaikissa muodoissaan klassisista ulkoistamisesta uuteen ulkoistaja-aaltoon - "pilvipalveluntarjoajiin". Infrastruktuurijärjestelmiä ja -elementtejä on paljon helpompi ylläpitää ja konfiguroida. Ohjelmistojen laatu kasvaa vuosi vuodelta ja integraattorin tehtävät muuttuvat.

Kuinka työskentelemme ideoiden kanssa

Tuotteen käynnistyssuunta sisään "LANIT-integraatio" on ollut olemassa yli vuoden. Päätavoitteemme on luoda uusia tuotteita ja tuoda niitä markkinoille. Ensimmäinen asia, josta aloitimme, oli tuotteiden luomisprosessin organisointi. Olemme tutkineet monia menetelmiä klassikosta hypeen. Yksikään niistä ei kuitenkaan vastannut tarpeitamme. Sitten päätimme ottaa Lean Startup -metodologian pohjaksi ja mukauttaa sen tehtäviimme. Lean Startup on Eric Riesin luoma yrittäjyyden teoria. Se perustuu sellaisten käsitteiden periaatteisiin, lähestymistapoihin ja käytäntöihin kuin lean valmistus, asiakaskehitys ja joustava kehitysmetodologia.

Mitä tulee suora lähestymistapa tuotekehityksen hallintaan: emme keksineet pyörää uudelleen, vaan sovelsimme jo olemassa olevaa kehitysmetodologiaa SCRUM, lisää luovuutta, ja nyt sitä voidaan turvallisesti kutsua SCRUM-WATERFALL-BANiksi. SCRUM on joustavuudestaan ​​huolimatta erittäin jäykkä järjestelmä ja sopii vain yhdestä tuotteesta/projektista vastaavan tiimin johtamiseen. Kuten ymmärrät, klassinen "integraatio"-liiketoiminta ei sisällä kokopäiväisten teknisten asiantuntijoiden määräämistä työskentelemään yhdessä projektissa (poikkeuksia on, mutta erittäin harvoin), koska tuotteiden parissa työskentelemisen lisäksi kaikki ovat kiireisiä nykyisten projektien parissa. SCRUMilta otimme työnjaon sprinteihin, päivittäiseen raportointiin, retrospektiiviin ja rooleihin. Valitsimme Kanbanin tehtävänkulkuamme ja se integroitui hyvin olemassa olevaan tehtävänseurantajärjestelmäämme. Järjestimme työmme sulautumalla saumattomasti olemassa olevaan asioiden järjestykseen.
Ennen markkinoille tuloa tuote käy läpi 5 vaihetta: idea, valinta, konsepti, MVP (lisätietoja alla) ja tuotanto.

Ajatus

Tässä vaiheessa on jotain ohimenevää – ideaa. Ihannetapauksessa idea olemassa olevan ongelman tai asiakkaan ongelman ratkaisemiseksi. Ideoista meillä ei ole pulaa. Alkuperäisen suunnitelman mukaan ne tulisi tuottaa teknisten alueiden työntekijöiden toimesta. Jotta idea hyväksyttäisiin jatkokehitettäväksi, tekijän on täytettävä Idea Design Template. On vain neljä kysymystä: Mitä? Minkä vuoksi? Kuka tarvitsee tätä? Ja jos ei meidän tuotteemme, niin mitä sitten?

Lähde

Valinta

Heti kun valmis malli on saapunut meille, käsittely- ja valintaprosessi alkaa. Valintavaihe on työvoimavaltaisin. Tässä vaiheessa muodostuu hypoteeseja ongelmista (ei turhaan maininnut edellisessä kappaleessa, että idean pitäisi ihannetapauksessa ratkaista asiakkaan ongelma) ja tuotteen arvosta. Muodostetaan mittakaavahypoteesi, ts. kuinka yrityksemme tulee kasvamaan ja menestymään. Potentiaalisten asiakkaiden kanssa tehdään ongelma- ja asiantuntijahaastatteluja, jotta saadaan alustava vahvistus siitä, että aiomme tuottaa jotain tarpeellista. Vaatii vähintään 10-15 haastattelua tehdäkseen johtopäätöksen tuotteen tarpeesta.

Jos olettamukset vahvistuvat, tehdään alustava taloudellinen analyysi, arvioidaan sijoituksen likimääräinen määrä ja sijoittajan mahdollinen tuotto. Tämän vaiheen tuloksena syntyy dokumentti nimeltä Lean Canvas, joka esitetään johdolle.

Käsite

Tässä vaiheessa noin 70 % ideoista eliminoidaan. Jos konsepti hyväksytään, alkaa idean kehitysvaihe. Muodostetaan tulevan tuotteen toimivuus, määritetään toteutuspolut ja optimaaliset tekniset ratkaisut sekä päivitetään liiketoimintasuunnitelma. Tämän vaiheen tuloksena on tekninen kehitysspesifikaatio ja yksityiskohtainen liiketoimintamalli. Jos onnistumme, siirrymme MVP- tai MVP-vaiheeseen.

MVP tai MVP

MVP on vähintään elinkelpoinen tuote. Nuo. tuote, joka ei ole täysin kehitetty, mutta joka voi jo tuoda lisäarvoa ja suorittaa toiminnallisuutensa. Tässä kehitysvaiheessa keräämme palautetta todellisilta käyttäjiltä ja teemme muutoksia.

Производство

Ja aivan viimeinen vaihe on tuotanto. Enintään 5 % tuotteista saavuttaa tämän vaiheen. Tämä 5 % sisältää vain tärkeimmät, välttämättömät, elinkelpoisimmat ja toimivat tuotteet.

Meillä on paljon ideoita ja olemme jo koonneet laajan portfolion. Analysoimme jokaisen idean ja teemme kaikkemme varmistaaksemme, että se saavuttaa loppuvaiheen. On erittäin mukavaa, että kollegamme eivät olleet välinpitämättömiä T&K-suunnassamme ja ovat aktiivisesti mukana tuotteiden ja ratkaisujen kehittämisessä ja toteutuksessa.

Kuinka teimme LANBIXin

Katsotaanpa tuotteen luomista käyttämällä todellista esimerkkiä - LANBIX-tuotetta. Tämä on "laatikollinen" ohjelmisto- ja laitteistojärjestelmä, joka on suunniteltu pienten IT-infrastruktuurien valvontaan ja nopeaan hälytykseen päätöksentekijöille ja yrityskäyttäjille chatbotin kautta ohjatuista toimintahäiriöistä. Valvontatoiminnon lisäksi LANBIX sisältää Help Desk -toiminnon. Tämä tuote on tarkoitettu vain sille markkinasegmentille, johon kohdistamme. Tämä on sekä etumme että tuskamme. Mutta ensin asiat ensin. Sanon heti, että LANBIX on elävä tuote (eli se ei ole lopullinen kehityksessään ja on seuraavalla MVP-kierroksella).

Ensimmäinen vaihe on siis idea. Idean syntymiseen tarvitaan ongelmia, ja niitä oli meillä, tai pikemminkin emme me, vaan ystävämme. Alla tarkastellaan useita todellisia tilanteita, jotka tapahtuivat eri toimialoilla.

Pieni rahastoyhtiö ylläpitää kahta taloa Moskovan alueella. Henkilökuntaa tietokoneilla on noin 15 henkilöä. Järjestelmän ylläpitäjä on vieraileva freelancer (yhden huolehtivan asukkaan älykäs poika). Vaikuttaa siltä, ​​että hallinnointiyhtiön toiminta on heikosti riippuvaista IT:stä, mutta tämän liiketoiminnan erityispiirre on kuukausittainen raportointi monille viranomaisille. Yrityksen päällikön järjestelmälevyltä (joka, kuten tavallista, yhdistää monia rooleja) on loppunut vapaa tila. Tämä ei tietenkään tapahtunut yhtäkkiä, varoitus kesti noin 2 kuukautta ja jätettiin jatkuvasti huomiotta. Mutta päivitys saapui, käyttöjärjestelmä päivitettiin ja, kuten onni, se jumiutui kesken päivityksen valittaen ennen "kuolemaa" varatusta levystä. Tietokone meni sykliseen uudelleenkäynnistykseen. Samalla kun selvitimme ongelmaa ja saimme raportteja, myöhästyimme raportoinnin määräajasta. Vaikuttaa siltä, ​​että vähäpätöinen toimintahäiriö on aiheuttanut erilaisia ​​ongelmia: tappioista oikeudenkäynteihin ja hallinnolliseen vastuuseen.

Lähde   

Vastaava tapaus sattui suuressa holdingyhtiössä, joka yhdisti monia pieniä yrityksiä, ja koko toimiston tekninen tukipalvelu oli yksi. Yhdellä osastolla pääkirjanpitäjän tietokone meni rikki. Se oli tiedossa jo pitkään, että se voi rikkoutua (tietokone oli epätoivoisesti hidastunut ja lämpenemässä), mutta pääkirjanpitäjä ei koskaan päässyt lähettämään pyyntöä tekniselle tuelle. Luonnollisesti se meni rikki juuri palkkapäivänä ja osaston työntekijät olivat ilman rahaa useita päiviä.

Pientukkukaupan pienyrityksellä oli myyntisivusto, jota isännöi ulkopuolinen sivusto. Saimme tiedon sen epäsuotuisuudesta puhelimitse kanta-asiakkaalta. Soittohetkellä sivusto oli ollut poissa käytöstä noin kolme tuntia. Kesti vielä pari tuntia sivustosta vastaavan henkilön löytämiseen ja vielä kaksi tuntia ongelman korjaamiseen. Näin ollen sivusto oli poissa käytöstä lähes koko työpäivän. Yrityksen kaupallisen johtajan mukaan tämä seisokki maksoi heille noin miljoona ruplaa.

Itse törmäsin vastaavaan tilanteeseen tullessani vastaanotolle ja jouduin VHI-ilmoittautumiseen. He eivät voineet lähettää minua lääkäriin vähäpätöisestä syystä - aamulla oli sähköpiikki, ja onnettomuuden jälkeen heidän postipalvelunsa ja tietty palvelu vakuutusyhtiön kanssa ei toiminut. Vastauksena kysymykseeni, missä järjestelmänvalvojasi ovat, minulle kerrottiin, että heidän järjestelmänvalvojansa tulee käymään heidän luonaan kerran viikossa. Ja nyt (kello oli tuolloin jo 16) hän ei ota puhelinta. Klinikka oli ainakin 00 tunnin ajan erillään ulkomaailmasta eikä pystynyt tarjoamaan maksullisia palveluita.

Mitä yhteistä kaikilla näillä tapauksilla on? Ehdottomasti kaikki ongelmat olisi voitu ennaltaehkäistä. IT-henkilöstön ajoissa reagoimalla vahinkoja olisi voitu vähentää. Tämä olisi mahdollista, jos käyttäjät tulkitsisivat oikein varhaiset oireet.

Olemme tunnistaneet ongelmahypoteesit:

• merkittävät raha- ja mainetappiot IT-infrastruktuurin vikojen hitauden vuoksi;
• käyttäjien virheelliset tulkinnat toimintahäiriön alkuoireista.

Mitä asiakas voi tehdä niille ja miten välttää vastaavat tilanteet tulevaisuudessa? Vaihtoehtoja ei ole montaa:

1. palkkaa korkeasti koulutettu järjestelmänvalvoja ja saa hänet työskentelemään tunnollisesti;
2. ulkoista IT-huolto erikoistuneelle palveluyritykselle;
3. toteuttaa itsenäisesti valvonta- ja vikailmoitusjärjestelmä;
4. tarjota käyttäjille/yrityshenkilöstölle koulutusta tietokonelukutaidon perusteista.

Päädytään kolmanteen vaihtoehtoon. Tarjotaan valvontajärjestelmä niille, jotka eivät käytä sitä eri syistä.

Lyyrinen poikkeama. Yritysmarkkinoiden IT-palveluiden seurantaan on käytetty erilaisia ​​järjestelmiä jo pitkään, eikä niiden eduista ole kiistaa. Juttelin suurten yritysten edustajien kanssa, katsoin kuinka liiketoiminnan ja IT:n suhdetta rakennettiin. Erään suuren koneenrakennusyrityksen tekninen johtaja on ulkoistanut IT-infrastruktuurin ylläpidon ulkopuoliselle yritykselle, mutta hän itse pysyy perillä kaikista asioista. Hänen toimistossaan roikkuu suuri valvontajärjestelmän näyttö, jossa on IT-palvelujen tilan indikaattorit. Kriittisimmät ovat mukana järjestelmässä. Tekninen johtaja voi milloin tahansa selvittää, mikä infrastruktuurin tila on, mitä tapahtuu, missä ongelma on, onko vastuuhenkilöille ilmoitettu ja onko ongelmaa ratkomassa.

Yllä luetellut tarinat saivat tiimimme pohtimaan, kuinka luoda optimaalinen seurantajärjestelmä pienille yrityksille. Tuloksena syntyi LANBIX - valvontajärjestelmä, jonka voi ottaa käyttöön täysin kuka tahansa ilman IT-taitoja. Järjestelmän päätavoite on yksinkertainen, kuten kaikkien järjestelmien, joilla pyritään lisäämään jatkuvuutta ja saatavuutta - vähentämään rahallisia ja muita tappioita odottamattomien seisokkien sattuessa. Laite on suunniteltu minimoimaan aika "jotain on rikki" ja "ongelma on korjattu" välillä.

Hypoteesien vahvistamiseksi suoritettiin ongelmahaastattelut. En voinut kuvitella, kuinka paljon ihmiset olisivat valmiita kertomaan yrittämättä myydä heille. Jokainen keskustelu kesti vähintään 1,5 tuntia ja saimme paljon jatkokehityksen kannalta hyödyllistä tietoa.

Tehdään yhteenveto tämän vaiheen tuloksista:

1. ongelmasta löytyy ymmärrystä,
2. arvon ymmärtäminen - on olemassa,
3. On olemassa idea ratkaisuksi.

Toinen vaihe oli yksityiskohtaisempi. Sen tulosten perusteella jouduimme esittelemään olennaisesti sijoittajan roolia edustavalle johdolle bisnestapaus (sama Lean Canvas) tehdäkseen päätöksen tuotteen tulevasta kohtalosta.

Aloitimme markkinatutkimuksella ja kilpailuanalyysillä saadaksemme selville, kuka, mitä ja mikä tärkeintä, miten heillä menee näillä markkinoilla.

Asiasta selvisi seuraavaa.

1. Segmentillemme (pienyritykset) ei ole markkinoilla valmiita laatikoituja valvontajärjestelmiä paria tai kolmea lukuun ottamatta, joista en ilmeisistä syistä kerro.
2. Tärkeimmät kilpailijamme ovat, kummallista kyllä, järjestelmänvalvojat, joilla on kotikirjoitetut skriptit ja "lisäosat" avoimen lähdekoodin valvontajärjestelmiin.
3. Avoimen lähdekoodin valvontajärjestelmien käytössä on selvä ongelma. On olemassa järjestelmä, on valtava määrä tietoa siitä, kuinka toimia ja muokata järjestelmää tarpeidesi mukaan. Haastattelemistani ylläpitäjistä monet myönsivät, että heillä ei ollut tarpeeksi pätevyyttä toteuttaa omia ideoitaan. Mutta he eivät voi myöntää tätä johdolle irtisanomisen pelossa. Se osoittautuu noidankehäksi.

Tämän jälkeen siirryimme analysoimaan potentiaalisten asiakkaidemme tarpeita. Olemme tunnistaneet itsellemme segmentin pieniä organisaatioita, joilla ei jostain syystä ole omaa IT-palvelua, jossa IT-asioista vastaa joko saapuva järjestelmävastaava, freelancer tai palveluyritys. IT-puoli ei päättänyt tulla mukaan, vaan yrityspuoli, joka tarjosi perustajille ja yritysten omistajille työkalun IT-infrastruktuuripalvelun laadun parantamiseen. Tuote, jonka pitäisi auttaa omistajia turvaamaan liiketoimintansa, mutta samalla se tuo työtä IT:stä vastaaville ihmisille. Tuote, joka tarjoaa yrityksille työkalun IT-tuen laadun seurantaan.

Vastaanotettujen tietojen käsittelyn tuloksena syntyi ensimmäinen vaatimuslista (eräänlainen karkea ruuhka) tulevalle tuotteelle:

• seurantajärjestelmän tulee perustua avoimen lähdekoodin ratkaisuun ja sen seurauksena halpa;
• helppo ja nopea asentaa;
• ei pitäisi vaatia erityisiä tietotekniikan tuntemuksia, jopa kirjanpitäjän (en missään nimessä halunnut loukata tämän ammatin edustajia) pitäisi pystyä ottamaan käyttöön ja määrittämään järjestelmän;
• pitäisi automaattisesti havaita kohteet valvomista varten verkossa;
• pitäisi automaattisesti (ja mieluiten automaattisesti) asentaa valvontaagentit;
• on kyettävä valvomaan ulkoisia palveluita, vähintään CRM-järjestelmää ja myyntisivustoa;
• tulee ilmoittaa ongelmista sekä yritykselle että järjestelmänvalvojalle;
• hälytysten syvyyden ja "kielen" tulisi olla erilainen järjestelmänvalvojan ja yrityksen osalta;
• järjestelmä on toimitettava omalla laitteistollaan;
• raudan tulee olla mahdollisimman helposti saatavilla;
• järjestelmän tulee olla mahdollisimman riippumaton ulkoisista tekijöistä.

Seuraavaksi laskettiin panostukset tuotekehitykseen (mukaan lukien teknisen osaston työntekijöiden työvoimakustannukset). Liiketoimintamallista laadittiin luonnos ja laskettiin tuotteen yksikkötalous.

Vaiheen tulos:

• korkean tason tuotteiden ruuhka;
• muotoiltu liiketoimintamalli tai mittakaavahypoteesi, jota ei ole vielä testattu käytännössä.

Siirrytään seuraavaan vaiheeseen - konseptiin. Täällä me insinöörinä löydämme itsemme alkuperäisestä elementistämme. On olemassa "toivelistoja", jotka jaetaan komponenteiksi/alijärjestelmiksi/ominaisuuksiksi, sitten niistä tehdään teknisiä määrityksiä/käyttäjätarinoita, sitten projekteja jne. En käsittele yksityiskohtaisesti joukon vaihtoehtoisten vaihtoehtojen valmisteluprosessia, vaan siirrytään suoraan vaatimuksiin ja valittuihin menetelmiin niiden toteuttamiseksi.

Vaatimus
päätös

• Sen pitäisi olla avoin seurantajärjestelmä;

Otamme avoimen lähdekoodin seurantajärjestelmän.

• Järjestelmän tulee olla yksinkertainen ja nopea asentaa;
• ei tarvitse vaatia erityistä IT-osaamista. Jopa kirjanpitäjän pitäisi pystyä ottamaan käyttöön ja konfiguroimaan järjestelmä.

Tarjoamme asennettua järjestelmää niin, että käyttäjän tarvitsee vain käynnistää laite ja konfiguroida sitä vähän, kuten reititin.

Suljetaan vuorovaikutus laitteen kanssa johonkin yksinkertaiseen ja kaikille ymmärrettävään.

Kirjoitetaan oma chatbot yhdelle tunnetuista pikaviestinnästä ja siirretään kaikki vuorovaikutus järjestelmän kanssa siihen.

Järjestelmän pitäisi:

• tunnistaa automaattisesti verkon valvontaan tarvittavat kohteet;
• automaattisesti asentaa valvonta-agentit;
• Pystyt seuraamaan ulkoisia palveluita, vähintään CRM-järjestelmää ja myyntisivustoa.

Kirjoitamme lisäosia valvontajärjestelmään:

• automaattinen esineen havaitseminen;
• agenttien automaattinen asennus;
• ulkopuolisten palvelujen saatavuuden seuranta.

Järjestelmän pitäisi:

• ilmoittaa ongelmista sekä yritykselle että järjestelmänvalvojalle;
• pystyt seuraamaan ulkoisia palveluita, vähintään CRM-järjestelmää ja myyntisivustoa. Ilmoitusten syvyyden ja "kielen" tulee olla erilainen järjestelmänvalvojan ja yrityksen osalta.
• Järjestelmän ei pitäisi vaatia erityistä IT-osaamista, vaikka kirjanpitäjän tulisi pystyä ottamaan käyttöön ja konfiguroimaan järjestelmä.

• Lisätään erityyppisiä ilmoituksia erityyppisille käyttäjille. Ne eroavat korkeudeltaan ja syvyydeltään. Yrityskäyttäjä saa ilmoituksia kuten "kaikki on hyvin, mutta Ivanovin tietokone kuolee pian". Ylläpitäjä saa täydellisen viestin virheestä, kuka, miten ja mitä tapahtui tai voi tapahtua.
• Lisätään mahdollisuus käyttää ylimääräisen vastuuhenkilön postia, jotta hän saa viestin vian sattuessa.
• Lisätään vuorovaikutusta ulkoisten palveluntarjoajien kanssa, jotka perustuvat sähköpostien lähettämiseen valmiilla tekstillä, koska Se on sähköposti, joka aiheuttaa tapahtuman.
• Kaikki vuorovaikutus järjestelmän kanssa yhdistetään chatbotiin, viestintä tapahtuu dialogityyliin.

täydentämään

• Lisätään "chat with administrator" -toiminto, jotta käyttäjä voi lähettää järjestelmänvalvojalle suoraan ongelmaa kuvaavan viestin.

• Järjestelmä on toimitettava omalla laitteistollaan.
• Rautaa pitää olla saatavilla.
• Järjestelmän tulee olla mahdollisimman riippumaton ympäristöstä.

• Otetaanpa valmis ja halpa Raspberry PI -tietokone.
• Suunnittelemme keskeytymättömän virtalähdekortin.
• Lisätään modeemi olemaan riippumaton paikallisverkon tilasta.
• Suunnittelemme kauniin rakennuksen.

Meillä on nyt kolme alajärjestelmää, joilla on omat vaatimuksensa ja näkemyksensä niiden toteuttamisesta:

• laitteisto-alijärjestelmä;
• seuranta osajärjestelmä;
• käyttäjän vuorovaikutuksen alijärjestelmä.

Teimme alustavan suunnittelun laitteisto-alijärjestelmälle. Kyllä kyllä! Kaikkia ketterän sääntöjä rikkoen kehitimme dokumentin, koska tuotantolaitokset työskentelevät asiakirjojen kanssa. Muille osajärjestelmille tunnistimme käyttäjät (henkilöt), valmistelimme käyttäjätarinoita ja kirjoitimme tehtäviä kehitystä varten.

Tämä päättää konseptivaiheen, ja tulos on:

• projekti laitteistoalustalle;
• muotoiltu visio käyttäjätarinoiden muodossa kahdelle muulle alajärjestelmälle;
• ohjelmiston prototyyppi, joka on toteutettu virtuaalikoneena;
• laitteiston prototyyppi, toteutettu telineen muodossa, jossa laitteistoratkaisujen lujuus testattiin;
• järjestelmänvalvojien suorittamat testaukset.

Ongelmat olivat tässä vaiheessa lähinnä organisatorisia ja liittyivät insinöörihenkilöstön tietämättömyyteen myynnin juridisista ja kirjanpidollisista näkökohdista. Nuo. Yksi asia on miettiä mitä ja miten myydä, ja aivan toinen asia on kohdata armoton lakikoneisto: patentit, kehitystehtävät, rekisteröinnit, EULA ja paljon muuta, mitä me luovina ihmisinä emme alun perin huomioineet.

Ei vielä ollut ongelmaa, vaan pikemminkin koteloiden suunnitteluun liittyvä vaikeus. Tiimimme koostuu vain insinööreistä, joten elektroniikka-asiantuntijamme "rakensi" kotelon ensimmäisen version pleksilasista.

Keho näytti lievästi sanottuna kiistanalaiselta, varsinkin yleisölle, modernin tekniikan pilaama. Vanhemman "Kulibinien" sukupolven joukossa oli tietysti asiantuntijoita - rakennus herätti heissä nostalgisia tunteita. Kotelo päätettiin valmistaa ja suunnitella uudelleen, koska vanhassa oli esteettisten puutteiden lisäksi myös rakenteellisia - pleksi ei kestänyt hyvin laitteen kokoamista ja purkamista ja sillä oli taipumus halkeilla. Kerron sinulle kotelon valmistuksesta lisää.

Ja nyt olemme lähellä maaliviivaa - MVP. Tämä ei tietenkään ole vielä lopullinen tuotantotuote, mutta se on jo hyödyllinen ja arvokas. Tämän vaiheen päätavoitteena on käynnistää "luo-arvioi-opi" -sykli. Juuri tässä vaiheessa LANBIX on.

"Luo"-vaiheessa loimme laitteen, joka suorittaa ilmoitetut toiminnot. Kyllä, se ei ole vielä täydellinen, ja jatkoimme sen parissa työskentelemistä.

Palataan vielä rungon valmistukseen, ts. tehtävään muuttaa laitteemme nostalgisesta moderniksi. Alussa selailin kaappivalmistajien ja teollisen muotoilun markkinoiden markkinoita. Ensinnäkin Venäjän markkinoilla ei ole paljon koteloita valmistavia yrityksiä, ja toiseksi teollisen suunnittelun kustannukset ovat tässä vaiheessa kohtuuttoman korkeat, noin miljoona ruplaa.

He ottivat yhteyttä markkinointiosastoomme suunnittelua varten, nuori suunnittelija oli valmis luoviin kokeiluihin. Esitimme näkemyksemme rungosta (olemme aiemmin tutkineet parhaita esimerkkejä rungon rakentamisesta), ja hän puolestaan ​​teki siitä taideteoksen. Jäljelle jää vain sen valmistaminen. Suunnittelustamme ylpeinä käännyimme kumppaneidemme puoleen. Heidän toimitusjohtajansa murskasi heti fantasiamme toteamalla täysin ilmaiseksi asioita, joita ei voitu tuottaa valitsemallamme tavalla. Kotelo voidaan valmistaa, eikä se ole huonompi kuin Applen, mutta kotelon hinta on kolme-neljä kertaa kalliimpi kuin kaikki elektroniset komponentit. Useiden toimenpiteiden ja hyväksyntöjen jälkeen olemme suunnitelleet kotelon, joka voidaan valmistaa. Kyllä, se ei ole niin kaunis kuin suunnittelimme, mutta se on ihanteellinen nykyisten tavoitteiden saavuttamiseen.

Vaiheen tulos: ensimmäinen erä laitteita valmiina taisteluun ja testaukseen.

Ja nyt vaikein on "arviointi"-vaihe, ja tuotteemme kanssa olemme juuri tässä vaiheessa. Voimme arvioida vain todellisten asiakkaiden käytön tulosten perusteella, eivätkä oletukset toimi tässä. Tarvitsemme näitä "varhaisia ​​omaksujia" antamaan palautetta ja tekemään tuotteeseen todella tarpeellisia muutoksia. Herää kysymys: mistä saada asiakkaita ja miten saada heidät osallistumaan kokeiluun?

Kaikista mahdollisista vaihtoehdoista valitsimme klassisen joukon digitaalisia työkaluja: aloitussivun ja mainoskampanjan sosiaalisissa verkostoissa.

Prosessi on jo käynnistetty, mutta tuloksista on liian aikaista puhua, vaikka vastauksia on jo saatu ja olemme saaneet vahvistusta monille hypoteeseillemme. Miellyttävä yllätys oli täysin erilaisten liiketoimintasegmenttien edustajien reaktio, paljon suurempi kuin odotimme. Olisi typerää jättää uudet esittelyt huomiotta, ja haastattelujen tulosten perusteella päätettiin käynnistää rinnakkainen LANBIX-linja nimeltä LANBIX Enterprise. Olemme lisänneet tuen hajautetuille infrastruktuureille, Wi-Fi-verkkojen valvontaan vianetsinnän ja lokalisoinnin avulla sekä viestintäkanavien laadun valvonnan. Palveluyritykset olivat eniten kiinnostuneita ratkaisusta. Samalla jo kehittämillämme laitteilla on tärkeä rooli ratkaisujen toiminnassa.

Mitä tapahtuu seuraavaksi

Mitä alkuperäisen LANBIXin kanssa tapahtuu seuraavaksi, selviää kampanjan tulosten perusteella. Jos hypoteesimme eivät toteudu Lean-metodologian mukaan, pääsemme siitä armottomasti eroon tai se muunnetaan uudeksi, koska ei ole mitään pahempaa kuin valmistaa tuote, jota kukaan ei tarvitse. Mutta nyt voimme sanoa, että tehty työ ei ollut turhaa ja sen ansiosta on ilmestynyt kokonainen rinnakkaisten tuotteiden haara, jonka parissa työskentelemme aktiivisesti. Menestyessään LANBIX siirtyy MVP-vaiheesta viimeiseen vaiheeseen ja kehittyy tuotemarkkinoinnin ymmärrettävien klassisten lakien mukaisesti.

Toistan, että nyt haluamme löytää varhaisia ​​käyttäjiä, yrityksiä, jotka voivat asentaa tuotteemme kerätäkseen palautetta. Jos olet kiinnostunut testaamaan LANBIXia, kirjoita kommentteihin tai yksityisviestiin.

Lähde

Lähde: will.com