Как мы работаем с идеями, и как родился 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 часов поликлиника была отрезана от внешнего мира и не могла оказывать платные услуги.

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

Мы выделили гипотезы проблем:

• существенные денежные и репутационные потери из-за низкой скорости реакции на неисправности в ИТ-инфраструктуре;
• неверная интерпретация ранних симптомов неисправности со стороны пользователей.

Что  может с ними сделать заказчик, и как избежать подобных ситуаций в будущем? Вариантов не так много:

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

Останавливаемся на третьем варианте. Давайте предложим систему мониторинга тем, кто ее не использует в силу разных причин.

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

Перечисленные истории заставили нашу команду задуматься над тем, как сделать оптимальную систему мониторинга для небольших компаний. В результате родился LANBIX — система мониторинга, которую  может развернуть абсолютно любой человек без знаний в области ИТ. Основная задача системы проста, как и у всех систем, направленных на повышение непрерывности и доступности, – снижение денежных и других потерь в случае возникновения внеплановых простоев. Устройство призвано до минимума сократить время между «у меня что-то сломалось» и «проблема устранена».

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

Суммируем результат этого этапа:

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

Второй этап был более детальным. По его результатам мы должны были представить руководству, которое по сути исполняет роль инвестора, бизнес-кейс (тот самый Lean Canvas) для принятия решения о дальнейшей судьбе продукта.

Начали мы с исследования рынка и конкурентного анализа с целью выяснить, кто, что и, главное, как делает на этом рынке.

Выяснилось следующее.

1. На  рынке нет готовых коробочных систем мониторинга для нашего сегмента (малый бизнес), за исключением пары-тройки, про которые я по понятным причинам говорить не буду.
2. Наши главные конкуренты, как ни странно, — системные администраторы с самописными скриптами и «допилками» к системам мониторинга с открытым исходным кодом.
3. Налицо явная проблема с использованием систем мониторинга с открытым исходным кодом. Есть система, есть огромное количество информации по работе и доработке системы под свои нужды. Из опрошенных мною администраторов многие признались, что у них не хватает компетенций для реализации задумок своими силами. А признаться руководству в этом они не могут из-за боязни увольнения. Получается замкнутый круг.

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

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

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

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

Результат этапа:

• высокоуровневый  бэклог продукта;
• сформулированная бизнес-модель или гипотеза масштаба, которую еще предстоит проверить на практике.

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

Требование
Решение

• Это должна быть открытая система мониторинга;

Берём систему мониторинга с открытым исходным кодом.

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

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

Замкнём взаимодействие с устройством на что-то простое и понятное всем.

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

Система должна:

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

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

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

Система должна:

• оповещать о неполадках как бизнес, так и системного администратора;
• иметь возможность мониторинга внешних сервисов, как минимум CRM-системы и продающего сайта. Степень глубины и «язык» оповещений должен быть разным для админа и бизнеса.
• Система не должна требовать специфических знаний в ИТ, даже бухгалтер должен быть в состоянии развернуть и настроить систему.

• Добавим разные виды уведомлений для разных типов пользователей. Они отличаются по подаче и глубине. Бизнес-пользователь получит уведомления по типу «всё хорошо, но компьютер Иванова скоро помрёт». Администратор получит полное сообщение об ошибке, у кого, как и что случилось или может случиться.
• Добавим возможность использования почты дополнительного ответственного лица, чтобы в случае поломки он получал сообщение.
• Добавим взаимодействие с внешними поставщиками сервисов на базе отправки  email с заранее заготовленным текстом, т.к. именно электронное письмо даёт основание на заведение инцидента.
• Все взаимодействие с системой замкнём на чат-бот, общение ведется в диалоговом стиле.

Дополнение:

• добавим функционал «чата с администратором», чтобы  пользователь мог отправить администратору сообщение с описанием проблемы напрямую.

• Система должна поставляться на собственном железе.
• Железо должно быть доступным.
• Система должна быть максимально не зависима от окружения.

• Возьмём готовый и дешёвый компьютер Raspberry PI.
• Спроектируем плату бесперебойного снабжения энергопитанием.
• Добавим модем для независимости от состояния локальной сети.
• Спроектируем красивый корпус.

У нас появились три подсистемы со своими требованиями и видением их реализации:

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

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

На этом этап концепции заканчивается, и его результатом стали:

• проект на аппаратную платформу;
• сформулированный вижн в виде пользовательских историй на остальные две подсистемы;
• прототип программной части, реализованный в виде виртуалки;
• прототип аппаратной части, реализованной в виде стенда, где собственно и проверялись на прочность аппаратные решения;
• тестирование, проведённое  нашими админами.

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

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

Выглядел корпус, мягко говоря, спорно, особенно для публики, избалованной современной техникой. Нашлись, конечно, ценители среди «кулибиных» старшего поколения — корпус вызвал у них  ностальгические чувства. Было решено изготовить и спроектировать корпус заново, поскольку старый помимо эстетических недостатков имел еще и конструктивные — оргстекло плохо переносило сборку-разборку устройства и норовило пойти трещинами. О производстве корпуса, расскажу дальше.

И вот мы вплотную подобрались к финишной прямой — MVP. Конечно, это еще не окончательный серийный продукт, но он уже приносит пользу и представляет ценность. Главная цель этого этапа — запуск цикла «создать-оценить-научиться». Именно на этом этапе находится LANBIX.

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

Возвращаемся к изготовлению корпуса, т.е. к задаче превратить наше устройство из вызывающего ностальгические чувства в современное. В начале, я прошерстил рынок на предмет производителей корпусов и оказания услуг промышленного дизайна. Во-первых, компаний, производящих корпусы, на российском рынке совсем не много, а во-вторых, стоимость промышленного дизайна на  данном этапе непомерно велика, около 1 млн рублей.

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

Результат стадии: первая партия устройств, готовых к бою и испытаниям.

А теперь самое сложное — стадия «оценить», и с нашим продуктом мы находимся как раз в этой точке. Оценивать мы можем только по результатам использования реальными заказчиками и никакие предположения тут не работают. Нам необходимы те самые «ранние последователи» для предоставления обратной связи и внесения тех изменений в продукт, которые действительно нужны. Возникает вопрос: где брать заказчиков и как убеждать их принять участие в эксперименте?

Из всех возможных вариантов, мы выбрали классический набор digital-инструментов: лэндинг и рекламная кампания в соцсетях.

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

Что будет дальше

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

Повторюсь, сейчас мы хотим найти ранних последователей, компании, которым можно установить наш  продукт с целью сбора обратной связи. Если вам интересно протестировать LANBIX, пишите в комментариях или личных сообщениях.

Источник

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