Как создать продукт, который полюбят

Рис. 3.1. Чем больше размер группы, тем больше «проблем с процессами» в ней возникает. Это требует дополнительных каналов коммуникации и может замедлить принятие решений[67]

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

• Команда из шести человек имеет всего 15 каналов коммуникации.

• Увеличиваем эту цифру до 10 — и нам придется справляться уже с 45 каналами.

• Если мы возьмем команду вроде той, куда я каждый день хожу на работу, — это Tinder, 70 человек, — число связей возрастет до 2415.

Однако необходимость работать с большим числом связей — не единственная проблема больших команд.

Слишком большие группы слишком уверены в себе. Людям кажется, что они могут сделать все быстрее, они склонны «все больше недооценивать время, необходимое на выполнение задачи». В 2010 году ученые Пенсильванского университета, Университета Северной Каролины в Чапел-Хилл и Калифорнийского университета в Лос-Анджелесе, изучавшие организационное поведение, провели ряд исследований, подтверждающих это мнение[68]. В одном из экспериментов команды получили задание собрать конструкцию из набора лего. Команды из двух человек справились за 36 минут, тогда как командам из четырех человек потребовалось на 44 процента больше времени.

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

Это яркий пример того, почему правило двух пицц отлично работает.

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

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

Всем нравятся совещания по продукту. Особенно если это этап принятия решения о том, что именно предстоит создавать.

Даже Стиву Джобсу нравилось принимать участие в этом этапе. «Однажды он сказал мне, — говорит Гленн Рейд, бывший директор по разработке приложений для потребителей в Apple, — что одна из причин, по которым он хотел быть CEO, — то, что никто не мог ему запретить присутствовать при создании продукта»[69].

Ведите себя так, будто вы работаете вышибалой в известном берлинском клубе «Бергхайн»[70]^, [71]. (Подсказка: вряд ли у вас получится, если вы не говорите по-немецки. К тому же тамошний охранник Свен, «постапокалиптическая версия Вагнера», диктует такой дресс-код, который вряд ли кому-то удастся изменить.)

Итак, кто в вашей команде? Что они знают о том, с какими проблемами вам пришлось столкнуться? И как вы организуете обсуждение?

На этом этапе у вас уже должен быть список всех, кто будет работать в команде над созданием продукта. Например:

• Продуктовый дизайнер или менеджер продукта (зависит от того, как устроена ваша компания и будете ли вы привлекать для создания продукта кого-то еще).

• Разработчик или разработчики, с которыми вы будете работать над созданием продукта, — обычно это фронтенд и бэкенд.

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

Итен Ша во время работы в KISSMetrics укомплектовывает такие команды…

…менеджером продукта, дизайнером и разработчиком. Иногда это несколько дизайнеров, несколько разработчиков, а иногда — менеджер команды разработчиков.

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

ВЕЧЕРИНКА В СТИЛЕ ДЕВЯНОСТЫХ