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

В „ЛАНИТ-Интеграции“ работят много креативни служители. Идеите за нови продукти и проекти буквално висят във въздуха. Понякога е много трудно да се откроят най-интригуващите. Затова с общи усилия разработихме своя методика. Как да изберем най-добрите проекти и да ги реализираме, четете в тази статия.

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

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

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

Що се отнася до подхода ни към управлението на разработката на продукта: не решихме да изобретяваме велосипеда, а приложихме вече съществуващата методология на разработка SCRUM, добавя креатив, и сега смело можем да наречем това SCRUM-WATERFALL-BAN. SCRUM, въпреки гъвкавостта си, е много строга система и е подходяща за управление на екип, който отговаря само за един продукт/проект. Както разбирате, класическият „интеграторски“ бизнес не предполага отделяне на технически специалисти на пълен работен ден за работа над един проект (изключения има, но са изключително редки), тъй като освен работа по продуктите, всички са заети с текущите проекти. От SCRUM взехме разделението на работата на спринтове, ежедневните отчети, ретроспективите и ролите. За работа с потока от задачи избрахме Kanban и той се интегрира отлично в нашата съществуваща система за проследяване на задачи. Успяхме да изградим работата си, плавно интегрирайки се в вече съществуващия ред на нещата.
Преди да излезе на пазара, продуктът преминава през 5 етапа: идея, селекция, концепция, MVP (по-подробно - по-долу) и производство.

Идеята

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

Източник

Избор

След като оформеният шаблон попадне при нас, започва процедурата по обработка и селекция. Етапът на селекция е най-трудоемкият. На този етап се формират хипотези за проблемите (не споменах случайно в предишния абзац, че в идеалния случай идеята трябва да решава проблема на клиента) и стойността на продукта. Създава се хипотеза за мащаба, т.е. как нашият бизнес ще расте и процъфтява. Провеждат се проблемни и експертни интервюта с потенциални клиенти за предварително потвърждение на това, че смятаме да произвеждаме нещо необходимо. Нужни са минимум 10-15 интервюта, за да се направи заключение за необходимостта от продукта.

Ако хипотезите бъдат потвърдени, се извършва предварителен финансов анализ, оценява се приблизителният обем на инвестициите и възможният доход на инвеститора. В резултат на този етап се създава документ под названието Lean Canvas и се представя на ръководството.

Концепция

На този етап се отсяват около 70% от идеите. Ако концепцията е одобрена, започва етапът на разработка на идеята. Съставят се функционалните възможности на бъдещия продукт, определят се пътищата за реализиране и оптималните технически решения, актуализира се бизнес планът. Резултатът от този етап е техническото задание за разработка и подробен бизнес случай. В случай на успех – преминаваме към етапа на MVP.

MVP

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

Производство

И последният етап – производство. До тази фаза стигат не повече от 5% от продуктите. В тези 5% влизат само най-важните, необходими, жизнеспособни и функционални продукти.

Имаме много идеи, вече събрани в обемен портфейл. Разглеждаме всяка идея и правим всичко възможно, за да стигне до финалната фаза. Много е приятно, че колегите не останаха безразлични към нашето R&D направление и активно участват в разработката и реализирането на продукти и решения.

Как направихме LANBIX

Нека разгледаме създаването на продукт на реален пример – продукта LANBIX. Това е „кутия“ софтуерно-хардуерен комплекс, предназначен за мониторинг на малки ИТ инфраструктури и бързо уведомяване на отговорните лица и бизнес потребителите за неизправности с управление чрез чат-бот. Освен функцията за мониторинг, LANBIX включва и функционалността Help Desk. Този продукт е ексклузивен за сегмента на пазара, където сме ориентирани. Това е и нашето предимство, и наша болка. Но всичко по реда си. Ще кажа направо, че LANBIX е жив продукт (т.е. не е окончателен в развитието си и е на поредния етап на MVP).

И така, първият етап – идея. За да се роди идея, са нужни проблеми, а те бяха у нас, по-точно не у нас, а у нашите познати. По-долу ще разгледаме няколко реални ситуации, възникнали в различни сфери на бизнеса.

Малка управляваща компания обслужва две сгради в Московска област. Персонал, който разполага с компютри, е около 15 души. Системният администратор — подходящ фрийлансър (умно дете на един от заинтересованите живущи). Струваше си, че дейността на УК слабо зависи от ИТ, но особеността на този бизнес е месечната отчетност пред множество инстанции. На системния диск на шефа на компанията (който обикновено съчетава многобройни роли) свърши свободното място. Естествено, това не се случи внезапно, предупреждението стоеше около 2 месеца и постоянно се игнорираше. Но дойде обновление, ОС се обнови и, за ужас, застря в средата на обновлението, оплаквайки се пред „смъртта“ си за заетия диск. Компютърът влезе в циклично рестартиране. Докато се разбираха с проблема и получаваха отчетите, пропуснаха сроковете за подаване на отчетността. Струваше си, че дребна повреда стана причина за различни неприятности: от загуби до съдебни дела и административна отговорност.

Източник   

Подобен случай се случи в голям холдинг, обединяващ множество малки компании, с единна техническа поддръжка за целия офис. В един от отделите се счупи компютърът на главния счетоводител. Беше известно отдавна, че може да се счупи (компютърът безумно забавяше и се прегряваше), но ръцете на главния счетоводител никак не достигаха до това, да изпрати молба в техническата поддръжка. Естествено, той се счупи точно на деня на заплатите и служителите на отдела прекараха няколко дни без пари.

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

Лично се сблъсках с подобна ситуация, когато отидох на прием в поликлиника и трябваше да отида в регистратурата на ДМС. Не можеха да ме насочат при лекаря по банална причина – сутринта имаше скок на напрежението и след инцидента техният пощенски сервис и някакъв сервиз за свързване с осигурителната компания не работеха. Когато попитах, къде са вашите администратори, ми беше казано, че админът им идва веднъж на седмица. А в момента (по това време вече беше 16:00) той не отговаря на телефона. Най-малко 7 часа поликлиниката беше откъсната от външния свят и не можеше да предоставя платени услуги.

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

Откроихме хипотезите за проблемите:

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

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

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

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

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

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

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

Обобщаваме резултата от този етап:

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

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

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

Установи се следното.

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

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

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

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

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

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

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

Преминаваме към следващия етап — концепцията. Тук ние като инженери попадаме в своята родна стихия. Има "желания", които се декомпозират на компоненти/подсистеми/функции, след това те се превръщат в ТЗ/потребителски истории, а след това в проект и т.н. Няма да спирам подробно на процеса на подготовка на масив от алтернативни варианти, направо ще преминем към изискванията и избраните методи за тяхната реализация.

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

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

Взимаме система за мониторинг с отворен код.

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

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

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

Ще напишем собствен чат-бот за един от известните мессенджъри и ще заведем всичкото взаимодействие със системата на него.

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

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

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

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

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

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

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

Допълнение:

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

• Системата трябва да се доставя на собствено оборудване.
• Оборудването трябва да е достъпно.
• Системата трябва да бъде максимално независима от околната среда.

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

Имаме три подсистеми с техните изисквания и визия за реализацията им:

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

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

На този етап концепцията завършва, а резултатите й са:

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

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

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

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

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

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

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

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

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

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

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

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

Какво следва

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

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

Източник

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