Демо программа что это такое

Содержание

Как провести демо клиенту

Зачем нам вообще проводить демо? В чем профит? Есть же дизайны, детально расписанные юзер стори или ТЗ, критерии приёмки. В конце концов, есть люди с зарплатой, которые проверяют, соответствует ли разработанное нами требованиям заказчика. Ответ — в ценности демо как для нас, как исполнителей, так и для наших клиентов: Ценность для клиента.

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

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

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

Что такое Samsung demo live demo unit ldu Обзор демо телефона самсунг актуально в 2022

Итак, мы условно разделяем клиентское демо на два основных этапа — подготовка и собственно сам «экшон».

Подготовка к демо

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

Пишем сценарий или демо-документ

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

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

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

Готовим среду

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

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

Samsung s10 ldu live demo unit стоит ли оно того ? что такое demo и root

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

Но тем не менее, если у нас в локали лежит добротная фича, которой по каким-то причинам нет на стейджинге (неполная реализация/работа только при участии духовых инструментов/не успели залить), а откровенно нового в демо мало, — мы её покажем! В конце концов, почему бы приятно не удивить клиента? 😉

Распределяем обязанности и роли

Мне кажется, нет единого «золотого» стандарта, по которому надо определять участников процесса. Есть команды, в которых демо всегда проводит один и тот же человек, и клиент пляшет от восторга. В некоторых случаях выступает вся команда, и тоже получается отличный материал.

Мы обычно подключаем к демо всю команду. По крайне мере тех её членов, чей уровень английского позволяет свободно рассказывать о проделанной работе и отвечать на вопросы клиентов и партнёров (они у нас в большинстве своём англоговорящие).

Есть несколько причин, по которым стоит привлечь к проведению демо всю команду:

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

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

Проводим внутреннее демо

Часто даже у такого незначительно события, как свадьба, есть репетиция. И нам тоже было бы неплохо ее провести. К тому же, в отличие от свадьбы, репетиция демо принесёт нам существенно больше профита. Ведь именно на этом этапе часто можно заметить/отловить огрехи, которые были допущены в процессе подготовки.

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

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

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

Чек-лист готовности к клиентскому демо

✓ написан сценарий проведения демо;

✓ подготовлена и проверена на работоспособность среда для проведения демо;

✓ каждый член команды знает, о чём он будет рассказывать и что показывать;

✓ внутреннее демо проведено;

✓ ошибки, выявленные на внутреннем демо, устранены.

Проведение демо

Итак, мы всё подготовили, сверились с приведённым выше чек-листом и назначили встречу с клиентом. У вас открыт демо-документ и вкладки с нужными страницами, команда в сборе и знает, что делать. Чтобы все прошло гладко, вот еще несколько моментов, о которых стоит помнить уже непосредственно на самом демо.

Управление ожиданиями

Здорово, когда команда понимает, чего ждёт клиент от каждого конкретного демо. Великолепно, если команда ещё и может все эти ожидания оправдать. А если нет? В этом случае лучше сразу дать клиенту понять, что столь вожделенный конструктор видео-каруселей к демонстрации пока не готов — то есть, фактически, снизить ожидания еще на старте.

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

Сторителлинг вместо сухих перечислений

Вы же помните, что демо — это публичное выступление и работа с аудиторией? Про некоторые компоненты, особенно визуально насыщенные, рассказывать легко — всё яркое, анимированное. Можно вообще просто радостно посвистывать в процессе демонстрации того, как у вас одна анимация на другую наезжает.

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

Мы в таких случаях стараемся придерживаться трёх правил демонстрации:

Рассказываем о сложных и «скучных» компонентах через сценарии их использования.
Показываем пользу разработанной нами функциональности для конкретных пользователей.
Приводим много примеров и выделяем отдельно время для ответов на вопросы клиента.

Нет

Это форма для загрузки товаров в интернет-магазин. Вот тут кнопка загрузки, а тут кнопка удаления. Можно загрузить один товар или сразу несколько. Всё работает, мы проверяли, идем дальше.

Да

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

Чтобы менеджерам было удобно работать сразу с большим объемом товаров, мы добавили .

Есть ли у вас какие-то вопросы или пожелания по работе этого инструмента?

Упор на то, что интересно клиенту

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

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

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

Сбор фидбека

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

Положительный фидбек

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

Что же можно сделать с исключительно положительным фидбеком?

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

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

Отрицательный фидбек

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

Если фидбека мало

Если есть ощущение, что фидбэка недостаточно, мы просим ещё! И, чтобы помочь клиенту и разговорить его, начинаем задавать вопросы. Много вопросов!

Например, можно узнать мнение о конкретных компонентах и функциональностях, задавая закрые вопросы: «Поведение этого компонента для анонимного пользователя прописано в ТЗ размыто, он должен показываться ему или нет?».

А открытые вопросы помогут настроить клиента «на порефлексировать» — что понравилось, что не понравилось, а если бы было так, а не иначе и т.д.

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

Что происходит после демо

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

Обычно мы разбираем фидбэк по зонам ответственности и распределяем по исполнителям. Огрехи разработки уходят разработчикам на ремонт. Туманные моменты в ТЗ, — людям, ответственным за написание документации, на прояснение. Хотелки, всплывшие во время демо, — руководителям и менеджерам проекта.

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

Заключение

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

Ну и пара советов в заключение:

постарайтесь сильно не волноваться — если вы нормально подготовлены, вероятнее всего, вы довольно здорово проведете время;
не забывайте контактировать с аудиторией, интересоваться её вопросами, а не просто читать демо-документ;
как бы странно это не звучало, попробуйте сосредоточиться на положительных моментах демо и желайте отрицательного фидбэка — с ним реально интереснее работать!

Автор статьи: Кирилл Кодин

Редактура: Марина Медведева

Фото в заголовке: Headway on Unsplash

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

Демо-версия — что значит?

что значит Демо-версия?

Для того, чтобы продвигать свои «изделия», маркетологи изобретают всё больше хитростей. К одной из такой уловок можно отнести Демо-версию. Что значит Демо-версия? Прочтите ещё несколько толковых публикаций, например, как понять слово Ломбард, что такое Локаут, что значит Логистика? Это выражение произошло от слова «демо», что означает демонстрацию.

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

Демо-версия (демонстрационная версия) — это предварительная, пробная, зачастую урезанная и практически всегда бесплатная версия продукта

Существует несколько видов демо-версий, например:

У треков или песен, часто связано с выражением демо-запись.

У компьютерных игр — обычно это полноценная игра, но с одним уровнем.

У компьютерных программ — их ещё называют триальными.

У приборов высокой сложности.

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

Источник: xn—-7sb3abqfg0a4g2a.xn--p1ai

Что такое демо-режим? — определение из техопедии

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

Демо-режим также известен как напольный режим или режим киоска.

Техопедия объясняет демо-режим

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

Краудсорсинг: что это такое, почему это работает и почему оно не уходит

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

Источник: ru.theastrologypage.com

Демоверсии видеоигр: от необходимости до обузы

Рассуждения о демонстрационных версиях видеоигр. Почему они были популярны раньше и куда пропали сейчас?

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

Истоки демоверсий

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

Если игроку нравилось, то он отправлял деньги разработчикам, получал код и разблокировал оставшуюся часть проекта. Затем, небольшие части игр собирались вместе на одном диске и продавались, например, вместе с заказами в каких-либо заведениях. Либо же, как у нас было раньше, шли бонусом к различным журналам.

Почему они были важны

Но зачем все это? Зачем запариваться, тратить отдельные средства на отдельные версии игры, на ее бесплатное распространение и все такое? Ну, ответ прост. Ради рекламы. В те далекие времена, когда интернета либо не было вовсе, либо на загрузку одной страницы уходило по полчаса, это был самый эффективный способ популяризации своего продукта.

Сейчас как помню, у меня было парочку выпусков игромании (вроде это была игромания, могу ошибаться) и с ними шли куча демок разных. Помню как перепроходил демо уровень для первой Call of Duty буквально десятки раз. А потом, когда обзавелся уже полноценной версией, было очень лампово вновь пройти затертый до дыр момент. Эх, были времена.

Опасная практика

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

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

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

Но почему бы не оставить демоверсии? Ведь обзоры обзорами, но ничто не заменит тебе твой личный опыт и вкус. Вы можете посмотреть десятки разных обзоров, на 99% состоящих из хвалебных эпитетов. После чего, приобрести игру и разочароваться в ней. Это нормально, и именно с решением подобной проблемы могли бы поспособствовать демонстрационные версии, ведь так?

На самом деле, не совсем.

Сейчас ААА сегмент находится не в самом лучшем состоянии. Думаю, ни для кого это не станет откровением. С каждым годом идеи для проектов высасываются сперва из пальцев, а потом и из всех других возможных источников. То же самое касается и технической части этих проектов.

В последнее время чуть ли не каждый второй (эту цифру я взял с потолка, ориентируясь чисто на своё восприятие) ААА проект выходит недоделанным, а порой и забагованным по самое горло. И теперь представьте, что получил бы человек, скачав, например, демоверсию Cyberpunk 2077 или Battlefield 2042? Не думаю, что после увиденного он стал бы тратить свои кровные на эти проекты. Вот так вот.

Итог

К сожалению, так уж получилось, что демоверсии прошли путь от жизненной необходимости до обузы, угрожающей бизнесу. Иронично, не так ли? Будучи крайне важной частью рекламной компании, сейчас демоверсии превратились в самую настоящую антирекламу, способную сыграть с проектом злую шутку. Я более чем уверен, что даже если бы демки и остались, то все равно не котировались бы.

Представьте, если взять вышеупомянутый Cyberpunk 2077. Если бы к нему существовала бы демоверсия, я более чем уверен, что она была бы вылизана вдоль и поперек. Чуете, к чему я клоню? Если раньше демки были просто первыми уровнями своих игр, то сейчас они бы полностью отличались бы от итогового продукта. Как лживый трейлер какого-нибудь фильма.

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

Тем не менее, демоверсии как явление вовсе не исчезли. Например, в Steam есть специальный раздел под демоверсии. А так же там регулярно проходит фестиваль самых разных демок. Сами же демоверсии игр по большей своей части вернулись туда, где они начинали. Я говорю, конечно же, о небольших студиях с их небольшими проектами.

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

Шутер Ролевая игра Приключенческий боевик Приключенческая игра PC PS4 Xbox One Switch PS5 Xbox Series X Другой Другая

Источник: www.ixbt.com