Разработка расписания проекта. Продуктовые стратегии в IT

? доступность сервера в режиме 24Ч7 и гарантии безопасности хранимой на нем информации;

? поддержка платформ, на которых был разработан программный продукт, в том числе поддержка PHP, MySQL и т. д.

К подобным ИТ-услугам можно отнести и услуги по поисковому продвижению сайтов в сети Интернет (SEO). В этом случае товарная политика такого рода компаний будет включать:

? анализ и внутреннюю оптимизацию сайта;

? выделение доли рынка, охватываемой тематикой сайта;

? создание и развитие фундаментальной стратегии развития сайта;

? предоставление услуг SEO, в том числе поисковой оптимизации и продвижения;

? интернет-маркетинг и т. д.

Аналогичным образом, исходя из специфики оказываемых услуг, будет определяться товарная политика и для других видов ИТ-услуг, таких как ИТ- консалтинг и аудит, системная и сетевая интеграция, поиск ИТ-специалистов и формирование команд разработчиков (выделенных центров разработки) и многих других.

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

Стратегия фокусирования при разработке программных продуктов и ИТ-услуг

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

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

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

Авторы прогремевшего в 2010 году бестселлера «Rework» утверждают, что не всегда нужно стремиться к увеличению функционала продукта по отношению к конкурентным аналогам. Иногда делать меньше - значительно лучше и конкурентоспособнее. Принадлежащая авторам компания 37signals - это небольшая команда, создающая «простое и фокусированное программное обеспечение». Как заявлено в официальных принципах работы: «Мы уверены, программы слишком сложны. Так много возможностей, так много кнопок, столько времени, чтобы разобраться. Наши продукты сводят это к минимуму. Мы создаем продукты, которые работают шикарней, чувствуют пользователя лучше, позволяют вести разработку, как вам удобно, и весьма легки в использовании». И действительно, предлагаемая этой компанией онлайн-платформа для управления проектами Basecamp лишена популярных диаграмм Ганта и прочих тяжеловесных элементов и предлагает пользователю лишь минимально необходимое: форум для общения, todo-листы и пространство для обмена файлами.

Стратегия фокусирования характерна и для других успешных проектов, которые даже не ставят себе цель уметь все. Так, например, Campfire предлагает пользователям групповой чат для бизнеса и ничего сверх этого; Highrise аккумулирует полезные контактные данные в распределенной книге контактов; Backpack предоставляет удобный органайзер, содержащий страницы для записей, хранящий заметки и задачи и позволяющий делать напоминания по телефону или электронной почте; Writeboard продвигает онлайн-доску, позволяющую писать и совместно использовать тексты; программа Ta-da List помогает организовать хранение списков дел в режиме онлайн.

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

Наличие дополнительных функций не делает продукт лучше. Более того, в ряде случаев сделать продукт лучше, как раз и означает убрать из него ту или иную привычную функцию или элемент. Напомним, что в 1999 году из персонального компьютера был исключен дисковод. Позднее его судьбу повторили стилус из смартфона, DVD-привод и компьютерная мышь из ноутбуков. Однако мы не ощущаем нехватку этих устройств. В итоге всех этих «урезаний» был создан новый стандарт для целой отрасли! Мы говорим про Apple.

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

Прототипирование программных продуктов. Сущность прототипирования

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

Прототип - черновая реализация базовой функциональности будущего продукта. В общем виде различают прототипы высокоточные (high-fidelity), представляющие полноценный продукт с ограниченной функциональностью, и схематичные (low-fidelity), лишь изображающие продукт.

С точки зрения Дмитрия Сатина, генерального директора Usabilitylab и признанного эксперта в сфере юзабилити, прототипы на ранних стадиях проекта крайне важны и гораздо эффективнее любых текстовых описаний.

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

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

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

Самое главное преимущество заключается в том, что прототип даст реальную возможность протестировать идею на потребителях еще до того, как будут сделаны существенные инвестиции в ее реализацию. Якоб Нильсен, эксперт в области веб-юзабилити из компании Nielsen Norman Group, получил количественную оценку, согласно которой даже самый простой схематичный прототип из бумаги (например, так называемый скетч) позволяет в 100 раз сократить затраты на внесение каких-либо действительно необходимых изменений в продукт.

Другие преимущества прототипирования можно описать следующими фактами:

1. Разработка полноценного прототипа принуждает вас с самого начала думать о продукте как о чем-то целом и реальном, а не как о наборе функций.

2. Прототип приводит к тесному сотрудничеству менеджера по продукту, системного архитектора и специалиста по интерактивному дизайну (interaction designer).

3. Полноценный прототип позволяет достаточно точно оценить затраты на разработку готового продукта.

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

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

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

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

Конечно, полноценное прототипирование - это не всегда дешево, а зачастую просто дорого. Однако процитируем Марти Кагана: «… даже если у вас почти нет ресурсов и очень мало денег, все равно нельзя отказываться от прототипирования. Это абсолютно необходимая, существенная часть вашей работы [как предпринимателя]».

Основные виды прототипирования программных продуктов

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

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

Бумажное прототипирование зародилось еще в середине 1980-х годов и стало очень популярным в 1990-х, когда такие «монстры», как IBM, Honeywell и Microsoft стали активно использовать его в процессе разработки своих программных продуктов. В настоящее время бумажные прототипы, как правило, используются специалистами по юзабилити.

По мнению Кэролин Снайдер, автора бестселлера «Paper Prototyping», подобный подход позволяет:

? протестировать идею программного продукта у пользователей еще до кодирования;

? очень быстро вносить изменения;

? быть независимым от технических средств.

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

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

И все же для многих программных продуктов бумажных прототипов может быть недостаточно. Какими же еще могут быть прототипы? Считается, что все используемые в мире ИТ-прототипы можно разделить на 2 большие группы в зависимости от способов их создания и последующего использования: одноразовые и эволюционные.

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

Эволюционные прототипы (Evolutionary Prototyping) - это в прямом смысле слова черновая реализация функционала программного продукта, его альфа-версия. По мере внесения изменений такой прототип эволюционирует в конечном итоге в полноценный готовый продукт.

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

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

Рустем Гайфутдинов из ALEE Software, компании-создателя GUI Machine, обобщая существующие подходы и инструменты, предлагает условную типизацию прототипов в мире ИТ. В табл. 2.1 представлены данные о четырех наиболее важных видах прототипов ИТ-продуктов и некоторых используемых для работы с ними инструментах.

Таблица 2.1. Наиболее важные виды прототипов ИТ-продуктов

Из табл. 2.1 видно, что степень точности и полноценности рассмотренных прототипов возрастает сверху вниз. Рустем Гайфутдинов пишет: «Большинство из нас делает «бумажные» прототипы в самом начале этапа сбора требований. Затем по мере уточнения требований увеличивается точность прототипов. Кто-то останавливается на вайфрейме, кто-то доводит до мокапов с дизайном, близким к конечному. Но наибольший интерес представляют интерактивные прототипы. Именно они позволяют полноценно вовлечь пользователя, показать систему целиком и в действии».

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

Концепция притворного прототипирования (pretotyping)

Еще одна заслуживающая внимания концепция - это притворное прототипирование, или «якобы-прототипирование» (pretotyping), предложенная Альберто Савойя.

Данная концепция относится к классу одноразовых прототипов и направлена на то, чтобы компания убедилась, что делает правильный продукт (the right it) еще до того, как проинвестирует много времени и усилий, чтобы сделать его правильно (to build it right).

Само слово pretotyping происходит от сочетания слов «PREtended» (при- творный), и «proTOTYPING» (прототипирование) и может быть переведено как «якобы-прототипирование». Авторы этого термина, как собственно и всей концепции, - Альберто Савойя (Alberto Savoia), сотрудник Google, Джереми Кларк (Jeremy Clark), ИТ-эксперт, и Патрик Коуплэнд (Patrick Copeland) из Google. Именно к их сайту www.pretotyping.org, а также к их книге «Pretotype It» мы и рекомендуем обратиться. Здесь же мы остановимся только на самых главных идеях и примерах концепции.

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

Вот какой пример «якобы-прототипирования» приводит сам Альберто Савойя. Джефф Хоукинс (Jeff Hawkins), главный технолог Palm, спроектировал GRiDPad - один из первых карманных компьютеров (handheld computer). Это был настоящий инженерный прорыв, но также и оглушительный рыночный провал, так как компьютер получился слишком большим. Чтобы не повторить ошибку во второй раз, Джефф выстругал из дерева брусок размером с карман его рубашки. И стал ходить с этим бруском в течение нескольких месяцев, притворяясь, что это и есть настоящий компьютер. Кто-то назначает ему встречу во время обеда в среду? Хоукинс достает деревянный брусок и «кликает» по «клавишам», проверяя свое «расписание». Ему нужен чей-то номер телефона? И он опять смотрит на кусок дерева. Все это позволило Джеффу проверить различные конфигурации интерфейса, в том числе расположение «клавиш», роль которых выполняли разрисованные кусочки бумаги, приклеенные на брусок. Таким образом, используя всего лишь простой кусок дерева, не стоящий практически ни цента, технолог смог протестировать идею карманного компьютера, в том числе его габариты, интерфейс, функционал и т.п. Итогом стал выпуск легендарного Palm Pilot, имевшего оглушительный рыночный успех.

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

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

Фальшивая дверь (The Fake Door) - создание описания или указания на продукт, который на самом деле не существует. Например, это может быть начальная страница несуществующего еще веб-сервиса, баннерная реклама, за которой нет реального предложения, кнопка или гиперссылка, ведущие якобы к услуге, скачиванию файла и т. п. Если потребители будут стучаться в такую фальшивую дверь, значит потенциальный спрос существует. Краудфандинг, с нашей точки зрения, также является превосходным методом фальшивой двери. Описание будущего продукта, выложенное на соответствующий ресурс, и реальные пожертвования реальных пользователей - отличный способ «якобы- прототипирования» и апробации.

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

Шахматная машина «Турок» (The Mechanical Turk) - замена сложных компьютерно-программных систем людьми, выполняющими необходимые функции. Например, сотрудникам компании IBM вместо того, чтобы делать дорогостоящий реальный прототип своей системы речевого ввода (speech-to-text machine), что потребовало бы создания специальной программной («софт») и специальной аппаратной («железо») частей, по факту понадобились только 2 отдельные комнаты, несколько недорогих устройств и добровольцев. В первой из комнат были установлены микрофон и монитор, во второй перед экраном компьютера расположилась девушка-машинистка, набиравшая текст с клавиатуры.

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

Однодневка (The One Night Stand Pretotype) - моделирование продукта, услуги или даже бизнеса в целом, не требующее долгосрочного и основательного тестирования. Альберто Савойя приводит пример с сетью американских магазинов Best Buy, владельцы которой планировали запустить новую услугу. Суть последней заключалась в том, что посетители приносят бывшую в употреблении бытовую электронику, остаточная стоимость которой оценивается экспертами и на ее основе определяется размер скидки, предоставляемой потребителю при покупке новых товаров.

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

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

Другой ярлык (The Re-label, the Impersonator prototype) - использование существующего продукта, выдаваемого за планируемый к выпуску путем изменения упаковки, ярлыков и т. п. Такой подход имеет место, когда вы берете дизайн страниц одной сети (предположим, LinkedIn), меняете все названия и другие детали и таким образом наглядно демонстрируете идею своей собственной социальной сети.

Диверсант (The Infiltrator) - разновидность предыдущего подхода, предполагающая внесение изменений в уже существующий продукт и проведение А/В-тестирования двух получившихся версий.

«Якобы-владение» (The Pretend-to-Own) - получение необходимого для оказания услуг оборудования на условиях аренды, вместо его полноценного приобретения. В частности, вместо закупки серверного оборудования для тестирования идеи нового онлайн-бизнеса могут быть использованы виртуальные сервера.

Дразнилка (The Teaser) - создание полноценной версии лишь для одной функции или части продукта, например: онлайн-карта Беларуси обладает полными функциональными возможностями, но содержит информацию только по городу Минску; онлайн-каталог увеселительных мероприятий включает мероприятия только на три определенных дня; мобильное приложение изначально выкладывается в магазин приложений в виде чрезвычайно усеченной бета- версии, а затем дорабатывается до полноценной версии с учетом обратной связи от пользователей и количества скачиваний.

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

А/В-тестирование

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

Хотите получить реальную обратную связь от потребителей? Просто сделайте две версии продукта и продавайте их на разных рынках или для разных сегментов или групп потребителей. А затем сравните результаты.

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

? имеется один и тот же объект, представленный в двух разных вариантах - A и В;

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

? первой группе демонстрируется версия А, второй соответственно - В;

? производится количественное измерение поведенческой реакции (напри- мер, оценивается количество нажатий кнопки «заказать»): первой группы на вариант А, второй группы на вариант В;

? сравниваются результаты и делается вывод о предпочтительности первого или второго варианта.

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

Учет эмоций потребителя при разработке программных продуктов и ИТ-услуг

К «мелочам», отделяющим посредственный продукт от выдающегося, эксперты относят эмоции, создаваемые продуктом, и ту историю, которую он рассказывает. Рассмотрим, как следует учитывать эмоции потребителя.

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

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

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

Еще одним ярким примером того, что функциональная полезность - это не всегда главное, служит минеральная вода Evian. Этот бренд уже давно воспринимается как элитарный. Не по качеству воды, т. е. по объективно измеримым характеристикам и свойствам, а просто на уровне чувств и ощущений. И покупатели платят именно за это!

Своеобразной классикой эмоционального маркетинга считается противостояние Coca Cola и Pepsi Cola. Вы, наверное, знаете про эксперименты среди обычных покупателей, которые в большинстве своем не могли отличить один напиток от другого, если они были разлиты в безымянные бутылки, но при этом имели весьма четкие эмоциональные предпочтения по отношению к Coca Cola. Один из авторов данного учебно-методического пособия наблюдал повторение этого же эксперимента в университетской аудитории: и вновь подавляющее большинство «подопытных» студентов не смогло отличить Coca Cola от Pepsi Cola. Другими словами, вовсе не объективные характеристики продукта, которыми в данном случае являются вкус, цвет и запах, а эмоциональное отношение к бренду играет решающую роль.

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

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

Прорабатывая идею нового продукта соответствующие специалисты ИТ- компании должны спросить себя:

1. Не забыл ли я при анализе полезности продукта про его эмоциональную составляющую? Не упустил ли я эту важную и необходимую деталь успеха?

2. Могу ли я не только сказать, кто мой потребитель, но и нарисовать его точный эмоциональный портрет?

3. Могу ли я четко сформулировать, буквально одним предложением, какова эмоциональная полезность моего продукта?

4. Знаю ли я, какие именно эмоции мой продукт вызовет у покупателя, и как я планирую зафиксировать и подвергнуть анализу эту эмоциональную реакцию?

5. Как именно и посредством чего моя идея нового продукта или бизнеса учитывает эмоции потенциального потребителя?

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

Правда, нужно также предупредить и об опасности преувеличенного (а тем более необоснованного!) оптимизма по отношению к эмоциям. Они крайне важны, но до определенного предела. И далеко не всегда. Как сказал известный российский маркетолог Александр Репьев: «Ответы … покажут нам ничтожно малые количества эмоционально окрашенных торговых марок. При наличии миллионов марок в мире это исчезающе малый процент. Все это, как минимум, говорит о том, что тема маркетинговых эмоций не заслуживает того внимания, которое ей уделяют авторы тысяч книг и статей, излагающих к тому же массу противоречивых и сумбурных «эмоциональных» теорий»

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Маркетинг программных продуктов и услуг : учеб.-метод. пособие / В. М. Стреж, В. А. Пархименко. - Минск : БГУИР, 2016. - 228 с.

2. Особенности продуктовой стратегии ИТ-компаний / Т. П. Розанова, Ю. Н. Иванова.

3. Федорова М. С. Разработка маркетинговой стратегии предприятия // Молодой ученый. -- 2011. -- №5. Т.1. -- С. 232-234.

4. Разработка расписания проекта [Электронный ресурс]. - Режим доступа: http://www.intuit.ru/studies/courses/646/502/lecture/11393

5. Энциклопедия по экономике [Электронный ресурс]. - Режим доступа: http://economy-ru.info/index/

6. Разработка расписания проекта [Электронный ресурс]. - Режим доступа: http://kursak.net/razrabotka-raspisaniya-proekta/

Размещено на Allbest.ru