Инди-разработка игр в команде из 2-3 человек: что реально работает
Инди-команда из 2-3 человек имеет совершенно другой режим отказа, чем большая студия — риски социальные и структурные, а не процессно-тяжёлые.
Реальный риск — не разногласие, а неясная принадлежность
Разногласие о творческом направлении нормально и часто полезно. Реальный убийца проекта — когда ни у кого нет явной власти над конкретной областью, так что решения пересматриваются раз за разом вместо того, чтобы быть принятыми один раз и оставленными позади.
Практическое решение, не требующее тяжёлого процесса: назначьте примерного владельца по умолчанию для каждой области (один человек склоняется к «финальному решению» по ощущению геймплея, другой — по арт-направлению, например) — не как жёсткую принадлежность, исключающую вклад других, а как решающий фактор, чтобы у разногласий был путь разрешения вместо бесконечного застревания.
Контроль версий не опционален даже при этом размере
Потеря работы из-за перезаписанных файлов или конфликтующих правок случается так же легко с двумя людьми, как и с двадцатью — Git (с общим удалённым репозиторием) стоит почти ничего настроить и избегает режима отказа, погубившего не одну маленькую проект. Это применимо к коду и, с правильными инструментами, к некоторым арт/дизайн-ассетам тоже.
Ритм коммуникации важнее выбора инструментов
Короткая, регулярная проверка (даже 15 минут, даже просто асинхронно в чате) не даёт двум людям молча расходиться в разных направлениях по одной и той же фиче на неделю. Конкретный инструмент (Discord, Slack, что угодно) имеет намного меньше значения, чем реальное наличие предсказуемого ритма, на который люди полагаются.
Дисциплина объёма работ сложнее с меньшим числом людей, а не легче
Маленькие команды часто предполагают, что естественно останутся в рамках объёма работ, потому что некому делегировать его расползание — на практике часто происходит обратное, поскольку нет никого, чья работа — сопротивляться идеям «ещё одной фичи».
Запись того, что явно вне объёма работ (не только того, что внутри), даёт команде что-то конкретное, на что можно указать, когда соблазнительное дополнение угрожает реальным срокам.
Разумная минимальная структура для 2-3 человек
| Область | Практика |
|---|---|
| Код/ассеты | Git с общим удалённым репозиторием, с первого дня |
| Решения | Примерный владелец по умолчанию для каждой области, как решающий фактор |
| Коммуникация | Предсказуемый, малозатратный ритм проверок |
| Объём работ | Явный список «этого не делаем», на который ссылаются при соблазне |
Честное преимущество оставаться такими маленькими
Команда из 2-3 человек может принимать решения и разворачиваться намного быстрее, чем что-либо большее — эта скорость реальное конкурентное преимущество конкретно для инди-проекта, и её стоит защищать намеренно, а не случайно воссоздавать накладные расходы процессов больших команд, разъедающие именно то преимущество, которое даёт маленький размер.
Частые вопросы
Какая самая большая причина распада маленьких инди-команд?
Неясная принадлежность решений, а не само разногласие — разногласие нормально и часто полезно; проблема в том, когда ни у кого нет явной власти реально принять финальное решение, так что решения застревают или пересматриваются раз за разом.
Должен ли каждый в маленькой команде уметь работать над всем?
Некоторое перекрытие полезно для устойчивости, если кто-то недоступен, но по-настоящему неопределённые роли («мы все вместе разберёмся») склонны создавать именно ту неоднозначность принадлежности, которая вызывает трения — примерный владелец по умолчанию для каждой области всё ещё помогает, даже если другие могут подключаться.
Является ли контроль версий избыточным для проекта из 2-3 человек?
Нет — это один из наименее необязательных инструментов даже в самом маленьком масштабе, поскольку конфликты слияния и потерянная работа случаются так же легко с 2 людьми, как и с 20, а стоимость правильной настройки крошечна по сравнению со стоимостью потери работы без него.