Технологии не стоят на месте, и процессы разработки движутся вместе с ними. Если раньше компании работали по модели «Waterfall», то сейчас, например, все стремятся внедрить «Scrum». Эволюция происходит и в сфере предоставления услуг по разработке программного обеспечения. Раньше компании предоставляли клиентам качественную разработку в рамках бюджета, останавливаясь на этом, сейчас же они стремятся обеспечить максимальную пользу для клиента и его бизнеса, предоставляя свою экспертизу.
Давайте рассмотрим вариант разработки продукта по ТЗ. Клиент приходит в компанию с конкретным заданием, на выходе он получает решение. Вроде бы это достаточно просто: клиент получил то что хотел, то есть решение изготовленное по его ТЗ.
В чем же проблема? На самом деле бизнесу не нужно решение по ТЗ. Ему нужен работающий продукт, который приносит доход. А это определяется не качеством разработки, а, в большинстве случаев, тем, нужен ли он рынку, понятен ли он пользователям, имеет ли он Value Proposition в принципе.
Исходя из статистики Cbinsights.com 9 из 10-ти стратапов проваливаются. Главная причина провалов, 42%, в том, что это просто никому не нужно.
Мы верим, что хороший продукт нельзя построить, не зная его пользователей. Поэтому как непосредственные участники создания продукта хотим знать, для кого мы это делаем, какие задачи мы хотим решить.
Это совершенно другой уровень погруженности команды в работу и совсем другой уровень коммуникации с заказчиком. Если мы хорошо знаем бизнес и пользователей клиента, мы можем говорить с ним на одном языке и предлагать действительно интересные решения, которые удовлетворят всех.
Так для чего же нужны исследования?
Стоит заметить, что исследования можно проводить как для стартапа, так и для состоявшегося продукта, на всем пути его развития.
Для чего они вообще нужны:
- понять цели, мотивы, проблемы пользователей и контекст использования продукта;
- выявить юзабилити проблемы в текущем решении или решении конкурентов;
- найти новые идеи для развития продукта и инсайты;
- понять, как продукт воспринимается по сравнению с конкурентами.
Давайте разберемся подробнее.
Понять цели, мотивы, проблемы пользователей и контекст использования продукта.
За каждым действием стоит какая то цель, за каждой целью — мотив. Для нас важно понять, почему пользователь выполняет ту или иную задачу, чтобы предложить ряд решений, который удовлетворит его.
Представьте себе, пользователь не хочет регистрироваться на сайте, он не хочет создавать на нем контент, он хочет, например, стать известным, заявить о себе ради славы и денег, а это можно сделать сотней других способов. Даже, если брать во внимание, что мы можем предоставить пользователю только один способ достижения этих целей, это можно подать по-разному.
Реализация так же может зависеть от того в каком контексте используется продукт. Есть разница, например, между расслабленным взаимодействием дома за компьютером и попытками взаимодействовать с интерфейсом на экране смартфона в переполненном общественном транспорте.
Узнайте, Почему вашему стартапу нужен MVP
Выявить юзабилити проблемы в текущем решении или решении конкурентов.
Если у клиента уже есть готовое решение, нам обязательно надо его изучить. Для того что бы узнать насколько эффективно и продуктивно пользователи взаимодействуют с продуктом а также насколько они удовлетворены работой с ним, нужно провести тестирование юзабилити.
Даже если у клиента нет готового продукта, наверняка есть аналоги. Никому не хочется наступать на чужие грабли, поэтому можно протестировать продукт конкурента и не допустить те же ошибки у себя.
Найти новые идеи для развития продукта и инсайты.
Вы, наверное, сразу вспомнили крылатую фразу Генри Форда «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь». Эту фразу можно трактовать по-разному. Когда пользователь озвучивает нам идею, мы спрашиваем: «Что это вам даст? Как вы решаете эту проблему сейчас? Сколько вы готовы заплатить за эту функцию?» А это совсем другое по сравнению с простым выполнением прихотей клиента.
Есть большая разница в том, чтобы сделать ускоритель лошадей и понять проблему медленного передвижения на относительно короткие дистанции и решить ее.
Понять, как продукт воспринимается по сравнению с конкурентами.
Если это уникальный продукт для уникальной аудитории, возможно, не стоит бояться конкуренции, но даже в таких случаях могут быть косвенные конкуренты, которые приуменьшают вашу прибыль.
В любом случае, нам нужно понять, с кем мы собираемся соревноваться, какие преимущества пользователи находят в решениях конкурентов, что мы можем позаимствовать, а что не будем реализовывать, чтобы не повторять чьи-то ошибки. Что мы можем сделать такого, чего нет у конкурентов, но пользователи ожидают это увидеть?
Заключение
В заключение хочется сказать, что разработка продуктов сейчас движется в направлении удовлетворения потребностей пользователей. Все давно понимают, что хорошая техническая реализация избавит от проблем при масштабировании продукта, поможет выдержать большие нагрузки, поддерживать код в хорошем состоянии на протяжении многих лет, но к тому нужен ли будет этот чистый код без багов хоть кому-нибудь приходят не все и не сразу.
Не основывайтесь только на своем личном мнении, найдите проблемы пользователя, исследуя их, придумайте, как решить эти проблемы, протестируйте, в правильном ли направлении вы движетесь, и вероятность провала существенно сократится.
