🥇Як мы працуем з ідэямі, і як нарадзіўся LANBIX

У «шчокі-Інтэграцыі» шмат крэатыўных супрацоўнікаў. Ідэі новых прадуктаў і праектаў літаральна вісяць у паветры. Выявіць самыя цікавыя часам бывае вельмі складана. Таму мы сумеснымі намаганнямі распрацавалі сваю методыку. Як адабраць найлепшыя праекты і рэалізаваць іх, чытайце ў гэтым артыкуле.

У Расіі, ды і ў свеце ў цэлым, адбываецца шэраг працэсаў, якія прыводзяць да трансфармацыі ІТ-рынку. Дзякуючы павелічэнню вылічальных магутнасцяў і з'яўленню тэхналогій сервернай, сеткавай і іншай віртуалізацыі, рынак перастаў мець патрэбу ў вялікай колькасці "жалеза". Вендары ўсё часцей аддаюць перавагу працы з заказчыкамі напрамую. На ІТ-рынку росквіт аўтсорсінгу ва ўсіх яго праявах, пачынаючы з класічнага аўтсорсінгу і заканчваючы аўтсорсерамі новай хвалі - "хмарнымі правайдэрамі". Інфраструктурныя сістэмы і элементы становяцца істотна прасцей у абслугоўванні і наладзе. Якасць ПЗ расце з кожным годам і задачы інтэгратара трансфармуюцца.

Як мы працуем з ідэямі

Прадуктовае стартап-кірунак у «шчокі-Інтэграцыі» існуе ўжо больш за год. Асноўная наша мэта - стварэнне новых прадуктаў і вывад іх на рынак. Першае, з чаго мы пачалі, - арганізавалі сам працэс стварэння прадуктаў. Мы праштудзіравалі мноства метадалогій, пачынаючы з класічных і заканчваючы хайпавымі. Аднак ніводная з іх не адпавядала нашым запытам. Тады мы вырашылі ўзяць за аснову метадалогію Lean Startup і адаптаваць яе пад свае задачы. "Беражлівы стартап" - тэорыя прадпрымальніцтва, створаная Эрыкам Рысам. У яе аснове ляжаць прынцыпы, падыходы і практыкі такіх канцэпцый, як ашчадная вытворчасць, customer development і гнуткая метадалогія распрацоўкі.

Што да непасрэдна падыходу да кіравання распрацоўкай прадукта: мы не сталі вынаходзіць ровар, а ўжылі ўжо існую метадалогію распрацоўкі SCRUM, дадаўшы крэатыў, і зараз яе смела можна назваць SCRUM-WATERFALL-BAN. SCRUM, нягледзячы на сваю гнуткасць, з'яўляецца вельмі цвёрдай сістэмай і падыходзіць для кіравання камандай, якая адказвае толькі за адзін прадукт/праект. Як вы разумееце, класічны «інтэгратарскі» бізнэс не мяркуе вылучэнні тэхнічных адмыслоўцаў на фултайм для працы над адным праектам (выключэнні бываюць, але вельмі рэдка), бо апроч працы над прадуктамі ўсё занятыя на бягучых праектах. З SCRUM мы ўзялі дзяленне працы на спрынты, штодзённую справаздачнасць, рэтраспектывы і ролі. Для працы са струменем задач мы абралі Kanban, і ён выдатна інтэграваўся ў нашу існую сістэму адсочвання задач. Мы выбудавалі працу, плаўна інтэграваўшыся ва ўжо існуючы парадак рэчаў.
Перш чым выйсці на рынак, тавар праходзіць 5 стадый: ідэя, адбор, канцэпцыя, MЖП (падрабязней - ніжэй) і вытворчасць.

Ідэя

На дадзеным этапе ёсць нешта эфемернае - ідэя. У ідэале, ідэя вырашэння існуючай праблемы або задачы кліента. Недахопу ў ідэях у нас няма. Па пачатковай задумцы яны павінны генеравацца супрацоўнікамі тэхнічных напрамкаў. Для таго, каб ідэя была прынята ў далейшую распрацоўку, аўтар павінен запоўніць "Шаблон афармлення ідэі". Там усяго чатыры пытанні: Што? Каб што? Каму гэта патрэбна? А калі не наш прадукт, дык што?

Крыніца

Адбор

Як толькі аформлены шаблон пападае да нас, стартуе працэдура апрацоўкі і адбору. Стадыя адбору найболей працаёмкая. На гэтым этапе адбываецца фармаванне гіпотэз праблем (я нездарма ў папярэднім абзацы згадаў, што ў ідэале ідэя павінна вырашаць праблему кліента) і каштоўнасці прадукта. Фармуецца гіпотэза маштабу, г.зн. як наш бізнэс збіраецца расці і квітнець. Праводзяцца праблемныя і экспертныя інтэрв'ю з патэнцыйнымі заказчыкамі для папярэдняга пацверджання таго, што мы збіраемся вырабляць нешта патрэбнае. Патрабуецца не менш за 10-15 інтэрв'ю, каб зрабіць выснову аб патрэбнасці прадукта.

Калі гіпотэзы пацвярджаюцца, ажыццяўляецца папярэдні фінансавы аналіз, ацэньваецца прыкладны аб'ём інвестыцый і магчымы заробак фундатара. У выніку дадзенага этапу нараджаецца дакумент пад назовам Lean Canvas і прэзентуецца кіраўніцтву.

Канцэпцыя

На гэтым этапе адсяюцца каля 70% ідэй. Калі канцэпт ухвалены, то пачынаецца стадыя прапрацоўкі ідэі. Фармуюцца функцыянальныя магчымасці будучага прадукта, вызначаюцца шляхі рэалізацыі і аптымальныя тэхнічныя рашэнні, актуалізуецца бізнес-план. Вынікам гэтага этапа з'яўляецца тэхнічнае заданне на распрацоўку і падрабязны бізнес-кейс. У выпадку поспеху - пераходзім да стадыі МЖП або MVP.

МЖП ці MVP

МЖП - гэта мінімальна жыццяздольны прадукт. Г.зн. прадукт, які ня дапрацаваны да канца, але ўжо можа прыносіць каштоўнасць і свой функцыянал выконвае. Абавязкова на дадзеным этапе распрацоўкі мы збіраем зваротную сувязь з рэальных карыстальнікаў і ўносім змены.

Вытворчасць

І самы апошні этап - вытворчасць. Да гэтай стадыі дабіраецца не больш за 5% прадуктаў. У гэтыя 5% уваходзяць толькі найболей важныя, патрэбныя, жыццяздольныя і функцыянальныя прадукты.

У нас шмат ідэй, ужо сабраны аб'ёмны партфель. Мы разбіраем кожную ідэю і робім усё, каб яна дайшла да фінальнай стадыі. Вельмі прыемна, што калегі не засталіся абыякавымі да нашага R&D-кірунку і прымаюць актыўны ўдзел у распрацоўцы, рэалізацыі прадуктаў і рашэнняў.

Як мы рабілі LANBIX

Разгледзім стварэнне прадукта на рэальным прыкладзе - прадукце LANBIX. Гэта "скрынкавы" праграмна-апаратны комплекс, прызначаны для маніторынгу невялікіх ІТ-інфраструктур і аператыўнага абвесткі адказных асоб і бізнес-карыстальнікаў аб няспраўнасцях з кіраваннем праз чат-бот. Апроч функцыі маніторынгу LANBIX уключае ў сябе функцыянал Help Desk. Гэты прадукт з'яўляецца эксклюзіўным для таго сегмента рынку, на які мы нацэліліся. Гэта і наша перавага, і наш боль. Але пра ўсё па парадку. Адразу скажу, што LANBIX – прадукт жывы (г.зн. ён не канчатковы ў сваім развіцці і знаходзіцца на чарговым вітку MVP).

Такім чынам, першая стадыя - ідэя. Каб нарадзілася ідэя, патрэбны праблемы, і яны ў нас былі, дакладней не ў нас, а ў нашых знаёмых. Ніжэй разгледзім некалькі рэальных сітуацый, якія адбыліся ў розных галінах бізнесу.

Невялікая кіруючая кампанія абслугоўвае два дамы ў Падмаскоўі. Штат супрацоўнікаў, якія маюць ПК, каля 15 чалавек. Сістэмны адміністратар - прыходны фрылансер (цямлівы сын аднаго з неабыякавых жыхароў). Здавалася б, дзейнасць КК слаба залежыць ад ІТ, але асаблівасць гэтага бізнэсу – штомесячная справаздачнасць перад мноствам інстанцый. На сістэмнай кружэлцы раздзела кампаніі (як звычайна, які сумяшчае мноства роляў) скончылася вольнае месца. Натуральна, гэта адбылося не раптоўна, папярэджанне вісела каля 2 месяцаў і ўвесь час ігнаравалася. Але прыляцела абнаўленне, АС абнавілася і як наліха завісла ў сярэдзіне абнаўлення, паскардзіўшыся перад "смерцю" на заняты дыск. Камп сышоў у цыклічную перазагрузку. Пакуль разбіраліся з праблемай і даставалі справаздачы, прапусцілі тэрмін падачы справаздачнасці. Здавалася б, дробязная няспраўнасць стала прычынай розных непрыемнасцяў: ад страт да судовых разбораў і адміністрацыйнай адказнасці.

Крыніца

Падобны выпадак адбыўся ў буйным холдынгу, які аб'ядноўвае мноства невялікіх кампаній, з адзінай службай тэхнічнай падтрымкі на ўвесь офіс. У адным з дэпартаментаў зламаўся камп'ютар галоўнага бухгалтара. Што ён можа зламацца, было вядома ўжо даўно (комп адчайна тармазіў і грэўся), але рукі галоўбуха ніяк не даходзілі да таго, каб адправіць заяўку ў тэхпадтрымку. Натуральна, зламаўся ён акурат у дзень заробку, і супрацоўнікі дэпартамента некалькі дзён сядзелі без грошай.

У невялікага бізнэсу па дробнааптовым гандлі лёг які прадае сайт, які хасціўся на вонкавай пляцоўцы. Аб яго недаступнасці даведаліся па тэлефоне ад пастаяннага заказчыка. На момант званка сайт ляжаў ужо каля трох гадзінаў. На пошукі асобы, адказнай за сайт, пайшла яшчэ пару гадзін, на ліквідацыю няспраўнасці — яшчэ дзве. Адпаведна, практычна ўвесь працоўны дзень сайт быў недаступны. Па словах камерцыйнага дырэктара кампаніі, гэты просты каштаваў ім каля 1 млн рублёў.

Я сам сутыкнуўся з падобнай сітуацыяй, калі прыйшоў на прыём у паліклініку і мусіў патрапіць у рэгістратуру ДМС. Да лекара мяне адправіць не маглі па банальнай прычыне - з раніцы быў скок напругі, і пасля аварыі іх паштовы сэрвіс і нейкі сэрвіс па сувязі са страхавой не працавалі. На маё пытанне, а дзе ж вашыя адміны, мне было сказана, што адмін у іх прыходны і наведвае іх раз у тыдзень. А зараз (на той момант час было ўжо 16:00) ён трубку не бярэ. Як мінімум 7 гадзін паліклініка была адрэзана ад знешняга свету і не магла аказваць платныя паслугі.

Што аб'ядноўвае ўсе гэтыя выпадкі? Абсалютна ўсе праблемы можна было прадухіліць загадзя. Пры своечасовай рэакцыі з боку людзей, якія абслугоўваюць ІТ, можна было зменшыць прычыненую шкоду. Гэта было б магчыма і пры правільнай інтэрпрэтацыі ранніх сімптомаў з боку карыстальнікаў.

Мы вылучылі гіпотэзы праблем:

істотныя грашовыя і рэпутацыйнага страты з-за нізкай хуткасці рэакцыі на няспраўнасці ў ІТ-інфраструктуры;
няслушная інтэрпрэтацыя ранніх сімптомаў няспраўнасці з боку карыстальнікаў.

Што можа з імі зрабіць замоўца, і як пазбегнуць падобных сітуацый у будучыні? Варыянтаў не так шмат:

узяць высокакваліфікаванага сістэмнага адміністратара ў штат і прымусіць яго працаваць сумленна;
аддаць абслугоўванне ІТ спецыялізаванай сэрвіснай кампаніі;
самастойна ўкараніць сістэму маніторынгу і абвесткі аб няспраўнасцях;
правесці навучанне карыстальнікаў/бізнес-персаналу асновам камп'ютарнай пісьменнасці.

Спыняемся на трэцім варыянце. Давайце прапануем сістэму маніторынгу тым, хто яе не выкарыстоўвае з-за розных прычын.

Лірычны адступ. Розныя сістэмы маніторынгу ІТ-сэрвісаў на enterprise-рынку выкарыстоўваюцца даўно, і іх карысць не аспрэчваецца. Я меў зносіны з прадстаўнікамі буйных кампаній, глядзеў, як выбудаваны ўзаемаадносіны бізнесу і ІТ. Тэхнічны дырэктар аднаго буйнога машынабудаўнічага прадпрыемства аддаў абслугоўванне ІТ-інфраструктуры знешняй кампаніі, але сам застаецца ў курсе ўсіх спраў. У яго ў кабінеце вісіць вялікі экран сістэмы маніторынгу з індыкатарамі стану ІТ-сэрвісаў. У сістэму заведзены самыя крытычныя. У любы момант тэхнічны дырэктар можа даведацца, у якім стане інфраструктура, што адбываецца, на якім участку праблема, ці абвешчаныя адказныя людзі, ці вырашаецца задача.

Пералічаныя гісторыі прымусілі нашу каманду задумацца над тым, як зрабіць аптымальную сістэму маніторынгу для невялікіх кампаній. У выніку нарадзіўся LANBIX – сістэма маніторынгу, якую можа разгарнуць абсалютна любы чалавек без ведаў у галіне ІТ. Асноўная задача сістэмы простая, як і ва ўсіх сістэм, накіраваных на павышэнне бесперапыннасці і даступнасці, - зніжэнне грашовых і іншых страт у выпадку ўзнікнення пазапланавых прастояў. Прылада заклікана да мінімуму скараціць час паміж "у мяне нешта зламалася" і "праблема ўхіленая".

Для пацверджання гіпотэз былі праведзены праблемныя інтэрв'ю. Я не мог уявіць сабе, колькі людзі гатовыя расказаць, калі не спрабаваць ім прадаваць. Кожная гутарка доўжылася не менш за 1,5 гадзіны, і мы атрымалі масу інфармацыі, карыснай для далейшай распрацоўкі.

Падсумоўваем вынік гэтага этапу:

разуменне праблемы - ёсць,
разуменне каштоўнасці - ёсць,
ідэя для рашэння - ёсць.

Другі этап быў больш дэталёвы. Па яго выніках мы павінны былі прадставіць кіраўніцтву, якое па сутнасці выконвае ролю інвестара, бізнес-кейс (той самы Lean Canvas) для прыняцця рашэння аб далейшым лёсе прадукта.

Пачалі мы з даследавання рынку і канкурэнтнага аналізу з мэтай высветліць, хто, што і, галоўнае, як робіць на гэтым рынку.

Высветлілася наступнае.

На рынку няма гатовых скрыначных сістэм маніторынгу для нашага сегмента (малы бізнэс), за выключэннем пары-тройкі, пра якія я па зразумелых прычынах казаць не буду.
Нашы галоўныя канкурэнты, як ні дзіўна, - сістэмныя адміністратары з самапіснымі скрыптамі і «дапілкамі» да сістэм маніторынгу з адкрытым зыходным кодам.
У наяўнасці відавочная праблема з выкарыстаннем сістэм маніторынгу з адчыненым зыходным кодам. Ёсць сістэма, ёсць вялікая колькасць інфармацыі па рабоце і дапрацоўцы сістэмы пад свае патрэбы. З апытаных мною адміністратараў многія прызналіся, што ў іх не хапае кампетэнцый для рэалізацыі задумаў саматугам. А прызнацца кіраўніцтву ў гэтым яны не могуць з-за боязі звальнення. Атрымліваецца замкнёнае кола.

Затым мы перайшлі да аналізу патрэб нашых патэнцыйных заказчыкаў. Мы вылучылі для сябе сегмент невялікіх арганізацый, па якіх-небудзь прычынах не маюць уласнай ІТ-службы, дзе за ІТ адказвае альбо прыходны сістэмны адміністратар, альбо фрылансер, альбо сэрвісная кампанія. Заходзіць вырашылі не бакі ІТ, а з боку бізнесу, прапаноўваючы заснавальнікам і ўласнікам бізнесу інструмент для павышэння якасці абслугоўвання ІТ-інфраструктуры. Прадукт, які павінен дапамагчы ўладальнікам засцерагчы свой бізнэс, праўда, у той жа час ён дадасць працы людзям, якія адказваюць за ІТ. Прадукт, які прадстаўляе бізнэсу інструмент кантролю за якасцю суправаджэння ІТ.

У выніку апрацоўкі атрыманых дадзеных нарадзіўся першы спіс патрабаванняў (нейкі грубіянскі бэклог) да будучыні прадукту:

сістэма маніторынгу павінна быць заснавана на рашэнні з адкрытым зыходным кодам і як следства таннай;
простая і хуткая ва ўстаноўцы;
не павінна патрабаваць спецыфічных ведаў у ІТ, нават бухгалтар (ні ў якім разе не жадаў абразіць прадстаўнікоў гэтай прафесіі) павінен быць у стане разгарнуць і наладзіць сістэму;
павінна аўтаматычна выяўляць аб'екты для маніторынгу ў сетцы;
павінна аўтаматызавана (а ў ідэале аўтаматычна) усталёўваць агенты маніторынгу;
павінна мець магчымасць маніторынгу вонкавых сэрвісаў, як мінімум CRM-сістэму і які прадае сайт;
павінна апавяшчаць аб непаладках як бізнэс, так і сістэмнага адміністратара;
ступень глыбіні і "мова" абвестак павінен быць розным для адміна і бізнэсу;
сістэма павінна пастаўляцца на ўласным жалезе;
жалеза павінна быць максімальна даступным;
сістэма павінна быць максімальна незалежнай ад вонкавых фактараў.

Далей былі разлічаны інвестыцыі на распрацоўку прадукта (уключаючы працавыдаткі супрацоўнікаў тэхнічнага дэпартамента). Падрыхтаваны эскіз бізнес-мадэлі і палічана юніт-эканоміка прадукта.

Вынік этапа:

высокаўзроўневы бэклог прадукта;
сфармуляваная бізнес-мадэль або гіпотэза маштабу, якую яшчэ трэба будзе праверыць на практыцы.

Пяройдзем да наступнага этапу - канцэпцыі. Тут мы як інжынеры пападаем у сваю родную стыхію. Ёсць «хатэлкі», якія дэкампазіруюцца на кампаненты/падсістэмы/фічы, далей яны ператвараюцца ў ТЗ/карыстальніцкія гісторыі, затым у праект і г.д. Не буду падрабязна спыняцца на працэсе падрыхтоўкі масіва альтэрнатыўных варыянтаў, пяройдзем адразу да патрабаванняў і абраным спосабам для іх рэалізацыі.

патрабаванне
рашэнне

Гэта павінна быць адчыненая сістэма маніторынгу;

Бярэм сістэму маніторынгу з адкрытым зыходным кодам.

Сістэма павінна быць простая і хуткая ва ўсталёўцы;
не павінна патрабаваць спецыфічных ведаў у ІТ. Нават бухгалтар павінен быць у стане разгарнуць і наладзіць сістэму.

Прапануем праінсталяваную сістэму, каб карыстачу засталося толькі ўлучыць прыбор і трохі яго наладзіць, па аналогіі з роўтарам.

Замкнем узаемадзеянне з прыладай на нешта простае і зразумелае ўсім.

Напішам свой чат-бот для аднаго з вядомых месэнджараў і завядзем усё ўзаемадзеянне з сістэмай на яго.

Сістэма павінна:

аўтаматычна выяўляць патрабаваныя да маніторынгу аб'екты ў сетцы;
аўтаматычна ўстанаўліваць агенты маніторынгу;
Мець магчымасць маніторынгу вонкавых сэрвісаў, як мінімум CRM-сістэмы і які прадае сайта.

Пішам дапаўненні для сістэмы маніторынгу па:

аўтаматычнаму выяўленню аб'ектаў;
аўтаматычнай усталёўцы агентаў;
маніторынгу даступнасці знешніх сэрвісаў.

Сістэма павінна:

апавяшчаць аб непаладках як бізнэс, так і сістэмнага адміністратара;
мець магчымасць маніторынгу вонкавых сэрвісаў, прынамсі CRM-сістэмы і які прадае сайта. Ступень глыбіні і «мова» абвестак павінен быць розным для адміна і бізнэсу.
Сістэма не павінна патрабаваць спецыфічных ведаў у ІТ, нават бухгалтар павінен быць у стане разгарнуць і наладзіць сістэму.

Дадамо розныя віды апавяшчэнняў для розных тыпаў карыстальнікаў. Яны адрозніваюцца па падачы і глыбіні. Бізнес-карыстальнік атрымае апавяшчэння па тыпе «ўсё добра, але кампутар Іванова хутка памрэ». Адміністратар атрымае поўнае паведамленне аб памылцы, у каго, як і што здарылася ці можа здарыцца.
Дадамо магчымасць выкарыстання пошты дадатковай адказнай асобы, каб у выпадку паломкі ён атрымліваў паведамленне.
Дадамо ўзаемадзеянне з вонкавымі пастаўшчыкамі сэрвісаў на базе адпраўкі email з загадзя нарыхтаваным тэкстам, т.я. менавіта электронны ліст дае падставу на ўстанову інцыдэнту.
Усё ўзаемадзеянне з сістэмай замкнем на чат-бот, зносіны вядзецца ў дыялогавым стылі.

Дапаўненне:

дадамо функцыянал "чата з адміністратарам", каб карыстач мог адправіць адміністратару паведамленне з апісаннем праблемы напроста.

Сістэма павінна пастаўляцца на ўласным жалезе.
Жалеза павінна быць даступным.
Сістэма павінна быць максімальна незалежная ад асяроддзя.

Возьмем гатовы і танны кампутар Raspberry PI.
Спраектуем плату бесперабойнага забеспячэння энергасілкаваннем.
Дадамо мадэм для незалежнасці ад стану лакальнай сеткі.
Спраектуем прыгожы корпус.

У нас з'явіліся тры падсістэмы са сваімі патрабаваннямі і бачаннем іх рэалізацыі:

падсістэма апаратнага забеспячэння;
падсістэма маніторынгу;
падсістэма карыстацкага ўзаемадзеяння.

Для падсістэмы апаратнага забеспячэння мы распрацавалі эскізны праект. Так так! Парушыўшы ўсе правілы аджайлізацыі, мы распрацавалі дакумент, таму што заводы-вытворцы працуюць менавіта з дакументамі. Для астатніх падсістэм мы вылучылі карыстальнікаў (персоны), падрыхтавалі карыстацкія гісторыі, напісалі заданні для распрацоўкі.

На гэтым этап канцэпцыі заканчваецца, і яго вынікам сталі:

праект на апаратную платформу;
сфармуляваны віжн у выглядзе карыстацкіх гісторый на астатнія дзве падсістэмы;
прататып праграмнай часткі, рэалізаваны ў выглядзе віртуалкі;
прататып апаратнай часткі, рэалізаванай у выглядзе стэнда, дзе ўласна і правяраліся на трываласць апаратныя рашэнні;
тэсціраванне, праведзенае нашымі адмінамі.

Праблемы на дадзеным этапе былі большай часткай арганізацыйныя і звязаныя з недастатковай падкаванасцю інжынернага складу ў юрыдычных і бухгалтарскіх аспектах продажаў. Г.зн. адна справа прыдумаць, што і як прадаваць, і зусім іншае - сутыкнуцца з бязлітаснай юрыдычнай машынай: патэнтамі, заданнямі на распрацоўку, пастаноўкай на баланс, EULA і многім іншым, чаго мы як творчыя людзі першапачаткова не ўлічылі.

Была яшчэ не праблема, а хутчэй, цяжкасць, злучанае з праектаваннем карпусоў. У нашай камандзе адны інжынеры, таму першы варыянт корпуса "стварыў" з аргшкла наш спецыяліст па электроніцы.

Выглядаў корпус, мякка кажучы, спрэчна, асабліва для публікі, распешчанай сучаснай тэхнікай. Знайшліся, вядома, знатакі сярод «кулібіных» старэйшага пакалення корпус выклікаў у іх настальгічныя пачуцці. Было вырашана вырабіць і спраектаваць корпус нанова, паколькі стары апроч эстэтычных недахопаў меў яшчэ і канструктыўныя - аргшкло дрэнна пераносіла зборку-разборку прылады і наравіла пайсці расколінамі. Аб вытворчасці корпуса, раскажу далей.

І вось мы ўшчыльную падабраліся да фінішнай прамой - MVP. Вядома, гэта яшчэ не канчатковы серыйны прадукт, але ён ужо прыносіць карысць і ўяўляе каштоўнасць. Галоўная мэта гэтага этапу - запуск цыклу "стварыць-ацаніць-навучыцца". Менавіта на гэтым этапе знаходзіцца LANBIX.

На стадыі "стварыць", мы стварылі прылада, якое выконвае заяўлены функцыянал. Так, яно яшчэ не ідэальна, і мы працягнулі над ім працаваць.

Вяртаемся да выраба корпуса, г.зн. да задачы ператварыць наша прылада з задзірлівага настальгічныя пачуцці ў сучаснае. У пачатку, я прошерстил рынак на прадмет вытворцаў карпусоў і аказанні паслуг прамысловага дызайну. Па-першае, кампаній, якія вырабляюць карпусы, на расійскім рынку зусім не шмат, а па-другое, кошт прамысловага дызайну на дадзеным этапе надмерна вялікая, каля 1 млн рублёў.

Па дызайн звярнуліся ў наш аддзел маркетынгу, малады дызайнер быў гатовы да творчых эксперыментаў. Мы выклалі сваё бачанне корпуса (папярэдне вывучыўшы лепшыя ўзоры корпусабудавання), а ён у сваю чаргу ператварыў яго ў твор мастацтва. Засталося толькі зрабіць. Мы, ганарлівыя сваім дызайнам, звярнуліся да партнёраў. Іх генеральны дырэктар маментальна разбурыў нашы фантазіі, цалкам бясплатна указаўшы на рэчы, якія немагчыма вырабіць абраным намі спосабам. Корпус вырабіць можна, і будзе не горш, чым у Apple, але кошт корпуса пры гэтым будзе ў тры-чатыры разы даражэй, чым усё электроннае начынне. Пасля чарады аперацый і ўзгадненняў мы спраектавалі корпус, які можа быць выраблены. Так, ужо не так прыгожы, як мы планавалі, але ідэальны для дасягнення бягучых мэт.

Вынік стадыі: першая партыя прылад, гатовых да бою і выпрабаванням.

А цяпер самае складанае - стадыя "ацаніць", і з нашым прадуктам мы знаходзімся як раз у гэтай кропцы. Ацэньваць мы можам толькі па выніках выкарыстання рэальнымі заказчыкамі і ніякія здагадкі тут не працуюць. Нам неабходны тыя самыя "раннія паслядоўнікі" для падавання зваротнай сувязі і занясенні тых змен у прадукт, якія сапраўды патрэбныя. Узнікае пытанне: дзе браць заказчыкаў і як пераконваць іх узяць удзел у эксперыменце?

З усіх магчымых варыянтаў, мы выбралі класічны набор digital-інструментаў: лэндынг і рэкламная кампанія ў сацсетках.

Працэс ужо запушчаны, але пакуль рана казаць аб выніках, хаця водгукі ўжо ёсць і мы атрымалі пацвярджэнне многіх нашых гіпотэз. Прыемнай неспадзеўкай была рэакцыя прадстаўнікоў зусім іншых сегментаў бізнэсу, значна буйней тых, на якія мы разлічвалі. Было б глупствам ігнараваць новыя ўступныя, і па выніках праведзеных інтэрв'ю было прынята рашэнне аб запуску паралельнай лінейкі LANBIX пад назвай LANBIX Enterprise. Мы дадалі падтрымку размеркаваных інфраструктур, маніторынг Wi-Fi-сетак з пошукам і лакалізацыяй няспраўнасцяў, маніторынг якасці каналаў сувязі. Найбольшую зацікаўленасць у рашэнні выказалі сэрвісныя кампаніі. Пры гэтым ужо распрацаваныя намі прылады ў працы рашэнняў гуляюць не апошнюю ролю.

Што будзе далей

Што будзе далей з першапачатковым LANBIX - стане зразумела па выніках кампаніі. У выпадку непацверджання нашых гіпотэз, паводле метадалогіі Lean, бязлітасна пазбавімся ад яго ці ён трансфармуецца ў нешта новае, бо няма нічога горш чым рабіць прадукт, які нікому не патрэбен. Але ўжо зараз можна сказаць, што праведзеная праца не дарэмная і дзякуючы ёй з'явілася цэлая галінка паралельных прадуктаў, над якімі мы актыўна працуем. У выпадку поспеху LANBIX пяройдзе са стадыі MVP у канчатковую стадыю і будзе развівацца па зразумелых класічных законах прадуктовага маркетынгу.

Паўтаруся, зараз мы хочам знайсці ранніх паслядоўнікаў, кампаніі, якім можна ўсталяваць наш прадукт з мэтай збору зваротнай сувязі. Калі вам цікава пратэставаць LANBIX, пішыце ў каментарах ці асабістых паведамленнях.

Крыніца

Крыніца: habr.com

Як мы працуем з ідэямі, і як нарадзіўся LANBIX