И вот в среду наступил момент, когда Оскару надо было принять решение.

– Полагаю, что этот вопрос мы должны решить все вместе, – сказал он, – мы же команда.

Всем эта идея страшно понравилась, и было проведено голосование. В результате команда выбрала не то решение, которое больше всего нравилось Оскару. Позднее оно хорошо себя зарекомендовало во время тестирования в пятницу, и в целом «спринт» прошел успешно. Так мы думали до тех пор, пока пару недель спустя нам не довелось еще раз пообщаться с Оскаром.

– В общем, тут такое дело… – Генеральный директор почесал в затылке. Он выглядел смущенным. – Я еще раз хорошенько все продумал… и решил, что, пожалуй, мы будем двигаться в другом направлении.

– Давайте угадаю, – предложил Джон. – Вы решили вернуться к той идее, которая была вам по душе во время «спринта».

– Ну да, – признался Оскар.

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

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

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

Окончательное решение принимается во время финального голосования. У каждого Распорядителя есть три особых голоса (на круглых стикерах должны быть проставлены его инициалы!). Решение, выбранное Распорядителем, и будет положено в основу прототипа, который предстоит тестировать в пятницу.

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

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

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

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

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

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

Но тут есть одна проблема. Поскольку у каждого Распорядителя имеется по три голоса и иногда Распорядителей бывает двое, победить в суперголосовании может не один набросок решения, а больше. Что делать, если эти решения конфликтуют друг с другом? И как поступить, если лежащие в их основе идеи не могут быть реализованы в рамках одного прототипа? Об этом вы узнаете из следующей главы.

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

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

Стюарт – опытный предприниматель, известный своей незаурядной интуицией. После неудачи с игрой Glitch именно интуиция подсказала ему создать Slack. А 10 годами ранее Баттерфилд, опять же к ней прислушавшись, запустил фотохостинг Flickr. Нужно ли говорить, что мнение генерального директора очень весомо? А вот Мёрси, менеджер по продукту, обеспокоена тем, что анимированные компьютерные персонажи еще больше запутают клиентов. Ее смущает и другое обстоятельство: инженерам-программистам потребуется ориентировочно от 4 до 6 месяцев, чтобы качественно воплотить эту идею.