Приемы проектирования сервисов (часть 5)

Это финальная статья цикла о приемах проектирования интернет сервисов.

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

champion-lg

В первой части были освещены вопросы о том, что такое проектирование и зачем оно нужно.

Во второй части мы поговорили о целях проектирования и ролях участников команды в этом процессе.

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

В четвертой части мы говорили о гипотезе о проблеме и сценариях использования сервиса (гипотезе о решении проблемы).

Где мы сейчас

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

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

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

Куда и как нам двигаться дальше

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

Не стоит отчаиваться. Как говорит Стивен Бланк: “Смею вас уверить, ни один бизнес-план не выдержит контактов с первыми клиентами. Стартап больше похож на американские горки, и предугадать его развитие практически невозможно.”

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

Процесс движения от гипотез к фактам

В данном курсе мы остановились на небольшом количестве гипотез. Если вы будете следовать методологии “Развития потребителей” Стивена Бланка, описанной в книге “4 шага к озарению”, то у вас их будет гораздо больше. Если вы подойдете к процессу более творчески и дотошно, то добавите много своих собственных гипотез. Вы можете озаботиться такими вопросами, как новые пользователи будут узнавать о вашем сервисе, кто эти ваши пользователи и т.д.

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

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

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

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

Если гипотеза не подтвердилась

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

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

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

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

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

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

S1.090-004

В заключении

На этом заканчивается курс “Приемы проектирования сервисов”. Этот курс позволит вам начать систематизировать ваши представления о том, как создаются продукты и какие сложности встанут перед вами в процессе работы над чем-то новым.

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

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

  • “4 шага к озарению” или “Стартап” Стивена Бланка (мне больше нравится первая)
  • “The Lean Startup” Eric Ries
  • “The Lean Analytics” Alistair Croll
  • “Дилемма инноватора”

 



Подписка на рассылку новых материалов

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



Запись опубликована в рубрике Аналитика, Без рубрики, Дизайн / Проектирование интерфейсов, Предпринимательство с метками , , , , , , , . Добавьте в закладки постоянную ссылку.