Пользовательские истории. Искусство гибкой разработки ПО

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

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

• Тщательно разработайте прототип, который выглядит совсем как настоящее приложение, и неважно, что он не выполняет того, чего хотят заказчики и пользователи. Зато, лишь увидев этот прототип, они тут же вскричали: «Как классно он выглядит!»

• Убедите себя, а затем и всех остальных, что тщательного исследования и профессионального дизайна достаточно для того, чтобы решение работало. В конце концов, вы строго придерживались дизайнерского процесса. Что может быть не так?

• Не беспокойтесь о стоимости реализации решения. Решение безоговорочно верное, и любая стоимость разработки оправданна.

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

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

Короткие циклы с эмпирическим обучением

Эрик Райс – автор книги под названием «Стартап по методологии Lean»[29]. В этой книге Эрик рассказывает, как он угодил в ловушку, описанную мной ранее под названием «старые недобрые времена». Он участвовал в создании продукта, который собиралась выпустить его компания, в качестве технического директора. Успешность продукта не вызывала сомнений ни у кого, кроме заказчиков и конечных пользователей. Встречались положительные отзывы, отрицательные отзывы, явное безразличие. Компания, конечно, ожидала совсем не такого результата.

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

Ценнейший вклад Эрика Райса в разработку программных продуктов – это упрощение и продуцирование такого способа мышления в короткую мантру «создание – обратная связь – извлечение опыта». Эрик подчеркнул, что времени на прохождение этого короткого цикла изучения требуется относительно немного. В традиционном процессе проектирования, как правило, затрачивается очень много времени на фазу исследования и дизайна – так много, что в конце концов вы привыкаете к решениям и не можете проверить, приводят ли эти решения к тем результатам, на которые вы рассчитывали. Если в традиционном дизайнерском процессе, как правило, требуются недели или месяцы на подтверждение верности идеи решения, то в процессе Lean Startup это, как правило, занимает всего несколько дней.