Как эффективно распределить нагрузку на команду

Вступление

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

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

Но, кто ищет тот всегда найдет, и как-то само, шаг за шагом, у нас получилось создать некую методологию эффективного управления равномерной загрузкой команд разработки…

Мы точно понимаем, что многие наши коллег с этим сталкиваются каждый день, и для кого-то именно сегодня это актуальный и нужный вопрос.

С нашей стороны, было бы преступлением не поделиться найденной стратегией управления в разработке IT продуктов… Итак погнали разбираться ⤵️

1️⃣ ШАГ: РАЗДЕЛЯЕМ ПРОЕКТЫ

Первое, к чему мы пришли - это то, что нужно разделить проекты в компании по их сложности и соответвенно стоимости.

Наша градация выглядит так:

• проекты группы А → это крупные проекты, в основном средний и крупный бизнес, которые дают самую большую выручку и большие контракты для нас, а объемы работ на таких проектах обычно равняются свыше 1000 часов;
• проекты группы B → это средней сложности проекты, в основном малый и средний бизнес, у которых ценник примерно посередине, а объемы работ на них приравниваются от 500 до 1000 часов;
• проекты группы С → это небольшие проекты, в основном стартапы, у которых ценник самый низкий, а объемы работ на них ориентировочно равны от 50 до 500 часов

2️⃣ ШАГ: РАЗДЕЛЯЕМ УРОВНИ СОТРУДНИКОВ

Следующим шагом рекомендуем, по типу разделения проектов, поделить ваши уровни сотрудников в компании.

Вот как у нас например:

• Senior → это профессионалы своего дела, кто только не только умеет давно, но и может научить других, имеет хороший опыт за плечами и громкие кейсы за спиной в рюкзаке, а уровень опыта равен свыше 5-6 лет;
• Middle → это те сотрудники, кто только умеет + имеет бекграунд и уже свой путь в IT, имеет за спиной участие в 10+ проектах и на руках конкретные кейсы, а уровень опыта составляет 2-4 года;
• Junior → в основном это те, кто только учиться, или имеет ограниченные знания и навыки в конкретно своей должности, а уровень опыта равен до 1 года

3️⃣ ШАГ: ОПИСАТЬ КАЖДУЮ ДОЛЖНОСТЬ

На этом шаге, мы создаем документ, который называется - конечный продукт должности.

По сути это такая личная карточка должности (по типу карты пациента в поликлинике), где вы заносите все главные составляющие каждой ложности и сотрудника:

• ФИО;
• Контакты;
• Должность;
• Стоимость часа;
• Ценный конечный продукт;
• Опыт и Артефакты (в таких проектах участвовал и какие были результаты)
• Метрики (это количественные показатели работы сотрудника, в зависимости от уровня сложности проекта: кол-во часов, проектов в месяц/год, KPI по каждому проекту и тд);
• Систему мотивации;
• Критерии развития (перечень метрик, при соблюдении которых, можно перейти на след уровень в компании)

4️⃣ ШАГ: СОЗДАТЬ ОТДЕЛЬНЫЕ КОМАНДЫ

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

😎 Что это за команды: это небольшие команды по 4-6 человек, которые могут самостоятельно выполнить тот или иной проект, в зависимости от его сложности, а также, эти команды должны иметь высокий коэффициент сыгранности внутри себя.

Если сказать другим словами, то такие команды должны быть выстроены по коэффициенту наименьшего сопротивления взаимодействия друг с другом…

5️⃣ ШАГ: НАБЛЮДАЕМ РАБОТУ СИСТЕМЫ

На этом шаге как раз и начинается магия)

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

1. Когда вам в компании заходит новый проект, ему сразу определяется статус.
   Пример: Давайте предположим что к нам залетел проект “СтартапХ” и по нашим критериям компании - он имеет статус B
2. Сразу под этот проект мы понимаем, что наши 3 команды точно его смогут реализовать.
   Пример: Под этот проект мы выбираем точно “Команду2” тк у них уже есть за плечами крутой кейс в данной тематике проекта. Они слаженно сработали и учли все оплошности, которые возникли в прошлом проекте
3. Также мы сразу можем предварительно рассчитать сроки по проекту, описать предполагаемое качество работ и их стоимость
   Пример: Мы сразу можем рассчитать, что на этот проект у нас уйдет от 500 до 1000 часов работ, причем точно знаем его день сдачи тк исходя из наших средних метрик, выбранная команда сделает его за 700 часов, что эквивалентно 140дн (4,6мес) тк наша “Команда2” будет работать со средней своей продуктивной скоростью в 5ч/день
4. Из текущей распределенной нагрузки, мы можем быть уверенны, что сотрудники не будут перенапрягаться на проекте, в результате чего будет обеспечено соответствующее качество продукта
   Пример: Каждый в команде четко определил свою зону ответственности, определил качество и сроки реализованного своей должностью продукта. Уверен, что за работы получит равноценную оплату + бонусы
5. После сдачи работ и официальной приемки проекта, команда собирается на ретроспективу, где выписывает важные моменты (как положительные так и промахи)
   Пример: По итогу спринта, “Команда2” выполнила проект за 120дн (4мес), что на 15% быстрее плановых сроков. За это каждый член команды подучит бонус в 15% сверху оговоренных зарплат за проект. Также на этапе разработки дизайна, возникла небольшая ошибка недопонимания 2 коллег, что привело к снижению качества отдельного блока продукта. Проанализировав данный опыт, коллеги пришли к тому, что в следующем проекте будут созваниваться между собой и корректировать совместные работы 1р/2 дня, а не 1р/неделю, как это было.

6️⃣ ШАГ: УЧИТЫВАТЬ ДОПОЛНИТЕЛЬНЫЕ МОМЕНТЫ

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

На них точно стоит опираться

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

📌 ВЫВОДЫ

Да, конечно данная система не идеально, она будет еще много раз докручивать и обновляется по мере проектов, команды и приходящих вызовов для компании.

И конечно, чтоит отметить, что данная методология хорошо применима в том случае, когда вы уже поработали с коллегами на каких-то проектов и можете оценить объективно их уровень и компетенции.

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