Почему Vox.com был создан за 9 недель, а не месяцев?

Можно по-разному относиться к Vox.com, но тот факт, что они за короткое время сумели заставить профессиональное сообщество говорить и спорить о себе, вызывает уважение.

А теперь давайте вспомним хронологию событий.

Эзра Кляйн и его команда объявили об уходе из The Washington Post 21 января. То, что они уходят в Vox Media, стало известно 26 января. Сайт Vox.com открылся 6 апреля. То есть прошло чуть больше двух месяцев, за которые был создан новый ресурс.

Это довольно быстро, если говорить про традиционные медиакомпании, которые часто могут по паре месяцев решать, какого вида доску купить для комнаты совещаний.

Но если мы говорим о современных стартапах, которые сегодня устанавливают стандарты, то такие сроки вполне оправданы.

Об этом говорит Эрик Райс:

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

Майкл Ловитт из Vox Media написал большой материал о том, как команда Vox.com работала над проектом, как им удалось сделать ресурс за такой относительно короткий срок.

Майкл Ловитт, Vox Media:

— Мы сделали Vox.com за девять недель. За это время мы спланировали, придумали, нарисовали, спрограммировали, протестировали и вышли в эфир. Для сравнения, The Verge (другой проект Vox Media, — ред.) был запущен за восемь месяцев.

Запустив первую версию сайта через шесть месяцев после старта работ, мы, по сути, только начали по-настоящему доделывать проект.

Мелисса [Бэлл] предложила термин «привести в действие» вместо «запуск». Именно так мы описывали то, что происходило с проектом. Мы приводили его в действие, выпуская обновления чуть ли не каждый день. Наша задача была постоянно дорабатывать и совершенствовать продукт. Мы планировали «по-быстрому облажаться и быстро исправить все ошибки».

Прежде чем начать работу над быстрым запуском Vox.com, нам нужно было решить одну проблему: как обеспечить редакции возможность готовить материалы, не дожидаясь запуска.

Когда мы работали над The Verge, для этих целей был создан простенький временный сайт на WordPress с названием This Is My Next. На нём наши авторы оттачивали все редакционные процессы, публиковали контент и работали с аудиторией. С Vox.com мы столкнулись с аналогичной задачей: как обесепечить редакции возможность делать контент, пока мы разрабатывали сайт.

Сначала мы планировали так же создать некий временный ресурс. А сам Vox.com запустить позже. Но когда мы начали обдумывать, сколько времени нам потребуется на создание такого ресурса, мы спросили себя: а, может быть, за это время мы успеем сделать полноценный продукт?

Мы планировали запустить Vox.com в конце 2014 года, но, посмотрев на то, каких успехов мы добились, совершенствуя Chorus (система управления контентом от Vox Media, — ред.) во время перезапуска The Verge, мы пересмотрели сроки. Сегодня система Chorus развилась до такого уровня, что позволяет нам относительно быстро создавать полнофункциональные сайты, «навернув» на неё дизайн. Кроме того, система является достаточно гибкой, чтобы мы могли приспособить её под наши новые идеи.

Чему может научить такой подход?

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

Во-вторых, мы не должны бояться потерпеть начальную неудачу, даже если наш продукт очень важен для аудиории (особенно, это касается всевозможных редизайнов и перезапусков).

В-третьих, важно не раздувать команду, важно чётко определять задачи и не раздувать сроки их исполнения.

В-четвёртых, не обязательно сразу же выпускать готовый проект; можно и нужно выпустить первую версию с минимально необходимым функционалом, давая возможность редакционной команде делать контент, а разработчикам дорабатывать функционал и отлавливать баги в реальных рабочих условиях, а не при тепличном внутреннем тестировании.

В-пятых, нужно объединять редакционную команду и команду разработчиков сразу же, как только мы начинаем работу над проектом; чтобы не получилось, как в басне «Лебедь, рак и щука».

В-шестых, нужно внимательно посмотреть на то, что у вас уже есть, что можно эффективно использовать в проекте, которым вы занимаетесь сейчас; не нужно изобретать велосипед.

В-седьмых, нет ничего невозможного и не стоит заранее усложнять то, что не является таким уж и сложным, даже если весь опыт других проектов говорит об обратном; технологии развиваются очень быстро: что было невозможно или сложно осуществимо ещё шесть месяцев назад, сегодня можно сделать своими руками.