🥇Як ми працюємо з ідеями і як народився 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