Как работим с идеи и как се роди LANBIX

В LANIT-Integration има много креативни служители. Идеите за нови продукти и проекти буквално висят във въздуха. Понякога може да бъде много трудно да се идентифицират най-интересните. Затова заедно разработихме собствена методология. Прочетете тази статия за това как да изберете най-добрите проекти и да ги реализирате.

В Русия и в света като цяло протичат редица процеси, които водят до трансформация на ИТ пазара. Благодарение на увеличаването на изчислителната мощност и появата на сървърни, мрежови и други технологии за виртуализация, пазарът вече не се нуждае от голямо количество хардуер. Доставчиците все повече предпочитат да работят директно с клиентите. ИТ пазарът преживява бум на аутсорсинга във всичките му форми, от класическия аутсорсинг до новата вълна аутсорсинг – „доставчици на облаци“. Инфраструктурните системи и елементи стават много по-лесни за поддръжка и конфигуриране. Качеството на софтуера расте всяка година и задачите на интегратора се трансформират.

Как работим с идеи

Посока за стартиране на продукта в "ЛАНИТ-Интеграция" съществува повече от година. Основната ни цел е да създаваме нови продукти и да ги пускаме на пазара. Първото нещо, с което започнахме, беше организирането на процеса на създаване на продукти. Изучихме много методологии, от класически до хайп. Никой от тях обаче не отговаряше на нашите нужди. Тогава решихме да вземем за основа методологията Lean Startup и да я адаптираме към нашите задачи. Lean Startup е теория за предприемачеството, създадена от Ерик Райс. Тя се основава на принципите, подходите и практиките на такива концепции като щадящо производство, развитие на клиентите и гъвкава методология за развитие.

Що се отнася до директния подход към управлението на разработката на продукта: ние не изобретихме колелото, а приложихме вече съществуваща методология за разработка SCRUM, добавяйки креативност и сега спокойно може да се нарече SCRUM-WATERFALL-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 часа клиниката беше откъсната от външния свят и не можеше да предоставя платени услуги.

Какво е общото между всички тези случаи? Абсолютно всички проблеми можеха да бъдат предотвратени предварително. При навременна реакция от страна на ИТ хората щетите можеха да бъдат намалени. Това би било възможно, ако ранните симптоми се интерпретират правилно от потребителите.

Ние идентифицирахме проблемни хипотези:

• значителни парични и репутационни загуби поради ниската скорост на реакция при грешки в ИТ инфраструктурата;
• погрешно тълкуване на ранните симптоми на неизправност от потребителите.

Какво може да направи клиентът с тях и как да избегне подобни ситуации в бъдеще? Няма много опции:

1. наемете висококвалифициран системен администратор и го накарайте да работи съвестно;
2. възложите ИТ поддръжката на специализирана сервизна компания;
3. самостоятелно внедрява система за мониторинг и докладване на грешки;
4. предоставя обучение на потребители/бизнес персонал в основите на компютърната грамотност.

Нека се спрем на третия вариант. Нека предложим система за мониторинг на тези, които не я използват по различни причини.

Лирично отклонение. Различни системи за мониторинг на ИТ услугите на корпоративния пазар се използват отдавна и ползите от тях не се оспорват. Разговарях с представители на големи компании, разгледах как се изграждат отношенията между бизнеса и ИТ. Техническият директор на едно голямо машиностроително предприятие е възложил поддръжката на ИТ инфраструктурата на външна фирма, но самият той остава в течение на всички въпроси. В офиса му виси голям екран на системата за мониторинг с индикатори за състоянието на ИТ услугите. Най-критичните са включени в системата. Във всеки един момент техническият директор може да разбере какво е състоянието на инфраструктурата, какво се случва, къде е проблемът, дали са уведомени отговорните лица и дали проблемът се решава.

Историите, изброени по-горе, накараха нашия екип да се замисли как да създадем оптимална система за наблюдение за малки компании. В резултат на това се роди LANBIX - система за мониторинг, която може да бъде внедрена от абсолютно всеки без никакви IT познания. Основната цел на системата е проста, като всички системи, насочени към увеличаване на непрекъснатостта и достъпността - намаляване на паричните и други загуби в случай на непланиран престой. Устройството е проектирано да намали до минимум времето между „нещо е счупено“ и „проблемът е отстранен“.

За потвърждаване на хипотезите бяха проведени проблемни интервюта. Не можех да си представя колко хора биха били готови да кажат, без да се опитват да им продадат. Всеки разговор продължи поне 1,5 часа и получихме много полезна информация за по-нататъшно развитие.

Нека обобщим резултатите от този етап:

1. има разбиране на проблема,
2. разбиране за стойност - има,
3. Има идея за решение.

Вторият етап беше по-детайлен. Въз основа на неговите резултати трябваше да представим на ръководството, което по същество играе ролята на инвеститор, бизнес случай (същото Lean Canvas), за да вземе решение за бъдещата съдба на продукта.

Започнахме с проучване на пазара и анализ на конкуренцията, за да разберем кой, какво и най-важното как се справя на този пазар.

Оказа се следното.

1. За нашия сегмент (малък бизнес) на пазара няма готови системи за наблюдение в кутия, с изключение на няколко или три, за които няма да говоря по очевидни причини.
2. Нашите основни конкуренти, колкото и да е странно, са системни администратори с домашно написани скриптове и „добавки“ към системи за наблюдение с отворен код.
3. Има ясен проблем с използването на системи за наблюдение с отворен код. Има система, има огромно количество информация как да работите и да модифицирате системата, за да отговаря на вашите нужди. Много от администраторите, които интервюирах, признаха, че нямат достатъчно компетенции, за да реализират идеите си сами. Но те не могат да признаят това пред ръководството от страх от уволнение. Получава се омагьосан кръг.

След това преминахме към анализиране на нуждите на нашите потенциални клиенти. Ние идентифицирахме за себе си сегмент от малки организации, които по някаква причина нямат собствена ИТ услуга, където или входящ системен администратор, на свободна практика, или компания за услуги отговаря за ИТ. Не ИТ страната реши да навлезе, а бизнес страната, предлагайки на основателите и собствениците на бизнес инструмент за подобряване на качеството на услугите на ИТ инфраструктурата. Продукт, който трябва да помогне на собствениците да осигурят своя бизнес, но в същото време ще добави работа на хората, които отговарят за ИТ. Продукт, който предоставя на бизнеса инструмент за наблюдение на качеството на ИТ поддръжката.

В резултат на обработката на получените данни се роди първият списък с изисквания (вид грубо изоставане) за бъдещия продукт:

• системата за мониторинг трябва да се основава на решение с отворен код и в резултат на това да е евтина;
• лесен и бърз монтаж;
• не трябва да изисква специфични познания в ИТ, дори счетоводител (по никакъв начин не исках да обидя представителите на тази професия) трябва да може да внедри и конфигурира системата;
• трябва автоматично да открива обекти за наблюдение в мрежата;
• трябва автоматично (и в идеалния случай автоматично) да инсталира агенти за наблюдение;
• трябва да може да наблюдава външни услуги, поне CRM система и уебсайт за продажба;
• трябва да уведомява както бизнеса, така и системния администратор за проблеми;
• степента на дълбочина и „език” на сигналите трябва да е различен за администратора и бизнеса;
• системата трябва да се доставя на собствен хардуер;
• желязото трябва да бъде възможно най-достъпно;
• системата трябва да бъде възможно най-независима от външни фактори.

След това бяха изчислени инвестициите в разработването на продукта (включително разходите за труд за служителите на техническия отдел). Изготвена е скица на бизнес модела и е изчислена единичната икономика на продукта.

Резултат от етапа:

• продуктово изоставане на високо ниво;
• формулиран бизнес модел или хипотеза за мащаба, която все още предстои да бъде тествана на практика.

Нека да преминем към следващия етап - концепция. Тук ние като инженери се озоваваме в родната стихия. Има „списъци с желания“, които се разлагат на компоненти/подсистеми/функции, след което се превръщат в технически спецификации/потребителски истории, след това в проект и т.н. Няма да се спирам подробно на процеса на изготвяне на набор от алтернативни варианти, нека преминем направо към изискванията и избраните методи за тяхното изпълнение.

Изискване
Решение

• Това трябва да бъде отворена система за наблюдение;

Взимаме система за наблюдение с отворен код.

• Системата трябва да бъде проста и бърза за инсталиране;
• не трябва да изисква специфични ИТ познания. Дори счетоводител трябва да може да внедри и конфигурира системата.

Ние предлагаме инсталирана система, така че потребителят трябва само да включи устройството и да го конфигурира малко, подобно на рутер.

Нека затворим взаимодействието с устройството до нещо просто и разбираемо за всички.

Нека напишем наш собствен chatbot за един от добре познатите месинджъри и да прехвърлим всички взаимодействия със системата към него.

Системата трябва:

• автоматично откриване на обекти, необходими за наблюдение в мрежата;
• автоматично инсталиране на агенти за наблюдение;
• Да може да наблюдава външни услуги, поне CRM система и уебсайт за продажба.

Пишем добавки за системата за мониторинг за:

• автоматично откриване на обекти;
• автоматично инсталиране на агенти;
• наблюдение на наличността на външни услуги.

Системата трябва:

• уведомява както бизнеса, така и системния администратор за проблеми;
• да можете да наблюдавате външни услуги, поне CRM система и уебсайт за продажба. Степента на дълбочина и „език“ на уведомленията трябва да са различни за администратора и бизнеса.
• Системата не трябва да изисква специфични ИТ познания; дори счетоводител трябва да може да внедри и конфигурира системата.

• Нека добавим различни видове известия за различни типове потребители. Те се различават по височина и дълбочина. Бизнес потребител ще получи известия като „всичко е наред, но компютърът на Иванов скоро ще умре“. Администраторът ще получи пълно съобщение за грешката, кой, как и какво се е случило или може да се случи.
• Нека добавим възможност за използване на пощата на допълнително отговорно лице, така че в случай на повреда да получи съобщение.
• Нека добавим взаимодействие с външни доставчици на услуги на базата на изпращане на имейли с предварително подготвен текст, т.к Имейлът е причината за инцидента.
• Цялото взаимодействие със системата ще бъде свързано с чатбот; комуникацията се провежда в диалогов стил.

допълни:

• Нека добавим функционалността на „чат с администратора“, така че потребителят да може да изпрати на администратора съобщение, описващо проблема директно.

• Системата трябва да се доставя със собствен хардуер.
• Желязото трябва да е налично.
• Системата трябва да бъде възможно най-независима от околната среда.

• Да вземем един готов и евтин Raspberry PI компютър.
• Ще проектираме платка за непрекъсваемо захранване.
• Нека добавим модем, който да е независим от състоянието на локалната мрежа.
• Ще проектираме красива сграда.

Вече имаме три подсистеми със собствени изисквания и визия за тяхното внедряване:

• хардуерна подсистема;
• подсистема за мониторинг;
• подсистема за взаимодействие с потребителя.

Разработихме идеен проект за хардуерната подсистема. Да да! След като нарушихме всички правила на agile, разработихме документ, защото производствените предприятия работят с документи. За останалите подсистеми идентифицирахме потребители (лица), подготвихме потребителски истории и написахме задачи за развитие.

Това приключва етапа на концепцията и резултатът е:

• проект за хардуерна платформа;
• формулирана визия под формата на потребителски истории за останалите две подсистеми;
• софтуерен прототип, реализиран като виртуална машина;
• прототип на хардуера, реализиран под формата на щанд, където хардуерните решения реално са тествани за здравина;
• тестване, извършено от нашите администратори.

Проблемите на този етап бяха предимно организационни и свързани с липсата на познания на инженерния персонал в правните и счетоводни аспекти на продажбите. Тези. Едно е да разбереш какво и как да продаваш, а съвсем друго е да се сблъскаш с безпощадна правна машина: патенти, задачи за разработка, регистрация, EULA и много други, които ние, като креативни хора, първоначално не сме взели под внимание.

Все още нямаше проблем, а по-скоро трудност, свързана с дизайна на загражденията. Нашият екип се състои само от инженери, така че първата версия на корпуса беше „изградена“ от плексиглас от нашия специалист по електроника.

Тялото изглеждаше, меко казано, противоречиво, особено за публиката, разглезена от съвременните технологии. Имаше, разбира се, ценители сред по-старото поколение "Кулибини" - сградата предизвикваше у тях носталгични чувства. Беше решено корпусът да се произведе и проектира наново, тъй като старият, освен естетически недостатъци, имаше и структурни - плексигласът не понасяше добре монтажа и демонтажа на устройството и имаше тенденция да се напуква. Ще ви разкажа за производството на кутията по-нататък.

И сега сме близо до финалната линия - MVP. Разбира се, това все още не е окончателен производствен продукт, но вече е полезен и ценен. Основната цел на този етап е стартирането на цикъла „създаване-оценка-научаване“. Точно на този етап се намира LANBIX.

На етапа „създаване“ създадохме устройство, което изпълнява декларираната функционалност. Да, все още не е идеален и ние продължихме да работим по него.

Да се ​​върнем към производството на тялото, т.е. към задачата да трансформираме нашето устройство от носталгично в модерно. В началото обикалях пазара за производители на шкафове и услуги за индустриален дизайн. Първо, на руския пазар няма много компании, които произвеждат кутии, и второ, цената на индустриалния дизайн на този етап е непосилно висока, около 1 милион рубли.

Те се свързаха с нашия маркетингов отдел за дизайна, младият дизайнер беше готов за творчески експерименти. Ние очертахме нашата визия за корпуса (след като преди това проучихме най-добрите примери за конструкция на корпуса), а той от своя страна го превърна в произведение на изкуството. Остава само да го произведем. Ние, горди с нашия дизайн, се обърнахме към нашите партньори. Техният изпълнителен директор веднага разби фантазиите ни, като ни посочи напълно безплатно неща, които не могат да бъдат произведени по избран от нас начин. Калъфът може да бъде произведен и няма да бъде по-лош от този на Apple, но цената на калъфа ще бъде три до четири пъти по-скъпа от всички електронни компоненти. След поредица от операции и одобрения, ние проектирахме корпус, който може да бъде произведен. Да, не е толкова красиво, колкото планирахме, но е идеално за постигане на текущи цели.

Резултат от етапа: първата партида устройства, готови за бой и тестване.

И сега най-трудното нещо е етапът „оценка“, а с нашия продукт сме точно на този етап. Ние можем да оценим само въз основа на резултатите от употребата от реални клиенти и тук никакви предположения не работят. Имаме нужда от тези „ранни осиновители“, за да предоставят обратна връзка и да правят промените в продукта, които наистина са необходими. Възниква въпросът: къде да вземем клиенти и как да ги убедим да участват в експеримента?

От всички възможни опции избрахме класически набор от дигитални инструменти: целева страница и рекламна кампания в социалните мрежи.

Процесът вече е стартиран, но е рано да се говори за резултати, въпреки че вече има отзиви и получихме потвърждение на много от нашите хипотези. Приятна изненада беше реакцията на представители на напълно различни бизнес сегменти, много по-големи от тези, които очаквахме. Би било глупаво да се игнорират новите въведения и въз основа на резултатите от интервютата беше решено да се пусне паралелна линия LANBIX, наречена LANBIX Enterprise. Добавихме поддръжка за разпределени инфраструктури, наблюдение на Wi-Fi мрежи с отстраняване на неизправности и локализация и наблюдение на качеството на комуникационните канали. Най-голям интерес към решението проявиха сервизните компании. В същото време устройствата, които вече сме разработили, играят важна роля в работата на решенията.

Какво ще стане по-нататък

Какво ще се случи с оригиналния LANBIX ще стане ясно от резултатите от кампанията. Ако хипотезите ни не се потвърдят, според Lean методологията ние безмилостно ще се отървем от него или ще го трансформираме в нещо ново, защото няма нищо по-лошо от това да направиш продукт, който не е нужен на никого. Но сега можем да кажем, че свършената работа не беше напразна и благодарение на нея се появи цял клон от паралелни продукти, върху които активно работим. Ако успее, LANBIX ще премине от етап MVP към последния етап и ще се развива според разбираемите класически закони на продуктовия маркетинг.

Повтарям, сега искаме да намерим ранни осиновители, компании, които могат да инсталират нашия продукт, за да съберем обратна връзка. Ако се интересувате от тестване на LANBIX, пишете в коментарите или на лични съобщения.

източник

Източник: www.habr.com