- PVSM.RU - https://www.pvsm.ru -
Те, кто занимается развитием технологического бизнеса (разработка ПО, интернет-сервисы и т.д.), наверняка читали такие книги, как «Преодоление пропасти» и «Внутри торнадо» авторства Джефри Мура. Из этих книг читателю известна модель жизненного цикла технологий на рынке (хотя сама модель появилась раньше, в книге другого автора, чего сам Мур в своих произведениях не скрывает).
Если вам эти книги не знакомы, то модель легко понимается по схеме (взята с сайта www.techlifecycles.com [1]):
Суть в следующем. Когда на рынок выводится новая технология, потребители распределяются по шкале склонности к риску. Сперва технологию опробуют новаторы (Innovators), потом идут ранние последователи (early adopters), раннее большинство (early majority), позднее большинство (late majority) и увальни (laggards). Последние если технолгию и купят — то только в случае, если у них больше не останется выбора (например, если она станет отраслевым стандартом). Соответственно, новаторов совсем немного, чуть больше ранних последователей. Но «серьезный бизнес» начинается тогда, когда вы дошли до раннего и позднего большинства. А до этой стадии можно не дойти — между ранними последователями и ранним большинством есть так называемая «пропасть» (обусловленная рядом причин, которые описаны в книге).
Новаторы и ранние последователи формируют так называемый «ранний рынок». Но и для такого рынка нужно сделать продукт, а не только описать идею в презентации. Лучшие собаководы рекомендуют использовать для разработки такого продукта стратегию MVP — Minimum Viable Product. Т.е. разработку минимальными усилиями продукта, который не стыдно показать раннему рынку. Кстати, термин «собаководы» употреблен здесь не только для красного словца. Цель MVP состоит в проверке утверждения, как говорят прогрессивные американские ИТ-предприниматели, «будет ли собака есть собачью еду» — то есть будут ли придуманным продуктом пользоваться (в т.ч. платно) вообще. Тут встает задача соблюсти баланс между тратой ресурсов на создание продукта, который может оказаться не нужным рынку, и созданием достаточной функциональности для вынесения верного вердикта «нужен/не нужен рынку» (совсем пустой продукт даже ранние последователи смотреть не будут — и можно сделать ложный вывод, что сама идея плохая). Итак, задача номер 1: определить рамки MVP.
После того, как минимальный продукт сделан, опробован на рынке, появились первые клиенты (именно клиенты, а не пользователи) — вы встаете рядом с пропастью. Для её преодоления другие собаководы (конкретно — упомянутый в начале Д. Мур) вводят понятие целостного продукта. Это готовый продукт, полностью покрывающий потребности конкретной ниши большого рынка в той области, которой соответствует продукт (утверждается, что сделать такой продукт сразу для всего рынка невозможно — с этим трудно не согласиться). Сделав такой продукт для конкретной ниши, вы растопите сердца той части раннего большинства, которая соответствует выбранной нише. А дальше подтянутся и остальные. Про выбор таковой ниши хорошо написано в тех самых книгах. В контексте данной статьи важен тот факт, что нужено сделать целостный продукт. Рамки которого, как уже вы поняли, нужно определить. Итак, задача номер 2: определить рамки целостного продукта.
Мы делаем SmartNut [2] — программное обеспечение (распротраняем только по модели SaaS) для автоматизации деятельности, связанной с обслуживанием клиентов сервисных компаний. И в данной статье мы хотим отразить свой опыт очерчивания рамок MVP и целостного продукта.
В нашем примере речь идет о системе автоматизации бизнес-процессов. Из определения понятна их основная ценность: автоматизировать процессы. И конкретно в нашем случае речь идет о процессах обслуживания клиентов (в случае CRM-систем речь пойдет о процессах продажи и т.д.). Следовательно, ценность системы — в предоставлении инструментов для автоматизации и оптимизации работы на каждом шаге процесса. А значит, ключевой для вашего продукта процесс должен быть разобран на составляющие.
Итак, процесс обслуживания клиентов состоит из:
И на каждом этапе можно придумать множество инструментов, автоматизирующих и оптимизирующих работу клиентской службы. Но мы же помним, что задача стоит в том, чтобы сделать минимальный по функциональности продукт, который будет иметь ценность для клиента. Мы решили, что продукт будет иметь хоть какую-то ценность, когда хотя бы часть заявок и задач на обслуживание может быть полностью «пропущена» через систему. И в нашем случае мы выбрали заявки типа «инцидент» (когда клиент сообщает о неисправности чего-либо и это нужно починить без откладывания в долгий ящик). В результате появились следующие верхнеуровневые требования к первой версии продукта:
Прием и регистрация заявок и задач на обслуживание:
Планирование выполнения заявок:
Выполнение заявок:
2 статуса для заявки (открытазакрыта);
Контроль и анализ:
Далее требования детализируются, но с учетом отбрасывания всего лишнего, что не является обязательным для «протаскивания» по процессу инцидентных заявок.
Так и получились границы нашего минимального продукта, который мы выпустили год назад. После этого мы начали этап закрытого тестирования (который продлился около месяца), собрали много отзывов.
С MVP — разобрались. Теперь переходим к целостному продукту. Как вы помните из прелюдии к статье, целостный продукт нужно делать для конкретной ниши и конкретной задачи. Казалось бы, у SmartNut [2] узкая специализация (обслуживание клиентов) и узкая ниша (сервисные компании). Но и здесь есть где сузиться. Для преодоления своей пропасти мы выбрали из всех подотраслей сервисных компаний ИТ-аутсорсинг. А именно те компании, которые занимаются абонентским обслуживанием компьютерной техники и прочих 1С-ов.
И в соответствии со спецификой этих компаний, для создания целостного продукта, мы решили, что наиболее правильный путь — это наращивание мяса на тот «скелет» из 4-х этапов процесса:
Прием и регистрация заявок и задач на обслуживание:
Планирование выполнения заявок и задач на обслуживание:
Выполнение заявок и задач на обслуживание:
Контроль и анализ:
(жирным выделено то, что входило в MVP, курсивом выделено то, что сделано после выхода MVP — все остальное впереди на ближайшие 8 месяцев).
И таким способом мы очертили для себя границы целостного продукта, с которым будем преодолевать пропасть, перед которой стоим. Как развивать продукт после преодоления пропасти — напишем после того, как её преодолеем.
P.S. В тексте почти ничего не сказано про общение с клиентами. Но это подразумевается. Это жизненная необходимость. Требования и приоретизация требований во многом идут именно от них. Просто статья не про то, как интервьюировать клиентов.
Автор: krubinshteyn
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/11634
Ссылки в тексте:
[1] www.techlifecycles.com: http://www.techlifecycles.com
[2] SmartNut: http://www.smartnut.ru
Нажмите здесь для печати.