Для тестирования продукта или бизнес модели

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

Ключевые термины (они же этапы разработки продукта), о которых пойдет речь: Proof of convept (подтверждение концепта), Prototype (прототип), MVP (минимально жизнеспособный продукт) – именно в такой последовательности имеет смысл их рассматривать.

1. Proof of concept — подтверждение концепта

Пример верстки карточек игры «Социальный Бизнес»

Концепт – это по сути просто описание идеи продукта, обычно в формате

«А» – это B для C, которые D

где А — это название проекта или продукта, B — формат, в котором продукт работает, C — целевая аудитория, D — уникальное предложение или потребность. В моем случае:

«Социальный бизнес» (A) – это настольная игра-тренажер (B) для некоммерческих организаций и инициативных групп (C), которые хотят освоить навык бизнес-моделирования для создания социального предприятия (D)

#1 Бизнес-модели IT проектов, Основы создания технологических продуктов

Пока этот концепт в моей голове, кроме меня он никому не понятен. Чтобы получить возможность объяснить свою идеи прежде всего себе самому, а потом уже и другим людям, нужно этот концепт визуализировать и подтвердить его. Proof of concept или подтверждение концепта (сокращенно PoC) нужно для того, чтобы понять, как в целом будет выглядеть продукт и как он потенциально будет работать.

В случае с настольной играй PoC – это минимальное оформление тех компонентов, которые должны войти в игру. У меня это карточки и поле «канва социальной бизнес-модели». Таким образом PoC для меня – это виртуальная модель игры, созданная в графическом редакторе. В таком виде её можно показывать другим людям, обсуждать, получать экспертные оценки и т.п.

Однако играть в это еще нельзя, т.к. она существует только в компьютере. Чтобы сыграть в новую игру, нужен её физический прототип.

2. Prototype – прототип

Одна из DIY версий карточек игры «Социальный Бизнес»

Для чего нужен прототип? Смысл прототипа в том, чтобы проверить на практике, насколько созданный концепт удобен, как им пользоваться и т.д. На фото одна из версий карточек, изготовленная на обычной офисной бумаге с помощью офисного резака. Как видно, эта версия по форме уже отличается от того, что было в прототипе – тестирование самых первых образцов, которые были вырезаны ножницами, показало, что прямоугольные карточки более удобны в пользовании и экономичны, чем квадратные. А еще из неудачных прототипов стало понятно:

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

3. MVP – минимально жизнеспособный продукт

Первая коробочная версия игры «Социальный бизнес»

Бизнес с нуля. Эрик Рис. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.

Когда прототипирование завершилось, и основные технические и содержательные проблемы устранены, можно переходить к тестированию продаж продукта. Продукт, который полностью «автономен», то есть который можно спокойно продать будущему пользователю – понятно как им пользоваться, он не развалится (как минимум первое время) и который выполняет ключевые функции, ради которых создавался (но не обязательно вообще все возможные) – такой продукт называется MVP, minimum viable product – минимально жизнеспособный продукт. В шутку его еще называют «минимально великолепный продукт», чтобы дословно транслитерировать английскую аббревиатуру MVP в русскую МВП.

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

Для чего нужен MVP? Для тестирования гипотезы о бизнес-модели продукта, куда в первую очередь входят такие вопросы:

• кто покупатель?
• как он совершает покупку?
• какова цена продукта?
• каковы переменные и постоянные издержки?

Для того, чтобы проверить, сойдутся ли продукт т рынок (product — market fit) игры в таком виде достаточно, и можно делать тестовые продажи. О том, как это делать, можно написать отдельный текст, поэтому в детали не буду углубляться сейчас. Тестовые продажи показали: кому интересен этот продукт, по какой цене его готовы покупать, сколько стоит его изготовление.

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

Источник: dzen.ru

Тестирование идеи тиражируемого программного продукта

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

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

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

Принципы тестирования идеи продукта и бизнес-модели

1. Придумайте схему, которая позволит протестировать бизнес-модель продукта как можно быстрее. В идеале — за пару недель.
2. Старайтесь продать продукт, до начала разработки. Для того, чтобы подтвердить ценность решения в глазах пользователя не обязательно иметь готовый продукт. В противном случае, вы рискуете потратить месяцы на разработку того, что никому не нужно.
3. Важно сразу подтвердить, что продукт будут покупать. Используйте подходы «Бережливого стартапа» Эрика Риса (Lean Startup. Eric Ries) или другие методологии, использующие понятие минимально жизнеспособного продукта (MVP, Minimum Viable Product). Не стремитесь к полноте и совершенству. Попробуйте продать недоработанный продукт только с ключевой для вашей идеи функциональностью, возможно, за меньшую сумму. Если идея пойдет — можно будет составлять подробное ТЗ и приступать к разработке.
4. Постарайтесь уйти от субъективности в оценке результатов тестирования и беспристрастно смотрите на цифры и метрики. Только они могут сказать, насколько эффективен проект и идея. Хотя, бывали случаи, когда успешные продукты рождались на интуиции и чутье, вопреки первоначальным количественным оценкам.
5. Учитесь закрывать неработающие проекты. Это психологически тяжело, но иногда лучше вовремя остановиться. В принятии решения также полагайтесь на цифры.
6. Ставьте себе амбициозные цели, т.к. большие цифры сразу указывают на узкие места в финансовой модели.
7. Работая над нишевым продуктом, стремитесь минимизировать зависимость вашего проекта от внешних факторов: чужих алгоритмов, партнеров, внешних источников данных и т.д.
8. Будьте готовы к развороту (pivot) — например, кардинально изменить параметры бизнес модели или, например, перейти с B2C на B2B рынок. Не будьте рабом своей идеи. Не бойтесь трансформировать и преображать ее.
9. На этапе тестирования не старайтесь проработать, автоматизировать или закрыть сотрудниками все этапы процесса. На самом первом этапе многое можно делать бесплатными средствами или за счет ручного труда: вместо бухгалтерской программы или дорогой CRM системы использовать Google Spreadsheets и Google Forms, вместо офиса работать дома, сайт сделать на бесплатном шаблоне или в конструкторе.

Методы тестирования идеи и бизнес-модели до начала этапа программирования

• Создайте несложный сайт или посадочную страницу (landing page) на шаблоне, который можно купить, например, на themeforest.net за $10-$15, на котором опишите свой продукт так, как будто он уже существует — с описанием его преимуществ, возможностей и ценовой модели. Купите небольшой, но достаточный для тестирования, объем контекстной рекламы по соответствующим ключевым словам и направьте трафик с рекламы на этот мини-сайт. Вместо установки продукта или регистрации, вы можете собирать адреса и телефоны заинтересовавшихся посетителей, пообещав им скидку на первую версию продукта или приглашение на участие в ее тестировании. Прием работает как для B2B, так и для B2C рынков. При данном подходе вы решите сразу три задачи:

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

Однако, тестируя идею своего будущего продукта с привлечением людей, всегда помните фразу, приписываемую Генри Форду:

«Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.»

Возможно, именно ваше чутье и чувство рынка окажутся более правыми, чем все те цифры, которые предрекали вам однозначный провал.

Ссылки по теме

• The Product / Market Fit Cycle
• Чек-лист ИТ-стартапа на начальной стадии развития: что нужно сделать, прежде чем тестировать каналы продаж

Источник: www.isdef.org

Тестирование на основе моделей

Картинка с unsplash.com

Обеспечение качества, оно же Quality Assurance, оно же QA, включает в себя много разных активностей, позволяющих делать продукт лучше. Незаменимая и широко известная часть этого процесса — тестирование.

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

Пара слов обо мне: меня зовут Настя Заречнева, и я обеспечиваю качество рекламы ВКонтакте. Раньше я работала в аутсорсе на самых разных проектах, выполняя роли от тест-аналитика до руководителя команды QA, поэтому не понаслышке знаю, что начинать тестирование заранее — классный способ сэкономить себе время и нервы в будущем.

Предисловие

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

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

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

Есть 2 варианта: либо учиться читать код (что не панацея, ведь даже разработчики зачастую разбираются лишь в той части системы, с которой непосредственно работают), либо искать другой существующий способ тестировать функциональные аспекты продукта.

Тут нам и приходят на помощь тестовые модели. Это не rocket science и не что-то ультрановое: аналогией с использованием тестовых моделей в разработке ПО можно считать использование схем при проектировании электроприбора или электроустановки. Даже если сама установка еще не готова, мы уже можем увидеть части системы, их связи и слабые места, — например, на изображении ниже можно заметить будущее короткое замыкание.

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

Тестирование на основе моделей (Model-Based Testing, далее MBT) — одна из техник тестирования черного ящика. В непрерывной разработке (и, как правило, частых поставках) большого продукта ошибка может стоить дорого, и именно потому, что MBT — один из проверенных и эффективных способов предотвратить ее как можно раньше, мне захотелось собрать и представить вам информацию о нем.

Что такое тестовые модели

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

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

Основные особенности тестовых моделей в том, что их можно начинать собирать еще до фактического старта разработки, и в том, что их можно обновлять и переиспользовать при изменении системы. Таким образом, тестовая модель дает более ясное представление о системе всем участникам разработки и упрощает поддержку будущей тестовой документации, — но обо всем по порядку.

Какое отношение к математике имеют тестовые модели

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