Книга Спринт. Как разработать и протестировать новый продукт всего за пять дней, страница 1. Автор книги Джон Зерацки, Брейден Ковитц, Джейк Кнапп

Разделитель для чтения книг в онлайн библиотеке

Онлайн книга «Спринт. Как разработать и протестировать новый продукт всего за пять дней»

Cтраница 1
Спринт. Как разработать и протестировать новый продукт всего за пять дней
Спринт. Как разработать и протестировать новый продукт всего за пять дней

* * *

Моей маме, которая помогала мне строить замки из картона, и Холли, которая всегда была готова заехать за мной, когда я умудрялся сесть не в тот автобус.

Джейк

Моему деду Гиббу, который купил бы первые пятьсот экземпляров этой книги.

Джон

Моим родителям, вдохновлявшим меня совершать открытия и делать мир лучше.

Брейден
От автора

То, как я работал, не работало.

В 2003 году у нас с женой родился первый ребенок. Когда пришла пора возвращаться на службу, мне хотелось лишь одного – чтобы время, проводимое мною в офисе, было столь же плодотворным и значимым, как и то, что я посвящал семье. Подвергнув свой рабочий метод тщательной ревизии, я с удивлением обнаружил, что затрачиваю на решение самых важных задач не так уж и много сил.

Я принялся за оптимизацию. Читал книги по повышению эффективности труда. Составлял многочисленные таблицы, пытаясь понять, что и как мне нужно делать, чтобы работать наиболее продуктивно: делать зарядку с утра или в обед, пить кофе или чай… Целый месяц посвятил экспериментам с пятью различными способами планирования. Соглашусь, выглядело это странно. И все же, шаг за шагом, я добивался своего, становясь все более собранным и организованным.

В 2007 г. я начал работать в Google. Для человека, повернутого на трудовой активности, здесь была создана идеальная среда. В Google с готовностью поощряют любые эксперименты – и не важно, связаны ли они с продукцией компании или с методами, которые выбирают для себя ее сотрудники, будь то отдельный человек… или целая команда.

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

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

Я внимательно изучил все результаты и обнаружил нечто удивительное: идеи, которые компания брала на вооружение и которые оборачивались успехом, были сгенерированы как угодно, но только не нашим «выкрикни-как-можно-громче» методом. Лучшие же из них так и вовсе исходили из совершенно других источников. Но вот из каких именно?

Сотрудники, не «прикрепленные» к той или иной команде, работали так же, как и всегда, – обдумывая свои идеи на рабочем месте, в кафе и даже в душе. И то, что выходило у них, было лучше того, что получалось у нас. Мозговые штурмы не давали ничего, кроме радостного возбуждения – а когда оно проходило, вдруг оказывалось, что порожденные в результате идеи абсолютно неконкурентоспособны.

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

Я сравнил мозговые штурмы с собственной ежедневной работой в Google. И вот что выяснилось: чем сложнее была поставленная передо мною задача и чем меньшим временем на ее решение я располагал, тем лучше оказывались результаты.

Один из таких проектов имел место в 2009 году. У одного из разработчиков Gmail, Питера Балсигера, родилась идея автоматической организации электронной почты: чтобы входящие сообщения можно было маркировать как «приоритетные». Мне эта задумка, получившая впоследствии название «Priority Box», показалось потрясающей, и я предложил другому разработчику Google, Энни Чен, вместе заняться ее реализацией. Энни согласилась – но только при условии, что работа займет не больше месяца: если за это время проект не сможет доказать свою состоятельность, она переключится на что-нибудь другое. Я был уверен, что месяца будет мало, но, приняв во внимание, насколько великолепным специалистом является Энни, все же решил рискнуть.

Мы разделили месяц на четыре временных отрезка – каждый длиной в одну рабочую неделю. Сначала мы разрабатывали модель, затем Энни и Питер создавали прототип, и уже к концу недели пользователи (немного, не больше двух-трех сотен) его тестировали.

В результате через месяц у нас получилось то, что люди поняли и чем они захотели пользоваться. Энни продолжила работать над «Priority Box», возглавив проект. Я же извлек важный и полезный урок: оказывается, можно успеть все придумать и протестировать за рекордный промежуток времени.

Еще через пару месяцев я отправился в стокгольмское отделение Google, чтобы встретиться с Сержем Лашапелем и Микаэлем Другге: мы обдумывали идею создания приложения для видеоконференций, которым можно было бы пользоваться прямо в веб-браузере. Времени в нашем распоряжении имелось немного – уже через несколько дней мне нужно было возвращаться домой, – а потому работать приходилось максимально быстро. Функционирующий прототип был готов уже к концу моей шведской командировки. Мы разослали его коллегам, а чуть позже стали использовать для собственных нужд. Через несколько месяцев с нашим приложением работала уже вся компания (а еще позже – и весь мир: после внесения необходимых усовершенствований и наведения лоска оно было выпущено под названием Google Hangouts).

Эти два случая ясно показали мне: ежедневная рабочая рутина может быть куда эффективнее сколь угодно мощного мозгового штурма. Но почему?

Во-первых, у нас имелась возможность спокойно поразмыслить над идеей самостоятельно, а не соревноваться в громкости, выкрикивая первое, что пришло на ум. Что же касается времени, то его было вполне достаточно, но при этом не слишком много. Маячившие на горизонте дедлайны заставляли сосредоточиться на решении конкретных задач. Я не мог позволить себе тратить драгоценные часы и дни на бесконечное пережевывание в уме одних и тех же деталей или на другую, менее важную работу – в общем, на все то, чем обычно наполнены мои трудовые будни.

Вход
Поиск по сайту
Ищем:
Календарь
Навигация