«Делегируй и умри»: четыре опасных заблуждения игровых разработчиков

Как благие намерения могут привести к закрытию студии.

Управляющий партнер DTF и вице-президент Cubic Games Сергей Бабаев в своей колонке рассказал о распространённых заблуждениях начинающих разработчиков игр, которые, пусть и звучат так, будто способны принести пользу производственному процессу, на деле лишь вредят ему.

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

Традиционно оговорюсь, что не стоит искать в материале алгоритмов определения «плохих людей» (не всё так просто) или тем более обижаться на них. Обсуждаемые мысли, несмотря на критичную оценку в материале, можно использовать в ряде случаев. Я же описываю те неприятные моменты, когда люди ими неосознанно злоупотребляют. Относиться к материалу стоит как к субъективной заметке в блоге, где я сознательно рассматриваю одну сторону медали, игнорируя всё, что считаю неважным для донесения своей мысли. Итак приступим.

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

Давайте порассуждаем о причинах. Мы склонны интерпретировать любую информацию в свою пользу. Если кто-то даёт совет, то первая реакция — максимально адаптировать услышанное и срочно убедить себя, что вы, за мелкими исключениями, всё так и делаете. То есть вам повторяют очевидные истины, будто вы сами их не знаете.

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

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

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

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

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

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

Рекомендация тут предельно проста — вникайте во всё, особенно если вы в начале пути. Чем больше у вас компетенций, тем сложнее вас обмануть и подвести.

Нет. Просто нет.

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

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

Сотрудник, несомненно, может раскрыть в себе несколько талантов, но это ни в коем случае не стоит превращать в систему. Он может быть крайне эффективен в своей роли исполнителя, но абсолютно не приспособлен ни к какому типу руководства. Более того лычка «босса» действительно манит и даже будучи абсолютно несчастным на новом месте и втайне желая вернуть всё на свои места, новоиспеченный лидер вряд ли с радостью примет вести о понижении.

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

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

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

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

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

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

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

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

Насколько Scrum не вреден сам по себе, настолько же он и не чудотворен. И вот в чём дело. Обычно компании задумываются о переходе на Scrum после того как устали от постоянного срыва сроков, перерасхода бюджетов и прочего, что до определенной степени, разумеется, является неотъемлемой частью нашей работы (но лишь до определенной). По идее, руководству надо залезть во все задачи, разобрать до мелочей процессы и понять, что именно вызывает проблемы.

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

Как человек передовой, информированный и читавший иностранные сайты (ну или переводы с иностранных сайтов), он предположит, что дело конечно же в неправильно выбранной методологии. Некомпетентность лидов, неадекватность требований — всё не причём. Дело именно в выборе методологии.

Часто (но не всегда) инициативным оказывается, мягко говоря, не самый ценный кадр, для которого такая активность компании хороший, а может и вовсе последний шанс, обеспечить свою «нужность». Работы при переходе на новую методологию всегда много — тут и поездки заграницу для того, чтобы перенять опыт; и поиск консультантов, которые поправят ошибки юных Scrum-сёрферов; и успешно заваленные месяцы работы, оправданные затем «болью при переходе, которая окупится сполна позже» и многое, многое другое.

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

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

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

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

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

Более того успешные разработчики даже изучив все материалы модифицировали прочитанное под себя до такого состояния, что от каноничного Scrum ничего не осталось. Всё это нисколько бы меня не волновало, если бы большие успешные студии не были примером для подражания новичков. Когда они слышат, что в Scrum есть магия от видных людей в индустрии, то сразу бросаются в этом направлении, не беря в учёт годы разработки, опыта и сил, вложенных этими компаниями в их “скрамы”. А это, скорее всего, уводит фокус внимания от продукта и проблем с ним в сторону более интересных изысканий.

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