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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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