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

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

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

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

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

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

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

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

Закон Паркинсона

Руководители знают, что разработка программного обеспечения идет в соответствии с законом Паркинсона: работа заполняет все время, отпущенное на нее, увеличиваясь в объеме. Если вы работаете в сфере разработки ПО, то вам, скорее всего, известно и следствие из этого закона, которое называют «правилом 90/90» (автором этого правила считают Тома Каргилла из Веll Labs): «Первые 90 % кода занимают первые 90 % времени разработки. Остальные 10 % кода занимают вторые 90 % времени разработки». Это уничижительное правило просто-напросто говорит, что даже в тот момент, когда первые 90 % кода написаны, программистам по-прежнему неизвестно, в какой стадии находится проект! Руководство прекрасно знает, что сдать проект в срок не получится, какие бы сроки ни были установлены. А учитывая то, что программисты наиболее продуктивно работают под давлением, руководители применяют дедлайн как один из рычагов воздействия на них.

В 1980-е и 1990-е годы вице-президентом по разработке в небольшой, но достаточно влиятельной компании под названием Т/Maker был Ройял Фаррос. Он говорил так: «Многие из нас устанавливали настолько жесткие дедлайны, что в них было заведомо невозможно уложиться. Такая ситуация лишний раз подтверждала одно из следствий закона Паркинсона: „Этап завершения проекта разработки требует в два раза больше времени, чем планировалось“. Я пребывал в твердом убеждении, что, если установить дедлайн, например, через шесть месяцев, на самом деле это займет год. Таким образом, если нужно было получить продукт через два года, дедлайн надо было устанавливать на один год. Такие сроки просто огорошивали, но метод срабатывал всегда».

Риджли Эверс, предприниматель в сфере разработки программного обеспечения, работая в Intuit над созданием QuickBooks, наблюдал ту же проблему. «Первая версия QuickBooks должна была выйти спустя девять месяцев. Мы правильно решили, что период разработки будет длиться столько же, сколько беременность, правда, кое в чем слегка ошиблись: срок подготовки проекта составил почти два с половиной года – как беременность слона».

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

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