Вспомнить все

Существует теория или мне кажется, что она существует, но ее нет, что в детстве мы потенциально умеем и знаем многое (петь, танцевать, рисовать и т.д.). Но с возрастом все эти знания забиваются в глубине нашего мозга другими, более важными в текущий момент.

Со временем мы концентрируемся лишь на том, что нам необходимо в работе. Да, кто-то пытается учиться, заглядывать в смежные области, но черпает оттуда лишь то, что нужно в сейчас для основной занятости.

В этом нет ничего плохого, и это даже хорошо, так как мы все знания адаптируем под свои потребности в конкретный момент времени. Но я это все веду немного к другому - будучи indie, есть шанс вспомнить все, и куда более высокий шанс узнать много нового, так как во всем приходиться разбираться самому.

Главным стимулом к обучению становится лень - двигатель прогресса, а мы все существа ленивые и без стимула никак. Вместе с ленью нас стимулируют ограничения - нет большой команды, нам некуда делегировать задачи. Мы начинаем разбираться сами, копать матчасть, смотреть туториалы и адаптировать это под свои нужды.

Так, к примеру, много лет назад я зарекся, что буду скриптовать, так как мне это банально надоело. И я действительно не скриптовал до начала этого года, когда мы начали в свободное от основной работы время делать проект - мне пришлось лезть и разбираться в юнити, найти удобный для себя формат и работать в нем (с playmaker мне стало куда проще работать с Unity). Но это "разобраться" пошло дальше, и я сейчас с удовольствием берусь поскриптовать в своем основном проекте, хотя это и не входит в мои обязаности, а мне, как оказалось на самом деле, нравится скриптовать.

В один период я учился рисовать, так как у меня не было возможности найти в проект художника, и со временем начало получаться. Да, было очень далеко до гуру, да и до джуниор артистов, но для своих потребностей было достаточно. Главное, что я понял - туториалы реально могут помогать, и они вытягивают из головы знания, которые где-то там уже есть (в школьные годы я хорошо рисовал, особенно любил натюрморты и цветовую абстракцию).

На днях мне пришлось разбираться с google analytics, который я видел впервые, так как мы запускали блог для Isles Of Umbra и нуждались в статистике, которую в tumblr посмотреть нельзя. Теперь полученные знания и понимание работы google analytics мне пригодятся и в основной работе, так как я никогда с ним не сталкивался (в основном работал с самописными тулзами для статистики, которые более выгодны для игровых проектов, чем сторонние).

Да, есть останавливающие факторы - в основном это нежелание разбираться и искать, а также время, которое тратится, так как это дополнительная нагрузка, даже если вы не один человек, а маленькая команда, кому-то придется делать RND всего, с чем вы не знакомы или никогда не работали.

Да, можно сказать, что так мы никогда не будем профессионалами в одном направлении, но будучи indie необходимо быть человеком-оркестром, и уметь все на удовлетворительном уровне (критерии умений и знаний ставим себе сами) лучше, чем уметь что-то одно, но при этом утонуть в попытках найти людей, которые будут уметь другое и готовы войти в вашу команду

Indie way #3 - Games Jamm's

Последних несколько месяцев не было совсем времени, чтобы писать в блог, да и не было о чем говорить. Но пост об участии в games jamm's и пользе от них созрел давно, и самое время в преддверии нового Ludum Dare поделиться своими мыслями.

Первый раз в игровом джеме я участвовал несколько лет назад, в гордом одиночестве, пытаясь сделать платформер. По итогу мне ничего так и не получилось, а я забил на эту идею на несколько лет.

Следующий раз, уже два года назад, мы собрались командой в три человека и участвовали в Ludum Dare, с игрой в стиле The Sting!. Это был командный зачет, у нас было 72 часа, за которые мы не сделали толком ничего, так как уперлись в проблему планирования времени.

В последнем Ludum Dare я участвовал лишь для того, чтобы проверить возможность концепции, и я ее удачно проверил, не выложив игру, но так родилась Isles Of Umbra, правда, тогда в совсем текстовом режиме, но это дало возможность поверить в свои силы и начать делать этот проект.

Последним джемом, в котором я участвовал, стал Games Jam: Kanobu, благодаря которому проект получил публичность. Мы приняли участие в двух этапах - игровой концепт и концепт арт. По итогу, хоть мы и ничего не выиграли, но собрали команду и сейчас делаем проект во всю, с желанием его закончить по IGF.

Джемы стали спортом для игровой индустрии, своеобразными забегами на выносливость, которых становится все больше. Иногда кажется, что скоро вся индустрия превратится из девелопмента в джем-батлы.

Но давайте теперь поговорим о том, что же нам дает джем:

• Proof of concept - да, большинство джемов имеют установленную тему, но никто не мешает придумать игру под нее, проверить ее на жюри и игроках, которые будут оценивать и по итогу уже сделать выводы. На эту проверку не уйдет много времени и вы сделаете необходимый минимум, так как сроки очень сжатые.
• Планирование времени - работая над игрой, похожей на The Sting!, нашим главным врагом было время. Мы слишком долго думали над тем, какую концепцию выбрать под тему, решили писать свой движок вместо того, чтобы взять готовое решение, плюс усталость, которая с каждым часом нас тормозила, так как мы жестко рашили. Но, выявив проблемы, с ними не сложно бороться - брать готовые технологии, в которых есть разбираешься, ставить временные рамки на каждую часть работы, если выходим за них - упрощать и урезать. Проверкой для меня станет новый Ludum Dare(25-28 апреля) где я буду с новой командой.
• Публичность - вы привлекаете к себе внимание, даже простые посты в блоге процесса разработки Ludum Dare могут вызвать бурное обсуждение в комментариях, а это уже хороший старт для дальнейшего развития проекта.
• Команда - благодаря Games Jam: Kanobu нам удалось собрать отличную команду. Не принимай мы там участия - мы бы еще долго искали художника и людей, готовых нам помогать, или даже просто ретвитить и шейрить сообщения о статусах разработки.
• Работа с ограничениями - бытует мнение, что ограничения - это плохо. Но на самом деле ограничения есть во всем, на протяжении всего девелопмента, и они стимулируют к лучшим решениям, чем безграничные ресурсы.

Еще один большой и важный плюс - джемы помогают выявить проблемы внутри команды, если вы участвуете не в одиночку, даже если вы, казалось бы, уже сработаны. Любой джем - это стресс, сжатые рамки, проблемы коммуникаций, которые вылазят наружу в первые часы и если их не решить, проект будет погублен. Выявляя эти проблемы в джеме, их можно исправить уже внутри сработанной команды. Для молодых и только созданных команд это хорошее испытание, чтобы сработаться либо увидеть, кто вам не подходит.

Indie way #2 - Ограничения

Продолжаю серию постов о indie-разработке, и сегодня речь пойдет о ограничениях и их пользе в разработке, и это касается не только indie-проектов. Следуя ограничениям, нам приходится изворачиваться и придумывать вещи куда интересней, чем если бы у нас были полностью развязаны руки.

Я уже не первый раз говорю об ограничениях, и в этом блоге тоже было несколько постов. Но я не устану это повторять, так как игровой дизайн - это problem solving, а при ограничениях чем, как не problem solving заниматься.

Но прежде чем мы начнем, посмотрите выступление Petri Purho, который рассказывает хорошо об ограничениях через призму отсутствия бюджета для игры, и почему это хорошо для разработки.

А теперь давайте поговорим про ограничения, которые разделим на три категории:

• Технология - я не зря первый пост из серии написал о технологиях, так как базируясь на их ограничениях, мы строим наш девелопмент. Я много раз слышал, что технология не должна тормозить дизайн, что наши программисты напишут технологию, на которой можно будет делать все и т.д. Но легко девелопить фичи там, где нет границ - делай что хочешь, даже особенно задумываться не надо. Другое дело, когда ты знаешь рамки, знаешь, что точно нельзя делать, и пытаешься придумать уже на этом дизайн, решив конкретные проблемы. 
• Деньги - имея ограниченный бюджет, мы зачастую получаем игру про капитана кругляша и его верных помощников квадратов. Да, деньги могут стать причиной закрытия проекта, но бюджет нам нужен для дополнительных сотрудников, возможно офиса, нанять художника, который сделает нам крутую картинку и т.д. Не имея возможности привлечь дополнительные ресурсы, используя ограниченный бюджет, мы концентрируемся на главном, том, что получается у нас лучше всего.
• Skills - да, много людей-пароходов, которые могут на достаточно уровне держать все части игры. Но так же много людей, которые пробуют, не умея рисовать, писать музыку или писать код. Используя для этого тулзы, которые не требуют знаний в программировании, бесплатные ассеты вместо графики (или покупая ее) и концентрируются на геймплее как главном, или технологии, или картинке - в зависимости от уровня скиллов. 

Ограничения позволяют нам не распылятся, не придумывать ничего лишнего и концентрироваться на главном - это может быть геймплей, музыка, код, арт. Но важно понимать, что лучше сконцентрироваться на сильной стороне проекта, той стороне, которую вы ему способны дать, и использовать для этого ограничения.

Indie way #1 - Технологии

Решил сделать серию небольших постов про indie development, которым я занимаюсь в свободное время. Точнее, уже много-много времени, и все никак не могу сдвинуться дальше кучи прототипов, которые попадают в стол. За это время набралось много всяких мыслей, которые не тянут на большой пост, а вот в блиц-формате пойдут хорошо. 

Так что, пожалуй, начнем с технологий, где я буду капитаном очевидность, и вообще говорить о понятных для многих вещах.

Я всегда завидовал людям, которые максимально универсальны, могут и код писать и рисовать и музыку делать, и дизайн придумывать. Даже если все это делается не на high level. При наличии таких умений разрабатывать indie-игру куда проще, чем обладать узкопрофильными знаниями.
Все таки, если нет возможности собрать команду, то indie для людей-пароходов.

Прототип платформера с ревайдом времени с использованием GameMaker 8.1

Свой первый прототип/игру я сделал в 12 лет, и тогда мне это казалось просто "ВАУ!!!!!!!1111, я смог это сделать", для этого я использовал Blitz Max, на который случайно набрел в интернете, начитался туториалов и сделал змейку с генерируемой графикой. (в основе лежал один из туториалов для Blitz Max, который я довольно сильно модифицировал).

Прототип одного из проектов с использованием самописного движка

Со времени первого прототипа я перепробовал множество технологий, попытался стать человеком-пароходом - я стал дизайнером, начал писать музыку, подтягиваю постоянно свои знания в написании кода. Я даже пытался научится рисовать, но с этим не срослось вообще, хотя в будущем буду пробовать еще.

Прототип UI проекта, который я делал вместе с mercai используя UDK

Ладно, вступление как-то затянулось, так что перейдем к технологиям. За последние годы я опробовал многое - Unity, UDK, Game Maker, Stencyl, Construct, вновь Blitz Max с желанием сделать модификацию на SCP, Twine, Phaser и т.д. Кстати, у Pixel Prospector есть хороший гайд по технологиям, используемым для разработки игр, и проектам, сделанных на них. Проекты, понятное дело, не показатель удобности технологии, но гайд интересный.

Я на всем пытался делать прототипы, чтобы понять для себя ограничения, о которых мы поговорим в одном из следующих постов, и пользу, а также понять, насколько и где удобно работать.

Попытка сделать красивый Volume light с использованием GameMaker 8.1

За время экспериментов я вывел для себя ряд абсолютно очевидных критериев, которые касаются не только игр, но и вообще разработки чего либо, просто потому что они помогают проще жить. Но в случае с игровыми движками все необходимо изначально было опробовать на себе. Итак, критерии:

• Документация -  как по мне, самый важный элемент любой технологии. Она помогает понять, как с этим работать, какие есть подводные камни и насколько сильно придется танцевать с бубном. Чем меньше документации, тем сильнее мы полагаемся на сообщество.
• Сообщество -  помогает с примерами, дает ответы даже на самые часто задаваемые вопросы по сотому разу, помогает с pro tips и прочими интересными вещами, которые не так легко обнаружить. Самое слабенькое коммюнити сейчас у Phaser, но тут и понятно, каждый считает, что проще написать свой html5 framework, чем развивать уже существующие, там дикий запад. Самые хорошие, но это опять имхо, у Game Maker и Unity.
• Простота использования - больше в контексте порога вхождения, так как не всегда высокий порог вхождения означает, что можно сделать что-то очень крутое,  но чем он выше, тем меньше людей остается с этой технологией, отсюда и меньшее количество людей в сообществе.
• Поддержка со стороны разработчиков - когда нет ответа в документации или в сообществе, единственный путь - обратиться к создателям. Когда есть официальная поддержка (пускай платная, что даже лучше), работать с таким движком куда приятнее, так как выше вероятность получить ответ. Но часто ситуация обратная, когда ответ нельзя получить и от разработчиков, так как они такого не пробовали делать или по другой причине (недавно читал подобный тред в сообществе Construct, где народ обсуждал парсинг текста).

Не помню, что за прототип, но на Unity ;)

Получилось немного больше, чем заметки на полях, следующие посты будут короче и более точечные, по конкретным идеям или проблемам.   

Изоляция

Сегодня должен был быть совсем другой пост, такой себе крик души, но я решил его отложить. На его месте будет продолжение моих недавних мыслей в твиттере на тему попыток поднятия денег и замкнутости нашей теплой и уютной индустрии.

Что мы делаем. Каждый раз, когда в любой компании людей заходит разговор - кто чем занимается, возникает тот неловкий момент, когда довольно тяжело объяснить, что же ты делаешь, и что такое делать игры. Как показывает практика, для людей со стороны игры - это что-то на уровне забавы и не может быть серьезным, не говоря уже о том, что это серьезный бизнес. За последних 5 лет мы пытались примерно 5 или 6 раз открыть собственную студию, и только один раз нам это удалось. Со всеми с кем мы общались, и у кто был не профильным инвестором был лишь один ответ "Я в этом ничего не понимаю и не буду инвестировать". Многие готовы инвестировать в e-commerce, и только единицы в игры. С одной стороны это не плохо, так как остаются не профильные инвесторы, но с другой их не так много и количества денег не достаточно для всех, кто пытается что-то делать.

Мы пытаемся повзрослеть. Наша теплая и ламповая индустрия усиленно пытается повзрослеть, пытаясь догнать кино, делать игры про серьезные проблемы, но мне кажется, что это путь не в ту сторону. Это взросление важно для аудитории, но никак не важно для денег, которые нужны на старте и во время девелопмента, так как все эти действия направлены на конечного потребителя, который пойдет покупать проект после релиза, если тот, конечно, случится...

У нас нет громких выходов. Мы замкнуты сами в себе, мы обсуждаем новости и проблемы в замкнутой экосистеме, и даже если эти новости хорошие и про большие продажи или прибыли, они остаются на страницах профильной прессы. Мы устраиваем хакатоны, но они привлекают наблюдателей со стороны, это опять таки наше внутреннее соревнование, чтобы показать свой уровень и засветиться среди своих. У нас нет громких выходов, о которых бы говорили все, а не только профильная пресса. Последним таким была продажа доли Super Cell за $1,53B, до этого - выкуп Activision Blizzard у Vivendi, помните еще что-то?
Да, тут можно вспомнить крах THQ или успешных социальных и мобильных издателей, но это опять таки своя уютная тусовка.

У нас есть kickstarter. После смерти привычной схемы работы через издателя у нас осталось два пути - искать инвесторов или собирать деньги через kickstarter или подобную проблему. В нашем случае kickstarter работает как хороший фильтр для проектов, так как направлен напрямую на привлечение будущей аудитории проекта. Как мне кажется, он может стать хорошей платформой для дальнейших инвестиций в студии, которые будут приходить извне индустрии. Все потому, что кикстартер публичная доска, где видно - что студия делает, смогла она собрать деньги или нет, как она будет зарабатывать, достаточно ли она просит денег на свою идею и тем самым реально ли оценивает свои силы. Очень полезный инструмент, только его стоит сделать массовым...

Тут можно еще о многом написать. Но главное, как мне кажется, то, что нужна схема, которая позволит нам стать более публичными и более взрослыми в этом плане. Да, будут возникать пузыри, но они были и раньше, и 90 процентов их смыло кризисом 2008. Они не затронут людей с хорошими проектами, которые понимают что делают. Все как и раньше.

В заложниках ситуаций

Так как я пропустил прошлое воскресенье и не написал ни одного поста в блог, то сегодня я буду отдуваться в двойне, и выберу более сложную и многогранную тему, которая касается увольнений в игровых студиях, и почему мы не выгоняем людей, когда они косячат.  

За последние несколько лет я не видел громких и массовых увольнений, хотя был свидетелем увольнения целых отделов, потому что руководство уставало от постоянных косяков, но это было довольно давно. Как и текучки в игровых компаниях - ее давным давно нет. Здесь я не рассматриваю уходы части команд, студии, которые выступают кузницей кадров для индустрии, закрытие студий или массовые сокращения по причинам кончившегося бюджета. Но если смотреть на нашу индустрию, то можно увидеть, что текучка действительно не большая, и вызвана она в основном уходом людей в момент, когда они считают, что нужно расти дальше или открывать свою студию, или же получают более выгодное предложение.

Но не смотря на небольшую текучку, я наблюдал другую ситуацию - когда людей не увольняют за косяки, а предпочитают их держать, проводя беседы, в надежде что человек поймет проблему и исправит ее. И эти ситуации повторялись в разных компаниях с разными уровнем факапа. Все выбирают увольнение как крайнюю меру, что, как мне кажется, не самое хорошее решение. 

Мы заложники. С одной стороны, люди - это главная часть нашего рабочего процесса, с другой стороны, мы все находимся в заложниках каждого отдела. Все процессы внутри разработки одного проекта зависят от разных отделов - дизайн зависит от реализации функционала для него программистами, программисты зависят как от дизайнеров, так и от художников, а удачный запуск проекта зависит от отдела маркетинга.

Но все работает правильно и идеально только в сферическом вакууме, в котором мы с вами никак не находимся, зато постоянно сталкиваемся с тем, что процессы сбоят, и нужно  принимать решения, которые вернут их к правильной работе.

Когда эта ситуация происходит на ранних этапах разработки, мы можем принять меры - сменить даты релизов, сменить исполнителей. Когда же это происходит на более поздних этапах - мы оказываемся в заложниках, так как есть люди, которые уже сделали большой кусок функционала, нарисовали много арта, написали много квестов или текстов и, сменив исполнителей, мы начнем терять время, возможно, очень много времени.

Время мы будем терять на поиски нового человека, на то, что человек потратит кусок рабочего процесса на разбор работы своего предшественника. Потому мы выбираем меньшее, как нам кажется в этот момент, из зол - разговор. Мы проводим беседы в надежде, что люди осознают, что они делают что-то не так и примут меры сами, мы надеемся на сознательность команды.

Вторым шагом мы переносим даты релизов, объяснив это для себя тем, что мы провели беседы, и это больше не повторится. Но почему-то это повторяется, а иногда с куда более плачевными последствиями для проекта, чем первый раз.

Разговоры не имеют смысла. Разговор в такой ситуации работает как стресс, и как любой стресс он заставляет людей "пробудится от сна разума" и начать делать свою работу, но этого не хватает на долго. Да, можно создавать такие стрессы постоянно, но есть высокая вероятность того, что команда под действием стрессов выгорит, и придется заменить всю команду, а возможно и закрыть проект. С другой стороны, разговор ничего не дает в более длительной перспективе, так как он не выступает гарантией того, что человек, показав сейчас понимание, не повторит тех же ошибок, когда внимание менеджмента переключится на другие проблемы, посчитав, что разговор помог.

Мы боимся терять время. При любых ошибках мы теряем самое драгоценное, это время, которое в нашем случае = деньги. Тратя больше времени чем мы планировали, мы приходим к тому, что бюджет, выделенный на определенное время, закончился, а проекта нет, нужно платить людям зарплату, а когда мы сможем выпустить проект, все еще не понятно. В страхе потерять время мы не увольняем людей, а ведем беседы, так как это опять таки меньшее из двух зол, как нам кажется. Хотя если смотреть на это глобально, то в беседах и попытке пробудить людей мы тратим больше времени, чем на поиск новых специалистов.

Искать новых специалистов тяжело, так как у игровой индустрии есть главный конкурент - рынок софтверного аутсорса, куда, к примеру, легко переманивают хороших и талантливых программистов. Есть большие компании, куда мечтают попасть дизайнеры и художники и т.д.. Поиск хорошего специалиста занимает время, много времени, и это время мы боимся потерять и выйти за рамки бюджета.

Нужно увольнять. Увольнения - это стресс, не только для одного человека, но и для всей команды, но это необходимый стресс, дающий понять, что делать косяки плохо, особенно если от этих косяков страдает вся команда. Люди должны быть ответственны за работу, которую они делают, если они этого не могут, от таких людей нужно избавляться на проекте. Увольнять нужно, исходя из обстоятельств, это может быть после первой беседы, это может быть после серьезного факапа, но с этим не стоит затягивать, иначе эта ситуация будет повторяться из раза в раз.

Понятно, что тут каждая студия выбирает путь для себя сама, это либо беседы, либо увольнения, точного решения проблемы нет, но нужно  понимать, что с проблемами необходимо бороться, и если не помогают разговоры, то необходимо переходить к увольнениям и поиску новых специалистов.

Борьба с ветряными мельницами

На стартаперском сленге, буквально в эту пятницу, я соверши exit. Я покинул игровой стартап, который начинался с арт-директора, меня и профильного инвестора. За почти 4 года, что я в нем провел, он вырос до 55 человек, изменился и начал требовать свежей крови, чем и был обусловлен мой уход.

Чтобы как-то начать этот пост, я вспомнил, как в детстве  довольно сильно любил Дон Кихота, который отвержено отправлялся на борьбу с ветряными мельницами. Когда я попал в индустрию, то понял, что тут каждый сам себе Дон Кихот, а ветряные мельницы на каждом углу, и вся карта затянута туманом войны.

Я всегда считал и продолжаю считать, что идеи в нашей индустрии ничего не стоят. И если пройтись по любому офису(маленькой или большой студии, тут значения не имеет), у каждого будет как минимум одна идея, которую он бы хотел делать. В нашей индустрии многого стоят люди, которые смогут реализовать ту или иную идею, и эти же люди являются ее главной проблемой. Люди это одна из первых мельниц, которую мы встречаем на пути к успешному проекту.

В отличии от аутсорса, в котором люди работают в одном направлении, игры это работа нескольких таких групп - дизайнеры, артисты, программисты, продюсера и bizdev'ы, маркетинг. Все эти люди разные не только в плане своих обязаностей, но и в плане психотипов и характеров. Кто-то считает что он великий художник, но при этом не умеет называть слои, кто-то считает себя гениальным дизайнером, но не может нормально задокументировать фичи и срывается на коллегах и т.д. Все они разные и по-своему талантливые, и всех этих людей нужно заставить работать вместе как один единственный механизм.

Тут возникает наша вторая мельница, это процессы. Только правильно построенные процессы могут сделать так, чтобы все эти люди не конфликтовали, чтобы программисты не ходили злые на артистов за неправильно названые файлы или слои, а артисты на дизайнеров за непонятный дизайн, по которому не понятно, что рисовать. И главная проблема тут в том, что не существует универсального рецепта, который можно применить ко всем командам. К каждой команде необходимо искать подход, пройти через ссоры, срывы сроков, увольнения и все таки построить процессы, которые позволят работать над продуктом.

Ну а третьей мельницей пускай будет лень, которая есть в любой индустрии, у любого сотрудника, но в играх у нее явное обострение. Недавно в блоге Сергея Климова, был хороший пост про людей, которые попали в индустрию "вопреки" всему - отсутствию больших денег, постоянной и сложной работе, давлению со стороны и т.д. Но в том посте был один главный пункт, что люди в индустрии должны делать постоянно переоценку ценностей, так как индустрия меняется и просто сесть и расслабить булки не получится.

А я последних несколько лет замечаю другую ситуацию, когда люди приходят в компанию с горящими глазами, с рвением делают свою работу, а спустя 2-3 года садятся на стул, расслабляются и перестают перформить. Хотя казалось бы, что вылететь и оказаться за бортом индустрии на 3-5 лет довольно легко, но это не пугает людей. И на само деле людям ничего не мешает  изучать что-то новое, пытаться себя как-то развивать, учитывая, что все есть в свободном доступе, а рядом есть коллеги, которые могут помочь. Складывается впечатление, что проработав долгое время на одном месте,  все пытаются свить себе теплое местечко там, забив на все остальное. Но не стоит забывать, что чем сильнее увлекаешься cover my ass development'ом, тем холоднее это место становится. Наша индустрия не постоянна, в ней происходят переменный каждый год, и если не пересматривать свои знания и умения, далеко в ней не убежать.

Можно еще довольно долго говорить о разных мельницах, их довольно много и для каждой команды они будут свои, тут все сильно зависит от самой команды и тех, кто эту команду тянет вперед. Я выделил лишь то, с чем сталкиваюсь с завидной регулярностью, в попытке построить dream team, которой под силу будет сделать любой проект вне зависимости от его сложности.

Хороший Продюсер

Мне хотелось написать большой пост о хороших продюсерах, но когда я начал его писать, я понял, что надолго меня не хватит и это превратится в кашу. Да и многие из нашей индустрии уже писали про хороших продюсеров, так что я выскажусь коротко. 

Этот пост коснется в трех небольших тезисах того, что по моему мнению должен делать хороший продюсер в команде, чтобы команда была успешной и успешно делала проекты.

• Хороший продюсер, это саппорт - он не вершитель судеб, он человек, который помогает команде преодолеть milestones и все ключевые этапы, а на этих этапах получить самый высокий результат. Но многие почему-то возомнили себя вершителями судеб в проекте, для таких в аду будет отдельный котел.
• Хороший продюсер внутри команды полностью абсорбирует все внешние стрессы - под внешними стрессами я подразумеваю любые запросы от издателей, инвесторов и других люде, которые пытаются залезть в мозг команде, посеять там хаос и всячески донести важность своего мнения. Задача продюсера работать как прослойка, которая пропускает в команду лишь важное не создавая из этого стресса для разработки.
• Хороший продюсер создает внутренние стрессы, которые позволяют команде двигаться дальше - это такой человек с флагом, который поднимет команду даже с колен, и она встанет и пойдет к следующему milestone и успешно его выполнит

Таких людей не хватает нашей уютной индустрии, и чем больше их будет появляться тем лучше и качественней будут проекты. Сейчас в большинстве случаев, мы имеем дело с вершителями судеб, которым все равно на проекты. 

Вертикальные связи, нетворинг и суровая реальность

Мне кажется, что мы больше говорим чем делаем. На каждой конференции или выставке,мы говорим о том, что нам нужны связи, нам нужна открытость, чтобы прийти и спросить ответа. И все согласно кивают головами, пытаются о чем-то говорить, обменяться контактами, да только на этом все, в большинстве случаев и заканчивается.

На каждой конференции или выставке, мы все обмениваемся визитками, о чем-то говорим для вида, а уже после них забываем, кто эти люди, и чем они могут нам помочь. И даже открыв их визитки, это ничем не помогает.

У меня в рюкзаке лежит большое количество визиток со всяких мероприятий, на них красуются надписи CEO/CTO и так далее. Иногда там написан сайт компании, на который я могу сходить. В 90 процентах случаев, все эти сайты не несут никакой информации, которая бы дала понимание с каким вопросом я могу обратится к этим людям.

Соответственно связи теряются либо навсегда, либо до следующей выставки, когда можно будет увидеть людей, если они в этот год приедут.

Вторая проблема, это наша занятость, за пределами которой нет времени на что-то еще. Мне иногда приходят письма с вопросами, я помечаю эти письма звездочкой, чтобы обязательно прочитать и ответить. Но в целом у меня в день приходит 200 писем, на которые нужно отвечать по работе. И на их фоне, письма с вопросами быстро теряются, а когда до них доходят руки, этот ответ уже может быть не актуальным.

Третья проблема и самая главная наши разговоры, мы все говорим, но на самом деле не хотим делится информацией. Возможно так сложилось исторически, что мы боимся, что украдут наши идеи, или воспользуются нашими советами, а мы с этого ничего не получим.

Пока эта проблема не исчезнет, наша индустрия будет уютной,но и закрытой, когда каждый идет своим личным путем, не имея возможности посоветоваться, так как не может либо найти людей делавших подобное, либо люди просто не могут ответить во время.

У меня за последний месяц было два насущных вопроса, один уже отпал, так как я нашел ответы на него сам, так как я не смог найти людей из CIS, которые подавались на IGF и могли бы мне прояснить ряд вопросов про early build. Но ответы я нашел сам и мы решили не гнаться в этом году за IGF, так как мы просто не успеем, и слишком поздно за это взялись.

Но теперь я смогу ответить на вопрос про IGF, если меня спросят, и я надеюсь, что мой ответ кому-то окажется полезным.

Второй вопрос который меня волнует, это площадки, на которых стоит сконцентрироваться для освещения проекта, так как мы планируем скорый анонс, то этот вопрос с каждым днем волнует меня все сильнее.

Да, у меня есть определенный план на ближайших 5 месяцев, по работе с коммюнити, прессой и т.д. Но я не уверен ни в одном пункте в нем, и мне не у кого спросить. Потому что все, у кому я могу задать вопрос, пошли по другому пути, либо еще делают свой проект, и находятся в той же точке что и я.

Такие дела.

CIS Indie House

Вот уже долгое время меня не покидает идея создать в CIS регионе пространство для работы indie-команд, где люди смогут найти себе партнеров в проекты или же просто начать/доделать свой проект. Пространство, которое направлено только на игровые проекты.

Я долго думал над форматом, изначально мне нравился вариант Indie House Toronto, но в наших реалиях он не будет ничем отличатся от обычного коворкинга, которых сейчас расплодилось довольно много.

Но окончательную формат данного пространства в моей голове сформировало две вещи:

• дать возможность разработчикам полностью сконцентрироваться на работе над проектом и убрать их от суеты города и прочих проблем, оставить в поле виденья только проект.
• школа дизайнеров Campus, которая была создана при поддержке Яндекса.

Собственно, ниже я попробую без сумбура изложить мысли на эту тему, и что именно хочется сделать.

Формат пространства
Пространство представляет собой место, в котором может работать 2-3 команды на постоянной основе и 3 сессионных команды. Максимальное количество участников - 20-25, из них:

• 10 - 12 постоянных участников
• 10 - 13 сессионных участников

Формат предполагает, что пространство находится удаленно от городов, и команды, участвующие в пространстве, проживают в нем на постоянной основе, либо в то время, пока проходит одна сессия.

Данный формат позволит убрать для участников команды рутину и суету, с которой они постоянно сталкиваются, находясь в городах. Тем самым команды получат максимальную концентрацию на проекте.

Также в формат будет входить:

• лекции от людей из индустрии - что позволит участникам получить дополнительный опыт
• нетворинг - когда команды деляться опытом друг с другом, чтобы уменьшить количество ошибок и риски
• совместное обсуждение проектов - чтобы повысить качество разрабатываемого продукта и получить отзыв от людей изнутри индустрии
• колаборейшен для создания новых проектов

Цели

1. Создать пространство как для работающих команд, так и для новичков
2. Создать площадку для обмена опыта, тем самым снизив риски разработки
3. Дать возможность командам начать либо завершить проект, концентрируясь только на нем 
4. Развивать indie-команды в CIS и помогать им выпускать проекты

Это не инкубатор и не акселератор
Важно понимать, что данный проект не является ни инкубатором не акселератором. Мы не будем давать командам деньги на разработку. Наша задача создать пространство, в котором команды максимально продуктивно смогут работать над проектами и обмениваться опытом с другими командами.

Пространство должно обеспечить максимально комфортные условия для разработки.

Формат участия в пространстве
Пространство подразумевает два типа участия:

• на постоянной основе
• сессионное участие

Постоянное участие предполагает:

• 2-3 команды, которые являются костяком пространства
• работают на постоянной основе в пространстве над своим проектом
• занимаются делами пространства, чтобы обеспечить максимальный комфорт участников пространства
• выступают финансовой стороной пространства

Постоянный состав может расширяться в зависимости от развития пространства, но изначальный костяк, это 2-3 команды.

Сессионное участие:

• участие в пространстве на протяжении 3-6 месяцев
• цель - начать проект и довести до прототипа, либо закончить уже начатый проект
• участие также 2-3 команд на первых этапах

Изначально для сессионного участие будут отбираться только команды с опытом, после второй сессии будут привлекаться новички для обучения. Первые две сессии должны показать успешность проекта.


Что необходимо для участия
На данный момент это все находиться лишь на стадии задумки, и, возможно, в некоторых концептуальных аспектах требует доработки. Но уже сейчас можно говорить о том, что потребуется для открытия такого пространства:

• костяк постоянных участников, которые выступят параллельно инвесторами данного пространства и будут его поддерживать (данный вопрос можно закрыть через внешних инвесторов или привлечение фондов, но хотелось бы, чтобы костяк команды плотно был вовлечен в работу пространства)
• Выбор места дислокации пространства, где оно будет находиться и на какое количество человек будет расчитанно
• Подготовка самого пространства для первой сессии
• Финансирование всей этой затеи

Основные моменты, с которыми необходимо определится на данный момент, это костяк команды, проект самого пространства и финансирование, которое потребуется для реализации данного проекта.

Исходя из этих элементов, мы сможем понять основные риски, а также сформировать необходимый бюджет для открытия пространства. Уже на основе этой информации мы сможем сформировать сроки на открытия пространства, в данный момент хотелось бы открыть его уже весной 2014 года.

Риски

Возможные риски:

• Не заинтересованность команд в таком пространстве, так как команды могут рассчитывать на финансирование их проектов, что пространство не предполагает по своей концепции
• Расположение пространства - может быть выбрано неудачное расположение пространства и по определенным причинам, команды могут быть не готовы сменить дислокацию
• Бюджет - костяк команды может не собрать необходимый бюджет на создание пространства, и необходимо будет заняться поиском внешних источников финансирования проекта

Данные риски необходимо максимально покрыть на этапе обсуждения концепции пространства, прежде чем переходить к работе над ним. 

Собственно вот такие мои мысли, давайте будем обсуждать, если кто-то заинтересован в проекте и хочет к нему присоединиться.