Как разрешить спор в команде, если вы геймдизайнер?
Эта статья будет короткая, но по делу. Есть множество разных способов разрешения спора внутри команды. Кому-то подойдут одни методы, кому-то - совершенно другие. Я хочу рассказать про метод, который мне больше всего понравился.
Представим такую ситуацию. Вы - геймдизайнер. К вам приходит программист, дизайнер, неважно, член вашей команды. И начинает предлагать что-то изменить в проекте. Например, дизайнер хочет, чтобы у дракона было не одна голова, а три. У вас начинается дискуссия, которая переходит в спор. Не будем углубляться в подробности, почему это может произойти и к чему это может привести. Что случилось - того не изменить. Вы говорите, как самый лучший геймдизайнер: "Хорошо, поступим таким образом". И начинаете рисовать таблицу, как на рисунке 1.
Думаю, вы уже поняли смысл данного метода. Но продолжим. Следующим действием вы опрашиваете людей, которые заинтересованы в проекте, можно брать не всю команду, а 5-6 человек. И расставляете «+», кто за какой вариант (рисунок 2). Предположим, что ваша идея оказалась предпочтительнее у команды. И по сути на этом спор можно заканчивать.
Чем хорош этот метод?
Вы слушаете своего члена команды и прислушиваетесь к его мнению. Он понимает, что может высказать свое видение по проекту и внести какие-то изменения, тем самым сохраняется командный дух.
Представьте ситуацию, что у вас есть классная идея по улучшению какой-либо фичи, вы подходите к руководителю, рассказываете, и он говорит: «НЕТ» - и все, конец. После этого и настроение уже не то, да и многие такого не выдерживают и увольняются, если это происходит систематично. А вы поступаете умнее. Вы опрашиваете команду, и если предложенная идея не понравится команде, то тут уже, извините, вы не один приняли решение, и так решило большинство.
А как вы решаете споры в своей команде?
если художник хочет, чтобы у дракона была не одна голова, а три, то это обсуждаемо. Но - только между ГД и художником, и голосование (в том числе размывающее ответственность за принятие решений) нужно устраивать только в рамках ваших отделов. А если договориться не удалось - пингануть продюсера, пусть будет третейским судьей.
но если программист или тестировщик хочет, чтобы у дракона было не одна голова, а три, то ГД должен 1) попросить аргументы 2) оценить их при наличии свободного времени 3) принять решение самостоятельно.
Ибо нехер устраивать новгородское вече по вопросам, которые относятся к узкой компетенции члена команды. Честно говоря, если количество голов дракона не влияет на игровые механики, то и ГД тут делать нечего, и договариваться должны художник и нарративщик.
Безусловно, могут быть какие-то исключения, особенно если команда маленькая, и люди закрывают две-три позиции. Но в целом вторжение в твою сферу ответственности дизморалит куда больше, чем отклонение фичи, предложенной соседнему отделу.
Странно на моем опыте вопрос с головой решался тем что делали несколько вариантов)))
а потом на практики проверяли что лучше
Есть более короткий вариант
Это он про кого так? Друг спрашивает.
Если дизайнер сказал, что у дракона три головы - значит у дракона три головы, при чем тут программист, геймдизайнер и QA?
А программист такой: мы аниматор под три головы пока будем переделывать, работа встанет на неделю. А ещё каждая голова независимо проджектайлы должна будет пускать или нет? А дракон умирать только после смерти всех голов? У нас на случай составных противников триггер ещё не дописан... Программист, блин, у них при чем. Такое ощущение, каждая идея находит воплощение сама собой и не требует обсуждения с исполнителем
Если дизайнер говорит, что у одноголового дракона 3 головы без обсуждения с продюсером и геймдизайнером, то он идет нахуй