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

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

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

• Хороший продюсер, это саппорт - он не вершитель судеб, он человек, который помогает команде преодолеть 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 года.

Риски

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

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

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

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

нативное 2D в Unity, GameMaker, эксперты и конкуренция

Вчера произошло событие, которого все ждали довольно давно, о котором все подозревали, но не знали, когда же случится (и главное - все еще не знают). Unity анонсировали нативную поддержку 2D, что звучит хорошо, и в то же время губит бизнес ребят из Asset Store с их 2D примочками, если нативная окажется лучше и удобней.

Впроочем, даже если ребят и не заденет, народ рефлекторно будет юзать нативный - зачем платить 40-50 долларов за стороннее малодокументированное поделье?

А на день раньше произошло еще одно знаковое событие - анонс YoYoGames в виде версии GameMaker Studio 1.2, который теперь флагманский продукт. Отыскать другие версии GameMaker отыскать на сайте производителя очень непросто. Теперь в GameMaker Studio множество новых фишек - шейдеры (нормал мапы, господа!!!), новый компилер и множество платформ, не покрывают они пока только консоли.

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

И сейчас эти два проекта практически наравне:

• низкий порог входа, как для новичков, так и для advanced пользователей
• удобная работа с 2D (в gamemaker так точно, что будет с unity пока не понятно, но верим в лучшее, их ролик обещает многое)
• покрытие множества платформ (конечно, отсутствие консолей в перечне платформ gamemaker немного огорчает, но не понятно, нужны ли они всем)

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

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

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

Out of Scope

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

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

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

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

Но к чему я это веду, это же состояние Out of Scope постоянно случается во время разработки и избавится от него довольно тяжело, если его запустить, но даже в запущенном состоянии это реально.

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

Основные причины, которые приводят к выходу за рамки scope:

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

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

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

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

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

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

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

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

В этом коротком видео всего за 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 недели разработки, позволяет избежать постоянной итерации исходного текста. 

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

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

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

О чувстве собственной важности

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

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

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

Подробнее на википедии.

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

Зачастую самый высокий уровень ЧСВ попадается у дизайнеров, так как удивительным образом наши дизайнеры без имени ведут себя на порядок хуже, чем люди с именем и 10-20 годами опыта в индустрии  из EU/USA (тут мы не берем в пример Клифа, так как у него это публичный образ, который играет ему на руку, прим. редактора).

Проблема с завышенным ЧСВ выявляется у дизайнеров на собеседованиях одним простым вопросом "Вы знаете, чем занимается наша студия?" - в ответ на который человек с завышенным ЧСВ чаще всего отвечает довольно шаблонно. Точнее, двумя путями:

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

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

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

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