{"id":3844,"url":"\/distributions\/3844\/click?bit=1&hash=4d7fce000a2ec2f7e5f8a0040eb16bc6a9d510f51acd726f741f57860d5c603e","title":"\u0415\u0441\u0442\u044c \u043b\u0438 \u0432 \u043c\u0438\u0440\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432\u0435\u0447\u043d\u043e\u0435? \u041e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u043c \u0432 \u043d\u0435\u043f\u0440\u043e\u0441\u0442\u043e\u043c \u0442\u0435\u0441\u0442\u0435","buttonText":"\u041f\u0440\u043e\u0439\u0442\u0438","imageUuid":"2b8bc26b-601b-5389-a8cc-d98f6166a132","isPaidAndBannersEnabled":false}
Инди
Nikita Proskurin

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

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

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

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

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

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

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

  • Научиться самому. И делать все самому. Но это не мой случай.
  • Найти тех, кто сделает. Завлечь их. Постараться облегчить им этот процесс по максимуму. Систематизировать все.

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

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

Неплохой фильм про "лишние вещи"

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

Содержание нашей Confluence на верхнем уровне

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

Содержание нашей 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 года.

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

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

  1. структурирование работы позволяет поддерживать единое информационное поле для команды;
  2. единая среда общения, постоянная запись, логирование и актуализация данных минимизируют искажение информации;
  3. обязательная обратная связь и общение необходимы для того, чтобы все чувствовали себя причастными и находились на “одной волне”. Творчество предполагает постоянный обмен информацией, именно из этого рождаются новые идеи и вдохновение.
  4. систематизация требует определенного уровня менеджерских навыков и хотя бы двоих администраторов, которые будут страховать друг друга.

Приложение

План постов:

  1. Как мы собирались. 28.09.2020 (ссылка)
  2. Как попали на первую конференцию. 05.10.2020 (ссылка)
  3. Как начали планировать разработку. 12.10.2020 (ссылка)
  4. Как набирали команду. 19.10.2020 (ссылка)
  5. Как шли на вторую выставку. 26.10.2020 (ссылка)
  6. Как заводили новые знакомства. 02.11.2020 (ссылка)
  7. Как и зачем меняли прототип. 09.11.2020 (ссылка)
  8. Как работали в период пандемии. 16.11.2020 (ссылка)
  9. Как уходят из команды и “увольнения”. 23.11.2020 (ссылка)
  10. Как ищем инвесторов и издателей. 30.11.2020 (ссылка на предыдущую часть)
  11. Как ставим процессы и базовые пайплайны. 07.12.2020
  12. Как обеспечиваем тимбилдинг. 14.12.2020
  13. Как управлять всем процессом разработки. 21.12.2020
  14. Какие особенности инди-удаленки. 28.12.2020
  15. Как и зачем продолжать расти. 04.01.2021

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

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

  • я в FB: ссылка
  • наш проект в Steam: Saturated Outer Space
  • пример статусного отчета о ходе проекта: *.PDF / *.XLSX (файл xlsx нужно скачивать к себе на компьютер, и вести его там, так как условное форматирование в google-sheets не работает)
0
2 комментария
Денис Кузнецов

"С самого начала разработки я пытался хоть какую-то систему с процессами" - что пытался? =)

Ответить
Развернуть ветку
Nikita Proskurin
Автор

Исправлено)

Ответить
Развернуть ветку
Читать все 2 комментария
null