{"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\/sv\/blog\/administrirovanie\/kak-my-rabotaem-s-ideyami-i-kak-rodilsya-lanbix","title":{"rendered":"Hur vi arbetar med id\u00e9er och hur LANBIX f\u00f6ddes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00e5 \u00abLANIT-Integration\u00bb finns det m\u00e5nga kreativa medarbetare. Id\u00e9er f\u00f6r nya produkter och projekt sv\u00e4var bokstavligen i luften. Att identifiera de mest intressanta kan ibland vara mycket sv\u00e5rt. D\u00e4rf\u00f6r har vi tillsammans utvecklat v\u00e5r egen metodik. Hur vi v\u00e4ljer ut de b\u00e4sta projekten och genomf\u00f6r dem kan du l\u00e4sa om i denna artikel.<\/p>\n

\"Hur<\/a><\/noindex>
\nI Ryssland, och faktiskt i v\u00e4rlden i stort, p\u00e5g\u00e5r en rad processer som leder till en transformation av IT-marknaden. Tack vare \u00f6kade ber\u00e4kningskapaciteter och framv\u00e4xten av server-, n\u00e4tverks- och annan virtualisering beh\u00f6ver marknaden inte l\u00e4ngre s\u00e5 mycket 'h\u00e5rdvara'. Leverant\u00f6rer f\u00f6redrar allt oftare att arbeta direkt med kunderna. Outsourcing blomstrar p\u00e5 IT-marknaden i alla dess former, fr\u00e5n klassisk outsourcing till den nya v\u00e5gen av outsourcingleverant\u00f6rer - 'molnleverant\u00f6rer'. Infrastruktursystem och element blir avsev\u00e4rt enklare att underh\u00e5lla och konfigurera. Kvaliteten p\u00e5 mjukvaran \u00f6kar f\u00f6r varje \u00e5r och uppgifterna f\u00f6r integrat\u00f6rerna f\u00f6r\u00e4ndras. <\/p>\n

\"Hur<\/p>\n

Hur vi arbetar med id\u00e9er<\/h2>\n

\nProduktstartup-riktningen inom \u00abLANIT-Integration\u00bb<\/a><\/noindex> har funnits i \u00f6ver ett \u00e5r. V\u00e5rt huvudm\u00e5l \u00e4r att skapa nya produkter och lansera dem p\u00e5 marknaden. Det f\u00f6rsta vi b\u00f6rjade med var att organisera sj\u00e4lva processen f\u00f6r produktutveckling. Vi har studerat m\u00e5nga metodologier, fr\u00e5n klassiska till trendiga. Men ingen av dem uppfyllde v\u00e5ra behov. D\u00e5 best\u00e4mde vi oss f\u00f6r att basera oss p\u00e5 Lean Startup-metodologin och anpassa den efter v\u00e5ra behov. 'Lean Startup' \u00e4r en entrepren\u00f6rsteori skapad av Eric Ries. Den bygger p\u00e5 principerna, tillv\u00e4gag\u00e5ngss\u00e4tten och praktikerna fr\u00e5n koncept som lean production, customer development och agil utvecklingsmetodik.<\/p>\n

N\u00e4r det g\u00e4ller sj\u00e4lva tillv\u00e4gag\u00e5ngss\u00e4ttet f\u00f6r produktutveckling: vi uppfann inte hjulet, utan anv\u00e4nde en redan befintlig utvecklingsmetodologi SCRUM<\/a><\/noindex>, med kreativitet tillagt, kan det nu stolt kallas SCRUM-WATERFALL-BAN. SCRUM, trots sin flexibilitet, \u00e4r ett mycket strikt system som \u00e4r l\u00e4mpligt f\u00f6r att hantera ett team som ansvarar f\u00f6r endast en produkt\/projekt. Som ni f\u00f6rst\u00e5r, f\u00f6ruts\u00e4tter klassisk \"integrator\u201d-verksamhet inte att tekniska specialister avs\u00e4tts p\u00e5 heltid f\u00f6r att arbeta med ett enda projekt (det f\u00f6rekommer undantag, men extremt s\u00e4llan), eftersom alla, f\u00f6rutom att arbeta med produkter, \u00e4r upptagna med p\u00e5g\u00e5ende projekt. Fr\u00e5n SCRUM har vi tagit uppdelningen av arbete i sprinter, daglig rapportering, retrospektiv och roller. F\u00f6r att hantera fl\u00f6det av uppgifter valde vi Kanban, och det har integrerats utm\u00e4rkt i v\u00e5rt befintliga system f\u00f6r uppgiftssp\u00e5rning. Vi har organiserat arbetet genom att smidigt integrera oss i den redan existerande ordningen.
\nInnan en produkt lanseras p\u00e5 marknaden genomg\u00e5r den 5 faser: id\u00e9, urval, koncept, MVP (mer om detta nedan) och produktion.<\/p>\n

Tanken<\/h2>\n

\nI detta skede finns n\u00e5got efem\u00e4rt \u2013 en id\u00e9. Idealt sett \u00e4r det en id\u00e9 f\u00f6r att l\u00f6sa ett befintligt problem eller en uppgift f\u00f6r kunden. Vi har inga brist p\u00e5 id\u00e9er. Initialt ska de genereras av anst\u00e4llda inom teknikavdelningarna. F\u00f6r att en id\u00e9 ska accepteras f\u00f6r vidare utveckling m\u00e5ste f\u00f6rfattaren fylla i \"Id\u00e9formatet\". D\u00e4r finns totalt fyra fr\u00e5gor: Vad? F\u00f6r vad? Vem beh\u00f6ver detta? Om det inte \u00e4r v\u00e5r produkt, vad \u00e4r det d\u00e5?<\/p>\n

\"HurK\u00e4lla<\/i><\/a><\/noindex><\/p>\n

Urval<\/h2>\n

\nN\u00e4r det ifyllda formatet kommer till oss startar behandlings- och urvalsprocessen. Urvalssteget \u00e4r det mest arbetskr\u00e4vande. I detta skede formuleras hypoteser om problem (jag n\u00e4mnde inte f\u00f6rg\u00e4ves i f\u00f6reg\u00e5ende stycke att id\u00e9n idealiskt sett ska l\u00f6sa kundens problem) och produktens v\u00e4rde. En hypotes om skala formuleras, det vill s\u00e4ga hur v\u00e5rt f\u00f6retag planerar att v\u00e4xa och blomstra. Problematiska och expertrelaterade intervjuer genomf\u00f6rs med potentiella kunder f\u00f6r prelimin\u00e4r bekr\u00e4ftelse av att vi planerar att producera n\u00e5got anv\u00e4ndbart. Minst 10-15 intervjuer kr\u00e4vs f\u00f6r att dra slutsatsen att produkten \u00e4r n\u00f6dv\u00e4ndig.<\/p>\n

\"Hur
\nOm hypoteserna bekr\u00e4ftas genomf\u00f6rs en prelimin\u00e4r ekonomisk analys, som bed\u00f6mer den ungef\u00e4rliga investeringsvolymen och den potentiella inkomsten f\u00f6r investeraren. Som ett resultat av detta steg f\u00f6ds ett dokument som kallas Lean Canvas och presenteras f\u00f6r ledningen. <\/p>\n

\"Hur<\/p>\n

Konceptet<\/h2>\n

\nI det h\u00e4r skedet filtreras cirka 70% av id\u00e9erna bort. Om konceptet godk\u00e4nns b\u00f6rjar vi med att vidareutveckla id\u00e9n. Funktionaliteter f\u00f6r den framtida produkten formuleras, implementeringsv\u00e4gar och optimala tekniska l\u00f6sningar definieras, och aff\u00e4rsplanen aktualiseras. Resultatet av detta skede \u00e4r en teknisk specifikation f\u00f6r utveckling och en detaljerad aff\u00e4rsplan. Om allt g\u00e5r bra g\u00e5r vi vidare till stadiet f\u00f6r MDP eller MVP.<\/p>\n

MDP eller MVP<\/h2>\n

\nMDP \u00e4r en minimalt livskraftig produkt. Det vill s\u00e4ga, en produkt som inte \u00e4r helt f\u00e4rdigutvecklad, men \u00e4nd\u00e5 kan ge v\u00e4rde och utf\u00f6ra sin funktion. Under denna utvecklingsfas samlar vi n\u00f6dv\u00e4ndigtvis feedback fr\u00e5n verkliga anv\u00e4ndare och g\u00f6r justeringar.<\/p>\n

Tillverkning<\/h2>\n

\nDen allra sista fasen \u00e4r tillverkning. Endast 5% av produkterna n\u00e5r denna fas. Dessa 5% omfattar endast de mest viktiga, n\u00f6dv\u00e4ndiga, livskraftiga och funktionella produkterna.<\/p>\n

Vi har m\u00e5nga id\u00e9er och en omfattande portf\u00f6lj har redan samlats in. Vi unders\u00f6ker varje id\u00e9 och g\u00f6r allt f\u00f6r att den ska n\u00e5 finalskedet. Det \u00e4r mycket trevligt att kollegorna har visat stort engagemang f\u00f6r v\u00e5r R&D-inriktning och aktivt deltar i utvecklingen och implementeringen av produkter och l\u00f6sningar.<\/p>\n

Hur vi skapade LANBIX<\/h2>\n

\nL\u00e5t oss titta p\u00e5 skapandet av en produkt genom ett verkligt exempel \u2014 produkten LANBIX. Det \u00e4r en 'boxad' programvaru- och h\u00e5rdvarukomplex avsedd f\u00f6r att \u00f6vervaka sm\u00e5 IT-infrastrukturer och snabbt informera ber\u00f6rda personer och aff\u00e4rsanv\u00e4ndare om fel via en chatbot. F\u00f6rutom \u00f6vervakningsfunktionen inkluderar LANBIX \u00e4ven Help Desk-funktionalitet. Denna produkt \u00e4r exklusiv f\u00f6r den marknadssegment vi riktar oss mot. Det \u00e4r b\u00e5de v\u00e5r f\u00f6rdel och v\u00e5r utmaning. Men allt i tur och ordning. Jag ska direkt s\u00e4ga att LANBIX \u00e4r en levande produkt (det vill s\u00e4ga den \u00e4r inte slutgiltig i sin utveckling och \u00e4r f\u00f6r n\u00e4rvarande i n\u00e4sta MVP-cykel). <\/p>\n

S\u00e5, det f\u00f6rsta steget \u00e4r id\u00e9n. F\u00f6r att en id\u00e9 ska f\u00f6das beh\u00f6vs problem, och vi hade dem, eller snarare v\u00e5ra bekanta hade dem. Nedan kommer vi att titta p\u00e5 n\u00e5gra verkliga situationer som intr\u00e4ffat i olika aff\u00e4rsomr\u00e5den. <\/p>\n

Ett litet f\u00f6rvaltningsf\u00f6retag hanterar tv\u00e5 byggnader i Moskva-regionen. Antalet anst\u00e4llda med datorer \u00e4r runt 15 personer. Systemadministrat\u00f6ren \u00e4r en frilansare (en clever son till en av de boende). Det verkade som om f\u00f6rvaltningsbolagets verksamhet knappt berodde p\u00e5 IT, men det som g\u00f6r detta f\u00f6retag unikt \u00e4r den m\u00e5natliga rapporteringen till m\u00e5nga instanser. Det fanns inte tillr\u00e4ckligt med utrymme kvar p\u00e5 systemdisken hos f\u00f6retagsledaren (som vanligt samlar p\u00e5 sig m\u00e5nga roller). Naturligtvis h\u00e4nde detta inte pl\u00f6tsligt, en varning hade h\u00e4ngt i n\u00e4stan 2 m\u00e5nader och konstant ignorerats. Men en uppdatering kom, operativsystemet uppdaterades och, som tur var, fastnade det i mitten av uppdateringen och klagade innan \"d\u00f6den\" p\u00e5 den upptagna disken. Datorn gick in i en cyklisk omstart. Medan de rattade med problemet och h\u00e4mtade rapporterna missade de inl\u00e4mningsfristen f\u00f6r redovisningen. Det verkade som om en trivial defekt orsakade m\u00e5nga problem: fr\u00e5n f\u00f6rluster till r\u00e4ttsliga tvister och administrativt ansvar.<\/p>\n

\"HurK\u00e4lla<\/i><\/a><\/noindex> \u00a0\u00a0<\/p>\n

Ett liknande fall intr\u00e4ffade i en stor koncern som f\u00f6renar m\u00e5nga sm\u00e5 f\u00f6retag, med en gemensam teknisk supporttj\u00e4nst f\u00f6r hela kontoret. I en av avdelningarna gick huvudbokf\u00f6rarens dator s\u00f6nder. Att den skulle g\u00e5 s\u00f6nder var k\u00e4nt l\u00e4nge (datorn segade sig och blev \u00f6verhettad), men huvudbokf\u00f6rarens h\u00e4nder hann aldrig n\u00e5 till att skicka en beg\u00e4ran till teknisk support. Naturligtvis gick den s\u00f6nder precis p\u00e5 l\u00f6neutbetalningsdagen, och avdelningens anst\u00e4llda satt utan pengar i flera dagar.<\/p>\n

\"Hur
\nEtt litet f\u00f6retag som sysslar med detaljhandel hade en f\u00f6rs\u00e4ljningswebbplats som hostades p\u00e5 en extern plattform. De fick veta om dess otillg\u00e4nglighet via telefon fr\u00e5n en \u00e5terkommande kund. Vid tidpunkten f\u00f6r samtalet hade webbplatsen varit nere i cirka tre timmar. Det tog ytterligare n\u00e5gra timmar att hitta den ansvariga f\u00f6r webbplatsen och tv\u00e5 timmar till f\u00f6r att \u00e5tg\u00e4rda felet. D\u00e4rav var webbplatsen n\u00e4stan hela arbetsdagen otillg\u00e4nglig. Enligt f\u00f6retagets kommersiella direkt\u00f6r kostade denna driftstopp dem omkring 1 miljon rubel. <\/p>\n

Jag har sj\u00e4lv st\u00f6tt p\u00e5 en liknande situation n\u00e4r jag kom till v\u00e5rdcentralen och skulle g\u00e5 till registreringen f\u00f6r DMS. De kunde inte skicka mig till l\u00e4karen av en enkel anledning \u2013 p\u00e5 morgonen var det ett str\u00f6mavbrott, och efter olyckan fungerade varken deras posttj\u00e4nst eller n\u00e5got s\u00e4tt att kontakta f\u00f6rs\u00e4kringsbolaget. N\u00e4r jag fr\u00e5gade om var deras administrat\u00f6rer var fick jag veta att de har en inhyrd administrat\u00f6r som kommer en g\u00e5ng i veckan. Och just nu (vid den tidpunkten var klockan redan 16:00) svarade han inte i telefon. V\u00e5rdcentralen var avsk\u00e4rmad fr\u00e5n omv\u00e4rlden i minst 7 timmar och kunde inte erbjuda betaltj\u00e4nster. <\/p>\n

\"Hur
\nVad f\u00f6renar alla dessa fall? Absolut alla problem kunde ha f\u00f6rhindrats i f\u00f6rv\u00e4g. Med en snabb reaktion fr\u00e5n de som arbetar med IT hade man kunnat minska den skada som orsakats. Detta skulle \u00e4ven ha varit m\u00f6jligt med en korrekt tolkning av tidiga symptom fr\u00e5n anv\u00e4ndarna.<\/p>\n

Vi har identifierat problemhypoteserna: <\/p>\n