проблема "говорить"

В этом коротком видео всего за 3 минуты Марк Риттенберг объясняет основную проблему менеджмента в RU/CIS, которая состоит в отсутствии умения налаживать коммуникации. Я думаю, что эта проблема свойственна не только нашему региону, но и EU/USA, возможно, в меньшей форме.

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

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

• мы не знаем что-то, но умолчим и будем долго биться головой об стену, пока не докопаемся до правильного решения задачи.
• о косяках и проблемах, так как пытаемся их решить сами, даже если косячим не мы.
• о сроках реализации, когда что-то пошло не так. Очень редко говорят, что "задача А пошла не так, по причине Б, это займет еще 3 дня", это говорят уже в момент, когда задача А должна быть готова.

Основная проблема тут в страхе, и с этим страхом нужно бороться внутри команды. Команда должна понимать, что если любой человек из нее скажет, что он не знает, как реализовывать эту задачу, то ему не ответят "ахахаха, днище иди учи", а объяснят, как ее делать, или на какие примеры посмотреть для ее реализации.

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

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

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

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

Нужно помнить, что в конце страдает не тот, кто мало работал, а тот, кто молчал и много работал.

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

3 мысли из лекции Никиты Буянова

Думаю, что не я один не подозревал, что существует компания AbsolutSoft, которая сделала и продолжает работу над Contract Wars. По ссылке можно найти первую часть выступления
Никиты Буянова, арт-директора в выше упомянутой компании, который рассказывает нам о выпуске проектов для midcore аудитории.

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

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

Любой инвестор хочет понимать - куда, а главное в кого он вкладывает деньги. В первую очередь деньги вкладываются в команду/людей, которые могут довести проект до конца, потом в сам проект.

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

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

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

Мысль 2: Не знание технологии
Сейчас много всего лежит прям перед нами - Unity, UDK, Game Maker, бери и используй. Порог вхождения в индустрию максимально низкий, но любая готовая технология не гарантирует нам успеха или 100 процентного завершения проекта.

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

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

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

Технология легко может похоронить ваш проект.

Мысль 3: выход за рамки ТЗ
Все в команде знают как сделать лучше, и это хорошо. Но у этой медали есть и вторая сторона, когда желание сделать лучше превращает фичу A в фичу В, потому что все пытались сделать лучше, а сделали совсем другое, а проекту без фичи А не жить никак.

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

Это же касается итераций - всегда должен быть предел, после которого фича апрувится или же выкидывается, и делается новая на ее место. Если такого предела в виде количества итераций не будет установлено в самом начале проекта - будем иметь смещенные сроки на непонятное значение, стремящееся к бесконечности.

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

А еще сходите и почитайте пост о времени у Сергея Климов в блоге.

А где же рок-н-ролл ?

Я тут, как и многие, уже успел посмотреть Grounded: Making The Last of Us, который довольно хорошо иллюстрирует саму разработку игр. Там много очень интересных моментов, даже для тех, кто не играл, а просто интересуется сутью процессов создания.

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

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

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

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

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

Документация устаревает в момент ее написания

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

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

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

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

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

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

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

• пишется one page document или же pitch, который отвечает на основные вопросы и на основе которого принимается решение о том, будет ли делаться проект;
• на основе питча пишется расширенная концепция, которая покрывает вопросы об основных механиках, которые мы будем использовать;
• после этого весь проект разбивается на промежуточные этапы для реализации этих механик;
• на основе этого создается дальнейшая документация, которая покрывает конкретно и детально те фичи, которые мы будем реализовывать на ближайшем промежутке.

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

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

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

Что мы имеем в сухом остатке:

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

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