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

Если вам эти книги не знакомы, то модель легко понимается по схеме (взята с сайта www.techlifecycles.com):

Суть в следующем. Когда на рынок выводится новая технология, потребители распределяются по шкале склонности к риску. Сперва технологию опробуют новаторы (Innovators), потом идут ранние последователи (early adopters), раннее большинство (early majority), позднее большинство (late majority) и увальни (laggards). Последние если технолгию и купят — то только в случае, если у них больше не останется выбора (например, если она станет отраслевым стандартом). Соответственно, новаторов совсем немного, чуть больше ранних последователей. Но «серьезный бизнес» начинается тогда, когда вы дошли до раннего и позднего большинства. А до этой стадии можно не дойти — между ранними последователями и ранним большинством есть так называемая «пропасть» (обусловленная рядом причин, которые описаны в книге).

Новаторы и ранние последователи формируют так называемый «ранний рынок». Но и для такого рынка нужно сделать продукт, а не только описать идею в презентации. Лучшие собаководы рекомендуют использовать для разработки такого продукта стратегию MVP — Minimum Viable Product. Т.е. разработку минимальными усилиями продукта, который не стыдно показать раннему рынку. Кстати, термин «собаководы» употреблен здесь не только для красного словца. Цель MVP состоит в проверке утверждения, как говорят прогрессивные американские ИТ-предприниматели, «будет ли собака есть собачью еду» — то есть будут ли придуманным продуктом пользоваться (в т.ч. платно) вообще. Тут встает задача соблюсти баланс между тратой ресурсов на создание продукта, который может оказаться не нужным рынку, и созданием достаточной функциональности для вынесения верного вердикта «нужен/не нужен рынку» (совсем пустой продукт даже ранние последователи смотреть не будут — и можно сделать ложный вывод, что сама идея плохая). Итак, задача номер 1: определить рамки MVP.

После того, как минимальный продукт сделан, опробован на рынке, появились первые клиенты (именно клиенты, а не пользователи) — вы встаете рядом с пропастью. Для её преодоления другие собаководы (конкретно — упомянутый в начале Д. Мур) вводят понятие целостного продукта. Это готовый продукт, полностью покрывающий потребности конкретной ниши большого рынка в той области, которой соответствует продукт (утверждается, что сделать такой продукт сразу для всего рынка невозможно — с этим трудно не согласиться). Сделав такой продукт для конкретной ниши, вы растопите сердца той части раннего большинства, которая соответствует выбранной нише. А дальше подтянутся и остальные. Про выбор таковой ниши хорошо написано в тех самых книгах. В контексте данной статьи важен тот факт, что нужено сделать целостный продукт. Рамки которого, как уже вы поняли, нужно определить. Итак, задача номер 2: определить рамки целостного продукта.

Наш ответ на вопрос «Что делать?»

Мы делаем SmartNut — программное обеспечение (распротраняем только по модели SaaS) для автоматизации деятельности, связанной с обслуживанием клиентов сервисных компаний. И в данной статье мы хотим отразить свой опыт очерчивания рамок MVP и целостного продукта.

В нашем примере речь идет о системе автоматизации бизнес-процессов. Из определения понятна их основная ценность: автоматизировать процессы. И конкретно в нашем случае речь идет о процессах обслуживания клиентов (в случае CRM-систем речь пойдет о процессах продажи и т.д.). Следовательно, ценность системы — в предоставлении инструментов для автоматизации и оптимизации работы на каждом шаге процесса. А значит, ключевой для вашего продукта процесс должен быть разобран на составляющие.

Итак, процесс обслуживания клиентов состоит из:

Приема и регистрации заявок и задач на обслуживание;
Планирования выполнения заявок и задач на обслуживание;
Выполнения заявок и задач на обслуживание;
Контроля и анализа процесса обслуживания.

И на каждом этапе можно придумать множество инструментов, автоматизирующих и оптимизирующих работу клиентской службы. Но мы же помним, что задача стоит в том, чтобы сделать минимальный по функциональности продукт, который будет иметь ценность для клиента. Мы решили, что продукт будет иметь хоть какую-то ценность, когда хотя бы часть заявок и задач на обслуживание может быть полностью «пропущена» через систему. И в нашем случае мы выбрали заявки типа «инцидент» (когда клиент сообщает о неисправности чего-либо и это нужно починить без откладывания в долгий ящик). В результате появились следующие верхнеуровневые требования к первой версии продукта:

Прием и регистрация заявок и задач на обслуживание:

Возможность сотрудником клиентской службы зарегистрировать заявку.

Планирование выполнения заявок:

Автоматический расчет дедлайна в соответствии с нормативами (aka SLA; кстати, потом мы поняли, что для минимального продукта это можно было бы не делать);
Списки заявок с возможностью фильтрации и сортировки по минимальному ряду параметров.

Выполнение заявок:
2 статуса для заявки (открыта\закрыта);

Возможность сменить ответственного за заявку;
Оповещение по email ответственного за заявку;
Возможность комментирования заявок;
Возможность посмотреть дополнительную информацию о клиенте и контактном лице заявки (т.е. возникает требование к наличию базы клиентов и контактных лиц).

Контроль и анализ:

Списки заявок с возможностью фильтрации и сортировки по минимальному ряду параметров (это тоже инструмент контроля, как и инструмент планирования);
Один отчет о по выполненым заявкам в разрезе клиентов, ответственных, в котором в том числе будет показываться, какие заявки выполнены в срок, а какие нет.

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

Так и получились границы нашего минимального продукта, который мы выпустили год назад. После этого мы начали этап закрытого тестирования (который продлился около месяца), собрали много отзывов.

С MVP — разобрались. Теперь переходим к целостному продукту. Как вы помните из прелюдии к статье, целостный продукт нужно делать для конкретной ниши и конкретной задачи. Казалось бы, у SmartNut узкая специализация (обслуживание клиентов) и узкая ниша (сервисные компании). Но и здесь есть где сузиться. Для преодоления своей пропасти мы выбрали из всех подотраслей сервисных компаний ИТ-аутсорсинг. А именно те компании, которые занимаются абонентским обслуживанием компьютерной техники и прочих 1С-ов.

И в соответствии со спецификой этих компаний, для создания целостного продукта, мы решили, что наиболее правильный путь — это наращивание мяса на тот «скелет» из 4-х этапов процесса:

Прием и регистрация заявок и задач на обслуживание:

Возможность сотрудником клиентской службы зарегистрировать заявку;
Вомзожность контактному лицу клиента самостоятельно зарегистрировать заявку из личного кабинета;
Настраиваемые типы заявок;
Web-форма регистрации заявок с возможностью встроить её в сайт;
Автоматическая регистрация заявок по email;
API;
Интеграция с внешними системами;
Автоматическое создание плановых задач по расписанию.

Планирование выполнения заявок и задач на обслуживание:

Списки заявок и задач с возможностью фильтрации и сортировки (с бОльшим количество критериев);
Автоматический расчет дедлайна в соответствии с нормативами (SLA);
Группировка списка заявок и задач по разным критериям;
Декомпозиция заявок и задач (распределение заявок и задач на несколько исполнителей);
Календарь загрузки инженеров;
Периодические автоинформирование инженеров о списке работ на период (по email);
Печатные формы (наряды на работу, акты выполненных работ, счета на оплату);
Каталог платных работ (для выполнения платных заявок);
Интеграци с GIS для отображения положения обслуживаемого офиса на карте (в нашем случае Яндекс.Карты).

Выполнение заявок и задач на обслуживание:

2 статуса для заявки (открыта\закрыта);
Возможность поставить заявку в статус «Отложена» (с заложенной логикой пересчета дедлайна по SLA);
Возможность сменить ответственного за заявку;
Оповещение по email ответственного за заявку;
SMS-оповещения инженеров;
SMS-оповещение клиентов;
Возможность комментирования заявок;
Возможность переписки с клиентом в комментариях к заявке через личный кабинет;
Возможность переписки с клиентом в комментариях к заявке через email;
Возможность посмотреть информацию об объектах обслуживания (база данных обслуживаемого оборудования, CMDB);
Возможность посмотреть дополнительную информацию о клиенте и контактном лице заявки;
PDA-интерфейс;
Мобильный клиент;
Настраиваемые статусы заявок.

Контроль и анализ:

Учет и анализ трудозатрат;
Расширенная отчетность;
Выгрузка списков в .xls.

(жирным выделено то, что входило в MVP, курсивом выделено то, что сделано после выхода MVP — все остальное впереди на ближайшие 8 месяцев).

И таким способом мы очертили для себя границы целостного продукта, с которым будем преодолевать пропасть, перед которой стоим. Как развивать продукт после преодоления пропасти — напишем после того, как её преодолеем.

P.S. В тексте почти ничего не сказано про общение с клиентами. Но это подразумевается. Это жизненная необходимость. Требования и приоретизация требований во многом идут именно от них. Просто статья не про то, как интервьюировать клиентов.

Стратегия развития: от MVP к целостному продукту