Пару лет назад вдохновлённый заметкой про «революционную систему управления рабочим временем» Артёма Горбунова о философии организации рабочих процессов внедрённой в одноименной студии, я озадачился вопросом: а сколько нужно человеческого ресурса для стабильной работы подразделения?



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

О чём речь?

В концепции, внедрённой в студии Артёма Горбунова, «Ресурс» как идея, и «ресурс» как главный объект изучения, вещи значительно многограннее, затрагиваемого мной вопроса. Я же хочу остановиться подробнее именно на человеческом ресурсе.

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

Ведь не зря ребята назвали концепцию именно «Ресурс», заведомо предвидя ассоциации с Human Resource.

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



Поясню, первый не то что бы прям ответственный по факту, он ответственный по уставу / регламенту / правилам. Т.е. на него возложена ответственность за деятельность подразделения, но это не означает, что во всех случаях он будет на 100% ответственным. А на втором лежит задача, прежде всего, по непосредственно реализации задач отдела. Первый, конечно, тоже, должен и может выполнять работу «руками», но в куда более меньшей степени.

Становление подразделения

Работают два, три, четыре человека, объём задач растёт, появляется необходимость повышения производительности и, если можно так сказать, отказоустойчивости отдела. Каким образом будем решать: увеличением количества сотрудников или повышением производительности текущих сотрудников, или задействуем оба направления? Появление таких вопросов — нормальный этап развития любого подразделения.



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

Так каков должен быть размер команды? Без кого в команде не обойтись?

Для становления отдела необходимо формировать в отделе здоровую конкуренцию. Такую, при которой конфликты минимальны, производительность максимальна и чётко видны перспективы роста заинтересованного сотрудника. Конкуренция в обществе равных слаба по своей природе — нет ориентира. Нельзя достичь значительного успеха/развития без примера впереди (хорошего или плохого).



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

Роли и специализация

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

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



Роли могут быть самые различные, от критика до всезнайки, самая очевидная — это Team Lead. Сотрудникам роли дадут возможность понять «с кем по какому вопросу можно посоветоваться». А руководителю будет еще один «добрый» инструмент самоорганизации коллектива.

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

Количество или качество?

И вот наступает момент, когда отдел сформирован, пусть и в минимальной комплектации, задачи выполняются, hr'ы время от времени предлагают новые кандидатуры.

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

Забегая вперед, скажу, что выводы к которым пришёл я, могут не подходить к вашей модели. Если ваша команда состоит только из профессионалов, или наоборот, — если ваша модель «отрабатывать» на износ юниоров, то схема не для вас.

Вы анализировали, кто в вашей команде делает больше всего реального продукта с заранее известным качеством?

Надеюсь, что ваш ответ «рядовой специалист». Молодой специалист не может решать задачи со скоростью рядового специалиста, по множеству причин: он учится, он задаёт много вопросов, он не обладает должными профессиональными навыками. Специалисты высших уровней: ведущие разработчики, технические лидеры, чаще занимаются более глобальными техническими вопросами: архитектура, инструментарий, учат юниоров и т.п.

И то, что молодые и ведущие специалисты делают реального продукта меньше — это норма.

Если иначе, то, скорее всего, у вас в команде есть некоторые сложности — каждый должен заниматься, прежде всего, своими задачами.

Концепция «Чаши»

Признаться, уже не припомню откуда появился термин «чаша», то ли у Горбунова подсмотрел прочёл, то ли в ходе обсуждения родился термин, то ли сам придумал,… не важно. Главное, что термин наглядно и довольно точно отражает концепцию.

Перейдём к делу. Условимся, что ось абсцисс (x) — это условный уровень прокаченности специалиста, а ось ординат (y) — это условное количество сотрудников данного уровня.

Представим отдел, в котором основная масса сотрудников — это юниоры. Посмотрим на «чашу» отражающую данную ситуацию.



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



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

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

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

Вспоминаем, что основную реальную работу делают рядовые специалисты. Посмотрим на «чашу» в таком случае.



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



Основная часть сотрудников — рядовые специалисты. Юниоры и ведущие есть, но без избытка. Юниорам есть куда расти, у специалистов есть среда для развития (есть кого учить, есть у кого учиться), у ведущих есть достаточная зона ответственности и контроля.

Цените специалистов! Они — главная сила подразделения.

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

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

Замечу, что вероятность ухода сотрудника максимальна именно на краях чаши: юниор может устать, понять что «не моё», либо не пройти испытательный срок, а поводом ухода ведущего может стать достижение предела в развитии внутри данного проекта/отдела/компании.

Используйте и развивайте!