Холакратия, или Идеальная компания разработчиков игр

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

Если вам повезло и нужно больше рук, увеличивайте количество команд (или «кругов»). Дайте возможность свободного перехода, но при условии, что нельзя присоединиться к команде, где больше 8 человек.

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

Отсутствие менеджеров и фокуса на должностных обязанностях делает возможным поиск идей на стыке областей и существование распределенного управления разработкой. Блокчейн из мира менеджмента.

Холакратия распространяет полномочия, традиционно закрепленные за руководителями и менеджерами, на всех сотрудников

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

Связанные с иерархией риски устраняются лишь частично. Отказ от «боссов» обязательно начнет сбоить, если вы захотите стать большими и присоединить 34, 55, 89 человек. Это не означает, что средние и крупные компании не могут применять концепции холакратии, а разве что иерархия будет присутствовать от внешних кругов к внутренним. Потери на взаимодействие и обмен информацией возрастают пропорционально количеству ступеней иерархии, вложенности кругов.

Если не искать специалиста в определенной области, то как нанимать новых людей? Быстро! Скорость в этом деле является основной характеристикой. Еще во время учебы в школе я понял, что дружить надо с теми, кто быстрее остальных решают примеры на математике. Натан Фоукс (работал над созданием Шрека, Кота в сапогах, Как приручить дракона…) советует художникам делать по одному рисунку каждый день, а это завидная скорость. Практика учит думать, но на это может потребоваться много времени. Следовательно, сотрудник является подходящим, если он способен быстро отрабатывать задачи и воспринимает их умом, а не практикой.

Проверяется прежде всего не обученность, а способность

Главное не спутать опыт и способности. При собеседовании быстрые ответы показывают опыт и наличие заготовок. А вот на задачах, требующих подготовки, проверяются способности. У кандидата должно быть минимум 25 минут на обдумывание примера рабочей задачи.

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

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

Решение о найме и увольнении должно приниматься несколькими членами команды.

Предположим, что разработка игры проходит четыре стадии:

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

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

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

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

Подробнее читайте в:

• Холакратия. Революционный подход в менеджменте – Робертсон Брайан Дж;
• Valve Handbook for New Employees.