Сразу с места в карьер: я не знаю ответа на этот вопрос. А вернее, я не знаю конкретных людей, ответственность которых за текущее состояние игры наибольшая. Возможно, даже сами CDPR ещё этого не знают. Да, этот пост не ставит перед собой цели найти конкретных виновных, он о другом. И мой ответ на вопрос из заголовка будет донельзя банальным: виновата CDPR. Это единственный значимый ответ с точки зрения потребителей.
Ведь потребитель смотрит на именитую компанию разработчика/издателя, а не на список сотрудников. Конечно, везде есть исключения, но отдельных именитых личностей, вроде Гейба или Кодзимы, не так много. Но в данном случае большинство игроков будут обвинять абстрактных «криворуких разрабов» из CDPR, не зная ничего про кранчи в частности, и закулисье в целом.
Так о чём же тогда этот пост, почему он возник, и какую цель перед собой ставит? Во-первых, это пост о том, что ответственность за проект лежит на каждом, кто причастен к нему. Она проявляется по разному, и не всегда напрямую соответствует исполняемым функциям.
Во-вторых, возник он после прочтения серии статей, три из которых вышли в один день. Сначала мной была прочитана статья о том, что тестеры не виноваты, от сеньора @Dmitry Bulanov:
Как он уточнил в конце статьи, есть куча нюансов. Но с основной мыслью статьи я не могу согласиться.
Следующая статья от товарища @Arseniy M напрямую противопоставляла себя вышеозначенной, но, по большей части, заголовком:
В статье кратко рассказывается о трудностях работы над большими проектами, и как с ними можно бороться. Конечно, это скорее анализ ситуации и проецирование личного опыта на студию разработчика (если автор не сотрудник CDPR, конечно).
Третья статья была от нашего любимого главреда, сонибоя, биллибоя… ну, вы и сами дальше знаете. @Вадим Елистратов написал о том, что игру погубила гордыня руководителей студии:
На самом деле, во всех трёх статьях так или иначе говорится о вине руководства. Это естественно, ведь за конечный продукт руководитель несёт непосредственную ответственность, на то он и руководитель.
Последняя статья, от пользователя с самой большой галочкой на сайте, @AMD Toxic Andrey Apanasik, вышла спустя 3 дня:
В ней уже ссылаются на сотрудников CDPR, жаловавшихся на адские условия труда и обман пользователей со стороны руководства. Конечно, вряд ли кто официально подтвердит данную информацию, но это не первые подобные заявления. Лично я считаю, что возникают они не на пустом месте, и хотя бы часть этого имела место быть.
И, наконец, в-третьих, целью этой статьи является рассуждение о том, какая же ответственность лежит персонально на каждом члене команды. А так же аристократическое обсуждение в комментах с достопочтенными пользователями DTF их взглядов на это, конечно же.
Вступление вышло несколько длиннее, чем я ожидал, но мне было важно пояснить мотивы, что сподвигли меня на написание статьи. Приступим же к основной части.
Персональная ответственность каждого за качество проекта
Для начала стоит ещё раз уточнить, что все описанные ситуации и примеры не относятся к CDPR. Я не знаю, как функционирует студия, какие процессы приняты в компании в целом, и в отдельных командах в частности, я не могу подтвердить или опровергнуть слухи от инсайдеров, поэтому не буду накидывать на вентилятор ради хайпа. Всё сказанное актуально для некой абстрактной студии, и служит для пояснения ответственности каждого сотрудника за качество проекта.
Конечно, когда речь идёт о маленьких инди-студиях, состоящих, порой, всего из нескольких человек, персональная ответственность выражена в гораздо большей степени. В больших компаниях важную роль играют руководители. Очень многое зависит от их умения построить процессы, определить приоритеты, и, конечно, запланировать работы. Естественно, на руководителях лежит очень большая ответственность за проект. Рядовые сотрудники же часто ощущают себя маленькими винтиками в огромной системе, которые просто выполняют свои функции, но состояние всего проекта от них почти не зависит.
На самом деле, это не так. Не все любят аналогии, но я рискну провести одну. Если один винтик из огромной системы выпадет, система не рухнет (если мы не говорим о «несущих» конструкциях, конечно 😉). Даже несколько утерянных винтиков система переживёт. Но что будет, если каждый винтик будет на своём месте, но немного ослаблен? Грубо говоря, система вроде как ещё останется целостной, но будет шататься и скрипеть.
Да, в большой компании есть много сотрудников на одной должности, способных заменить друг друга. Требуется это в том числе и для того, чтобы вся система работала, ведь результат работы одного нужен для работы другого. В больших проектах вся работа чаще всего делится на отдельные этапы, называемые «спринтами». В спринты планируется определённый объём работ, оговаривается их порядок — ведь дизайнер не сможет делать работу без необходимых механик, например. Некоторые сотрудники делают работу, которая пригодится другим уже в следующих спринтах. Но если случаются нештатные ситуации, то их надо решать, чтобы производственный процесс не останавливался. Ведь это снежный ком, который в итоге выльется в большие проблемы со сроками. Приведу грубые примеры.
- Художник Петя заболел? Хорошо, персонажей будет рисовать Вася, так как они нам нужны прямо сейчас для работы аниматоров. А машины, которые должен был рисовать Вася, запланируем в следующий спринт, они на данном этапе нам не к спеху.
- Программист Коля сделал баг в механике на прошлой неделе, который блокирует работу QA? Надо чинить, но он сейчас занят другой важной задачей, которая необходима для работы дизайнеров. Тогда баг пусть чинит Саша, ведь он занят сейчас настройкой физики пуль, и от результата его работы другие сотрудники не зависят.
Но я уже чувствую возражения: ведь работа Васи и Саши тоже нужна, откуда взять на неё время? И тут мы подошли к ответственности руководителей. Да, это их обязанность. Спринт должен быть спланирован с учётом рисков. Если все сотрудники забиты работой так, что двинуть ничего никуда нельзя, то будут возникать тупиковые ситуации и кранчи. Если что то выходит из под контроля выше ожидаемого, всё равно должно быть место для манёвра. В крайнем случае, руководитель может принять решение отрезать фичу, если видит, что продолжение работы над ней может очень сильно сдвинуть работы над всем проектом в целом.
Описанные выше примеры про болезни и баги для больших компаний — вещи статистически вычислимые. Работают они обычно через системы вроде JIRA, и собрать данные о том, сколько человеко-времени в среднем тратится на различные процессы, с целью учёта этого времени в планах — вполне посильная задача.
И тут может создаться иллюзия, что при грамотном руководстве непременно должен выйти крутой проект. Но правильные процессы — ещё не залог успеха проекта. Яркий пример — Star Wars: Battlefront II, вся система прогрессии в которой была построена на лутбоксах. И решение было не спонтанное, всю систему основательно задизайнили так, что после поражения в первой лутбоксовой войне разработчикам понадобилось очень много времени, чтобы переделать систему.
Дабы не развивать бурление, отвлечёмся от SW Battlefront II и монетизации, ведь мы не знаем, кем и как было принято решение о введении подобной системы. Представим, что в какой то большой компании решают делать новую игру. Приходит геймдизайнер, и говорит:
— Я придумал крутую систему прокачки, вот презентация. Тут мы видим огромное дерево навыков, и игрок должен с умом распределять имеющиеся ресурсы. От прокачки геймплей будет кардинально меняться, и соответствовать стилю и ожиданиям игрока!
В итоге игроки получают огромное дерево прокачки, значительную часть которого занимают пассивные умения вроде «+2% скорости» и «-5% получаемого от взрывов урона» просто потому, что геймдизайнер не смог придумать так много уникальных способностей. Он мог бы попросить помощи, чтобы в один из спринтов запланировать другим геймдизайнерам придумать уникальные способности, но решил, что и этого будет достаточно. Вот мы и пришли ещё к одной персональной ответственности.
Но что же его коллега, другой геймдизайнер? Увидел он это всё, подумал: «шляпа какая то, скучно!». И продолжил делать свою работу. Руководитель может не обладать достаточной компетенцией чтобы понять, что система скудна, но его коллега может. Но вместо того, чтобы обсудить ситуацию, а может, и предложить какие то решения, просто ничего не делает. Да, у него есть своя работа, но, приняв решение не озвучивать найденную проблему, эта проблема стала быть и в его ответственности.
Теперь рассмотрим обратную ситуацию. Нарисовал художник, допустим, меч. Очень необычный, богатая фантазия у художника. Коллеги-художники оценили креативность подхода, похвалили. Но пришёл программист, и говорит: «я тут меч увидел, который выдаётся в награду за трудный квест. Это что за ***** вообще?». Обиделся художник, сказал: «сам ты *****, а я так вижу. Тыж не художник, а я не говорю тебе, как правильно программировать». На что программист замечает, что спросил других коллег-программистов, и всем меч не понравился. Но получает возражение, что все они не художники, и ничего не понимают.
А дело в том, что большинство игроков тоже не художники, и не смогли оценить креативности талантливого сотрудника. И это ещё одна ответственность — данный художник не умеет воспринимать критику. Конечно, когда один человек критикует, это не репрезентативно, особенно, если критикующий не специалист в этой области. Но когда то же самое говорят несколько человек — это, как минимум, повод задуматься.
Рассмотрим дугой пример. На собрании у программиста спросили: сколько времени займёт система роста деревьев в реальном времени, вокруг которой геймдизайнеры могли бы построить экономику и дать игроку уникальный опыт? Он исследовал задачу, и дал оценку, после чего начали работу. Пока он делает её, геймдизайнеры рассчитывают экономику, основываясь на этой системе: игрок получит определённое количество ресурсов, зависящее от высоты дерева, и его состояния. Но в результате работы программист понимает, что недооценил свои силы. Всплывает множество подводных камней, куча багов, проблемы с производительностью. Даже дополнительные силы коллег, брошенные на помощь, не спасают. В добавок ко всему, систему очень трудно тестировать и отлаживать. А фича уже была заявлена игрокам.
В итоге приходит понимание, что дальнейшая разработка фичи может потопить весь проект. Приходится отказаться от неё, выделить время для переделки экономики, что повлечёт за собой либо кранч, либо отрезание ещё какого то контента. В добавок ко всему, и игроки не довольны, что обещанного не получили. И ответственность лежит на том, кто обещал сделать эту систему.
Взглянем и на работу QA. Нашёл он баг, что в одном случае из десяти в квесте застревает NPC, из-за чего квест нельзя пройти, и приходится загружаться, или фейлить его. И вроде редко роллится баг, и к софтлоку не приводит. Поставил его с низким приоритетом. Багов к релизу накопилось много, успели починить только критичные. Но игра продалась миллионным тиражом. А значит баг нароллился примерно у ста тысяч пользователей. Число не маленькое, и бурление в твиттере обеспечено. Есть ли тут ответственность QA? Конечно!
Ситуаций бывает много. И для разных студий они будут разными ввиду различия в принятых процессах. Но, надеюсь, общую картину мне удалось описать.
Так что же в итоге?
Я привёл пусть и грубые, но довольно яркие примеры, для того, чтобы дать понимание: и в маленьких проектах, и в больших, конечный результат зависит от работы каждого. Но в случае большого проекта персональная ответственность может быть размыта за огромной работой всей команды. Но это не значит, что её нет. Мой коллега, занимающий должность технического директора, любит говорить: нет плохих людей, есть плохие процессы. Ведь он сам принимает решение о найме сотрудника, и говорить, что он плохой и плохо справляется с задачами — камень в свой огород.
Большие команды не возникают внезапно, они вырастают из маленьких, у которых уже есть за спиной опыт, а значит, и ошибки. Да и текущие проекты не делаются залпом, а разбиваются на спринты, что позволяет подводить промежуточные итоги, и планировать дальнейшую работу с их учётом.
Хороший руководитель разбирает допущенные ошибки, находит причину, и строит процессы так, чтобы они работали над их устранением. Не уложились в спринт и кранчевали из-за не учтённого в плане времени на болезни и баги? — Собираем статистику, и учитываем. Геймдизайнер написал один из основных дизайнов по прокачке и способностям персонажа? — Надо обсудить его всей командой геймдизайна. Арт периодически вызывает вопросы у широких масс? — Делаем регулярную рассылку на всю студию с открытым обсуждением. И так далее.
То, что произошло с Cyberpunk 2077, ещё предстоит разобрать в самой CDPR, и, судя по слухам, дела уже движутся. Но сейчас у них ещё много забот по доведению игры до такого состояния, чтобы её можно было вернуть в PS Store. Всё, что мы видим со стороны, из доступных источников информации, лишь говорит нам, что в студии действительно серьёзные проблемы, но верить им, или нет — личное дело каждого. Я же буду надеяться, что поднявшаяся волна даст толчок к пересмотру процессов внутри студии, ведь их игры мне очень нравятся, и хочется, чтобы CDPR продолжили существовать и радовать меня, и миллионы других пользователей ими.
TL;DR
- Шоколад не виноват! Пост не ставит цели оправдать или обвинить кого то из CDPR.
- Ответственность даже за большие проекты есть на каждом причастном работнике в разной степени.
- Но определяться эта ответственность и её последствия должны внутри студии, т.к. лишь там люди располагают наиболее полной информацией.
