После того как у всех нас появилось одинаковое представление о пользователях программного продукта и о проблемах, на которых мы концентрируемся, можно предположить, каковы будут возможные решения. Мы снова используем принципы дизайнерского мышления – выдвигаем и рассматриваем несколько независимых решений, но стараемся как можно быстрее прийти к соглашению о том, какое решение будет самым лучшим. Иногда одно решение выбрать не получается и приходится брать в работу несколько. Не следует переоценивать важность этого этапа, так как, очевидно, мы в любом случае делаем какие-то ошибки.
Определите рискованные предположения
Поскольку мы выдвинули немало догадок о наших пользователях и их сегодняшних проблемах, давайте явно назовем эти догадки. В частности, потребуется совместная работа по составлению списка того, что мы считаем соответствующим истине, но если окажется, что это не так, придется переделывать все заново.
То же самое нужно сделать в отношении нашего решения. Следует подумать, какой реакции на него мы ожидаем от своих пользователей и как, по нашему мнению, они будут использовать это решение. Мы формируем в уме какие-то гипотезы о возможных путях взаимодействия пользователей и нашего продукта. Мы также обсуждаем технические риски – то, что может поставить под угрозу реализацию нашего решения.
Имея списки догадок и предположений о заказчиках, пользователях и нашем решении, мы можем выделить самые крупные, по нашему мнению, риски.
Дизайн, реализация и небольшие проверки
Именно здесь заметны наибольшие отличия.
В старые недобрые времена мы планировали и создавали весь продукт целиком. В процессе дизайна прототипировали весь продукт целиком или большую его часть. Следуя подходу Lean Startup, где наша цель – учиться как можно скорее, мы делаем все от нас зависящее, чтобы сделать самый простой и быстрый прототип. Во многих случаях получившееся даже нельзя, строго говоря, назвать прототипом.
Вот пример из жизни моих друзей из некоммерческой организации под названием ITHAKA. Они работали над продуктом под названием JSTOR. Если в последние десять лет вы учились в каком-нибудь американском колледже, то, скорее всего, пользовались JSTOR в библиотеке, чтобы найти статьи или книги для заданного вам реферата.
Студенты, пользующиеся продуктом, хотели бы с легкостью делать это в любом месте – в кофейне, дома, во время путешествия. Но подключиться к JSTOR, находясь вне колледжа, было очень сложно. Нужно было ввести имя пользователя и пароль сети колледжа, так что, сидя где-то в кофейне, студенты должны были авторизоваться и получить доступ ко всем ресурсам, лицензированным университетом. Команда JSTOR уже нашла решение, но использовать его было трудновато. Они хотели проверить новый способ взаимодействия.