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

В чём дело? Понятно, что человек, работающий один, получает весь приз себе.
Понятно, что при отсутствии главного демопати трудно планировать большие проекты.
Но главное не в этом. Главное - не выработано умение работать в команде.

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

Но в хорошей команде надо уметь работать.

* * *

У каждого проекта есть руководитель, он же пинатель.
Это не обязательно программист, но лучше бы, чтобы это был он - ибо на этого человека замыкается вся цепочка сборки и релиза.
Это лицо, ответственное за весь проект, на него летят все шишки по качеству и срокам.
Для проекта лучше (надёжнее), чтобы этот человек делал половину работы, но для воспитания командного духа лучше более глубокое разделение труда. Поэтому надо быть хорошим руководителем.

Хороший руководитель:
- знает, сколько времени нужно и на что;
- распределяет работу по исполнителям в соответствии с их возможностями;
- не тянет резину с распределением работ и передачей материалов;
- назначает чёткое задание (причём знает, в чём надо ограничивать соавторов, а что оставить на их усмотрение);
- назначает чёткий срок (с запасом на непредвиденные задержки);
- резервирует возможность внезапного отказа исполнителя и готов при этом спасти проект.

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

Хороший соавтор:
- знает, сколько времени нужно и на что;
- не вводит в заблуждение о своих возможностях;
- не тянет резину с ответами;
- делает не на "отвали", а реально хочет хорошего результата;
- соблюдает срок не "ну подожди ещё немножко" (начал в последний день, как студент-двоечник!), а точно;
- если сказал "сделаю", значит сделал! (Если обстоятельства действительно форсмажорные, СРАЗУ ЖЕ сообщи об этом и передай материалы, а не пропадай из переписки, как стыдливое дерьмо! Тебя ждут люди!)

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

Соавтор может сам распределять свою работу дальше, пользуясь своими связями. Он тоже может быть руководителем.

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

Часто можно слышать: "Как так получилось, была такая большая группа и вдруг вся исчезла?"

В менеджменте есть такое понятие - "bus factor". Оно означает минимальное число сотрудников, которых проект должен потерять, чтобы он не мог продолжаться. Если есть хоть один незаменимый человек - bus factor равен 1. Если работа каждого человека зарезервирована и может быть перехвачена другим - bus factor равен 2 и выше. Обычно все проекты на Спектруме имеют bus factor именно 1, и исключением являются лишь немногие системные программы.

Понятно, если речь идёт об indie-игре, у которой есть конкретный автор и вдохновитель.
Но ОЧЕНЬ ПЛОХО, если речь идёт о целой организации.

Есть три решения: анархия в организации (нет организатора как такового), высокие лидерские качества членов команды (каждый готов заменить павшего командира), или же у организатора есть конкретный заместитель.
Что лучше? Неизвестно. Во всяком случае, memento mori.
