Откровения аварийного инженера

Или как сэкономить 15% и более от бюджета на разработку

Я профессионально работаю с Unreal Engine уже более 9 лет. За это время я освоил множество специальностей и занимал разные должности в разработке игр: от разработчика-«пехотинца» до менеджера больших команд разработчиков игр и даже консультировал инвесторов игровых компаний.

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

Если у игровой компании в Лос-Анджелесе появляется проблема с Unreal Engine 4, которую никто не может решить, в конце концов звонят мне. Я пишу эту статью, чтобы объяснить, почему мне звонят, как избежать необходимости таких звонков, и что я обычно делаю, получив такой звонок.

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

Скорее всего, эта статья не относится к вам, если вы работаете в тесной небольшой инди-команде. Большинство случаев — это истории из жизни, поэтому они не всегда могут быть применимы для вас. Из-за самой природы моей работы меня редко упоминают «в титрах»: сам факт того, что я участвовал в исправлении ошибок команды, остаётся конфиденциальным. Именно по этой причине информация обо мне передаётся клиентами устно, поэтому нет никаких публичных доказательств того, что у меня есть необходимый опыт, чтобы писать на такие темы. Я пишу эту статью и не важно, поверят мне или нет, потому что люди, которым нужно знать эту информацию, не прочитают её, пока не станет слишком поздно… Если вкратце, то это и есть та проблема, о которой я пишу.

Остановите выгорание, начните рост

В Большом Лос-Анджелесе есть постоянная и неутолимая потребность в разработчиках игр высокого уровня, специализирующихся на Unreal Engine 4. Невероятно часто я видел, как команды нанимают одного или нескольких разработчиков начального/среднего уровня, а затем незамедлительно пытаются повесить на них обязанности сениоров/более высоких уровней, не давая им возможности роста и права на ошибку. Это связано с тем, что команды обычно решают выпустить продукт, не имея средств для создания такого продукта.

Я считаю, что это приводит к быстрой текучке и чрезмерному выгоранию: это цикл отрицательной обратной связи, разрушающей потенциал локального таланта высокого уровня, таким образом создавая ещё более серьёзный спрос на них. Если вы окажетесь в Большом Лос-Анджелесе, то я рекомендую вам посетить местный митап создателей игр, на которых бывает много алкоголя, и найти там разработчиков; если угостите их, они поделятся с огромным количеством ужасной и заставляющей задуматься информации по этой теме.

Перегрузка разработчика — верный способ прийти к сложному в поддержке проекту. Если вы не разрабатываете прототип «на выброс», то сложный в поддержке проект — один из скорейших способов вызвать усталость разработчиков. Если ваши разработчики во время работы едят и готовят на завтрак, обед и ужин спагетти из блюпринтов, то их не радует, что в офисе есть подключенная к 300-дюймовому монитору Nintendo 64.

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

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

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

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

Я взял такой пример потому, что видел уже, что происходит, когда инженер без опыта дизайна систем соединяет все эти три системы; получается хаос, при котором для открытия каждой двери может потребоваться убийство NPC. Если для двери требуется ключ, а все ключи выпадают из мёртвых NPC и единственный способ убить мёртвого NPC — выстрелить из оружия, то вы привязываете дизайн игры к необходимости выстрела из оружия для косвенного открывания двери. Звучит забавно, но всё так и есть. Но подобные смехотворные проблемы и зависимости возникают постоянно. Концепцию ключа можно реализовать таким образом, что простое действие, позволяющее дизайнеру уровня расположить ключ, который можно поднять, окажется невероятно затратной в реализации функцией. Или хуже того — для неё понадобится отдельная система, удваивающая трудозатраты на реализацию игровой концепции ключа. Это особенно справедливо при увеличении масштаба проблемы: 10-20+ систем работают совместно, а единственный, кто знает, как они работают, по какой-то причине пропал. Представьте, что у команды осталось всего три дня до выпуска продукта, а в ней больше нет разработчика, ответственного за эти системы, и разработчики более низкого уровня не могут научиться поддержке и изменению этих систем. Что вы будете делать? Кому звонить?

Нет инженера — есть проблема

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

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

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

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

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

Учитесь на своих ошибках

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

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

Разработчик высокого уровня — это не только код

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

Со временем вы начинаете видеть паттерны работы компаний, и если компания говорит, что подрядчик X стал причиной проблемы Y, и вы уже раньше имели дело с работой X, то вы на шаг ближе к решению проблемы Y. Хотя такая информация может оказаться бесценной, к сожалению, если вы достаточное время не занимались таким видом работы, то у вас не будет готового «каталога» информации, которую можно просеивать. Как и сказано в начале статьи, эту задачу иногда можно решить, просто купив другому разработчику напиток. Разработчики обычно не нарушают NDA, но узнать слухи о том, как на самом деле работает компания, гораздо проще, чем можно подумать. Не могу пересчитать случаи, когда мне удавалось решить крупномасштабные проблемы, просто поговорив с бывшим разработчиком или знакомым знакомого знакомого и узнав, что компания X говорит одно, а на самом деле было совсем другое. Трудно писать о таких типах проблем, потому что обычно они связаны с очень конкретными людьми на очень конкретных должностях с очень конкретными проблемами; написав о них, я нарушил бы конфиденциальность своей работы. Иногда внутреннюю информацию можно использовать для решения широкого диапазона проблем: от того, где искать нужные анимации, до ответа на вопрос, что на самом деле случилось с миллионами долларов компании.

Вот один пример, который сложно будет опознать с изменёнными именами, числами и спецификой.

Издатель «Белка» нанял компанию «Лось» для создания в двухлетний срок Игры с бюджетом 1 миллион долларов. Издатель «Белка» поставил условие, что компания «Лось» должна привлечь подрядчика «Кролик» для создания концепт-арта и подрядчика «Птица» для работы над анимациями. Оплата услуг «Кролика» и «Птицы» должны выполняться из этого бюджета в 1 000 000 долларов. Компания «Лось» приняла эти условия, даже несмотря на то, что её отговаривал от этого инженер-консультант Боб, сказавший, что если подходить реалистично, то для разработки Игры понадобится 2 000 000 долларов. У компании «Лось» ушло три года и 2 500 000 долларов на разработку посредственной и частично неготовой Игры. Спустя эти три года меня пригласила компания «Лось», чтобы я выяснил, можно ли полностью доделать Игру за минимальный бюджет, и разобрался в том, что же пошло не так. Проанализировав информацию от всех участвующих сторон, я довольно легко доказал, что в издателе «Белка» есть член правления Джо, имевший тайную долю в доходах подрядчиков «Кролик» и «Птица». Джо злонамеренно передал «Кролику» и «Птице» спецификации, требовавшие гораздо меньше работы, чем на самом деле требовалось, что привело к недопоставке. При этом он понимал, что у команды разработчиков компании «Лось» слишком мало опыта, чтобы она могла понять несоответствие объёмов работы. Эту информацию я собрал, спрашивая мнение о происходящем у разработчиков-«пехотинцев», и попросив помощи у инженера-консультанта Боба на открытой вечеринке местной игровой компании в баре. Так как компания «Лось» приняла всю работу, переданную ей подрядчиками «Кролик» и «Птица», с юридической точки зрения именно компания была виновата в том, что в результате ей пришлось платить больше за дополнительную работу «Кролика» и «Птицы», увеличившую доходы члена правления Джо. На эту потенциальную опасность верно указал Боб, но он был всего лишь консультантом, а в компании «Лось» не было технического руководителя, способного подтвердить его выводы. Если бы у компании был разработчик высокого уровня, то она могла отказаться от этой сделки или, по крайней мере, оценить недостаточный объём работы подрядчиков, и обсудить эту проблему с издателем «Белкой» с учётом навязанных членом правления Джо условий. Вместо этого, издатель «Белка» по полной поимел компанию «Лось», которая в результате развалилась. Издатель «Белка» продолжает использовать свои порочные практики и по сей день, только называется теперь издателем «Мусорная Панда».

Новостные медиа полностью согласились с издателем и обвинили во всём компанию «Лось», не упоминая ни члена правления Джо, ни подрядчиков «Кролик» и «Птица». Вся правда о подобных ситуациях никогда не раскрывается и вину обычно целиком навешивают на разработчиков, вне зависимости от участия в деле других злонамеренных сторон.

Кстати, все ваши подчинённые вам врут (потому что вы их не слышите)

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

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

Если сообщения о проблемах не приводят ни к каким действиям, то это становится скорейшим способом превращения сотрудников, особенно разработчиков, из энтузиастов компании в работников типа «пришёл на работу, ушёл с работы, остальное — не мои проблемы». Большинство сотрудников, особенно разработчики, хотят совершенствовать компанию и себя… пока не понимают, что их мысли никому не важны.

Могу привести один из таких примеров. Разработка проекта компании заняла больше времени, чем следовало, и меня позвали, чтобы я или ускорил разработку, или выяснил, в чём причина. Сразу же после попадания в офис, и ещё до того, как я встретился с нанявшим меня человеком, несколько разработчиков посоветовало мне как можно быстрее убегать, потому что продюсер, обладавший абсолютной властью над разработкой, не владел инженерными знаниями, и продолжал назначать тикеты не тем разработчикам: сетевые разработчики занимались исправлением геймплея, разработчики геймплея исправляли проблемы рендеринга, и так далее. Из-за такой путаницы создавались частые планёрки для устранения этой путаницы, а больше всего разработчики ненавидят одну вещь — частые планёрки. Каждый из этих разработчиков говорил, что доносил проблему продюсеру и высшему руководству, и они показывали электронную переписку, даже не получив разрешение на предоставление мне доступа к такой информации. Они так устали от этой ситуации, что просто сдались и начали закрывать навешиваемые на них тикеты. Один из сетевых разработчиков потратил три месяца на изучение и исправление графов анимации. В этом случае разработчики нашли способ самосовершенствования, но, к сожалению, без совершенствования компании. Так как мне удалось узнать это даже до экскурсии по компании, я немедленно выложил всё это высшему руководитству. Они сразу же спросили, кто раскрыл мне эту информацию и захотели принять жёсткие меры из-за нарушения субординации, вместо того, чтобы попытаться решить проблему. За то, что я не назвал имён, от работы со мной отказались, а мои услуги больше не требовались. Спустя месяц в команде вместо 7 осталось 2 разработчика, они покидали тонущий корабль. Ещё через месяц мне позвонили и сказали, что у компании больше нет команды разработчиков и спросили мои расценки на завершение разработки. Их предложение было намного ниже, чем бюджет, необходимый на реализацию требуемых этапов. В результате они наняли совершенно новую команду ещё менее опытных разработчиков, и процесс повторился заново.

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

Если вы менеджер, то можете понять, что разработчик доволен своей работой, если он свободно может давать обратную связь руководству об имеющихся у него проблемах. Если вы разработчик, то можете понять, что менеджер активно работает на вашей стороне, если вы видите, что в ответ на вашу обратную связь принимаются хотя бы какие-то действия. Когда происходит и то, и другое, то руководство может заметить увеличение количества проблем, о которых сообщается в процессе разработки, но также увидит и увеличение количества решений, а это лучше, чем меньшее количество замеченных проблем, когда критические задачи остаются нерешёнными. Хорошим инструментом для определения того, в каком лагере вы находитесь, являются диаграммы сгорания задач (Burndown charts). Если при правильном использовании ПО отслеживания ошибок вы видите всплески ошибок, а значения количества открытых проблем еженедельно не соответствуют количеству решённых проблем, то ваша команда использует свои возможности не полностью. Есть большая вероятность того, что на неё влияют какие-то скрытые проблемы. Соберитесь и выслушайте их, но, что гораздо важнее, предпримите действия. Во многих случаях даже неверное действие с правильным посылом лучше, чем отсутствие действия, если вы действительно хотите признать ошибку. Если траектория сгорания задач представляет собой наклонную линию (например, прямую), то ваша команда, скорее всего, работает как надо, и вам нет нужды контролировать её.

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

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

Если вы не прислушаетесь к такому пересказу информации и по-прежнему будете настроены на найм сторонних работников для решения своих проблем, то я возьмусь за необходимый объём разработки и потрясу вас тем, насколько продуктивным может быть один инженер. На самом деле это не потому, что я супергениальный разработчик высокого уровня, а потому, что могу использовать труд вашей команды правильно, ведь вы слишком непробиваемы, чтобы уяснить это иным способом. Это возвращает нас к разделу «Учитесь на своих ошибках». Я дам вам все необходимые инструменты и вложу все свои умения, чтобы помочь вам избежать одних и тех же ошибок. Если вы не захотите учиться, что я с радостью возьму дополнительную оплату в следующий раз, когда вы мне позвоните.

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

Не становитесь военной историей с GDC

Что это за история? У самых опытных игровых разработчиков есть свои военные истории. И вам не захочется стать одной из них. Поверьте мне, когда компания достигает определённого уровня ада, об этом узнают все. Все. А если ещё не знают, то узнают очень скоро.

Некоторые из перечисленных ниже пунктов случаются слишком уж часто.

Военные истории имеют следующие (а также некоторые другие) признаки:

• В компании присутствуют всевозможные нападки и оскорбления
• HR открыто выступает «на стороне компании»
• При сдаче продукции часто используются неоплачиваемые тесты графических ресурсов
• Бизнес-сделки заключаются стрипклубах
• Собеседования происходят в стрипклубах
• Вечеринки для сотрудников проводятся в стрипклубах
• Любые события, происходящие в стрипклубах, когда компания не связана со стрипклубами
• Бизнес-сделки заключаются под наркотой
• Кокаин в открытую употребляется прямо в офисе
• Вы увольняете сотрудника, потому что влюбились в его пару и это почему-то кажется вам хорошей идеей
• Вы нанимаете сотрудника, потому что влюбились в его пару и это почему-то кажется вам хорошей идеей
• Все действия, связанные с манипуляциями с любимыми людьми коллег
• Вы позволяете Сотруднику X класть обрезки своих ногтей на стол Сотрудника Y как месть Сотруднику Y, потому что Сотрудник X подозревает, что однажды Сотрудник Y украл его «Пепси»
• Постоянная задержка выплаты зарплаты на несколько недель
• Намеренное изъятие почты сотрудников
• Разрешение сотрудникам намеренно читать чужую почту
• У вас общая уборная с другой компанией, при этом эта компания явно не соблюдает правила поведения в уборной и вы продолжаете игнорировать этот факт
• Устные оскорбления персонала, который явно перерабатывает и испытывает проблемы с психикой, потому что постоянно перерабатывает и подвергается устным оскорблениям
• В вашей компании без каких-либо серьёзных причин бьют сотрудников, бизнес-партнёров и т.д.
• Создание иерархической структуры на основании мастерства игры в гольф
• Вы просто засранец и позволяете, чтобы под вашим руководством совершались гадкие поступки
• Вы не предоставляете сотрудникам доступ к питьевой воде, но продолжаете нанимать людей
• Создание атмосферы, в которой две противоположные стороны проблемы могут существовать без каких-либо компромиссов с обеих сторон

Возможно, нам стоит начать кампанию #gamedevwarstory.

Не будьте жертвой корпоративной культовой культуры или культуры Kool-aid

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

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

Если вы нанимаете кого-то из таких больших компаний, «пьющих Kool-aid», то важно проверить кандидатов на способность мыслить самостоятельно. Что подойдёт вашей компании, не всегда подходит компании X, и если кандидат не может приспособиться, то вы готовите для себя потенциальную военную историю.

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

Развиваемся как разработчик/даём расти своим разработчикам

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

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

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

Если вы разработчик, то у вас всегда есть «самое слабое место». Джунов, мидов и сениоров как раз обычно отличают друг от друга их слабые, а не сильные места. Бывают и исключения, но обычно всё происходит так.

Например, вы хорошо освоили C++ и Unreal Engine 4, а также замечательно умеете предоставлять доступ к геймплейным системам, чтобы с ними могли работать дизайнеры. Но вам не хватает способности донести дизайнерам то, к чему именно вы открыли им доступ. Это сигнализирует о том, что вы мид: вам можно доверить работу, но чтобы разобраться в работе, в команде должны быть другие люди. Если для организации встреч и донесения информации вам больше нужна помощь сверху, чем сбоку, то вы мид.

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

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

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

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

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

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

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

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

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

Глупые вещи, которые делают в процессе создания плохие разработчики или компании без разработчиков, вредящие им самим

Когда дело доходит до чисто инженерного аспекта работы разработчиком, то иногда быть разработчиком означает просто придерживаться кажущихся простыми принципов. Если меня вызывают, чтобы определить чисто инженерную проблему, то 95% времени я обычно трачу на обнаружение проблемы, 4% на её устранение, а 1% на то, чтобы рассказать всем, что проблема решена.

Любой разработчик высокого уровня, специализирующийся на Unreal Engine 4, должен знать, как пользоваться профайлером потока игры и профайлером GPU. Он должен уметь создавать блюпринты и/или писать код на C++, не создавая спагетти. Он должен хотя бы на простейшем уровне понимать, что происходит во всём движке и всех его системах. Менеджер любой команды должен уметь распознавать, способен ли разработчик на это. На эту тему можно написать целую статью, поэтому вместо этого я просто перечислю самые до смешного стандартные проблемы, с которыми я сталкиваюсь каждый раз, когда меня нанимают для решения «задачи оптимизации» проекта. Я надеюсь, что прочитав об этих проблемах, вы научитесь понимать мыслительный процесс, необходимый для распознавания признаков, приводящих к дорогостоящей сложной в поддержке разработке.

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

• Используйте систему управления версиями: вы не пользуетесь управлением версиями? Вы не знаете, что такое система управления версиями? Если вы отвечаете утвердительно, то ваш путь будет полон боли. Слышали когда-нибудь про игровую компанию, утерявшую мастер-копию дерева разработки и месяцы работы, потому что кто-то пролил воду на работающий жёсткий диск? Поверьте мне, такое случается.
• Уменьшите размеры коммитов, улучшите их журналирование: загрузка в Perforce изменения 2000 файлов размером 2ГБ с описанием «выполнил работу» — ужасная практика. Она не поможет, если нам когда-нибудь понадобится отследить проблему, которую, возможно вызвали вы своими последними двумя тысячами файлов.
• Создайте сборки и тестируйте их: представьте, что дедлайн разработки игры равен двум годам. Представьте, что первый плейтест проводится через 1 год и 9 месяцев после начала разработки. Такое случается. Регулярно создавайте сборки и тестируйте их, даже начиная с первой недели разработки. Если вы работаете в серьёзной компании, разрабатывающей игры, то у вас наверно должен быть какой-то автоматизированный конвейер создания сборок. Подсказка профессионала: автоматизация дешевле и эффективнее человеческого труда.
• Тестируйте сборки на целевом оборудовании: студии, занимающиеся разработкой для VR или мобильных устройств, часто зовут меня решить их проблемы. Представьте, что 1 год разрабатываете игру для VR и совершенно точно знаете, что минимальным требованием будет видеопроцессор Nvidia 960. Затем вы выполняете свой первый тест на 960 спустя 11 месяцев разработки и внезапно обнаруживаете, что вообще не умещаетесь в рамки производительности видеопроцессора. Такое в Большом Лос-Анджелесе происходит с периодичностью минимум в 3 месяца.
• Перестаньте создавать спагетти: не могу передать всё важность этого требования. Если вы работаете с блюпринтами, то хватит производить спагетти. Вы создаёте проблемы на ровном месте.
• Дайте разработчикам время привести создаваемую в спешке систему в божеский вид: если вы подгоняете разработчиков, чтобы они закончили proof of concept или прототип, но потом собираетесь использовать эту механику в производстве, то дайте им возможность усовершенствовать/переделать систему. При быстром соединении всего в кучу вы получите спагетти.
• Старайтесь придерживаться какого-нибудь руководства по стилю: вы не обязаны быть идеальными, но проект должен оставаться целостным на протяжении всего времени разработки. Если вы этого не сделаете, то найм новых сотрудников окажется гораздо затратнее, потому что им придётся разбираться в вашем хаосе. У вас нет руководства по стилю? Попробуйте использовать моё.
• Нельзя откладывать сетевой аспект на потом: если вы знаете, что делаете многопользовательскую игру, то пусть она поддерживает мультиплеер с самого начала. Нельзя просто «добавить мультиплеер» потом.
• Работайте с профайлерами: если я прихожу, запускаю профайлер и сразу же обнаруживаю проблему с блюпринтом, тратящим 100 мс вместо 1 мс, то просто возвращаюсь домой и высылаю вам счёт на оплату целого дня работы.
• Относитесь к предупреждениям как к ошибкам. Относитесь к ошибкам как к грехам: «Ой, да это предупреждение уже несколько месяцев всплывает, можете о нём забыть». Нет. Оно предупреждает вас по какой-то причине. Если игнорировать предупреждения, то они принесут за собой увеличивающийся вал проблем. Если вы игнорируете ошибки, то стреляете себе в ногу. У ошибок есть свои причины.
• Если у вас есть ведущий разработчик, то не игнорируйте его: если ведущий разработчик говорит, что нужно потратить 2 000 долларов на SSD или купить лицензию X на продукт Y, а вы сразу говорите «нет», потому что считаете, что разработчик просто пытается потратить ваш бюджет, то вам или нужно научиться доверять разработчику, или искать нового. Я видел компанию, которая впустую теряла 70 человеко-часов в неделю просто потому, что у сотрудников были медленные жёсткие диски. Если купить всем быстрые SSD, то это будет стоить компании около 60 человеко-часов бюджета. Допустим, эта проблема длилась больше четырёх месяцев. Тогда она растратила тысячу человеко-часов просто потому, что руководство не захотело платить за лишних шестьдесят.
• «На моей машине работает»: если вы сталкиваетесь с проблемой «на моей машине работает, а на его нет», то сразу сравните различия в файлах на двух системах. В 90% случаев разница помогает выявить проблему. Если отчёт о различиях сообщает, что файлы одинаковы, то проблема может быть связана с системой.
• Нет, скорее всего, это не баг компилятора: компилятор намного умнее вас. Если код не компилируется, то помните, что чаще всего проблема не в компиляторе, а в вас.
• Текстуры 4k нужны не всегда: вам не нужны текстуры 4k для каждого ресурса, если только это не указано явно. При создании мешей учитывайте плотность текселов.
• 1000 динамических источников освещения — это плохо: хватит использовать в проекте кучу динамического освещения. Да, это выглядит замечательно при 3 FPS, но если вы не создаёте что-то вроде офлайн-ренденинга, то ваша игра не будет игрой при 3 FPS.
• Вам не нужны 500 подбираемых объектов: нет, лаг не стоит того, чтобы иметь возможность взять один карандаш из коробки с 256 карандашами. Только если ваша игра не о карандашах.
• Научитесь созданию PBR-контента: вы создаёте реалистичные ресурсы с помощью десятилетних техник моделирования и текстурирования ресурсов? Потратьте немного времени и средств на изучение PBR. Вам совершенно точно не нужна для каждого ресурса карта отражений с разрешением 4k.
• Для камней не нужно 12 слотов материалов: корни этой проблемы лежат в предыдущей проблеме. Если для камней используется 12 слотов материалов, то вы что-то делаете не так.
• Используйте LOD: если в вашем проекте нет ресурсов с LOD, то хотя бы сгенерируйте для плотных мешей LOD автоматически.
• Компоненты затратнее, чем вы думаете: это обычно становится очевидно при профилировании, но знайте, что любой объект или компонент, перемещающийся в мире, должен обработать движение всех своих дочерних компонентов. Это может быть очень медленно, поэтому при возможности избегайте встраиваемых компонентов и глубоких цепочек компонентов.
• VR — хватит мучать отражения: разумеется, 20 зеркальных поверхностей, вычисляемых в реальном времени, выглядят потрясающе, но вам ни за что не удастся заставить их работать на оборудовании с необходимым уровнем частоты кадров.
• VR — используйте Forward Rendering вместо Deferred Rendering: если никто в вашей команде не знает разницы между отложенным (deferred) и прямым (forward) рендерингом, а вы работаете над VR-проектом, то немедленно переходите на прямой рендеринг. У меня иногда бывало так, что я всего лишь заходил в офис игровой компании, переключал проект на прямой рендеринг и сразу возвращался домой, потому что необходимый уровень производительности уже оказывался достигнут. Исключение: если вы совершенно точно знаете, что такое отложенный рендеринг в VR, то, разумеется, используйте его.
• VR — используйте свежие версии движка: в каждой новой версии UE4 вводится множество улучшений VR. Вы никогда не должны опаздывать больше, чем на две версии, потому что так вы снижаете скорость по не очень разумным причинам. Кто-то может с этим не согласиться, но у меня всегда оказывалось, что затраты на апгрейд стоили повышения скорости.

Обращение к разработчикам

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

Вы не одиноки в своём одиночестве.

Если вы не нашли своего личного резинового утёнка, то продолжайте его искать.

Примечание автора после публикации статьи

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

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