Страница 33 из 86
При разработке второго прототипа iPhone мы столкнулись с целым рядом новых проблем - мы не смогли правильно разработать конструкцию. Антенны, GPS, камеры, терморегуляторы. Мы никогда раньше не создавали мобильных телефонов, не говоря уже о смартфонах, и наши предположения оказались ошибочными. И снова.
Перезагрузка. Начать сначала.
Рис. 3.5.2
Эта модель iPod-телефона на самом деле не была нашей - она поступила от производителя, до которого дошли слухи о том, что мы работаем над телефоном, и он хотел предложить нам свою идею. Это странное устройство демонстрирует невозможность создания телефона на базе колесика. Верхняя половина поворачивается на 180 градусов, чтобы можно было использовать экран для набора номера или отправки СМС - в общем-то, неплохая идея, но это не iPhone.
Только в третьей версии мы достаточно хорошо разобрались во всех деталях, чтобы создать правильное устройство V1.
Но мы никогда бы не дошли до третьего проекта, если бы не поставили себе жесткие сроки в первых двух - если бы не оборвали себя через несколько месяцев, не перезагрузились и не пошли дальше.
Мы наложили на себя как можно больше ограничений: не слишком много времени, не слишком много денег, не слишком много людей в команде.
Последнее замечание очень важно.
Рис. 3.5.3
Мы провели много времени, играя с различными концепциями, и эти безумные пластиковые плиты были получены в ходе испытаний ранних форм-факторов. Они позволили нам увидеть, как наши идеи будут ощущаться в руках, карманах и сумочках, когда мы пытались понять, что имеет смысл, а что нет.
Не нанимайте людей только потому, что это возможно. В большинстве проектов, находящихся на стадии разработки концепции, можно многое сделать, имея в штате около десяти человек или даже меньше. Вы же не хотите набрать штат, а потом оказаться вынужденным разрабатывать проект по принципу "комитета", или заставить кучу людей сидеть в сторонке и ждать, пока вы сами все придумаете.
К концу первого проекта iPhone над ним работало около восьмисот человек. Но представьте себе, что было бы, если бы все восемьсот человек были с нами с самого начала и наблюдали, как мы отказываемся от задуманного и начинаем проект заново? А затем повторили бы это через несколько месяцев? Это был бы хаос. Восемьсот человек в панике, а мы бесконечно успокаиваем всех, концентрируемся на позитиве, пытаемся синхронизировать всех этих людей с поистине безумным количеством итераций.
Поэтому сохраняйте проект небольшим, пока это возможно. И не выделяйте слишком много денег на начальном этапе. Люди делают глупости, когда у них есть гигантский бюджет, - они слишком много проектируют, слишком много думают. Это неизбежно приводит к удлинению взлетно-посадочных полос, увеличению сроков и замедлению сердцебиения. Намного, намного медленнее.
Как правило, срок поставки нового продукта не должен превышать 18 месяцев, в крайнем случае - 24. Оптимальный срок - где-то между 9 и 18 месяцами. Это относится к аппаратному и программному обеспечению, атомам и битам. Конечно, есть вещи, которые требуют больше времени - например, исследования могут занимать десятилетия. Но даже если на изучение вопроса уйдет десять лет, регулярные проверки по ходу дела позволят вам быть уверенным в том, что вы все еще ищете правильный ответ. Или задавать правильные вопросы.
Каждый проект нуждается в "сердцебиении".
До запуска V1 это сердцебиение полностью внутреннее. Вы еще не общаетесь с внешним миром, поэтому у вас должен быть сильный внутренний ритм, который подталкивает вас к установленной дате запуска.
Этот ритм складывается из основных вех - заседаний совета директоров, совещаний всех сотрудников или вех проекта в определенные моменты разработки продукта, когда все - и инженеры, и маркетологи, и продавцы, и служба поддержки - могут сделать паузу и синхронизироваться друг с другом. Это может происходить раз в несколько недель или раз в несколько месяцев, но это необходимо для того, чтобы все двигались в ногу с внешним объявлением.
И для того, чтобы поддерживать ритм проекта, каждая команда должна выпускать свои собственные результаты в своем темпе. Сердцебиение каждой команды может быть разным - это могут быть шестинедельные спринты, еженедельные обзоры или ежедневные контрольные встречи. Это может быть scrum, waterfall или kanban - любая организационная структура или подход к управлению проектами, который вам подходит. У творческой команды сердце будет биться совсем иначе, чем у инженерной; у компании, производящей аппаратное обеспечение , ритм работы команды будет медленнее, чем у компании, занимающейся только перемещением электронов. Неважно, каков этот ритм, ваша задача - поддерживать его на должном уровне, чтобы команда знала, чего от нее ждут.
Я научился этому в компании Philips, когда мне впервые пришлось создавать сердцебиение с нуля.
Когда мы начинали, вся команда была довольно молодой и не имела опыта управления проектами, поэтому мы наняли консультантов, которые помогли нам составить график. Они предложили разбить наши задачи на полдня. Команда оценила, сколько полудней потребуется для выполнения каждой части проекта, и мы разбили все месяцы, недели и дни, необходимые для выполнения каждой задачи. Затем мы составили подробные графики на 12-18 месяцев вперед с учетом индивидуальной загрузки каждого.
Это казалось вполне разумным. Мы одобрительно кивали консультантам. Отлично! У нас есть реальный график! Возможно, мы и вправду справимся! Пока мы не поняли, что:
Никто не может точно оценить свое время или все действия, которые ему придется выполнить.
Пытаться вникать в детали на таком большом расстоянии бесполезно. Что-то всегда испортит ваш план.
Мы тратили все свое время на составление расписания, спорили о том, что можно сделать за полдня, а что нет, и невозможно было увидеть весь лес сквозь полдерева.
Каждый раз, когда продукт менялся и эволюционировал, мы впадали в ступор. Вместо того, чтобы просто разобраться с изменениями, мы вынуждены были требовать от всех, чтобы они сказали нам, сколько полдня им потребуется для того, чтобы справиться с изменениями. Каждую неделю мы тратили часы на то, чтобы "проработать график" с каждым членом команды, вместо того чтобы действительно работать.
Через несколько месяцев мы отказались от этой системы. Больше никаких половинчатых дней. Мы разделили свое время на более крупные куски - недели, месяцы. Мы начали смотреть на наши проекты с макросъемки. И это позволило нам создать V1 Velo примерно за восемнадцать месяцев. Затем мы передали его, сверкающего и нового, в отдел продаж и маркетинга.
И они совершенно не знали, что с ним делать. Они никогда не видели его раньше. Они не знали, как его продавать, где его продавать, как его рекламировать. Они были на втором плане для нас, а теперь мы были на втором плане для них.
Мы выяснили, что у нас есть свой внутренний пульс, но никогда не синхронизировали его с другими командами. Никто не мог угнаться за нашим ритмом. Мы танцевали под свой ритм, уверенные, что все внимание приковано к нам, а наш партнер по танцам в другом конце комнаты получает пунш и думает об электробритвах.
Нам нужны были внутренние вехи в рамках проекта - регулярные контрольные встречи, на которых мы должны были убедиться, что все понимают, как развивается продукт, и могут развивать свою часть бизнеса вместе с ним. И чтобы убедиться, что продукт по-прежнему имеет смысл. Убедиться, что он по-прежнему нравится маркетингу. Понравился ли он продажам. Чтобы убедиться, что служба поддержки по-прежнему может его объяснить. Убедиться, что все знают, что именно они производят, и каков план запуска этого продукта.
Эти этапы замедляют работу в краткосрочной перспективе, но в конечном итоге ускоряют всю разработку продукта. К тому же они делают продукт лучше.