Путь инди. Часть 11/15. Как ставим процессы и базовые пайплайны

“Все управление в конечном счете сводится к стимулированию активности других людей”
Ли Якокка

Кто я, чем я делюсь и почему вам может быть интересно, указано в первом посте (ссылка).

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

Ссылки на все статьи из серии в приложении.

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

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

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

1# Принцип достаточности и необходимости

Не перегружать всех планированием и отчетностью было очень важно. Но нужно было постоянно иметь актуальный список задач каждого участника. Поначалу я взял это на себя, поднял Jira для команды, завел там проекты, согласно направлениям работы (код, геймдизайн, арт, административные вопросы и так далее). Но тасктрекер в нашем случае стал не кнутом в руках менеджера. Это просто список дел, разбитый по типам, срокам, ответственным, приоритетам и прочим параметрам, которые кажутся важными. На первых порах задачи ставил я сам, а в большинстве случаев закрывал их тоже сам, даже за других людей. Теперь этим занимается наш PM. Что это дает для команды? У каждого всегда есть список его личных задач с приоритетами. Каждый знает, что ему надо делать в моменте и что надо будет делать после. Нам это помогло исключить дурацкие вопросы “а что мне делать, я не знаю” или “это не моя задача”. Закрывать таски никого не заставляем, главное, чтобы задачи выполнялись как таковые.

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

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

На мой взгляд эти 3 инструмента как раз то, что является минимальным и необходимым для каждой команды. Если не хотите поднимать Jira и Confluence, то в виде альтернативы могу посоветовать Trello и Notion, соответственно. Функционал конечно не такой широкий, но на старте закроет все, что может пригодиться. Я знаю, что существуют еще и Google-документы, но без них вообще никуда, я даже не рассматриваю их, так как это инструмент из разряда “must have”.

2# Если что-то не написано, значит этого нет

Так как команда у нас больше 3 человек информация не может храниться только в головах участников. Поэтому ввели правило “все обязательно записывается на Confluence”: геймдизайнерские решения, изменения в ЛОРе, смена размеров предметов и юнитов, таблицы параметров, наборы ассетов, контент-планы, пайплайны, маркетинговая стратегия и прочее. Иногда вести на Confluence что-то неудобно, тогда обязательно пробрасываем ссылку на соответствующий документ или ресурс. Если какая-то информация не была закреплена письменно (ссылкой), то считается, что этого не обсуждали, этого просто не было.

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

3# Создавать и использовать пайплайны

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

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

4# Единая среда общения

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

5# Постоянная обратная связь и общение

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

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

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

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

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

Период, который я обозрел: февраль 2019 - октябрь 2019 года.

Дифирамбы: руководитель команды (администратор / РМ) - это не тот, кто со всех требует выполнения работы. Это тот, кто упрощает всем жизнь, организовывает процессы, делает так, чтобы всем было понятно как, в какое время и что от них потребуется. Это тот самый свет в конце тоннеля, а не поезд, который наезжает всем на пятки и просто бесит.

Что надо, чтобы управлять разработкой в не маленькой команде:

Приложение

План постов:

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

Дополнительные ссылки и материалы: