Производство фильмов
Производство фильмов – занятие непомерно дорогостоящее, как и создание программного обеспечения. Голливуд снимает фильмы дольше, чем мы производим программы в Кремниевой Долине, и нам есть чему поучиться у них. Действительно дорогостоящая часть – это непосредственная съемка фильма. Все эти камеры, сцены, техники, актеры ежедневно съедают многие тысячи долларов. Хорошие фильмопроизводители четко контролируют эту стадию и заранее планируют все подробнейшим образом. Тратя время и деньги на создание подробных раскадровок и съемочных расписаний, они экономят кучу времени и денег во время съемок.
Процесс создания фильма можно разбить на три крупных стадии: подготовка, производство, доводка. На стадии подготовки появляется и дорабатывается сценарий, выполняются работы по дизайну, нанимаются актеры и персонал для съемок, находятся инвесторы. На стадии производства зажигаются софиты, включаются камеры, режиссеры выкрикивают указания, актеры играют роли. На стадии доводки происходит монтаж фильма, запись звукового сопровождения и проработка маркетинговой кампании. Эти стадии достаточно хорошо соответствуют стадиям разработки программного обеспечения.
На стадии подготовки руководители занимаются проектированием взаимодействия для продукта, нанимают программистов и находят инвесторов. На стадии производства зажигаются мониторы, компиляторы включаются в работу, руководители выкрикивают указания, а программисты пишут код. На стадии доводки отлаживается код, пишется документация, прорабатывается маркетинговая компания.
Важная особенность этого трехстадийного процесса: подготовка позволяет минимизировать длительность стадии производства. Зеленый свет началу съемок стоит невероятно дорого, поэтому экономия нескольких дней съемки может возместить многие недели работы на стадиях подготовки и доводки. Подготовка к съемке занимает год и более, интенсивные съемки – пару месяцев, а доводка – еще многие и многие месяцы.
Более того, по мере роста технической сложности фильмов (что получится, если скрестить фильм с компьютером?) все меньше остается производственной работы, которую можно выполнить без тщательного предварительного планирования. Если планируется дуэль кинозвезды и созданного на компьютере пришельца на лазерных мечах, эта дуэль будет сниматься на фоне синего экрана и в действительности не состоится, поэтому все действия актера вплоть до мельчайших движений и направления взгляда следует спланировать.
Создатели фильмов знают, что у них будет лишь один шанс сделать все верно, поэтому никогда не забывают о стадии подготовки. В мире компьютерной разработки многие руководители считают, что смогут все починить в следующей версии, поэтому давление в области планирования снижается. Это предположение обходится ужасающе дорого.
Сегодня создавать программы так же сложно, как фильмы, однако процесс разработки по преимуществу игнорирует этот факт. Мне встречаются в основном команды разработчиков, которые тратят несколько дней или недель (максимум) на планирование и проектирование, затем от 6 до 18 месяцев – на программирование, затем всего пару месяцев занимаются отладкой, тестированием и документированием. Подозреваю, нам многому следует научиться у киноиндустрии. Если бы мы больше времени тратили на стадию подготовки, на проектирование, то смогли бы сэкономить массу дорогостоящего времени программистов.
Стадия подготовки в киноиндустрии – самая дешевая. Затраты на создание раскадровки дорогостоящей погони со взрывами и специальными эффектами не очень велики. Чтобы внести радикальные изменения, достаточно ластика, карандаша и какого-то времени. Тщательная детализация на бумаге экономит миллионы в тот момент, когда включается камера, а в автомобили набиваются каскадеры и взрывчатые вещества. Подготовка – это инвестиции во время, которое экономит наличные средства и повышает вероятность успеха.
Если режиссер передумал и хочет взорвать вертолет вместо поезда, то на стадии подготовки сделать это просто и обойдется недорого. Подобные изменения во время съемки практически самоубийственны. Создатели фильмов это знают, а потому не торопятся во время подготовки, а во время производства следуют этим планам.
Для уже существующих продуктов цикл искажается еще больше. Ежегодное обновление возможностей для уже вышедшего на рынок продукта может вообще не оставлять времени на предварительное проектирование. Руководитель разработки продукта просто ведет перечень возможностей, запрошенных клиентами, и каждый год без лишних церемоний вручает этот список программистам.
Как и в случае производства фильмов, стадия тщательного проектирования продукта в процессе разработки может дать огромные преимущества. Создавая на бумаге подробный план для продукта, мы исключаем многочисленные неопределенности в программировании, а также существенно снижаем риски, обычно сопутствующие выпуску продукции, основанной на программном обеспечении.
Руководство должно взять на себя ответственность и включать проектирование в процесс до того, как начато программирование. Если проводить аналогии, проектирование взаимодействия – это архитектура, а не дизайн интерьеров. Проектирование взаимодействия определяет, куда будет залит бетон фундамента, точно так же, как и самый подходящий материал для занавесок или портьер на окна. Проектировщики взаимодействия должны получить моральные полномочия диктовать форму и конституцию продукта программистам. Это приведет к серьезным культурным сдвигам, но после таких перемен программисты станут счастливее, а вы получите выгоды от значительно более совершенного продукта.
В обмен на такую власть сообщество проектировщиков взаимодействия также должно принять определенную ответственность. Во-первых, проектировщики должны войти в число лиц, кровно заинтересованных в исходе игры. Они должны сойти с боковой линии, откуда сейчас дают советы программистам, разрешая тем принять полную ответственность за успех продуктов. Недостаточно просто иметь правильные идеи. Необходимо добиться применения этих идей на практике, и единственный способ это сделать состоит в том, чтобы проектировщики взаимодействия встали ближе к точке риска. Программисты приближаются к этой точке с каждой строкой кода.
Кроме того, проектировщики взаимодействий должны фиксировать свои предложения в письменной форме.
Документируйте замысел, чтобы дать ему жизнь
Один из действительно жестких уроков, которые мне пришлось усвоить за прошедшие годы, таков. Хорошее и даже отличное проектирование бессмысленно, если не воплощается в жизнь. И оно никогда не воплощается в жизнь, не будучи описанным подробно, точно и со всеми деталями, причем в терминах, имеющих смысл для программистов. Описание должно быть письменным, включать исчерпывающие подробности, сопутствующие свидетельства и примеры. Оно должно быть напечатано и переплетено во множестве экземпляров. Его следует лично представить команде разработчиков. Вице-президент разработки в этот момент должен присутствовать, кивать и улыбаться. Еще лучше, если это будет президент компании.
Необходимо, чтобы проектировщики писали, кадрировали, анимировали, прототипировали свои решения настолько полно и подробно, чтобы программисты могли считать эти решения чертежами и писать на их основе код. Необходимо описывать достаточное количество ситуаций, давая разработчикам уверенность в том, что решение достаточно надежно, чтобы дожить до реализации.
Проектирование в письменной форме подобно плану сражения. Каждый знает свою роль, обладает критической и своевременной информацией. Все могут действовать сообща и гармонично, создавая продукт, ориентированный на конкретного пользователя.
Программисты прибегают к довольно действенной «пассивно-агрессивной» тактике. Не вступая в конфронтацию, призванную разрешить вопрос, они избегают внимания к нему и втихую предпринимают – или не предпринимают – определенное действие. Как пассажир, который направляет каноэ, исподтишка наклоняясь то влево, то вправо. Одна из моих любимых бизнес-аксиом – «если этого нет на бумаге, значит, это не существует» – в мире проектирования программного обеспечения верна, как нигде. Если что-то не записано, более чем вероятно, что это будет неправильно истолковано или опущено. Дело в том, что мотивация программистов очень сильно расходится с мотивацией пользователей. Недостаточно исключить диалоговое окно из описания, проектировщик обязан явным образом указать, где программист не должен по собственной инициативе добавлять лишнее окно. Программистам нравятся диалоговые окна. Они считают, что оказывают пользователю услугу, добавляя в свободные минуты пару дополнительных диалоговых окон. А пользователи эти окна ненавидят, потому что диалоги их изматывают и снижают производительность.
