LANIT-Integration-ում կան բազմաթիվ ստեղծագործ աշխատողներ: Նոր ապրանքների և նախագծերի գաղափարները բառացիորեն կախված են օդում: Երբեմն կարող է շատ դժվար լինել բացահայտել ամենահետաքրքիրները: Ուստի մենք միասին մշակեցինք մեր սեփական մեթոդաբանությունը։ Կարդացեք այս հոդվածը, թե ինչպես ընտրել լավագույն նախագծերը և իրականացնել դրանք:
Ռուսաստանում և ամբողջ աշխարհում տեղի են ունենում մի շարք գործընթացներ, որոնք հանգեցնում են ՏՏ շուկայի վերափոխմանը։ Հաշվողական հզորության ավելացման և սերվերի, ցանցի և այլ վիրտուալացման տեխնոլոգիաների առաջացման շնորհիվ շուկան այլևս կարիք չունի մեծ քանակությամբ սարքավորումների: Վաճառողներն ավելի ու ավելի են նախընտրում ուղղակիորեն աշխատել հաճախորդների հետ: ՏՏ շուկան իր բոլոր ձևերով աութսորսինգի բում է ապրում՝ սկսած դասական աութսորսինգից մինչև աութսորսերների նոր ալիք՝ «ամպային մատակարարներ»: Ենթակառուցվածքային համակարգերը և տարրերը շատ ավելի հեշտ են դառնում պահպանել և կարգավորել: Ծրագրային ապահովման որակը տարեցտարի աճում է, և ինտեգրատորի խնդիրները փոխակերպվում են:
Ինչպես ենք մենք աշխատում գաղափարների հետ
Ապրանքի գործարկման ուղղությունը դեպի գոյություն ունի ավելի քան մեկ տարի: Մեր հիմնական նպատակն է ստեղծել նոր ապրանքներ և դրանք շուկա հանել։ Առաջին բանը, որով մենք սկսեցինք, արտադրանքի ստեղծման գործընթացի կազմակերպումն էր։ Մենք ուսումնասիրել ենք բազմաթիվ մեթոդոլոգիաներ՝ դասականից մինչև հիփ: Սակայն նրանցից ոչ մեկը չի բավարարել մեր կարիքները։ Հետո մենք որոշեցինք հիմք ընդունել Lean Startup մեթոդաբանությունը և հարմարեցնել այն մեր առաջադրանքներին: Lean Startup-ը ձեռներեցության տեսություն է, որը ստեղծվել է Էրիկ Ռայսի կողմից: Այն հիմնված է այնպիսի հասկացությունների սկզբունքների, մոտեցումների և պրակտիկայի վրա, ինչպիսիք են նիհար արտադրությունը, հաճախորդների զարգացումը և ճկուն զարգացման մեթոդաբանությունը:
Ինչ վերաբերում է արտադրանքի մշակման կառավարման անմիջական մոտեցմանը. մենք ոչ թե նորից հայտնագործեցինք անիվը, այլ կիրառեցինք արդեն գոյություն ունեցող զարգացման մեթոդաբանությունը , ավելացնելով կրեատիվությունը, և այժմ այն կարելի է ապահով անվանել SCRUM-WATEFALL-BAN: SCRUM-ը, չնայած իր ճկունությանը, շատ կոշտ համակարգ է և հարմար է միայն մեկ ապրանքի/նախագծի համար պատասխանատու թիմ ղեկավարելու համար: Ինչպես հասկանում եք, դասական «ինտեգրացիոն» բիզնեսը չի ներառում լրիվ դրույքով տեխնիկական մասնագետների նշանակումը մեկ նախագծի վրա աշխատելու համար (բացառություններ կան, բայց չափազանց հազվադեպ), քանի որ ապրանքների վրա աշխատելուց բացի, բոլորը զբաղված են ընթացիկ նախագծերով: SCRUM-ից մենք վերցրեցինք աշխատանքի բաժանումը սպրինտերի, ամենօրյա հաշվետվությունների, հետահայացների և դերերի: Մենք ընտրեցինք Kanban-ը մեր առաջադրանքների հոսքի համար և այն լավ ինտեգրվեց մեր առկա առաջադրանքների հետևման համակարգին: Մենք կառուցեցինք մեր աշխատանքը՝ անխափան կերպով ինտեգրվելով իրերի գոյություն ունեցող կարգին:
Մինչև շուկա մուտք գործելը ապրանքն անցնում է 5 փուլով՝ գաղափար, ընտրություն, հայեցակարգ, MVP (ավելի մանրամասն ստորև) և արտադրություն։
Գաղափար
Այս փուլում ինչ-որ անցողիկ բան կա՝ գաղափար: Իդեալում, գոյություն ունեցող խնդիր կամ հաճախորդի խնդիր լուծելու գաղափար: Գաղափարների պակաս չունենք։ Նախնական պլանի համաձայն, դրանք պետք է գեներացվեն տեխնիկական տարածքների աշխատակիցների կողմից։ Որպեսզի գաղափարն ընդունվի հետագա զարգացման համար, հեղինակը պետք է լրացնի «Գաղափարների ձևավորման ձևանմուշը»: Միայն չորս հարց կա՝ ի՞նչ: Ինչի համար? Ո՞ւմ է սա պետք: Եվ եթե ոչ մեր արտադրանքը, ապա ի՞նչ:
Ընտրություն
Ավարտված ձևանմուշը մեզ հասնելուն պես սկսվում է մշակման և ընտրության ընթացակարգը։ Ընտրության փուլն ամենաաշխատատարն է։ Այս փուլում ձևավորվում են խնդիրների վարկածներ (զուր չէ, որ ես նշեցի նախորդ պարբերությունում, որ իդեալականորեն գաղափարը պետք է լուծի հաճախորդի խնդիրը) և ապրանքի արժեքը: Ձևավորվում է սանդղակի վարկած, այսինքն. ինչպես է մեր բիզնեսը զարգանալու և բարգավաճելու: Խնդրի և փորձագիտական հարցազրույցներ են անցկացվում պոտենցիալ հաճախորդների հետ՝ նախնական հաստատում տալու համար, որ մենք պատրաստվում ենք արտադրել ինչ-որ անհրաժեշտ բան: Արտադրանքի անհրաժեշտության մասին եզրակացություն անելու համար անհրաժեշտ է առնվազն 10-15 հարցազրույց։
Վարկածների հաստատման դեպքում կատարվում է նախնական ֆինանսական վերլուծություն, գնահատվում է ներդրումների մոտավոր ծավալը և ներդրողի հնարավոր շահույթը: Այս փուլի արդյունքում ծնվում և ղեկավարությանը ներկայացվում է Lean Canvas անունով փաստաթուղթ։
Հայեցակարգ
Այս փուլում գաղափարների մոտ 70%-ը վերացվում է։ Եթե հայեցակարգը հաստատվի, ապա սկսվում է գաղափարի մշակման փուլը։ Ձևավորվում է ապագա արտադրանքի ֆունկցիոնալությունը, որոշվում են իրականացման ուղիները և օպտիմալ տեխնիկական լուծումները, թարմացվում է բիզնես պլանը։ Այս փուլի արդյունքը զարգացման տեխնիկական բնութագրումն է և մանրամասն բիզնես գործը: Հաջողության դեպքում մենք անցնում ենք MVP կամ MVP փուլ:
MVP կամ MVP
MVP-ն նվազագույն կենսունակ արտադրանք է: Նրանք. արտադրանք, որը լիովին զարգացած չէ, բայց արդեն կարող է արժեք բերել և կատարել իր ֆունկցիոնալությունը։ Պարտադիր է, որ զարգացման այս փուլում մենք հետադարձ կապ հավաքենք իրական օգտատերերից և փոփոխություններ կատարենք:
Արտադրություն
Իսկ ամենավերջին փուլը արտադրությունն է։ Ապրանքների 5%-ից ոչ ավելին հասնում է այս փուլին։ Այս 5%-ը ներառում է միայն ամենակարևոր, անհրաժեշտ, կենսունակ և ֆունկցիոնալ արտադրանքը։
Մենք ունենք բազմաթիվ գաղափարներ և արդեն հավաքել ենք ծավալուն պորտֆոլիո։ Մենք վերլուծում ենք յուրաքանչյուր գաղափար և անում ենք ամեն ինչ, որպեսզի այն հասնի վերջնական փուլ։ Շատ հաճելի է, որ մեր գործընկերները անտարբեր չմնացին մեր R&D ուղղության նկատմամբ և ակտիվ մասնակցություն ունեցան արտադրանքի և լուծումների մշակմանն ու ներդրմանը։
Ինչպես պատրաստեցինք LANBIX-ը
Եկեք նայենք արտադրանքի ստեղծմանը, օգտագործելով իրական օրինակ՝ LANBIX արտադրանքը: Սա «արկղային» ծրագրային և ապարատային համակարգ է, որը նախատեսված է փոքր ՏՏ ենթակառուցվածքները վերահսկելու և որոշում կայացնողներին և բիզնես օգտագործողներին անհապաղ զգուշացնելու համար չաթբոտի միջոցով վերահսկվող անսարքությունների մասին: Ի լրումն մոնիտորինգի գործառույթի, LANBIX-ը ներառում է Help Desk-ի գործառույթը: Այս ապրանքը բացառիկ է շուկայական հատվածի համար, որը մենք թիրախավորում ենք: Սա և՛ մեր առավելությունն է, և՛ մեր ցավը։ Բայց առաջին հերթին առաջինը: Անմիջապես կասեմ, որ LANBIX-ը կենդանի արտադրանք է (այսինքն՝ այն վերջնական չէ իր մշակման մեջ և գտնվում է MVP-ի հաջորդ փուլում):
Այսպիսով, առաջին փուլը գաղափարն է։ Որպեսզի գաղափար ծնվի, պետք են խնդիրներ, և դրանք մենք ունեինք, ավելի ճիշտ՝ ոչ մենք, այլ մեր ընկերները։ Ստորև մենք կանդրադառնանք մի քանի իրական իրավիճակների, որոնք տեղի են ունեցել բիզնեսի տարբեր ոլորտներում:
Փոքր կառավարչական ընկերությունը երկու տուն է պահում Մոսկվայի մարզում: ԱՀ-ներով անձնակազմը մոտ 15 հոգի է։ Համակարգի ադմինիստրատորը այցելու ֆրիլանսեր է (հոգատար բնակիչներից մեկի խելացի որդին): Թվում է, թե կառավարող ընկերության գործունեությունը թույլ կախված է ՏՏ-ից, սակայն այս բիզնեսի առանձնահատկությունը շատ իշխանություններին ամսական հաշվետվություն ներկայացնելն է։ Ընկերության ղեկավարի համակարգային սկավառակը (որը, ինչպես միշտ, միավորում է բազմաթիվ դերեր) սպառվել է ազատ տեղից։ Բնականաբար, դա հանկարծակի տեղի չունեցավ, զգուշացումը կախված էր մոտ 2 ամիս և անընդհատ անտեսվում էր։ Բայց թարմացում եկավ, ՕՀ-ն թարմացվեց և, ի բախտի բերեց, այն սառեց թարմացման կեսին՝ «մահվանից առաջ» բողոքելով զբաղված սկավառակից: Համակարգիչը գնաց ցիկլային վերագործարկման: Մինչ մենք լուծում էինք խնդիրը և ստանում հաշվետվություններ, մենք բաց թողեցինք հաշվետվության վերջնաժամկետը: Թվում է, թե չնչին անսարքությունն առաջացրել է տարբեր անախորժություններ՝ կորուստներից մինչև դատական և վարչական պատասխանատվություն:
Նմանատիպ միջադեպ տեղի է ունեցել խոշոր հոլդինգում, որը միավորում է բազմաթիվ փոքր ընկերությունների՝ ամբողջ գրասենյակի մեկ տեխնիկական սպասարկման ծառայությունով: Բաժիններից մեկում խափանվել է գլխավոր հաշվապահի համակարգիչը. Երկար ժամանակ հայտնի էր, որ այն կարող է փչանալ (համակարգիչը հուսահատորեն դանդաղում էր և տաքանում), բայց գլխավոր հաշվապահը այդպես էլ չհասցրեց հարցում ուղարկել տեխնիկական սպասարկմանը։ Բնականաբար, այն խափանվել է հենց աշխատավարձի օրը, և վարչության աշխատակիցները մի քանի օր առանց փողի են մնացել։
Փոքր մեծածախ առևտրի փոքր բիզնեսն ուներ վաճառքի կայք, որը տեղակայված էր արտաքին կայքում: Դրա անհասանելիության մասին հեռախոսով տեղեկացանք մշտական հաճախորդից։ Զանգի պահին կայքը մոտ երեք ժամ չի աշխատում: Եվս մի երկու ժամ պահանջվեց կայքի պատասխանատուին գտնելու համար, ևս երկու ժամ՝ խնդիրը շտկելու համար։ Ըստ այդմ՝ կայքը գրեթե ողջ աշխատանքային օրվա ընթացքում անհասանելի է եղել։ Ընկերության կոմերցիոն տնօրենի խոսքով, այս պարապուրդը նրանց վրա արժեցել է մոտ 1 միլիոն ռուբլի:
Ես ինքս հանդիպեցի նմանատիպ իրավիճակի, երբ եկել էի կլինիկայում ժամադրության և ստիպված էի գնալ VHI գրանցման: Նրանք չկարողացան ինձ բժշկի ուղարկել աննշան պատճառով. առավոտյան հոսանքազրկվել էր, իսկ վթարից հետո նրանց փոստային ծառայությունը և ապահովագրական ընկերության հետ շփվելու որոշակի ծառայությունը չաշխատեց: Հարցիս՝ որտե՞ղ են ձեր ադմինները, ինձ ասացին, որ իրենց ադմինը շաբաթը մեկ է գալիս ու այցելում։ Իսկ հիմա (այդ ժամանակ արդեն ժամը 16:00-ն էր) նա չի վերցնում հեռախոսը։ Առնվազն 7 ժամ կլինիկան կտրված էր արտաքին աշխարհից և չէր կարողանում վճարովի ծառայություններ մատուցել։
Ի՞նչ ընդհանուր բան ունեն այս բոլոր դեպքերը։ Բացարձակապես բոլոր խնդիրները հնարավոր էր կանխել նախապես։ ՏՏ ոլորտի աշխատակիցների ժամանակին արձագանքելու դեպքում վնասը կարող էր կրճատվել։ Դա հնարավոր կլիներ, եթե օգտագործողների կողմից վաղ ախտանշանները ճիշտ մեկնաբանվեին:
Մենք բացահայտել ենք խնդրի վարկածները.
- զգալի դրամական և հեղինակության կորուստներ ՏՏ ենթակառուցվածքի անսարքություններին արձագանքման ցածր արագության պատճառով.
- օգտագործողների կողմից անսարքության վաղ ախտանիշների սխալ մեկնաբանություն:
Ի՞նչ կարող է անել հաճախորդը դրանց հետ, և ինչպե՞ս խուսափել նմանատիպ իրավիճակներից ապագայում: Շատ տարբերակներ չկան.
- վարձել բարձր որակավորում ունեցող համակարգի ադմինիստրատոր և ստիպել նրան բարեխղճորեն աշխատել.
- ՏՏ տեխնիկական սպասարկումը փոխանցել մասնագիտացված սպասարկման ընկերությանը.
- ինքնուրույն իրականացնել մոնիտորինգի և անսարքությունների հաշվետվության համակարգ.
- օգտատերերին/բիզնեսի անձնակազմին տրամադրել համակարգչային գրագիտության հիմունքների ուսուցում:
Հանգստանանք երրորդ տարբերակի վրա. Մոնիտորինգի համակարգ առաջարկենք նրանց, ովքեր տարբեր պատճառներով չեն օգտվում դրանից։
Լիրիկական շեղում. Ձեռնարկությունների շուկայում ՏՏ ծառայությունների մոնիտորինգի տարբեր համակարգեր վաղուց են կիրառվում, և դրանց առավելությունները վիճելի չեն: Ես խոսեցի խոշոր ընկերությունների ներկայացուցիչների հետ, նայեցի, թե ինչպես են կառուցվել բիզնեսի և ՏՏ հարաբերությունները: Մեկ խոշոր մեքենաշինական ձեռնարկության տեխնիկական տնօրենը ՏՏ ենթակառուցվածքի սպասարկումը դրել է արտաքին ընկերության, սակայն ինքը տեղյակ է բոլոր հարցերին։ Նրա գրասենյակում կախված է մոնիտորինգի համակարգի մեծ էկրան՝ ՏՏ ծառայությունների կարգավիճակի ցուցիչներով։ Ամենակրիտիկականները ներառված են համակարգում։ Տեխնիկական տնօրենը ցանկացած պահի կարող է պարզել, թե ինչ վիճակում են ենթակառուցվածքները, ինչ է կատարվում, որտեղ է խնդիրը, ծանուցվե՞լ են պատասխանատուները, խնդիրը լուծվո՞ւմ է։
Վերը թվարկված պատմությունները մեր թիմին ստիպեցին մտածել, թե ինչպես ստեղծել օպտիմալ մոնիտորինգի համակարգ փոքր ընկերությունների համար: Արդյունքում ծնվեց LANBIX-ը. մոնիտորինգի համակարգ, որը կարող է կիրառվել բացարձակապես յուրաքանչյուրի կողմից՝ առանց ՏՏ գիտելիքների: Համակարգի հիմնական նպատակը պարզ է, ինչպես բոլոր համակարգերը, որոնք ուղղված են շարունակականության և մատչելիության բարձրացմանը. չնախատեսված պարապուրդի դեպքում նվազեցնել դրամական և այլ կորուստները: Սարքը նախատեսված է նվազագույնի հասցնելու համար «ինչ-որ բան կոտրվել է» և «խնդիրը շտկված» միջև ընկած ժամանակահատվածը:
Վարկածները հաստատելու համար անցկացվել են խնդրահարույց հարցազրույցներ: Ես չէի կարող պատկերացնել, թե որքան մարդիկ պատրաստ կլինեն պատմել՝ չփորձելով վաճառել նրանց: Յուրաքանչյուր զրույց տևեց առնվազն 1,5 ժամ, և մենք ստացանք հետագա զարգացման համար օգտակար շատ տեղեկություններ:
Ամփոփենք այս փուլի արդյունքները.
- կա խնդրի ըմբռնում,
- արժեքի ըմբռնում - կա,
- Կա լուծման գաղափար.
Երկրորդ փուլն ավելի մանրամասն էր. Ելնելով դրա արդյունքներից՝ մենք պետք է ներկայացնեինք ղեկավարությանը, ով ըստ էության ներդրողի դերում է, բիզնես գործ (նույն Lean Canvas) ապրանքի հետագա ճակատագրի վերաբերյալ որոշում կայացնելու համար։
Մենք սկսեցինք շուկայի ուսումնասիրությամբ և մրցակցային վերլուծությամբ՝ պարզելու համար, թե ովքեր, ինչ և, որ ամենակարևորը, ինչպես են նրանք գործում այս շուկայում։
Պարզվեց հետեւյալը.
- Մեր սեգմենտի (փոքր բիզնեսի) համար շուկայում պատրաստի տուփով մոնիտորինգի համակարգեր չկան, բացառությամբ մի քանի-երեքի, որոնց մասին ես չեմ խոսի հասկանալի պատճառներով:
- Մեր հիմնական մրցակիցները, տարօրինակ կերպով, համակարգի ադմինիստրատորներն են՝ տնային գրված սցենարներով և բաց կոդով մոնիտորինգի համակարգերի «հավելումներով»:
- Բաց կոդով մոնիտորինգի համակարգերի օգտագործման հստակ խնդիր կա: Գոյություն ունի համակարգ, կա հսկայական քանակությամբ տեղեկատվություն այն մասին, թե ինչպես աշխատել և փոփոխել համակարգը ձեր կարիքներին համապատասխան: Իմ հարցազրույցի ադմինիստրատորներից շատերը խոստովանեցին, որ չունեն բավարար իրավասություններ իրենց գաղափարներն ինքնուրույն իրականացնելու համար: Բայց նրանք չեն կարող դա խոստովանել ղեկավարությանը` վախենալով աշխատանքից ազատվելուց: Ստացվում է արատավոր շրջան։
Այնուհետև մենք անցանք մեր պոտենցիալ հաճախորդների կարիքների վերլուծությանը: Մենք մեզ համար հայտնաբերել ենք փոքր կազմակերպությունների մի հատված, որոնք ինչ-ինչ պատճառներով չունեն իրենց սեփական ՏՏ ծառայությունը, որտեղ ՏՏ համար պատասխանատու է կա՛մ մուտքային համակարգի ադմինիստրատորը, կա՛մ ֆրիլանսերը, կա՛մ սպասարկող ընկերությունը: Ոչ թե ՏՏ կողմը որոշեց մտնել, այլ բիզնես կողմը՝ հիմնադիրներին և բիզնեսի սեփականատերերին առաջարկելով ՏՏ ենթակառուցվածքի ծառայության որակը բարելավելու գործիք: Արտադրանք, որը պետք է օգնի սեփականատերերին ապահովել իրենց բիզնեսը, բայց միևնույն ժամանակ աշխատանք կավելացնի այն մարդկանց, ովքեր պատասխանատու են ՏՏ համար: Ապրանք, որը բիզնեսին տրամադրում է ՏՏ աջակցության որակի մոնիտորինգի գործիք:
Ստացված տվյալների մշակման արդյունքում ծնվել է ապագա արտադրանքի պահանջների առաջին ցանկը (մի տեսակ կոպիտ հետք).
- մոնիտորինգի համակարգը պետք է հիմնված լինի բաց կոդով լուծման վրա և արդյունքում՝ էժան;
- հեշտ և արագ տեղադրում;
- չպետք է պահանջի ՏՏ ոլորտում հատուկ գիտելիքներ, նույնիսկ հաշվապահը (ոչ մի կերպ չէի ուզում վիրավորել այս մասնագիտության ներկայացուցիչներին) պետք է կարողանա տեղակայել և կարգավորել համակարգը.
- պետք է ավտոմատ կերպով հայտնաբերի օբյեկտները ցանցում մոնիտորինգի համար.
- պետք է ավտոմատ կերպով (և իդեալականը ավտոմատ կերպով) տեղադրի մոնիտորինգի գործակալներ.
- պետք է կարողանա վերահսկել արտաքին ծառայությունները, առնվազն CRM համակարգը և վաճառվող կայքը.
- պետք է տեղեկացնի ինչպես բիզնեսին, այնպես էլ համակարգի ադմինիստրատորին խնդիրների մասին.
- ծանուցումների խորության և «լեզուների» աստիճանը պետք է տարբեր լինի ադմինիստրատորի և բիզնեսի համար.
- համակարգը պետք է մատակարարվի սեփական սարքաշարով.
- երկաթը պետք է հնարավորինս հասանելի լինի.
- համակարգը պետք է հնարավորինս անկախ լինի արտաքին գործոններից:
Այնուհետև հաշվարկվել են արտադրանքի զարգացմանն ուղղված ներդրումները (ներառյալ տեխնիկական բաժնի աշխատակիցների աշխատանքային ծախսերը): Պատրաստվել է բիզնես մոդելի ուրվագիծ և հաշվարկվել է արտադրանքի միավորի տնտեսությունը:
Փուլի արդյունքը.
- բարձր մակարդակի արտադրանքի կուտակում;
- ձևակերպված բիզնես մոդել կամ մասշտաբի վարկած, որը դեռ պետք է փորձարկվի գործնականում:
Անցնենք հաջորդ փուլին` հայեցակարգին: Այստեղ մենք՝ որպես ինժեներներ, հայտնվում ենք մեր հայրենի տարերքի մեջ։ Կան «ցանկությունների ցուցակներ», որոնք տարրալուծվում են բաղադրիչների/ենթահամակարգերի/հատկանիշների, այնուհետև դրանք վերածվում են տեխնիկական բնութագրերի/օգտագործողների պատմությունների, այնուհետև՝ նախագծի և այլն։ Ես մանրամասն չեմ անդրադառնա այլընտրանքային տարբերակների զանգվածի պատրաստման գործընթացին, եկեք անմիջապես անցնենք պահանջներին և դրանց իրականացման ընտրված մեթոդներին:
Պահանջ
որոշում
- Այն պետք է լինի բաց մոնիտորինգի համակարգ.
Մենք վերցնում ենք բաց կոդով մոնիտորինգի համակարգ:
- Համակարգը պետք է լինի պարզ և արագ տեղադրվող;
- չպետք է պահանջի հատուկ ՏՏ գիտելիքներ: Նույնիսկ հաշվապահը պետք է կարողանա տեղակայել և կարգավորել համակարգը:
Մենք առաջարկում ենք տեղադրված համակարգ, որպեսզի օգտագործողին միայն անհրաժեշտ լինի միացնել սարքը և մի փոքր կարգավորել այն՝ երթուղիչի նման:
Եկեք փակենք սարքի հետ փոխազդեցությունը բոլորի համար պարզ և հասկանալի բանով:
Եկեք գրենք մեր սեփական չաթբոտը հայտնի ակնթարթային մեսենջերներից մեկի համար և համակարգի հետ բոլոր փոխազդեցությունները փոխանցենք դրան։
Համակարգը պետք է.
- ավտոմատ կերպով հայտնաբերել ցանցում մոնիտորինգի համար անհրաժեշտ օբյեկտները.
- ավտոմատ կերպով տեղադրել մոնիտորինգի գործակալներ;
- Կարողանալ վերահսկել արտաքին ծառայությունները, առնվազն CRM համակարգը և վաճառվող կայքը:
Մենք հավելումներ ենք գրում մոնիտորինգի համակարգի համար՝
- օբյեկտների ավտոմատ հայտնաբերում;
- գործակալների ավտոմատ տեղադրում;
- արտաքին ծառայությունների հասանելիության մոնիտորինգ:
Համակարգը պետք է.
- տեղեկացնել ինչպես բիզնեսին, այնպես էլ համակարգի ադմինիստրատորին խնդիրների մասին.
- կարողանալ վերահսկել արտաքին ծառայությունները, առնվազն CRM համակարգը և վաճառվող կայքը: Ծանուցումների խորության աստիճանը և «լեզուն» պետք է տարբեր լինեն ադմինիստրատորի և բիզնեսի համար:
- Համակարգը չպետք է պահանջի հատուկ ՏՏ գիտելիքներ, նույնիսկ հաշվապահը պետք է կարողանա տեղակայել և կարգավորել համակարգը:
- Ավելացնենք տարբեր տեսակի ծանուցումներ տարբեր տեսակի օգտատերերի համար։ Նրանք տարբերվում են բարձրությամբ և խորությամբ: Գործարար օգտատերը կստանա ծանուցումներ, ինչպիսիք են «ամեն ինչ լավ է, բայց Իվանովի համակարգիչը շուտով կմեռնի»: Ադմինիստրատորը կստանա ամբողջական հաղորդագրություն սխալի մասին, թե ով, ինչպես և ինչ է տեղի ունեցել կամ կարող է պատահել:
- Ավելացնենք լրացուցիչ պատասխանատուի փոստից օգտվելու հնարավորությունը, որպեսզի անսարքության դեպքում նա հաղորդագրություն ստանա։
- Եկեք ավելացնենք փոխգործակցությունը արտաքին ծառայություններ մատուցողների հետ՝ հիմնված նախապես պատրաստված տեքստով նամակներ ուղարկելու վրա, քանի որ Դա էլփոստն է, որը տեղիք է տալիս միջադեպին:
- Համակարգի հետ բոլոր փոխազդեցությունները միացված կլինեն չաթ-բոտին, հաղորդակցությունն իրականացվում է երկխոսության ոճով:
Հավելվածը:
- Ավելացնենք «զատ ադմինիստրատորի հետ» ֆունկցիոնալությունը, որպեսզի օգտատերը կարողանա ադմինիստրատորին ուղղակիորեն խնդիրը նկարագրող հաղորդագրություն ուղարկել:
- Համակարգը պետք է մատակարարվի սեփական ապարատով:
- Երկաթը պետք է հասանելի լինի:
- Համակարգը պետք է հնարավորինս անկախ լինի շրջակա միջավայրից:
- Վերցնենք պատրաստի և էժան Raspberry PI համակարգիչ։
- Մենք նախագծելու ենք անխափան սնուցման տախտակ:
- Ավելացնենք մոդեմ, որ անկախ լինի տեղական ցանցի վիճակից։
- Մենք նախագծելու ենք գեղեցիկ շենք։
Այժմ մենք ունենք երեք ենթահամակարգ՝ իրենց պահանջներով և դրանց իրականացման տեսլականով.
- ապարատային ենթահամակարգ;
- մոնիտորինգի ենթահամակարգ;
- օգտագործողների փոխազդեցության ենթահամակարգ:
Մենք մշակել ենք ապարատային ենթահամակարգի նախնական դիզայն։ Այո այո! Խախտելով շարժունության բոլոր կանոնները՝ մենք փաստաթուղթ ենք մշակել, քանի որ արտադրական գործարաններն աշխատում են փաստաթղթերով։ Մնացած ենթահամակարգերի համար մենք բացահայտեցինք օգտատերերին (անձանց), պատրաստեցինք օգտատերերի պատմություններ և գրեցինք առաջադրանքներ զարգացման համար:
Սա ավարտում է հայեցակարգի փուլը, և արդյունքը հետևյալն է.
- նախագիծ ապարատային հարթակի համար;
- ձևակերպված տեսլականը օգտագործողների պատմությունների տեսքով մնացած երկու ենթահամակարգերի համար.
- ծրագրային ապահովման նախատիպ, որն իրականացվում է որպես վիրտուալ մեքենա;
- սարքաշարի նախատիպը, որն իրականացվել է ստենդի տեսքով, որտեղ ապարատային լուծումներն իրականում փորձարկվել են ամրության համար.
- մեր ադմինների կողմից իրականացված թեստավորում:
Խնդիրներն այս փուլում հիմնականում կազմակերպչական էին և առնչվում էին վաճառքի իրավական և հաշվապահական ասպեկտների վերաբերյալ ինժեներական անձնակազմի գիտելիքների պակասին: Նրանք. Մի բան է պարզել, թե ինչ և ինչպես վաճառել, և բոլորովին այլ բան է բախվել անողոք իրավական մեքենայի հետ՝ արտոնագրեր, զարգացման առաջադրանքներ, գրանցում, EULA և շատ ավելին, որոնք մենք՝ որպես ստեղծագործ մարդիկ, ի սկզբանե հաշվի չենք առել:
Դեռևս խնդիր չկար, այլ ավելի շուտ դժվարություն՝ կապված պարիսպների նախագծման հետ: Մեր թիմը բաղկացած է միայն ինժեներներից, ուստի պատյանի առաջին տարբերակը «կառուցվել է» պլեքսիգլասից մեր էլեկտրոնիկայի մասնագետի կողմից:
Մարմինը, մեղմ ասած, հակասական տեսք ուներ, հատկապես ժամանակակից տեխնոլոգիաներով փչացած հանրության համար: «Կուլիբինների» ավագ սերնդի մեջ, իհարկե, գիտակներ կային. շենքը նրանց մեջ նոստալգիկ զգացումներ էր առաջացնում: Որոշվեց նորովի արտադրել և նախագծել պատյանը, քանի որ հինը, բացի էսթետիկ թերություններից, ուներ նաև կառուցվածքայիններ. պլեքսիգլասը լավ չէր հանդուրժում սարքի հավաքումն ու ապամոնտաժումը և հակված էր ճաքելու: Գործի պատրաստման մասին կպատմեմ հետագա:
Եվ հիմա մենք մոտ ենք վերջնագծին՝ MVP: Իհարկե, սա դեռ վերջնական արտադրության արտադրանք չէ, բայց արդեն օգտակար և արժեքավոր է։ Այս փուլի հիմնական նպատակն է սկսել «ստեղծել-գնահատել-սովորել» ցիկլը: Սա հենց այն փուլում է, որում գտնվում է LANBIX-ը:
«Ստեղծել» փուլում մենք ստեղծեցինք սարք, որն իրականացնում է նշված գործառույթը: Այո, այն դեռ կատարյալ չէ, և մենք շարունակեցինք աշխատել դրա վրա։
Եկեք վերադառնանք մարմնի արտադրությանը, այսինքն. մեր սարքը նոստալգիկից ժամանակակիցի վերածելու առաջադրանքին: Սկզբում ես ուսումնասիրեցի պահարաններ արտադրողների և արդյունաբերական դիզայնի ծառայությունների շուկան: Նախ՝ ռուսական շուկայում պատյաններ արտադրող շատ ընկերություններ չկան, և երկրորդ՝ արդյունաբերական դիզայնի արժեքը այս փուլում արգելիչ բարձր է՝ մոտ 1 միլիոն ռուբլի։
Դիզայնի համար դիմեցին մեր մարքեթինգի բաժնին, երիտասարդ դիզայները պատրաստ էր ստեղծագործական փորձերի։ Մենք ուրվագծեցինք կորպուսի մեր տեսլականը (նախկինում ուսումնասիրելով կորպուսի կառուցման լավագույն օրինակները), իսկ նա, իր հերթին, այն վերածեց արվեստի գործի։ Մնում է միայն արտադրել այն։ Մենք, հպարտանալով մեր դիզայնով, դիմեցինք մեր գործընկերներին։ Նրանց գործադիր տնօրենը անմիջապես ջախջախեց մեր երևակայությունները՝ բոլորովին անվճար մատնանշելով բաներ, որոնք հնարավոր չէ արտադրել մեր ընտրած ձևով: Պատյանը կարող է արտադրվել, և այն ավելի վատը չի լինի, քան Apple-ը, բայց գործի արժեքը կլինի երեքից չորս անգամ ավելի թանկ, քան բոլոր էլեկտրոնային բաղադրիչները: Մի շարք գործողություններից և հաստատումներից հետո մենք նախագծել ենք բնակարան, որը կարող է արտադրվել: Այո, այն այնքան էլ գեղեցիկ չէ, որքան մենք նախատեսել էինք, բայց այն իդեալական է ընթացիկ նպատակներին հասնելու համար:
Փուլի արդյունքը՝ մարտական և փորձարկման պատրաստ սարքերի առաջին խմբաքանակը։
Իսկ հիմա ամենադժվարը «գնահատման» փուլն է, և մեր արտադրանքով մենք հենց այս պահին ենք։ Մենք կարող ենք գնահատել միայն իրական հաճախորդների կողմից օգտագործման արդյունքների հիման վրա և այստեղ ոչ մի ենթադրություն չի գործում: Մեզ պետք են այդ «վաղ որդեգրողները», որպեսզի հետադարձ կապ տրամադրեն և ապրանքի մեջ կատարեն փոփոխություններ, որոնք իսկապես անհրաժեշտ են: Հարց է առաջանում՝ որտեղի՞ց ձեռք բերել հաճախորդներին և ինչպե՞ս համոզել նրանց մասնակցել փորձին։
Բոլոր հնարավոր տարբերակներից մենք ընտրեցինք թվային գործիքների դասական հավաքածու՝ վայրէջք էջ և գովազդային արշավ սոցիալական ցանցերում։
Գործընթացն արդեն մեկնարկել է, բայց արդյունքների մասին դեռ վաղ է խոսել, թեև արդեն արձագանքներ կան, և մենք ստացել ենք մեր շատ վարկածների հաստատումը։ Հաճելի անակնկալ էր բիզնեսի բոլորովին այլ սեգմենտների ներկայացուցիչների արձագանքը՝ շատ ավելի մեծ, քան մենք սպասում էինք։ Հիմարություն կլիներ անտեսել նոր ներածությունները, և հարցազրույցների արդյունքների հիման վրա որոշվեց գործարկել զուգահեռ LANBIX գիծ, որը կոչվում է LANBIX Enterprise: Մենք ավելացրել ենք բաշխված ենթակառուցվածքների աջակցություն, Wi-Fi ցանցերի մոնիտորինգ՝ խնդիրների վերացման և տեղայնացման միջոցով, ինչպես նաև կապի ալիքների որակի մոնիտորինգ: Լուծման նկատմամբ մեծագույն հետաքրքրություն են հայտնել սպասարկող ընկերությունները։ Միևնույն ժամանակ, լուծումների գործարկման մեջ կարևոր դեր են խաղում մեր արդեն իսկ մշակած սարքերը։
Ինչ կլինի հաջորդ:
Թե ինչ կլինի հետո օրիգինալ LANBIX-ի հետ, պարզ կդառնա արշավի արդյունքների հիման վրա: Եթե մեր վարկածները չհաստատվեն, Lean մեթոդոլոգիայի համաձայն, մենք անխղճորեն կազատվենք դրանից կամ այն կվերածվի նորի, քանի որ ավելի վատ բան չկա, քան ոչ ոքի պետք չէ ապրանք պատրաստելը։ Բայց հիմա կարելի է ասել, որ կատարված աշխատանքն իզուր չի անցել, և դրա շնորհիվ ի հայտ է եկել զուգահեռ արտադրանքի մի ամբողջ ճյուղ, որի վրա մենք ակտիվ աշխատում ենք։ Հաջողության դեպքում LANBIX-ը MVP փուլից կտեղափոխվի վերջնական փուլ և կզարգանա արտադրանքի շուկայավարման հասկանալի դասական օրենքների համաձայն:
Կրկնում եմ՝ հիմա մենք ուզում ենք գտնել վաղ ընդունողներ, ընկերություններ, որոնք կարող են տեղադրել մեր արտադրանքը՝ հետադարձ կապ հավաքելու համար։ Եթե հետաքրքրված եք LANBIX-ի փորձարկումներով, գրեք մեկնաբանություններում կամ անձնական հաղորդագրություններում:
Source: www.habr.com