{"id":34675,"date":"2019-10-31T21:59:45","date_gmt":"2019-10-31T18:59:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-rabotaem-s-ideyami-i-kak-rodilsya-lanbix\/"},"modified":"2019-10-31T21:59:45","modified_gmt":"2019-10-31T18:59:45","slug":"kak-my-rabotaem-s-ideyami-i-kak-rodilsya-lanbix","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-rabotaem-s-ideyami-i-kak-rodilsya-lanbix","title":{"rendered":"Hvordan vi arbejder med id\u00e9er, og hvordan LANBIX blev til","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I \"LANIT-Integration\" er der mange kreative medarbejdere. Id\u00e9er til nye produkter og projekter h\u00e6nger bogstavelig talt i luften. At identificere de mest interessante kan ofte v\u00e6re en stor udfordring. Derfor har vi i f\u00e6llesskab udviklet vores egen metode. L\u00e6s i denne artikel, hvordan man udv\u00e6lger de bedste projekter og realiserer dem.<\/p>\n

\"Hvordan<\/a><\/noindex>
\nI Rusland og i verden generelt er der en r\u00e6kke processer i gang, som f\u00f8rer til en transformation af IT-markedet. Takket v\u00e6re den stigende computerkraft og fremkomsten af server-, netv\u00e6rks- og andre virtualiseringsteknologier, har markedet ikke l\u00e6ngere behov for store m\u00e6ngder 'hardware'. Leverand\u00f8rer foretr\u00e6kker i stigende grad at arbejde direkte med kunderne. Outsourcing blomstrer p\u00e5 IT-markedet i alle sine former, fra klassisk outsourcing til den nye b\u00f8lge af udbydere \u2013 'cloud-udbydere'. Infrastruktur-systemer og elementer bliver v\u00e6sentligt enklere at vedligeholde og konfigurere. Kvaliteten af software stiger hvert \u00e5r, og integratorens opgaver transformeres. <\/p>\n

\"Hvordan<\/p>\n

Hvordan vi arbejder med id\u00e9er<\/h2>\n

\nProduktstart-up-retningen i \"LANIT-Integration\"<\/a><\/noindex> har eksisteret i mere end et \u00e5r. Vores prim\u00e6re m\u00e5l er at skabe nye produkter og bringe dem p\u00e5 markedet. Det f\u00f8rste, vi startede med, var at organisere selve produktudviklingsprocessen. Vi har gennemg\u00e5et mange metodologier, fra de klassiske til de hypede. Men ingen af \u200b\u200bdem svarede til vores behov. Derfor besluttede vi at tage udgangspunkt i Lean Startup-metodologien og tilpasse den til vores behov. \"Lean Startup\" er en entrepren\u00f8rskabs teori, skabt af Eric Ries. Den bygger p\u00e5 principper, tilgange og praksisser fra koncepter som slank produktion, customer development og agil udviklingsmetodologi.<\/p>\n

N\u00e5r det kommer til selve tilgangen til produktudviklingsledelse: vi opfandt ikke hjulet, men anvendte en allerede eksisterende udviklingsmetodologi SCRUM<\/a><\/noindex>, tilf\u00f8jet kreativitet, og nu kan det trygt kaldets SCRUM-WATERFALL-BAN. SCRUM, p\u00e5 trods af sin fleksibilitet, er et meget stramt system og egner sig til at styre et team, der kun er ansvarligt for \u00e9t produkt\/projekt. Som du forst\u00e5r, tillader en klassisk 'integrator'-forretning ikke, at tekniske specialister tildeles fuldtid til at arbejde p\u00e5 \u00e9t projekt (der er undtagelser, men de er sj\u00e6ldne), da alle er besk\u00e6ftiget med igangv\u00e6rende projekter udover arbejdet med produkterne. Fra SCRUM har vi taget arbejdet op i sprint, daglig rapportering, retrospektiver og roller. For at arbejde med opgavernes flow valgte vi Kanban, og det integrerede sig glimrende i vores eksisterende opgavetrackingssystem. Vi har struktureret arbejdet og glidende integreret os i den allerede eksisterende orden.
\nF\u00f8r et produkt kommer p\u00e5 markedet, gennemg\u00e5r det 5 faser: id\u00e9, udv\u00e6lgelse, koncept, M\u0416\u041f (se n\u00e6rmere nedenfor) og produktion.<\/p>\n

Id\u00e9<\/h2>\n

\nP\u00e5 dette stadium er der noget efemerisk \u2013 en id\u00e9. Ideelt set en id\u00e9 til l\u00f8sning af et eksisterende problem eller en opgave for kunden. Vi har ikke mangel p\u00e5 id\u00e9er. If\u00f8lge den oprindelige plan skal de genereres af medarbejdere i de tekniske retninger. For at en id\u00e9 kan godkendes til videre udvikling, skal forfatteren udfylde 'Id\u00e9formuleringens skabelon'. Der er kun fire sp\u00f8rgsm\u00e5l: Hvad? Hvorfor? Hvem har brug for det? Og hvis ikke vores produkt, hvad s\u00e5?<\/p>\n

\"HvordanKilde<\/i><\/a><\/noindex><\/p>\n

Udv\u00e6lgelse<\/h2>\n

\nN\u00e5r den udfyldte skabelon kommer til os, starter behandlings- og udv\u00e6lgelsesprocessen. Udv\u00e6lgelsesfasen er den mest arbejdskr\u00e6vende. P\u00e5 dette stadium dannes hypoteser om problemer (jeg n\u00e6vnte ikke for ingenting, at id\u00e9en ideelt set skal l\u00f8se et kundeproblem) og produktets v\u00e6rdi. Det formuleres en skala-hypotese, dvs. hvordan vores forretning planl\u00e6gger at vokse og trives. Der gennemf\u00f8res problem- og ekspertinterviews med potentielle kunder for at bekr\u00e6fte, at vi har til hensigt at producere noget nyttigt. Der kr\u00e6ves mindst 10-15 interviews for at drage konklusioner om produktets n\u00f8dvendighed.<\/p>\n

\"Hvordan
\nHvis hypoteser bekr\u00e6ftes, gennemf\u00f8res en forel\u00f8big finansiel analyse, der vurderer det omtrentlige investeringsbel\u00f8b og den mulige indtjening for investoren. Som resultat af dette stadium skabes et dokument kaldet Lean Canvas, som pr\u00e6senteres for ledelsen. <\/p>\n

\"Hvordan<\/p>\n

Koncept<\/h2>\n

\nP\u00e5 dette stadium sorteres cirka 70% af ideerne fra. Hvis konceptet godkendes, begynder fasen med udvikling af ideen. De funktionelle muligheder for det fremtidige produkt formes, implementeringsveje og optimale tekniske l\u00f8sninger bestemmes, og forretningsplanen aktualiseres. Resultatet af dette trin er en teknisk opgave til udvikling og en detaljeret business case. Ved succes g\u00e5r vi videre til MLP eller MVP-fasen.<\/p>\n

MLP eller MVP<\/h2>\n

\nMLP er det minimum levedygtige produkt. Det vil sige, et produkt, der ikke er f\u00e6rdigudviklet, men allerede kan skabe v\u00e6rdi og opfylde sine funktioner. P\u00e5 dette udviklingstrin indsamler vi n\u00f8dvendigvis feedback fra rigtige brugere og foretager \u00e6ndringer.<\/p>\n

Produktion<\/h2>\n

\nDen aller sidste fase er produktion. Ikke mere end 5% af produkterne n\u00e5r denne fase. Disse 5% er kun de vigtigste, n\u00f8dvendige, levedygtige og funktionelle produkter.<\/p>\n

Vi har mange ideer og en omfattende portef\u00f8lje samlet. Vi gennemg\u00e5r hver id\u00e9 og g\u00f8r alt, hvad vi kan, for at bringe dem til den endelige fase. Det er meget tilfredsstillende, at kolleger ikke har v\u00e6ret ligeglade med vores R&D-omr\u00e5de og deltager aktivt i udviklingen og implementeringen af produkter og l\u00f8sninger.<\/p>\n

Hvordan vi lavede LANBIX<\/h2>\n

\nLad os se p\u00e5 produktudviklingen med et konkret eksempel - produktet LANBIX. Dette er et \"boxeret\" software-hardware kompleks, designet til overv\u00e5gning af sm\u00e5 IT-infrastrukturer og hurtig varsling af ansvarlige personer og forretningsbrugere om fejl med styring gennem en chatbot. Ud over overv\u00e5gningsfunktionen inkluderer LANBIX Help Desk-funktionen. Dette produkt er eksklusivt for den markedssegment, vi har m\u00e5lrettet. Dette er b\u00e5de vores fordel og vores udfordring. Men mere om det senere. Jeg vil straks sige, at LANBIX er et levende produkt (dvs. det er ikke endeligt i sin udvikling og er p\u00e5 en ny MVP-cyklus). <\/p>\n

S\u00e5 den f\u00f8rste fase er id\u00e9en. For at en id\u00e9 kan opst\u00e5, er det n\u00f8dvendigt med problemer, og vi havde nogle, n\u00e6rmere bestemt ikke vi, men vores bekendte. Nedenfor vil vi se p\u00e5 flere virkelige situationer, der er sket i forskellige erhverv. <\/p>\n

Et lille ejendomsselskab h\u00e5ndterer to bygninger i Moskva-regionen. Personalet med adgang til en computer t\u00e6ller omkring 15 personer. Systemadministratoren er en freelancetekniker (den snedige s\u00f8n af en af de engagerede beboere). Det skulle synes, at ejendomsselskabets aktivitet i h\u00f8j grad er uafh\u00e6ngig af IT, men en s\u00e6rlig egenskab ved denne forretning er m\u00e5nedlig rapportering til mange instanser. Den systemdisk, som lederen benytter (som s\u00e6dvanligt kombinerer mange funktioner), var l\u00f8bet t\u00f8r for plads. S\u00e5ledes skete dette ikke pludseligt; advarslen havde v\u00e6ret synlig i n\u00e6sten 2 m\u00e5neder og blev konstant ignoreret. Men der kom en opdatering, OS blev opdateret, og som ved en d\u00e5rlig sk\u00e6bne fr\u00f8s det midt i opdateringen og klagede inden 'd\u00f8den' over den optagne disk. Computeren gik i en cyklisk genstart. Mens man k\u00e6mpede med problemet og hentede rapporterne, overskred de fristen for at indsende rapporten. Det skulle synes, at en banal fejl blev \u00e5rsag til forskellige problemer: fra tab til retssager og administrativt ansvar.<\/p>\n

\"HvordanKilde<\/i><\/a><\/noindex> \u00a0\u00a0<\/p>\n

En lignende h\u00e6ndelse fandt sted i en stor koncern, som samler mange sm\u00e5 virksomheder, med en central teknisk supporttjeneste for hele kontoret. I en af afdelingerne br\u00f8d computerens hovedbogholder sammen. At den kunne g\u00e5 i stykker, var allerede kendt i lang tid (computeren havde desperat forsinket arbejdet og var blevet overophedet), men bogholderens h\u00e6nder n\u00e5ede ikke til at sende en anmodning til teknisk support. Selvf\u00f8lgelig gik den i stykker lige p\u00e5 l\u00f8nningsdagen, og medarbejderne i afdelingen sad i flere dage uden penge.<\/p>\n

\"Hvordan
\nEn lille virksomhed, der driver engroshandel, havde et salgshjemmeside, der blev hostet p\u00e5 en ekstern platform. De fik besked om dets utilg\u00e6ngelighed via telefon fra en fast kunde. P\u00e5 tidspunktet for opkaldet havde hjemmesiden v\u00e6ret uden forbindelse i omkring tre timer. Det tog yderligere et par timer at finde den ansvarlige for hjemmesiden, og at l\u00f8se problemet tog yderligere to timer. Derfor var hjemmesiden praktisk talt utilg\u00e6ngelig i hele arbejdsdagen. If\u00f8lge virksomhedens kommercielle direkt\u00f8r kostede denne nedetid dem omtrent 1 million rubler. <\/p>\n

Jeg har selv st\u00e5et i en lignende situation, da jeg kom til konsultation i klinikken og skulle tilmelde mig DMS. De kunne ikke sende mig til l\u00e6gen af en simpel \u00e5rsag - der havde v\u00e6ret et str\u00f8msvigt om morgenen, og efter uheldet fungerede deres e-mailservice og en forbindelse til forsikringsselskabet ikke. P\u00e5 mit sp\u00f8rgsm\u00e5l om, hvor deres administrator var, blev jeg fortalt, at de havde en vikaradministrator, som kun kom \u00e9n gang om ugen. Og nu (p\u00e5 det tidspunkt var klokken allerede 16:00) tog han ikke telefonen. Klinikken havde v\u00e6ret afsk\u00e5ret fra omverdenen i mindst 7 timer og kunne ikke tilbyde betalte tjenester. <\/p>\n

\"Hvordan
\nHvad har alle disse tilf\u00e6lde til f\u00e6lles? Absolut alle problemer kunne have v\u00e6ret forhindret p\u00e5 forh\u00e5nd. Med rettidig reaktion fra de personer, der h\u00e5ndterer IT, kunne den p\u00e5f\u00f8rte skade v\u00e6re blevet reduceret. Dette ville ogs\u00e5 have v\u00e6ret muligt ved korrekt fortolkning af tidlige symptomer fra brugerne.<\/p>\n

Vi har identificeret problemhypoteser: <\/p>\n