Хабрахабр

[Перевод] Откровения аварийного инженера

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Используйте систему управления версиями: вы не пользуетесь управлением версиями? Вы не знаете, что такое система управления версиями? Если вы отвечаете утвердительно, то ваш путь будет полон боли. Слышали когда-нибудь про игровую компанию, утерявшую мастер-копию дерева разработки и месяцы работы, потому что кто-то пролил воду на работающий жёсткий диск? Поверьте мне, такое случается.
  • Уменьшите размеры коммитов, улучшите их журналирование: загрузка в 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. Вы никогда не должны опаздывать больше, чем на две версии, потому что так вы снижаете скорость по не очень разумным причинам. Кто-то может с этим не согласиться, но у меня всегда оказывалось, что затраты на апгрейд стоили повышения скорости.

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть