На фоне вот этой статьи на PA Report о том, как все мрачно в нашей индустрии, в разных обсуждениях возникли мнения, что все проблемы, конечно же, из-за бюджетов. Бюджеты маленькие, жизнь боль, никто не мотивирован, вот и делаем мрачные игры.
Винить бюджет и нехватку денег - самое популярное из всего, что я слышу на протяжении многих лет. Но бюджеты все-таки по больничке чуть более чем достаточны, а вот проблемы есть реальные и куда более серьезные, чем бюджет. Потому как если нет проблем с командой или они решаемы внутри команды, бюджет никогда не будет проблемой. Понятно, что ситуации бывают разные, и денег бывает совсем мало, но тут нужно понимать, что хороший проект требует хороших вложений, и пытаться сделать хороший проект просто выживая - не самый лучший путь.
Но перед тем как продолжить читать дальше, послушайте отличный доклад от Petri Purho "Why Being Poor and Having No Budget is Good For Making Game". Его я привожу часто в пример, когда начинаются разговоры за бюджеты. Он банальный, в нем нет ничего нового, но он дает понять, что игры можно делать и без бюджетов.
И вот самый частый пример комуникаций - есть дизайнер собирающий/скриптующий проект, и есть люди, которые поставляют ему контент, который он собирает в игру. Еще в этой цепочке есть программисты, которые сделали движок и весь поступающий контент должен быть с правильным неймингом и прочими атрибутами, чтобы собирающему дизайнеру было понятно, что делать.
И тут возникает следующая ситуация: программисты что-то не дописали в документации, художники что-то в ней не дочитали, и по факту к дизайнеру пришел контент абсолютно не в том виде, в котором он планировал его получить. И что зачастую делают люди, допуская тем самым глобальную ощибку - они не говорят о возникшей проблемы, а решают, что проще пофиксить самому, чем возвращать обратно художникам на переделку. Соответственно, такое решение порождает вал ошибок и эти ошибки не прекратятся, так как каждый свято верит, что делает все правильно.
А как тут не верить в правоту того, что делаешь, если никто ни о чем не говорит? Зачастую эту проблему замечают на поздних этапах, а еще чаще, когда дизайнер под валом того, что он все правит и затыкает дыры, встает и увольняется.
Но заставлять людей говорить опять таки тяжело, и они постоянно будут отмахиваться тем, что им проще это сделать, чем сидеть без работы, пока кто-то пофиксит. У нас в этой ситуации приходят на помощь две вещи - Scrum и PM.
В Scrum в ходе утренних стендапов есть такой момент, когда каждый должен озвучить проблемы, которые у него есть. Когда все говорят, что проблем нет, то это опять таки боязнь о них говорить, тут хорошо срабатывает простое обсуждение того, что сейчас делается, и проблемы начинают всплывать сами, хотя еще 5 минут назад все уверяли, что никаких проблем нет и не может быть.
И в конец хочется сказать, что закрывать бюджетами все проблемы - это, конечно, выход, но при решении проблем внутри команды нытье про бюджеты автоматически исчезает, да и сам процесс разработки становится прозрачней и понятней.
Винить бюджет и нехватку денег - самое популярное из всего, что я слышу на протяжении многих лет. Но бюджеты все-таки по больничке чуть более чем достаточны, а вот проблемы есть реальные и куда более серьезные, чем бюджет. Потому как если нет проблем с командой или они решаемы внутри команды, бюджет никогда не будет проблемой. Понятно, что ситуации бывают разные, и денег бывает совсем мало, но тут нужно понимать, что хороший проект требует хороших вложений, и пытаться сделать хороший проект просто выживая - не самый лучший путь.
Но перед тем как продолжить читать дальше, послушайте отличный доклад от Petri Purho "Why Being Poor and Having No Budget is Good For Making Game". Его я привожу часто в пример, когда начинаются разговоры за бюджеты. Он банальный, в нем нет ничего нового, но он дает понять, что игры можно делать и без бюджетов.
Но вернемся же к нашим проблемам, которые возникают внутри команды, и которые куда страшнее любого бюджета, так как они разваливают нашу команду и проект изнутри. На самом деле таковых проблем очень много, но я остановлюсь на тех, которые чаще всего встречаются.
Нежелание нести ответственность
Команда так или иначе наемные сотрудники, даже если мы стимулируем их высокими зарплатами, project equity, печеньками, тренингами и так далее, чтобы держать мотивацию на высоком уровне. И частая проблема, которая тут возникает, это проблема нежелания нести ответственность за задачи, которые делаются, за качество фичей, которые получаются на выходе.
Эта проблема может возникнуть по двум причинам:
- прийти от команды - когда у команды не достаточно скиллов, или команда не считает, что нужно напрягаться чуть больше, чем им платят.
- прийти от менеджмента - когда менеджмент настолько боится дать возможность команде принять решение и нести за него ответственность, что принимает их сам, всячески контролируя и опекая команду.
Первое, что нужно сделать в такой ситуации - перестать мешать команде работать и отпустить их, чтобы они поняли свою важность, смогли самоорганизоваться и начать принимать решения.
Контроль оставить только на финальном принятии решения - пускать это в билд или нет.
И даже если мы не пускаем это в билд сейчас, то давать команде решить проблему фичи, улучшить ее, проитерировать и т.д. Это очень легко звучит на словах, но очень тяжело отпустить тотальный контроль над командой, когда такие условия уже созданы.
И тут я дам ссылку еще на одно видео от Alternativa Platform, где они рассказывают, как боролись с этой проблемой на примере своей студии - много хорошей и полезной информации.
Что же касается проблемы, когда команда сама не хочет принимать решения, то тут есть лишь одна рекомендация: заставить команду понять, что когда она берется выполнять работу в виде той или иной фичи, то она подписывает некий незримый контракт, который нужно выполнить, что команда согласилась, что ей хватит скиллов для этой работы.
Это тяжело и нужно много разговоров, уговоров и других способов мотивации. Многие бросят это занятие на полпути, но легко бросить команду или сменить, а не сформировать реально взрослую, принимающую решения и высоко мотивированную.
Отсуствие понятия готовности проекта и непонимание, куда мы движемся
В Scrum существует такое понятие, как готовность к продаже. По окончании каждого спринта команда должна деливерить продукт в той стадии готовности, которую можно продавать. Когда можно встать и сказать, что вот этот билд имеет ограниченный функционал, но мы можем его поставить потребителям и продавать, все остальное будет добавлено в патчах или DLC.
Это может казаться смешным, о каком готовом продукте можно говорить на старте разработки и так далее, но если мы к этому стремимся, то снимаем с себя два очень важных риска - время и бюджет.
Когда мы имеем продукт, побитый на небольшие этапы, и на каждом из этих этапов имеем хоть и маленький, но завершенный продукт, то по истечении времени на продакшен или в финале бюджет, мы сможем сказать, что продукт есть и его можно продавать.
Достичь этого понимания сложно, так как нужно выработать процесс, при котором команда будет успевать заделиверить готовый продукт в срок, не упираться тому, что готовый продукт можно реально сделать.
Но для этого мы и используем на своих проектах Scrum. Не всегда получается деливерить продукт в срок, но на каждом спринте команда делает все, чтобы по окончанию спринта мы имели продукт, который можно показать, пускай в нем только две фичи, но это законченный продукт.
Что почитать на эту тему - легко находиться гуглом, там много наглядных схем и диаграмм, объясняющих, почему готовый продукт важен и почему на это не стоит забивать.
Кривая мотивация
Я честно скажу, что до конца не понимаю, как бороться с кривой мотивацией, я понимаю откуда она возникает, но бороться с нею тяжело. Кривая мотивация, это когда просто опускаются руки и поднять их тяжело, она зачастую возникает от слишком долгой работы над одним проектом, затянутых сроков и смены приоритетов.
У меня есть пример появления кривой мотивации на примере смещения сроков и смены приоритетов. Представим себе ситуацию, что есть команда, которая знает, что у них до релиза месяц, и проект вроде бы уже готов к релизу в минимальном размере, все остальное запланировано на апдейты. Но за две недели до релиза возникает смена приоритетов, которая смещает релиз еще на месяц, и вот что тут происходит.
Команда уже настроилась, что нужно релизиться, что нужно сделать финальный рывок, и вот когда этот финальный рывок начат, перед командой просто возникает стена, в которую она ударяется с разбегу. И понятно, что за этот месяц можно успеть дополишить проект, внести правки и коррективы, которые пойдут ему на пользу, но сделать такой еще один рывок через месяц будет намного тяжелее, так как возникает та самая кривая мотивация.
Проблема коммуникаций
Не смотря на то, что этот пункт находиться последним, от этого он не является менее важным, и на самом деле должен быть первым по важности. Комуникации - сложная часть работы ибо все разработчики разные: кто-то любит много говорить, но не по делу, кто-то только по делу, а кто-то предпочитает просто молча делать свою работу и ни о чем не говорить.И вот самый частый пример комуникаций - есть дизайнер собирающий/скриптующий проект, и есть люди, которые поставляют ему контент, который он собирает в игру. Еще в этой цепочке есть программисты, которые сделали движок и весь поступающий контент должен быть с правильным неймингом и прочими атрибутами, чтобы собирающему дизайнеру было понятно, что делать.
И тут возникает следующая ситуация: программисты что-то не дописали в документации, художники что-то в ней не дочитали, и по факту к дизайнеру пришел контент абсолютно не в том виде, в котором он планировал его получить. И что зачастую делают люди, допуская тем самым глобальную ощибку - они не говорят о возникшей проблемы, а решают, что проще пофиксить самому, чем возвращать обратно художникам на переделку. Соответственно, такое решение порождает вал ошибок и эти ошибки не прекратятся, так как каждый свято верит, что делает все правильно.
А как тут не верить в правоту того, что делаешь, если никто ни о чем не говорит? Зачастую эту проблему замечают на поздних этапах, а еще чаще, когда дизайнер под валом того, что он все правит и затыкает дыры, встает и увольняется.
Но заставлять людей говорить опять таки тяжело, и они постоянно будут отмахиваться тем, что им проще это сделать, чем сидеть без работы, пока кто-то пофиксит. У нас в этой ситуации приходят на помощь две вещи - Scrum и PM.
В Scrum в ходе утренних стендапов есть такой момент, когда каждый должен озвучить проблемы, которые у него есть. Когда все говорят, что проблем нет, то это опять таки боязнь о них говорить, тут хорошо срабатывает простое обсуждение того, что сейчас делается, и проблемы начинают всплывать сами, хотя еще 5 минут назад все уверяли, что никаких проблем нет и не может быть.
И в конец хочется сказать, что закрывать бюджетами все проблемы - это, конечно, выход, но при решении проблем внутри команды нытье про бюджеты автоматически исчезает, да и сам процесс разработки становится прозрачней и понятней.
Комментариев нет:
Отправить комментарий