Обратите внимание: если люди работают в нескольких локациях, в этом нет ничего плохого — если только компания старается устроить все так, чтобы в каждой из этих локаций команды находились в одном месте.
О том, как мы поступаем, когда людей невозможно посадить в одном месте, подробно поговорим позже.
ЗАДАЧИ И КОМПЕТЕНЦИИ КОМАНДЫ
Итак, мы перечислили основные характеристики продуктовой команды, после чего встает следующий важный вопрос: каковы ее задачи и компетенции? За что именно несет ответственность та или иная продуктовая команда?
Одна из сторон этого вопроса — какой вид работы ей предстоит выполнить? Очень важно, чтобы команда отвечала за всю эту работу — все проекты, функциональные характеристики, исправление ошибок, производительность, оптимизацию и изменение контента, — словом, абсолютно за все, что связано с продуктом, над которым она трудится.
Другая сторона — сфера компетенции. В некоторых типах компаний продуктовая команда отвечает за весь продукт. Но сегодня продукты становятся слишком сложными для одной команды (возьмем хотя бы Facebook или PayPal), поэтому каждая команда отвечает за ту или иную меньшую, но значимую часть пользовательского опыта. Например, вы работаете в команде eBay, отвечающей за технологию обнаружения и предотвращения случаев мошенничества или за инструменты и сервисы для крупных продавцов. Или, скажем, вы сотрудник Facebook, и ваша команда несет ответственность за новостные ленты, приложение для устройств на iOS или функциональные возможности конкретного рынка.
В небольшом стартапе этот вопрос решается легко, ведь в нем обычно трудятся одна-две команды, и распределить задачи и компетенции довольно просто. Но по мере роста компании количество команд увеличивается до двадцати, потом до пятидесяти, а в очень крупных продуктовых компаниях и того больше. Координация их работы существенно усложняется (об этом мы подробнее поговорим далее в разделе «Масштабирование: продукт»), но, к счастью, наша концепция отлично поддается масштабированию — по сути, это один из ключей к масштабируемости.
Есть множество эффективных способов разрезать пирог. Иногда каждая команда занимается тем или иным типом пользователя или клиента; иногда каждая из них отвечает за свой тип устройства. В некоторых случаях распределение базируется на отдельных частях рабочего процесса, или так называемого пути клиента. А иной раз, — по правде говоря, очень часто, — мы определяем сферу компетенции команд, основываясь на архитектуре. Объясняется это тем, что архитектура определяет арсенал технологий, используемых для разработки софта, и часто требует разной технической квалификации и опыта.
