Чаша ресурса — советы по созданию команды
Пару лет назад вдохновлённый заметкой про «революционную систему управления рабочим временем» Артёма Горбунова о философии организации рабочих процессов внедрённой в одноименной студии, я озадачился вопросом: а сколько нужно человеческого ресурса для стабильной работы подразделения?
Речь пойдёт об идеях и выводах, к которым я пришёл, работая руководителем. Статья будет полезна начинающим руководителям и тем, кто только планирует им стать.
В концепции внедрённой в студии Артёма Горбунова, «Ресурс» как идея, и «ресурс» как главный объект изучения, вещи значительно многограннее, затрагиваемого мной вопроса. Я же хочу остановиться подробнее именно на человеческом ресурсе.
Примеры отстоя в рабочих разговорах:
«А ты где?» (по телефону опаздывающему сотруднику)
«Это Макс так по телефону сказал»
«Это Таня так письмо написала»
«А я говорил, что так будет»
«А почему ты опять по ночам работаешь?»
«Хорошо, что ты к нам присоединился» (при опоздании)
«У нас не принято уходить в 23:00 в ночь перед дедлайном» (сотруднику с синяками под глазами, работающему с девяти утра)
Ссылка на заметку
Кто-то скажет, что это совершенно разные вещи, и будет частично прав. Но именно частично, ибо основным объектом вышеупомянутой концепции является человек / сотрудник.
Ведь не зря ребята назвали концепцию именно «Ресурс», заведомо предвидя ассоциации с Human Resource.
Представьте ситуацию, формируется новая группа / отдел / проект. Пусть стартовое количество сотрудников равняется двум. Каковы роли этих людей? Даже среди двух людей должна быть схема подчинённости, так как кто-то один конкретный должен нести ответственность за деятельность отдела. Таким образом получается, что один — человек ответственный, а второй — деятельный.
Поясню, первый не то что бы прям ответственный по факту, он ответственный по уставу / регламенту / правилам. Т.е. на него возложена ответственность за деятельность подразделения, но это не означает, что во всех случаях он будет на 100% ответственным. А на втором лежит задача, прежде всего, по непосредственно реализации задач отдела. Первый, конечно, тоже, должен и может выполнять работу «руками», но в куда более меньшей степени.
Работают два, три, четыре человека, объём задач растёт, появляется необходимость повышения производительности и, если можно так сказать, отказоустойчивости отдела. Каким образом будем решать: увеличением количества сотрудников или повышением производительности текущих сотрудником, или задействуем оба направления? Появление таких вопросов — нормальный этап развития любого подразделения.
Ответом, как правило, является работа сразу в двух направлениях: увеличивается количество сотрудников и и повышается качество навыков сотрудников, как текущих, так и новых.
Так каков должен быть размер команды? Без кого в команде не обойтись?
Для становления отдела необходимо формировать в отделе здоровую конкуренцию. Такую при, которой конфликты минимальны, производительность максимальна и чётко видны перспективы роста заинтересованного сотрудника. Конкуренция в обществе равных слаба по своей природе — нет ориентира. Нельзя достичь значительного успеха/развития без примера впереди (хорошего или плохого).
Речь не идёт о конкуренции между рядовым специалистом и ведущим разработчиком, роль ведущего разработчика в том, чтобы дать возможность развиваться быстрее тому, кто заинтересован. Тут есть и обратный момент, если специалист не стремиться к развитию, то и не нужно его заставлять. Нужно найти ему комфортную позицию / роль / задачу. Возможно в этом и есть ценность данного сотрудника.
Развивайте в членах команды роли. Не назначайте, а именно развивайте! Инициатива обладать той или иной ролью, должна исходить от самого сотрудника, пусть и неосознанно.
Проанализируйте, кто из сотрудников чем занимается кроме выполнения своих прямых обязанностей.
Роли могут быть самые различные, от критика до всезнайки, самая очевидная — это Team Lead. Сотрудникам роли дадут возможность понять «с кем по какому вопросу можно посоветоваться». А руководителю будет еще один «добрый» инструмент самоорганизации коллектива.
В дополнение к ролям, можно и нужно развивать в сотрудниках специализации: какие-либо узкие направления, безумно интересные конкретному сотруднику. Данный скил время от времени требуется применять в отделе, но его обладание у всех членов команды, совсем необязательно.
И вот наступает момент, когда отдел сформирован, пусть и в минимальной комплектации, задачи выполняются, hr'ы время от времени предлагаю новые кандидатуры.
Появляются разумные вопросы: каких сотрудников искать, как усилить команду, как обеспечить резервирование, где найти ресурсы на техническое развитие отдела?
Забегая вперед, скажу, что выводы к которым пришёл я, могут не подходить к вашей модели. Если ваша команда состоит только из профессионалов, или наоборот, — если ваша модель «отрабатывать» на износ юниоров, то схема не для вас.
Вы анализировали, кто в вашей команде делает больше всего реального продукта с заранее известным качеством?
Надеюсь, что ваш ответ «рядовой специалист». Молодой специалист не может решать задачи со скоростью рядового специалиста, по множеству причин: он учится, он задаёт много вопросов, он не обладает должными профессиональными навыками. Специалисты высших уровней: ведущие разработчики, технические лидеры, чаще занимаются более глобальными техническими вопросами: архитектура, инструментарий, учат юниоров и т.п.
И то, что молодые и ведущие специалисты делают реального продукта меньше — это норма.
Если иначе, то, скорее всего, у вас в команде есть некоторые сложности — каждый должен заниматься, прежде всего, своими задачами.
Признаться, уже не припомню откуда появился термин «чаша», толи у Горбунова подсмотрел прочёл, толи в ходе обсуждения родился термин, толи сам придумал,… не важно. Главное, что термин наглядно и довольно точно отражает концепцию.
Перейдём к делу. Условимся, что ось абсцисс (x) — это условный уровень прокаченности специалиста, а ось ординат (y) — это условное количество сотрудников данного уровня.
Представим отдел, в котором основная масса сотрудников — это юниоры. Посмотрим на «чашу» отражающую данную ситуацию.
Видим сильно перегруженную левую часть. Данный вариант самый дорогой с точки зрения управления и тестирования. Но дешёвый с точки зрения ежемесячных затрат на оплату труда. Что касается общей стоимости разработки, то она будет напрямую зависеть от качества кода. И разброс тут может быть значителен. Время разработки при такой схеме большое.
Обратная ситуация, если основу команды составляют ведущие специалисты. Одно дело, когда общий/средний уровень рядового специалиста высок, другое — когда эти специалисты занимают высокие позиции внутри команды/проекта.
При таком раскладе возможности вертикального роста сильно ограничены, падает мотивация, растёт недовольство сотрудников, которое необходимо компенсировать.
Да, существуют команды состоящие из одних бородатых специалистов, но в таком случае, в команде должна быть запредельная мотивация на продукт/компанию и т.п. Должен быть объединяющий фактор, который будет выше всего. Данная атмосфера более характерна стартапам, нежели состоявшимся продуктам.
Вспоминаем, что основную реальную работу делают рядовые специалисты. Посмотрим на «чашу» в таком случае.
Обратите внимание, что суммарное количество специалистов во всех графиках одинаковое. Для наглядности продемонстрируем различные ситуации на одном изображении.
Основная часть сотрудников — рядовые специалисты. Юниоры и ведущие есть, но без избытка. Юниорам есть куда расти, у специалистов есть среда для развития (есть кого учить, есть у кого учиться), у ведущих есть достаточная зона ответственности и контроля.
Цените специалистов! Они — главная сила подразделения.
Молодых специалистов может быть много, вы не сможете адекватно управлять большим количеством юниоров при отсутствии сотрудников с высокими управленческими навыками. Крутых разработчиков тоже может быть много, им может не хватить крутых задач.
А много специалистов с опытом в 2-3 года — это счастье! Более половины задач, как правило, — это текущая разработка и поддержка существующего кода. А для этих задач вашей команде необходимо достаточное количество рядовых специалистов.
Замечу, что вероятность ухода сотрудника максимальна именно на краях чаши: юниор может устать, понять что «не моё», либо не пройти испытательный срок, а поводом ухода ведущего может стать достижение предела в развитии внутри данного проекта/отдела/компании.
Используйте и развивайте!
© Megamozg
