Часть II. Цена слишком высока

3. Пустые растраты

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

Управление дедлайнами

В Кремниевой долине сложились некоторые навязчивые устои касательно времени вывода продуктов на рынок. Существует распространенное предположение, что выпустить продукт прямо сейчас гораздо лучше, нежели сделать это позже. Такая устоявшаяся необходимость служит оправданием нереалистичным амбициозным срокам сдачи и выгоранию сотрудников, занятых в проекте, но на деле это лишь прикрытие, отвлекающий маневр, за которым скрываются намного более серьезные и глубокие страхи. Любому предпринимателю прекрасно известно, что вывести на рынок раздражающий и расстраивающий пользователя продукт спустя три месяца от начала его разработки ничуть не лучше, чем выпустить приятный пользователю продукт спустя шесть месяцев.

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

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

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

Как выглядит «завершенный» продукт?

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

Описания бывают двух типов. Мы можем либо подробно описать физический вид требуемого продукта, либо обозначить, какова будет ожидаемая реакция пользователя на конечный продукт. Так, в сфере строительства и архитектуры план является таким документом, который удовлетворяет условиям первого типа описаний. Если же речь идет о съемке нового фильма или открытии ресторана, в своем описании мы фокусируемся на тех эмоциях и ощущениях, которые должен испытать посетитель. Проектируя программы и продукты на их основе, нам обязательно следует прибегнуть к совмещению обоих типов описаний.

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

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

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

Без подобных планов создатели программ оказываются лишенными ясного понимания, что считать готовым продуктом, поэтому они назначают приблизительную дату завершения, а когда она наступает, просто объявляют продукт готовым. Наступило первое июня? Значит, продукт готов. «Запускаем!» – говорят они, и дедлайн становится единственной контрольной точкой степени завершенности продукта.

Разумеется, программисты и предприниматели далеко не дураки, оттого продукт не получится слишком уж оторванным от реальности. У него будет широкий набор функций, и работать он станет стабильно и без сбоев. Он даже начнет прекрасно справляться с задачами, если окажется в руках людей, сильно заинтересованных в том, чтобы так оно и было. Может статься даже так, что продукт проходил юзабилити-тестирование, при котором группа добровольцев пытается выполнять на нем задачи под наблюдением специалистов по юзабилити. Но так как количество предпринятых разумных мер предосторожности этим ограничивается, мы все еще не можем с большой долей вероятности ответить на вопрос, будет ли продукт успешным.