Данил Денеко, разработчик игр и проджект-менеджер с десятилетним стажем, рассказал о том, чего НЕ стоит делать, если хочешь довести игру до релиза.
На ошибках, конечно, учатся — если осталось, что исправлять. В случае проджект-менеджера один фак-ап может привести к лавине трудностей, вплоть до закрытия проекта.
Я — Данил Денеко, разработчик и проджект-менеджер с десятилетним стажем в индустрии, а также автор курса «Менеджмент игровых проектов» от XYZ School. За плечами у меня четыре студии и более 12 выпущенных тайтлов. Сегодня я составил для вас несколько эмоциональных заметок о том, что НЕ нужно делать ПМу.
Перечисленные в них «грехи» не обязательно приведут к краху, но с большой вероятностью отправят команду в производственный ад.
Помню, на стриме в чате мелькнул коммент следующего содержания: «Что делает ПМ? — Орет».
Есть руководители, которые считают, что окрик солидным командным голосом повышает мотивацию сотрудников, а кранчи вообще полезны. Логика понятна: если нежничать, потом, когда нужно будет напрячься — все отвыкнут, не смогут совершить трудовой подвиг.
Но, на мой личный взгляд, крик вообще никого не мотивирует. И дело не в том, что я горячий сторонник профессора Преображенского и считаю, что к живым существам нужно исключительно с лаской.
Я допускаю, что крик и мат могут давать какой-то результат в других индустриях. Там, где не требуются уникальные комбинации знаний, навыков и интересов. Там, где у людей нет выбора (или их что-то очень сильно удерживает). Там, где можно уволить или принять заявление от сотрудника и тут же нанять другого.
Геймдев же отличается тем, что для позиций выше среднего уровня поиск толкового и ответственного специалиста нередко превращается в квест, который длится неделями, месяцами, а иногда и годами.
Это не значит, что не случается поводов — в отдельных случаях, бывает, очень хочется и поорать. На человека, на группу сотрудников, на глупость, на безразличие; вообще на ситуацию и тяжелую долю ответственного руководителя.
В лучшем случае это не поможет, и окружающие сочувственно покивают, мол, «вот, довели хорошего человека». В худшем оскорбленный сотрудник пойдет обновлять резюме и принимать накопившиеся приглашения о дружбе от многочисленных рекрутеров в соцсетях.
Комитет ведущих специалистов и директоров собирается не реже одного раза в календарную неделю для обсуждения текущих вопросов, согласования планов, календарных дат и основных приоритетов разработки очередного обновления разрабатываемого программного обеспечения, последующих обновлений, а также вопросов формирования кадрового состава и организационной структуры команды разработки.
Теперь сравните этот абзац и следующий:
Лиды и директора проекта собираются раз в неделю, чтобы обсудить:
— ход разработки апдейта;
— планы на следующие версии;
— потребность в новых специалистах.
Норвежские скальды собирали из цветистых метафор целые предложения, делая из «битвы» «прибой блеска лезвий». Люди, пораженные недугом бюрократии, превращают «план» в «согласованный список мероприятий, необходимых для реализации целей, обозначенных в Уставе Проекта».
Никто в здравом уме не будет читать подобное, даже если под тоннами канцелярита скрывается здравое предложение. Всегда учитывайте специфику рабочей культуры вашей команды.
Хороший документ = полезное содержание + удобная форма
Нужно что-то объяснить — напишите простыми словами. Где уместно — добавьте картинок. С указательными стрелочками.
И если перечисляете много всего, разбейте на список. Списки прекрасны. Как завещал нам Умберто Эко, они помогают нам сделать бесконечность постижимой.
Разработка и оперирование большой игры — это командная работа. Хотя бы потому, что объём требуемых знаний навыков слишком обширен.
Да, встречаются исключения — гении-одиночки, или маленькие команды талантливых и опытных гениев. Но, как правило, геймдев — это про совместную работу. И в этой совместной работе обычно не бывает людей, которые единолично могут принять компетентное решение по любому вопросу. Даже если они формально обладают таким правом.
Найм и увольнение требуют участия нескольких сотрудников компании с разными квалификациями. Формулирование задачи, оценка объема работы — знаний и навыков профильных специалистов. Обсуждение планов выпуска — участия нескольких сторон.
Хороший ПМ может выявить проблемы, запустить их обсуждение и решение. Но очень часто ПМ не может решить их в одиночку.
Речь сейчас не о праве на ошибку, которое есть у каждого и не о стремлении к профессиональному росту. Мы говорим о ситуации, когда ПМ замыкает на себе все процессы — когда ничего нельзя сделать без уведомления, разрешения, согласия.
«Все решения лидов должны проходить через ПМа»
«Прежде чем браться за новую задачу – согласуйте с ПМом»
«ПМ на больничном/в отпуске/в командировке, без него собеседований не проводить»
Дело даже не в фальшивом героизме, а в том, что это приведёт к остановке большинства процессов. Скорость обработки входящих запросов у людей, конечно, различается. И её даже можно повысить. Но в случае одного члена команды она всегда меньше, чем у всех остальных вместе взятых.
В одном из вариантов такого поведения ПМ сам забирает себе все права: сам двигает задачи в трекере, только сам пишет все-все-все письма клиенту или издателю, сам принимает решения о найме или увольнении. Такой микро-менеджмент приведёт к коллапсу проекта или нервной системы менеджера.
«Текучка» затягивает — я знаю это из собственного опыта. Интенсивность работы высокая, проект зарабатывает деньги, штат расширять не успеваем, людей не хватает, и приходится выбирать между планами на полугодие и двумя пожарами, идущими прямо сейчас.
Простой пример. На одном из проектов была ситуация, когда архитектура приложения требовала дополнительной отладки: приходилось городить костыли, задачи занимали всё больше времени, разработчики были демотивированы.
Интуитивный подход: срочно искать дополнительных людей, чтобы сдавать очередной апдейт, который задерживается, потому что задачи почему-то занимают больше времени, чем мы планировали.
Правильный подход: найти время, чтобы сесть с разработчиками, прочесать весь проект и запланировать работы по исправлению архитектуры приложения.
«Но какие планы? Тут все горит!» — кажется нам в моменте.
И это одна из частых когнитивных ошибок — предположение, что завтра у нас будет больше свободного времени, чем сегодня.
Проблема в том, что без внятной стратегии гореть будет всё чаще и чаще, а время, отнятое у решения долгосрочной проблемы в пользу одного пожара откликнется двумя в следующем месяце, квартале, году.
Думаете, проще будет отстраивать всё с нуля?
В нашумевшем мини-сериале «Чернобыль» главный герой произносит: «Каждая наша ложь составляет долг правде. Рано или поздно долг нужно оплачивать».
Чем выше в иерархии врут, тем проще оправдать ложь линейным специалистам. В какой-то момент проект и команда начинают жить в параллельной реальности. И не обязательно активно врать — иногда достаточно промолчать, затянуть или заболтать обсуждение. Игнорировать, обвинить в паникерстве, пессимизме.
Способность ПМа видеть реальную картину происходящего на проекте неразрывно связана со способностью отличать правду от обмана или самообмана. И начинается она с признания собственных сильных и слабых сторон, ошибок, промахов. Для исправления ошибки бывает достаточно информировать тех, кого это коснулось, и описать шаги по исправлению проблемы.
Я периодически вижу утверждение, что ПМ — единственный человек в игровой студии, которому можно безразлично относиться к создаваемой игре.
«Ему даже движок ставить не надо – вся работа в совещаниях, таблицах, документах. Вот вообще всё равно, что мы там делаем – хоть ММО-головоломку, хоть порно-шутер.»
С таким подходом лучше вообще не браться ни за какую работу, не только в геймдеве. Безразличие к игре постепенно приведёт к безразличию или даже неприязни к задачам. К содержанию апдейта. К производственным процессам. К мотивации команды.
«Что там опять заказал дизайнер или клиент? Какая разница!?»
Разница есть.
Лучше всего запоминаются проекты, которые вызывают эмоциональный отклик – нравится механика, нравится сеттинг. Если команда на совещаниях с энтузиазмом обсуждает предысторию персонажа и вам тоже интересно, если можете сами предложить идею, вместе со всеми смеетесь над шутками — вы понимаете, почему все эти люди здесь собрались и что их мотивирует. А значит, и сами болеете за результат.
«Менеджмент игровых проектов» — курс от XYZ School об управлении разработкой игровых проектов разных жанров. В ходе обучения вы узнаете, как эффективно организовывать работу в команде и настраивать производственный процесс.