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

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

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

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

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

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

Идея

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

Източник

Отбор

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

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

Концепцията

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

МЖП или MVP

МЖП е минимален жизнеспособен продукт. Т.е. продукт, който не е довършен, но вече може да носи стойност и да изпълнява своята функционалност. На този етап от разработката непременно събираме обратна връзка от реални потребители и правим промени.

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

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

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

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

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

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

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

Източник   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изяснихме следното.

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

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

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

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

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

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

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

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

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

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

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

• Системата трябва да е проста и бърза за инсталиране;
• не трябва да изисква специфични познания в IT. Дори счетоводител трябва да е в състояние да разгръща и настройва системата.

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

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

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

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

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

Пишем допълнения за системата за мониторинг по:

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

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

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

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

Допълнение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какво ще се случи след това

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

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

Източник

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