Глава 14. Управление

Бригадир Джон устал от рабочих, которые все портят. Поэтому он купил Puppetron – последнее слово в области управления. Ему больше не придется отдавать указания и надеяться, что они будут выполнены правильно. Теперь он мог надеть на голову шлем Puppetron и контролировать все действия рабочих силой мысли. Он стал подобен кукловоду, дергающему за тысячу веревочек, лично координируя действия каждого работника. Это было чудесно.

Бригадир Джон и его команда строили мост. Когда уже половина работ была выполнена, мост рухнул и всех убил.

Следователи обнаружили сотни мест с халтурной сваркой, перекрученные кабели, смещенные стойки и отсутствие болтов. Как будто ни одна из работ не была выполнена работником осознанно.

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

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

Банальность зла

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

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

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

Тейлоризм

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

Ф. У. Тейлор

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

Около 1900 года человек по имени Фредерик Тейлор начал изучать рабочие процессы и увидел огромные пробелы в традиционных методах. Он приступил к созданию стиля управления, который впоследствии будет известен как тейлоризм.

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

Тейлор не пытался заставить рабочих понять, что они делают. Для него они были неуклюжими идиотами, и их понимание было ненужным. «Рабочий, наилучшим образом приспособленный для фактического выполнения своей работы, не способен в полной мере уяснить себе этот ее научный фундамент без помощи и руководства со стороны тех, кто работает вместе с ним или над ним. Это объясняется у него либо отсутствием образования, либо недостатком умственных способностей» – писал Тейлор.

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

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

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

Но что происходит, если работа сложная и не повторяющаяся? Что будет, если информации больше, чем может выдержать один мозг? Теперь «главный мозг» перегружен данными. Он начинает игнорировать детали, упрощать или пропускать важные сигналы. Решения становятся хуже, и возникают лишние действия.

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

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

Так что тейлоризм, являющийся надежным стандартным методом, не подходит для разработки игр. Но существует решение.

Распределенный разум

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

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

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

Это невозможно с помощью тейлоризма. Мы не можем отнимать решения у рабочих и отдавать их в руки нескольких руководителей. Чтобы распределенный интеллект работал, мы должны разделить власть между членами команды.

Распределение власти

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

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

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

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

ЕСТЕСТВЕННАЯ ВЛАСТЬ разработчика распространяется на любое решение, в котором он разбирается лучше, чем кто-либо другой из членов команды.

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

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

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

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

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

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

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

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

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

Присвоение и доверие

Слово «arrogant» происходит от французского s’arroger и означает «присваивать чужие полномочия». Люди присваивают полномочия по принятию решений, когда отнимают их у человека, над которым у них естественная власть.

ПРИСВОЕНИЕ – это предъявление прав на принятие решения, которое подпадает под естественную власть другого человека.

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

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

Это распространенная проблема, которая возникает из глубинных когнитивных искажений. Геймдизайн полон скрытых возможностей. Один уровень или система могут быть сыграны сотнями или тысячами разных способов, и чтобы понять игру, недостаточно посмотреть ее обзор. Однако кажется, что все именно так и происходит из-за глубоко укоренившегося предположения WYSIATI (что видишь, то и есть). Руководитель не знает, сколько он не знает, так как никогда не видел того, чего не знает. Поскольку он сам не осознает, что информации не хватает, то считает, что видит полную картину. Таким образом, он присваивает себе полномочия по принятию решений, считая, что может сделать лучше, а подчиненные возмущаются и уходят.

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

Чтобы вместе работать над игрой, мы должны доверять друг другу. Это не призыв к командной работе или мотивационный лозунг. Это голые факты, и слово «должны» я использую в буквальном смысле. Доверие – это не опция. Мы не можем исправлять чужие ошибки просто потому, что не в состоянии понять работу друг друга. Поэтому лидер, руководящий командой болванов, обречен. Он не может защититься от идиотизма, когда во всей студии принимается слишком много решений, находящихся вне его понимания и юрисдикции. Любые усилия, которые он предпринимает, чтобы защититься от людей, которых он считает тупее, чем они есть, только помешают команде. Единственный вариант – привлечь людей, которым вы можете доверять, и начать доверять.

Задать направление

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

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

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

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

Лидеры не могут указывать подчиненным, как выполнять любую мелкую задачу. Необходимо задать масштабное НАПРАВЛЕНИЕ.

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

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

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

Например, руководя уровнем в игре ужасов, высокомерный лидер и приверженец тейлоризма может сказать: «Игрок просыпается в ванне кровавой воды. На зеркале нацарапано: “Ты не сбежишь”. Игрок осматривает дом и находит тело своей подруги. Вскоре после этого он встречает врага с мачете, и поскольку у игрока нет оружия, ему придется бежать из дома, а противник будет его преследовать». Вот список задач, которые необходимо выполнить. И если бы все работали так, как запланировано, все было бы гораздо проще. Но что происходит, если тестировщики отказываются бежать от мачете или смеются над дурацким посланием на зеркале? Сотрудники не могут решить эти проблемы самостоятельно. Они не понимают, что делают, и у них нет полномочий что-либо менять. Следовательно, они должны вернуться к руководителю, а тот, вероятно, предложит им плохое решение, потому что ему не хватает глубоких знаний об уровне и он не присутствовал на провалившемся плейтесте. Специальные знания сотрудников не учитываются, и процесс срывается.

Лидер должен задать направление: «Этот уровень должен научить игрока всем основным элементам управления, кроме управления оружием, которое следует оставить до следующего уровня. Он должен включать историю о мертвой девушке, чтобы мы могли развернуть ее позже. Следует также добавить героя с мачете. Поскольку следующий уровень начинается за пределами заброшенного дома, этот должен закончиться тем, что игрок выходит через входную дверь дома. Это первый уровень, так что игра может начинаться с любой локации. Наконец, не показывайте главного героя, я хочу, чтобы на этом этапе он оставался загадкой». Теперь команда может приниматься за работу. Они могут начать с того же дизайна, который первоначально предлагал менеджер проекта. Но во время итерации они, скорее всего, найдут лучший способ достичь тех же целей. Плейтесты и мозговой штурм раскроют новые уровни проблем и решений, которые лидер никогда не смог бы найти в одиночку. Освободившись от строго регламентированного списка задач, разработчики могут использовать возможности и решать проблемы по мере их возникновения. Дизайн изменится, но поскольку разработчики понимают его роль в более крупной структуре, то смогут убедиться, что он хорошо и правильно вписывается в следующий уровень. А руководитель освобождается от обязанности следить за деталями.

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

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

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

Сотрудники должны РЕЗЮМИРОВАТЬ новую полученную информацию и предоставлять лидеру соответствующие выводы.

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

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