Книга: Спринт: Как разработать и протестировать новый продукт всего за пять дней
10. Выбор решения
Нам всем знакомы подобные совещания. Они тянутся бесконечно долго, обсуждение постоянно перескакивает с темы на тему, и участники лишь понапрасну тратят время и силы. В результате часто принимаются решения, которые никому не нравятся, или хуже того, до решения дело вообще не доходит. Мы не антропологи, но у нас накопилась масса наблюдений относительно контрпродуктивного поведения людей в офисной среде (да и сами мы не раз вели себя подобным образом). Если пустить все на самотек, то обсуждение часто идет по такому сценарию:
Конечно же, это преувеличение, но не такое уж и сильное. Может быть, вы тоже попадали в подобные ситуации. Кто-то предлагает решение, на него обрушивается шквал критики; бедняга пытается пояснить детали, но тут у кого-то другого появляется новая идея:
Такого рода обсуждения производят удручающее впечатление. Краткосрочная память и количество энергии, которые люди в состоянии направить на принятие решения, весьма ограничены. Когда мы перескакиваем от варианта к варианту, нам трудно удерживать в голове важные детали. Если обсуждение какой-либо идеи продолжается слишком долго, то мы просто устаем – и чувствуем себя как судья на конкурсе кулинаров, которому предстоит попробовать массу блюд, а он уже объелся яблочным пирогом.
Если мы хотим извлечь пользу из мнений всех присутствующих, то зачастую оказываемся вынужденными смириться с подобным способом обсуждения. Но только не во время «спринта». В среду мы специально структурируем день таким образом, чтобы одновременно заниматься только одним делом – и сделать его хорошо. Сначала мы фокусируемся на оценке имеющихся набросков решений, затем – на их критике, и наконец, делаем окончательный выбор. Выглядеть это должно примерно так, как показано на рисунке далее.
Ваша задача в среду утром – определиться, какие из вариантов решений должны в итоге превратиться в прототипы. Наш девиз в этот момент: «Не естественно, зато эффективно». Вместо того чтобы предаваться дискуссиям, не имеющим ярко выраженной цели, обсуждение в группе будет организовано по строго определенному сценарию. С точки зрения традиционного общения такой формат обсуждения окажется не слишком комфортным – но если по ходу вы действительно почувствуете себя Споком из «Стартрека», разрывающимся между своей эмоциональной человеческой половиной и строгой вулканской дисциплиной, значит, вы все делаете правильно. Сценарий сконструирован таким образом, чтобы получить максимум отдачи от профессиональных знаний членов команды, учесть свойственные им сильные и слабые стороны и по возможности облегчить окончательный выбор.
Чтобы продемонстрировать, как в среду должна выглядеть работа команды, мы воспользуемся примером еще одного стартапа. Сейчас эта компания разрабатывает программное обеспечение для управления предприятиями, но первоначально у нее была совсем иная специализация. Ее первым продуктом стала видеоигра под названием Glitch («Сбой в системе»).
В Glitch может одновременно играть множество людей, но никаких боевых действий друг против друга они не ведут. Наоборот, там поощряется сотрудничество, все участники должны совместно решать проблемы и общаться. К сожалению, эта необычная игра, в которой акцент делается на сотрудничестве, так и не стала популярной среди широкой аудитории (возможно, это многое говорит об обществе, в котором мы живем).
Когда стало очевидно, что Glitch не станет хитом продаж, компания предприняла нечто экстраординарное. Вместо того чтобы заняться новой игрой или закрыться, она перенесла свои усилия на доработку мессенджера, который прежде использовался исключительно для общения сотрудников внутри самой компании. Ее основатель Стюарт Баттерфилд интуитивно почувствовал, что мессенджер может оказаться полезным и для других фирм. Новый продукт вышел на рынок под названием Slack.
Компании, работающие в области высоких технологий, встретили его с восторгом. Уже через год мессенджером пользовались 500 000 сотрудников более чем 60 000 компаний. Для программного обеспечения, ориентированного на использование в офисе, это был неслыханный успех. Когда разработчики Slack заявили, что их софт является самым быстро набирающим обороты приложением для бизнеса за всю историю, специальные издания охотно с ними согласились.
Популярность мессенджера росла чрезвычайно быстро, но, как это часто бывает, Slack столкнулся с рядом проблем. Чтобы продолжать расширяться, разработчику следовало научиться объяснять преимущества своего продукта более широкому кругу клиентов. Это не так легко, как может показаться. На первый взгляд, идея приложения достаточно проста: это корпоративный мессенджер. Но в реальности все гораздо сложнее.
Slack приобрел такую популярность, потому что он меняет привычные подходы к организации рабочих процессов. Использующие его члены команды обычно начинают с того, что отправляют друг другу моментальные сообщения. Затем они постепенно отказываются от электронной почты. Но Slack предназначен не только для общения один на один. Когда сотрудники переходят на этот мессенджер, они получают возможность пользоваться чатами и общаться в группах. Вскоре Slack многим заменяет даже беседы по телефону. Члены команды используют специальное приложение для управления проектами. Они подключают к Slack другое программное обеспечение и электронные сервисы, получая таким образом доступ к служебной информации в целом. Slack становится той осью, вокруг которой крутится вся работа. Как отмечает один из репортеров газеты The New York Times, использующий данный мессенджер: «У меня возникло чувство, что я стал гораздо ближе к своим коллегам, которые находятся на другом конце страны, и мне это нравится. Для работы это очень важно».
Но как объяснить потенциальным клиентам, что именно делает Slack? Чем этот мессенджер отличается от других, более привычных, и в чем состоят его преимущества? Это действительно трудная задача. Разобраться в проблеме поручили команде, которую возглавляла Мёрси Грейс, только что приступившая к работе в должности менеджера по продукту. Мёрси решила начать со «спринта», а поскольку Google Ventures является одним из инвесторов, она пригласила нас в нем поучаствовать.
В «спринт» – команду вошли сама Мёрси, два дизайнера, инженер, маркетолог и несколько представителей Google Ventures. К утру среды все шло точно по графику. В нашем распоряжении оказалась дюжина набросков, развешанных по стеклянным стенам офиса при помощи синего скотча.
Мы молча передвигались по комнате, в первый раз рассматривая эскизы, созданные участниками команды. На одном из них был представлен пример хорошо известной компании, уже применяющей Slack; в другом было использовано видео с анимацией; третий имел вид презентации, снабженной комментариями. Абсолютно все идеи оказались разными, и у каждой имелся свой потенциал. Нам предстоял трудный выбор.
К счастью, не было никакой необходимости делать этот выбор немедленно. С помощью маленьких круглых стикеров мы обозначили те элементы, которые показались нам наиболее интересными. Через несколько минут почти на каждом наброске красовалось по нескольку стикеров. Закончив эту работу в полной тишине, мы собрались вместе, чтобы по очереди обсудить каждый из набросков. Мы следили за тем, чтобы дискуссия была короткой, и фокусировались только на тех элементах, которые были отмечены стикерами. Мы также включили таймер.
Понадобилось немногим менее часа, чтобы обсудить все имеющиеся эскизы. Затем каждому «спринтеру» выдали розовые круглые стикеры для участия в голосовании. Несколько минут размышлений, и мы все молча проголосовали, прикрепив свои стикеры к тем из набросков, которые считали нужным воплотить в виде прототипа и протестировать.
После короткой дискуссии мы обратились к Распорядителям: Мёрси и Стюарту, генеральному директору, который ненадолго присоединился к нам, чтобы высказать свое мнение. Они еще раз взглянули на розовые стикеры, пару минут подумали и тоже отдали свои «суперголоса». Решение было принято – без всяких продолжительных дебатов и агитации за тот или иной вариант.
В «спринте», проводившемся в компании Slack, было представлено около дюжины различных вариантов решений, причем все они без исключения выглядели достаточно перспективными. Каждый участник считал собственную идею наиболее эффективной. И каждый мог легко отнять у нас как минимум час, приводя уйму доводов в поддержку своего варианта. Но если бы мы действительно захотели потратить по часу на обсуждение каждой идеи, то на это мог уйти весь день. И еще не факт, что в результате было бы принято окончательное решение.
Поэтому мы предпочитаем следовать сценарию «спринта», который позволяет проводить критику набросков и делать окончательный выбор максимально эффективно. В среду к обеду мы уже точно знали, какие идеи будем тестировать.
- 2. Выбор технического решения
- Глава 8. Ролевой анализ принятия решения о покупке
- Решения о выборе стимулов
- 2 Выбор ниши
- 11.2. Технология принятия решения в условиях чрезвычайной ситуации
- Управление пользователями и разрешениями узла
- Как не запутаться в разрешениях доступа к файлам?
- «Если бы у вас была волшебная палочка, что бы вы сделали для решения проблемы?»
- Приложение 2. Досье на лицо, принимающее решения (ЛПР)
- О решениях IBM Service Management
- Шаг 5. Работа с вопросами, сомнениями и возражениями покупателя. Помощь в принятии решения о покупке
- 3.5. Разрешения IPC