Hvordan vi jobber med ideer og hvordan LANBIX ble født

Det er mange kreative ansatte på LANIT-Integration. Ideer til nye produkter og prosjekter henger bokstavelig talt i luften. Noen ganger kan det være svært vanskelig å identifisere de mest interessante. Derfor utviklet vi sammen vår egen metodikk. Les denne artikkelen om hvordan du velger de beste prosjektene og implementerer dem.

I Russland, og i verden som helhet, foregår det en rekke prosesser som fører til transformasjonen av IT-markedet. Takket være økningen i datakraft og fremveksten av server-, nettverks- og andre virtualiseringsteknologier, trenger ikke markedet lenger en stor mengde maskinvare. Leverandører foretrekker i økende grad å jobbe direkte med kunder. IT-markedet opplever en boom innen outsourcing i alle dens former, fra klassisk outsourcing til den nye bølgen av outsourcing – «skyleverandører». Infrastruktursystemer og -elementer blir mye enklere å vedlikeholde og konfigurere. Kvaliteten på programvaren vokser hvert år, og oppgavene til integratoren blir transformert.

Hvordan vi jobber med ideer

Produktoppstartsretning inn "LANIT-integrasjon" har eksistert i over ett år. Vårt hovedmål er å skape nye produkter og bringe dem ut på markedet. Det første vi begynte med var å organisere prosessen med å lage produkter. Vi har studert mange metoder, fra klassisk til hype. Ingen av dem møtte imidlertid våre behov. Da bestemte vi oss for å legge Lean Startup-metodikken til grunn og tilpasse den til våre oppgaver. Lean Startup er en teori om entreprenørskap laget av Eric Ries. Den er basert på prinsippene, tilnærmingene og praksisene til konsepter som lean manufacturing, kundeutvikling og fleksibel utviklingsmetodikk.

Når det gjelder den direkte tilnærmingen til produktutviklingsledelse: vi oppfant ikke hjulet på nytt, men brukte en allerede eksisterende utviklingsmetodikk SCRUM, legger til kreativitet, og nå kan det trygt kalles SCRUM-WATERFALL-BAN. SCRUM er, til tross for sin fleksibilitet, et veldig rigid system og egner seg for å lede et team som er ansvarlig for kun ett produkt/prosjekt. Som du forstår, innebærer den klassiske "integrasjonsvirksomheten" ikke å tildele tekniske spesialister på heltid til å jobbe med ett prosjekt (det er unntak, men ekstremt sjelden), siden i tillegg til å jobbe med produkter, er alle opptatt med aktuelle prosjekter. Fra SCRUM tok vi arbeidsfordelingen i sprint, daglig rapportering, tilbakeblikk og roller. Vi valgte Kanban for oppgaveflyten vår og den integrerte godt i vårt eksisterende oppgavesporingssystem. Vi strukturerte arbeidet vårt ved sømløst å integrere i den eksisterende orden av ting.
Før et produkt kommer inn på markedet går det gjennom 5 stadier: idé, utvalg, konsept, MVP (mer detaljer nedenfor) og produksjon.

Idé

På dette stadiet er det noe flyktig - en idé. Ideelt sett en idé for å løse et eksisterende problem eller klientproblem. Vi mangler ikke på ideer. I henhold til den opprinnelige planen skal de genereres av ansatte i tekniske områder. For at en idé skal bli akseptert for videreutvikling, må forfatteren fylle ut "Idedesignmalen". Det er bare fire spørsmål: Hva? For hva? Hvem trenger dette? Og hvis ikke vårt produkt, hva da?

Kilde

Utvalg

Så snart den ferdige malen når oss, starter behandlingen og utvelgelsen. Utvelgelsesstadiet er det mest arbeidskrevende. På dette stadiet dannes hypoteser om problemer (det var ikke for ingenting jeg nevnte i forrige avsnitt at ideen ideelt sett skulle løse en klients problem) og verdien av produktet. Det dannes en skalahypotese, dvs. hvordan virksomheten vår skal vokse og blomstre. Det gjennomføres problem- og ekspertintervjuer med potensielle kunder for å gi en foreløpig bekreftelse på at vi skal produsere noe som trengs. Det tar minst 10-15 intervjuer for å trekke en konklusjon om behovet for produktet.

Hvis hypotesene bekreftes, utføres en foreløpig finansiell analyse, det omtrentlige investeringsvolumet og investorens mulige inntjening vurderes. Som et resultat av dette stadiet blir et dokument kalt Lean Canvas født og presentert for ledelsen.

Konseptet

På dette stadiet er omtrent 70 % av ideene eliminert. Hvis konseptet blir godkjent, begynner idéutviklingsstadiet. Funksjonaliteten til det fremtidige produktet dannes, implementeringsveier og optimale tekniske løsninger fastsettes, og forretningsplanen oppdateres. Resultatet av denne fasen er en teknisk spesifikasjon for utvikling og en detaljert forretningscase. Hvis det lykkes, går vi videre til MVP- eller MVP-stadiet.

MVP eller MVP

MVP er et minimum levedyktig produkt. De. et produkt som ikke er ferdig utviklet, men som allerede kan gi verdi og utfører sin funksjonalitet. Det er avgjørende at vi på dette stadiet av utviklingen samler inn tilbakemeldinger fra ekte brukere og gjør endringer.

Produksjon

Og det aller siste stadiet er produksjonen. Ikke mer enn 5 % av produktene når dette stadiet. Disse 5 % inkluderer kun de viktigste, nødvendige, levedyktige og funksjonelle produktene.

Vi har mange ideer og har allerede satt sammen en omfangsrik portefølje. Vi analyserer hver idé og gjør alt for å sikre at den når sluttfasen. Det er veldig hyggelig at våre kolleger ikke forble likegyldige til vår FoU-retning og tar en aktiv del i utvikling og implementering av produkter og løsninger.

Hvordan vi laget LANBIX

La oss se på å lage et produkt ved å bruke et ekte eksempel - LANBIX-produktet. Dette er et "innpakket" programvare- og maskinvaresystem designet for å overvåke små IT-infrastrukturer og raskt varsle beslutningstakere og forretningsbrukere om funksjonsfeil kontrollert via en chatbot. I tillegg til overvåkingsfunksjonen inkluderer LANBIX Help Desk-funksjonalitet. Dette produktet er eksklusivt for markedssegmentet vi retter oss mot. Dette er både vår fordel og vår smerte. Men først ting først. Jeg vil si med en gang at LANBIX er et levende produkt (det vil si at det ikke er endelig i utviklingen og er på neste MVP-runde).

Så det første trinnet er ideen. For at en idé skal bli født, trenger du problemer, og vi hadde dem, eller rettere sagt ikke oss, men vennene våre. Nedenfor vil vi se på flere reelle situasjoner som oppsto i ulike forretningsområder.

Et lite forvaltningsselskap vedlikeholder to hus i Moskva-regionen. Personalet med PC er ca 15 personer. Systemadministratoren er en besøkende frilanser (den smarte sønnen til en av de omsorgsfulle beboerne). Det ser ut til at virksomheten til forvaltningsselskapet er svakt avhengig av IT, men det særegne ved denne virksomheten er månedlig rapportering til mange myndigheter. Systemdisken til sjefen for selskapet (som som vanlig kombinerer mange roller) har gått tom for ledig plass. Naturligvis skjedde ikke dette plutselig; advarselen hang i ca. 2 måneder og ble konstant ignorert. Men en oppdatering kom, operativsystemet ble oppdatert, og som heldigvis frøs det midt i oppdateringen og klaget før "døden" over en opptatt disk. Datamaskinen gikk inn i en syklisk omstart. Mens vi løste problemet og fikk rapporter, bommet vi på rapporteringsfristen. Det ser ut til at en triviell funksjonsfeil har forårsaket forskjellige problemer: fra tap til rettssaker og administrativt ansvar.

Kilde   

En lignende hendelse skjedde i et stort holdingselskap, som forener mange små selskaper, med en enkelt teknisk støttetjeneste for hele kontoret. På en av avdelingene gikk datamaskinen til regnskapssjefen i stykker. Det hadde vært kjent lenge at den kunne gå i stykker (datamaskinen ble desperat bremset ned og varmet opp), men regnskapssjefen rakk aldri å sende en forespørsel til teknisk støtte. Det brøt naturlig nok sammen akkurat på lønningsdagen, og avdelingsansatte sto uten penger i flere dager.

En liten bedrift i liten engroshandel hadde et salgsnettsted, som ble hostet på en ekstern plattform. Vi fikk vite om utilgjengelighet på telefon fra en vanlig kunde. På tidspunktet for samtalen hadde stedet vært nede i rundt tre timer. Det tok ytterligere et par timer å finne den ansvarlige for nettstedet, og ytterligere to for å fikse problemet. Følgelig var siden utilgjengelig nesten hele arbeidsdagen. I følge selskapets kommersielle direktør kostet denne nedetiden dem rundt 1 million rubler.

Selv møtte jeg en lignende situasjon da jeg kom på time på klinikken og skulle til VHI-registreringen. De kunne ikke sende meg til legen av en triviell grunn - det var en strømstøt om morgenen, og etter ulykken fungerte ikke posttjenesten deres og en bestemt tjeneste for å kommunisere med forsikringsselskapet. Som svar på spørsmålet mitt, hvor er administratorene dine, ble jeg fortalt at administratoren deres kommer og besøker dem en gang i uken. Og nå (på den tiden var klokken allerede 16:00) tar han ikke telefonen. I minst 7 timer var klinikken avskåret fra omverdenen og kunne ikke tilby betalte tjenester.

Hva har alle disse sakene til felles? Absolutt alle problemer kunne vært forhindret på forhånd. Med rettidig respons fra IT-folkene kunne skadene vært redusert. Dette ville vært mulig hvis de tidlige symptomene ble tolket riktig av brukerne.

Vi har identifisert problemhypoteser:

• betydelige penge- og omdømmetap på grunn av lav responshastighet på feil i IT-infrastrukturen;
• feiltolkning av tidlige symptomer på funksjonsfeil av brukere.

Hva kan kunden gjøre med dem, og hvordan unngå lignende situasjoner i fremtiden? Det er ikke mange alternativer:

1. ansette en høyt kvalifisert systemadministrator og få ham til å jobbe samvittighetsfullt;
2. outsource IT-vedlikehold til et spesialisert serviceselskap;
3. uavhengig implementere et overvåkings- og feilrapporteringssystem;
4. gi opplæring til brukere/bedriftspersonell i grunnleggende datakunnskaper.

La oss slå oss ned på det tredje alternativet. La oss tilby et overvåkingssystem til de som ikke bruker det av ulike årsaker.

Lyrisk digresjon. Ulike systemer for overvåking av IT-tjenester i bedriftsmarkedet har vært brukt i lang tid, og fordelene deres er ikke omstridt. Jeg snakket med representanter for store selskaper, så på hvordan forholdet mellom virksomhet og IT ble bygget. Den tekniske direktøren for en stor maskinbyggende bedrift har satt ut vedlikeholdet av IT-infrastrukturen til et eksternt selskap, men han er selv orientert om alle saker. På kontoret hans henger en stor overvåkingssystemskjerm med indikatorer på statusen til IT-tjenestene. De mest kritiske er inkludert i systemet. Teknisk direktør kan når som helst finne ut hvordan infrastrukturen er, hva som skjer, hvor problemet er, om de ansvarlige er varslet, og om problemet løses.

Historiene oppført ovenfor fikk teamet vårt til å tenke på hvordan vi kan lage et optimalt overvåkingssystem for små selskaper. Som et resultat ble LANBIX født - et overvåkingssystem som kan distribueres av absolutt alle uten IT-kunnskap. Hovedformålet med systemet er enkelt, som alle systemer rettet mot å øke kontinuitet og tilgjengelighet - redusere penge- og andre tap ved uplanlagt nedetid. Enheten er designet for å redusere tiden mellom "noe er ødelagt" og "problemet er løst" til et minimum.

For å bekrefte hypotesene ble det gjennomført problemintervjuer. Jeg kunne ikke forestille meg hvor mye folk ville være villige til å fortelle uten å prøve å selge til dem. Hver samtale varte i minst 1,5 time, og vi fikk mye nyttig informasjon for videre utvikling.

La oss oppsummere resultatene av dette stadiet:

1. det er en forståelse av problemet,
2. forståelse av verdi - det er,
3. Det er en idé til en løsning.

Den andre fasen var mer detaljert. Basert på resultatene måtte vi presentere for ledelsen, som i hovedsak spiller rollen som en investor, en business case (det samme Lean Canvas) for å ta en beslutning om produktets fremtidige skjebne.

Vi startet med markedsundersøkelser og konkurranseanalyser for å finne ut hvem, hva og, viktigst av alt, hvordan de gjør det i dette markedet.

Det viste seg følgende.

1. Det er ingen ferdige overvåkingssystemer på markedet for vårt segment (småbedrifter), med unntak av et par eller tre, som jeg av åpenbare grunner ikke vil snakke om.
2. Våre hovedkonkurrenter er merkelig nok systemadministratorer med hjemmeskrevne skript og "tillegg" til overvåkingssystemer med åpen kildekode.
3. Det er et klart problem med å bruke åpen kildekode-overvåkingssystemer. Det er et system, det er en enorm mengde informasjon om hvordan du fungerer og modifiserer systemet for å passe dine behov. Av administratorene jeg intervjuet, innrømmet mange at de ikke hadde nok kompetanse til å implementere ideene sine på egenhånd. Men de kan ikke innrømme dette overfor ledelsen i frykt for oppsigelse. Det viser seg å være en ond sirkel.

Deretter gikk vi videre til å analysere behovene til våre potensielle kunder. Vi har selv identifisert et segment av små organisasjoner som av en eller annen grunn ikke har egen IT-tjeneste, hvor enten en innkommende systemadministrator, en frilanser eller et serviceselskap har ansvar for IT. Det var ikke IT-siden som bestemte seg for å gå inn, men forretningssiden, som tilbyr gründere og bedriftseiere et verktøy for å forbedre kvaliteten på IT-infrastrukturtjenesten. Et produkt som skal hjelpe eiere med å sikre virksomheten sin, men som samtidig vil tilføre arbeid til de som har ansvar for IT. Et produkt som gir bedrifter et verktøy for å overvåke kvaliteten på IT-støtte.

Som et resultat av behandlingen av de mottatte dataene ble den første listen over krav (en slags grov etterslep) for det fremtidige produktet født:

• overvåkingssystemet må være basert på en åpen kildekodeløsning og som et resultat billig;
• enkel og rask å installere;
• bør ikke kreve spesifikk kunnskap innen IT, selv en regnskapsfører (på ingen måte ønsket jeg å fornærme representanter for dette yrket) bør kunne distribuere og konfigurere systemet;
• skal automatisk oppdage objekter for overvåking på nettverket;
• bør automatisk (og ideelt sett automatisk) installere overvåkingsagenter;
• må kunne overvåke eksterne tjenester, minst et CRM-system og en selgende nettside;
• bør varsle både virksomheten og systemadministratoren om problemer;
• graden av dybde og "språk" for varsler bør være forskjellig for administratoren og virksomheten;
• systemet må leveres på egen maskinvare;
• jern skal være så tilgjengelig som mulig;
• systemet bør være mest mulig uavhengig av eksterne faktorer.

Deretter ble investeringer i produktutvikling beregnet (inkludert lønnskostnader for ansatte i teknisk avdeling). Det ble utarbeidet en skisse av forretningsmodellen og enhetsøkonomien til produktet ble beregnet.

Etapperesultat:

• produktetterslep på høyt nivå;
• en formulert forretningsmodell eller skalahypotese som ennå ikke er testet i praksis.

La oss gå videre til neste trinn - konsept. Her befinner vi oss som ingeniører i vårt opprinnelige element. Det er "ønskelister" som dekomponeres til komponenter/delsystemer/funksjoner, så blir de omgjort til tekniske spesifikasjoner/brukerhistorier, deretter til et prosjekt osv. Jeg vil ikke dvele i detalj på prosessen med å forberede en rekke alternative alternativer; la oss gå rett til kravene og de valgte metodene for implementering av dem.

Krav
beslutning

• Det bør være et åpent overvåkingssystem;

Vi tar et åpen kildekode overvåkingssystem.

• Systemet skal være enkelt og raskt å installere;
• bør ikke kreve spesifikk IT-kunnskap. Selv en regnskapsfører bør kunne distribuere og konfigurere systemet.

Vi tilbyr et installert system slik at brukeren bare trenger å slå på enheten og konfigurere den litt, i likhet med en ruter.

La oss lukke interaksjonen med enheten til noe enkelt og forståelig for alle.

La oss skrive vår egen chatbot for en av de velkjente instant messengers og overføre all interaksjon med systemet til den.

Systemet skal:

• automatisk oppdage objekter som kreves for overvåking på nettverket;
• automatisk installer overvåkingsagenter;
• Kunne overvåke eksterne tjenester, minst et CRM-system og en selgende nettside.

Vi skriver tillegg for overvåkingssystemet for:

• automatisk gjenkjenning av objekter;
• automatisk installasjon av agenter;
• overvåke tilgjengeligheten av eksterne tjenester.

Systemet skal:

• varsle både virksomheten og systemadministratoren om problemer;
• kunne overvåke eksterne tjenester, minst et CRM-system og en selgende nettside. Graden av dybde og "språk" for varslinger bør være forskjellig for administrator og virksomhet.
• Systemet skal ikke kreve spesifikk IT-kunnskap, selv en regnskapsfører skal kunne distribuere og konfigurere systemet.

• La oss legge til ulike typer varsler for ulike typer brukere. De er forskjellige i tonehøyde og dybde. En bedriftsbruker vil motta varsler som "alt er bra, men Ivanovs datamaskin vil snart dø." Administrator vil motta en fullstendig melding om feilen, hvem, hvordan og hva som har skjedd eller kan skje.
• La oss legge til muligheten til å bruke posten til en ekstra ansvarlig person, slik at han i tilfelle et sammenbrudd vil motta en melding.
• La oss legge til interaksjon med eksterne tjenesteleverandører basert på å sende e-poster med forhåndsforberedt tekst, fordi Det er e-posten som gir opphav til hendelsen.
• All interaksjon med systemet vil bli koblet til en chatbot; kommunikasjonen foregår i en dialogstil.

supplere:

• La oss legge til funksjonaliteten til "chat med administratoren" slik at brukeren kan sende administratoren en melding som beskriver problemet direkte.

• Systemet må leveres på egen maskinvare.
• Jern må være tilgjengelig.
• Systemet skal være mest mulig uavhengig av omgivelsene.

• La oss ta en ferdiglaget og billig Raspberry PI-datamaskin.
• Vi vil designe et avbruddsfri strømforsyningskort.
• La oss legge til et modem for å være uavhengig av tilstanden til det lokale nettverket.
• Vi skal designe et vakkert bygg.

Vi har nå tre delsystemer med egne krav og visjon for implementering:

• maskinvare undersystem;
• overvåking delsystem;
• undersystem for brukerinteraksjon.

Vi utviklet et foreløpig design for maskinvaredelsystemet. Ja Ja! Etter å ha brutt alle reglene for smidighet, utviklet vi et dokument, fordi produksjonsanlegg jobber med dokumenter. For de resterende delsystemene identifiserte vi brukere (personer), utarbeidet brukerhistorier og skrev oppgaver for utvikling.

Dette avslutter konseptstadiet, og resultatet er:

• prosjekt for en maskinvareplattform;
• formulert visjon i form av brukerhistorier for de resterende to delsystemene;
• en programvareprototype implementert som en virtuell maskin;
• en prototype av maskinvaren, implementert i form av et stativ, hvor maskinvareløsningene faktisk ble testet for styrke;
• testing utført av våre administratorer.

Problemene på dette stadiet var for det meste organisatoriske og knyttet til manglende kunnskap hos ingeniørpersonalet i de juridiske og regnskapsmessige aspektene ved salg. De. En ting er å finne ut hva og hvordan man skal selge, og noe helt annet er å stå overfor en hensynsløs juridisk maskin: patenter, utviklingsoppgaver, registrering, EULA og mye mer som vi som kreative mennesker ikke tok hensyn til i utgangspunktet.

Det var ennå ikke et problem, men snarere en vanskelighet knyttet til utformingen av kabinettene. Teamet vårt består kun av ingeniører, så den første versjonen av kabinettet ble "bygget" av plexiglass av elektronikkspesialisten vår.

Kroppen så mildt sagt kontroversiell ut, spesielt for publikum, bortskjemt med moderne teknologi. Det var selvfølgelig kjennere blant den eldre generasjonen "Kulibins" - bygningen fremkalte nostalgiske følelser hos dem. Det ble besluttet å produsere og designe kassen på nytt, siden den gamle, i tillegg til estetiske feil, også hadde strukturelle - plexiglasset tålte ikke montering og demontering av enheten godt og hadde en tendens til å sprekke. Jeg skal fortelle deg om produksjonen av saken videre.

Og nå er vi nærme målstreken – MVP. Selvfølgelig er dette ennå ikke et endelig produksjonsprodukt, men det er allerede nyttig og verdifullt. Hovedmålet med denne fasen er å lansere syklusen "skap-evaluer-lær". Dette er akkurat det stadiet LANBIX er på.

På "opprett"-stadiet opprettet vi en enhet som utfører den angitte funksjonaliteten. Ja, det er ikke perfekt ennå, og vi fortsatte å jobbe med det.

La oss gå tilbake til produksjonen av kroppen, dvs. til oppgaven med å transformere enheten vår fra nostalgisk til moderne. I begynnelsen søkte jeg markedet etter skapprodusenter og industrielle designtjenester. For det første er det ikke mange selskaper som produserer etuier på det russiske markedet, og for det andre er kostnadene for industriell design på dette stadiet uoverkommelig høy, omtrent 1 million rubler.

De tok kontakt med markedsavdelingen vår for designet, den unge designeren var klar for kreative eksperimenter. Vi skisserte vår visjon om skroget (har tidligere studert de beste eksemplene på skrogkonstruksjon), og han gjorde det på sin side til et kunstverk. Det gjenstår bare å produsere det. Vi, stolte av designet vårt, henvendte oss til våre partnere. Konsernsjefen deres knuste umiddelbart fantasiene våre ved å peke på, helt gratis, ting som ikke kunne produseres på vår valgte måte. Etuiet kan produseres, og det vil ikke være verre enn Apples, men kostnaden for etuiet vil være tre til fire ganger dyrere enn alle elektroniske komponenter. Etter en rekke operasjoner og godkjenninger har vi designet et hus som kan produseres. Ja, det er ikke så vakkert som vi planla, men det er ideelt for å nå gjeldende mål.

Resultat av etappen: den første gruppen med enheter klare for kamp og testing.

Og nå er det vanskeligste "evalueringsstadiet", og med produktet vårt er vi akkurat på dette punktet. Vi kan kun evaluere basert på resultatene av bruk av ekte kunder, og ingen antagelser fungerer her. Vi trenger de "early adopters" for å gi tilbakemelding og gjøre de endringene i produktet som virkelig trengs. Spørsmålet oppstår: hvor skal man få kunder og hvordan overbevise dem om å delta i eksperimentet?

Av alle mulige alternativer valgte vi et klassisk sett med digitale verktøy: landingsside og reklamekampanje på sosiale nettverk.

Prosessen er allerede igangsatt, men det er for tidlig å snakke om resultater, selv om det allerede er svar og vi har fått bekreftet mange av våre hypoteser. En hyggelig overraskelse var reaksjonen fra representanter for helt andre forretningssegmenter, mye større enn de vi forventet. Det ville være dumt å ignorere de nye introduksjonene, og basert på resultatene fra intervjuene ble det besluttet å lansere en parallell LANBIX-linje kalt LANBIX Enterprise. Vi har lagt til støtte for distribuert infrastruktur, overvåking av Wi-Fi-nettverk med feilsøking og lokalisering, og overvåking av kvaliteten på kommunikasjonskanaler. Servicebedrifter uttrykte størst interesse for løsningen. Samtidig spiller enhetene vi allerede har utviklet en viktig rolle i driften av løsningene.

Hva vil skje videre

Hva som vil skje videre med den originale LANBIX vil bli klart basert på resultatene av kampanjen. Hvis hypotesene våre ikke bekreftes, i henhold til Lean-metodikken, vil vi nådeløst bli kvitt den eller den vil bli forvandlet til noe nytt, fordi det ikke er noe verre enn å lage et produkt som ingen trenger. Men nå kan vi si at arbeidet som ble utført ikke var forgjeves, og takket være det har det dukket opp en hel gren av parallelle produkter, som vi jobber aktivt med. Hvis det lykkes, vil LANBIX gå fra MVP-stadiet til sluttstadiet og vil utvikle seg i henhold til de forståelige klassiske lovene for produktmarkedsføring.

Jeg gjentar, nå ønsker vi å finne tidlige brukere, selskaper som kan installere produktet vårt for å samle tilbakemeldinger. Hvis du er interessert i å teste LANBIX, skriv i kommentarfeltet eller private meldinger.

Kilde

Kilde: www.habr.com