Те, кто занимается развитием технологического бизнеса (разработка ПО, интернет-сервисы и т.д.), наверняка читали такие книги, как «Преодоление пропасти» и «Внутри торнадо» авторства Джефри Мура. Из этих книг читателю известна модель жизненного цикла технологий на рынке (хотя сама модель появилась раньше, в книге другого автора, чего сам Мур в своих произведениях не скрывает).
Если вам эти книги не знакомы, то модель легко понимается по схеме (взята с сайта 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. В тексте почти ничего не сказано про общение с клиентами. Но это подразумевается. Это жизненная необходимость. Требования и приоретизация требований во многом идут именно от них. Просто статья не про то, как интервьюировать клиентов.
Автор: krubinshteyn
