«Серьезные проблемы в нашей работе имеют не
технологическую, а социальную природу»
Том Демарко.
Эпилог.
Статья рассчитана на людей, имеющих очень скудный опыт работы в команде, либо вообще не имеющих оного.
Многим, наверное, она покажется примитивной, зато многим сбережёт нервы. И запомните - как ни странно, общение и сосуществование по-прежнему остаётся одной из самых насущных проблем для начинающих разработчиков. И если вы сможете решить эту проблему - у вас вероятно хватит ума решить остальные.
Давайте жить работать дружно!
Очень тяжелым порогом является переход от рассмотрения человеком личных перспектив, к рассмотрению перспектив команды. Все стремятся к лидерству. С этим в первую очередь связан сумбур по поводу выбора жанра, сюжетной линии (если таковая присутствует), движка и тд. Примеров внутри командных политических войн масса, каждый участник пытается засунуть в дизайн-документ свою идею, вовсе не задумываясь о её реализации. Если его идея не принимается, то он обижается, формирует “оппозицию” и тут два варианта - либо очередной переворот с выбором руководителя, либо эта “оппозиция” подвергается различного рода репрессиям и в конечном итоге команду покидает. Зачастую это либо половина, либо большая часть команды.
Если вы хотите заниматься разработкой, то сейчас самое время понять, что труд в команде разделяется и каждого должна заботить исключительно его часть работы. Все очень болезненно реагируют на замечания или критику в свой адрес и в то же время позволяют себе постоянно сомневаться в компетентности других участников. Программисты думают, что самая важная часть проекта это они, художники, композиторы, моделлеры соответственно думают точно так же. Но я вынужден вас разочаровать, все люди заменимы. Команда, если хотите, это единый организм, где важен любой его компонент.
Личность каждого, безусловно, ярка и индивидуальна, только в процессе разработки личность человека отодвигается на второй план, и проявлять свою индивидуальность нужно в творчестве, повышая общий энтузиазм новыми достижениями, а не зацикливая общее внимание на личных проблемах.
Следующим порогом является переход от процесса обсуждения благ, которые появятся у участников команды после создания проекта (яхт, машин, особняков и тд.), непосредственно к процессу разработки.
Обычно многие сталкиваются с резким несоответствием своих представлений о разработке и тяжёлыми буднями девелопера. Разработка это в первую очередь рутина, и для того чтобы рутина превратилась в фан нужно очень и очень многое для этого сделать. Можно представить некую модель, безусловно все начинают работу с морем энтузиазма, затем энтузиазм потихонечку угасает, что-то не получается, а миллионов всё нет и нет, именно тут начинается губительный процесс угасания.
Ну что, геймдев это вовсе не весело и забавно как казалось на первый взгляд?
Единственным лекарством от такой болезни является смена подхода. Не стоит раньше времени раздумывать о перспективах и дразнить себя образами дорогих машин или курортных пейзажей. Научитесь получать удовольствие от самой работы, тогда каждое новое достижение будет носить характер некой приятной неожиданности. Вот он фан, вот она истинная радость креатива. А различные тусовки, игры и прочее развлекалово это прикладное, награда за долгий и не лёгкий труд.
Из всего вышеперечисленного можно вывести 5 основных правил, соблюдая которые можно избавиться от негатива, возникающего в команде.
1. Смените личные перспективы на перспективы команды. - Почувствуйте, каково это быть частью сплочённого коллектива, когда вы готовы подставить своё плечо в качестве опоры и любой из команды сделает для вас то же самое.
2. Забудьте о политике. Команда это единый организм, где важна каждая его клеточка и болезнь одной клетки может привести к заболеванию всего организма. - Все любят политику, и все так или иначе пытаются в ней участвовать, но внутри команды политика должна отсутствовать. Перенесите это на пример организма. Только представьте, ваша печень отказывается функционировать, чтобы доказать что она, чёрт возьми, главный орган.
3. Реализуйте свои идеи в вашей области занятости. Не лезьте к гейм-дизайнеру с критикой и советами «как надо», если вы художник. Лучше постарайтесь сделать так, чтобы у остальных отсутствовало подобное желание по отношению к вашим работам.
4. Не думайте о том какого цвета будет ваш Бентли до того момента как у вас реально появятся деньги на то чтобы его купить. Находите удовольствие не в мечтаниях, а в работе.
5. Собирайте команду оптимального размера. Пока есть возможность не набирать новых людей – не делайте этого.
Пролог.
В команде, как таковой, не должно быть первых или вторых ролей, я считаю что, например, дизайнер - такая же по значимости должность как PM (прим. PM – Project Manager). Каждый должен посильно участвовать в работе всех ролей, каждый имеет право обсуждать дизайн, тестировать, планировать. Но всегда когда приходит момент принимать решения - его принимает один человек, который отвечает за соответствующую роль.
Люди, качество взаимоотношений между ними, несомненно - это один из главных факторов успеха разработки.
