- PVSM.RU - https://www.pvsm.ru -
Пару лет назад вдохновлённый заметкой про «революционную систему управления рабочим временем» Артёма Горбунова о философии организации рабочих процессов внедрённой в одноименной студии, я озадачился вопросом: а сколько нужно человеческого ресурса для стабильной работы подразделения?
Речь пойдёт об идеях и выводах, к которым я пришёл, работая руководителем. Статья будет полезна начинающим руководителям и тем, кто только планирует им стать.
В концепции внедрённой в студии Артёма Горбунова, «Ресурс» как идея, и «ресурс» как главный объект изучения, вещи значительно многограннее, затрагиваемого мной вопроса. Я же хочу остановиться подробнее именно на человеческом ресурсе.
Примеры отстоя в рабочих разговорах:
«А ты где?» (по телефону опаздывающему сотруднику)
«Это Макс так по телефону сказал»
«Это Таня так письмо написала»
«А я говорил, что так будет»
«А почему ты опять по ночам работаешь?»
«Хорошо, что ты к нам присоединился» (при опоздании)
«У нас не принято уходить в 23:00 в ночь перед дедлайном» (сотруднику с синяками под глазами, работающему с девяти утра)
Ведь не зря ребята назвали концепцию именно «Ресурс», заведомо предвидя ассоциации с Human Resource [2].
Представьте ситуацию, формируется новая группа / отдел / проект. Пусть стартовое количество сотрудников равняется двум. Каковы роли этих людей? Даже среди двух людей должна быть схема подчинённости, так как кто-то один конкретный должен нести ответственность за деятельность отдела. Таким образом получается, что один — человек ответственный, а второй — деятельный.
Поясню, первый не то что бы прям ответственный по факту, он ответственный по уставу / регламенту / правилам. Т.е. на него возложена ответственность за деятельность подразделения, но это не означает, что во всех случаях он будет на 100% ответственным. А на втором лежит задача, прежде всего, по непосредственно реализации задач отдела. Первый, конечно, тоже, должен и может выполнять работу «руками», но в куда более меньшей степени.
Работают два, три, четыре человека, объём задач растёт, появляется необходимость повышения производительности и, если можно так сказать, отказоустойчивости отдела. Каким образом будем решать: увеличением количества сотрудников или повышением производительности текущих сотрудником, или задействуем оба направления? Появление таких вопросов — нормальный этап развития любого подразделения.
Ответом, как правило, является работа сразу в двух направлениях: увеличивается количество сотрудников и и повышается качество навыков сотрудников, как текущих, так и новых.
Для становления отдела необходимо формировать в отделе здоровую конкуренцию. Такую при, которой конфликты минимальны, производительность максимальна и чётко видны перспективы роста заинтересованного сотрудника. Конкуренция в обществе равных слаба по своей природе — нет ориентира. Нельзя достичь значительного успеха/развития без примера впереди (хорошего или плохого).
Речь не идёт о конкуренции между рядовым специалистом и ведущим разработчиком, роль ведущего разработчика в том, чтобы дать возможность развиваться быстрее тому, кто заинтересован. Тут есть и обратный момент, если специалист не стремиться к развитию, то и не нужно его заставлять. Нужно найти ему комфортную позицию / роль / задачу. Возможно в этом и есть ценность данного сотрудника.
Развивайте в членах команды роли. Не назначайте, а именно развивайте! Инициатива обладать той или иной ролью, должна исходить от самого сотрудника, пусть и неосознанно.
Проанализируйте, кто из сотрудников чем занимается кроме выполнения своих прямых обязанностей.
Роли могут быть самые различные, от критика до всезнайки, самая очевидная — это Team Lead. Сотрудникам роли дадут возможность понять «с кем по какому вопросу можно посоветоваться». А руководителю будет еще один «добрый» инструмент самоорганизации коллектива.
В дополнение к ролям, можно и нужно развивать в сотрудниках специализации: какие-либо узкие направления, безумно интересные конкретному сотруднику. Данный скил время от времени требуется применять в отделе, но его обладание у всех членов команды, совсем необязательно.
И вот наступает момент, когда отдел сформирован, пусть и в минимальной комплектации, задачи выполняются, hr'ы время от времени предлагаю новые кандидатуры.
Забегая вперед, скажу, что выводы к которым пришёл я, могут не подходить к вашей модели. Если ваша команда состоит только из профессионалов, или наоборот, — если ваша модель «отрабатывать» на износ юниоров, то схема не для вас.
Надеюсь, что ваш ответ «рядовой специалист». Молодой специалист не может решать задачи со скоростью рядового специалиста, по множеству причин: он учится, он задаёт много вопросов, он не обладает должными профессиональными навыками. Специалисты высших уровней: ведущие разработчики, технические лидеры, чаще занимаются более глобальными техническими вопросами: архитектура, инструментарий, учат юниоров и т.п.
Если иначе, то, скорее всего, у вас в команде есть некоторые сложности — каждый должен заниматься, прежде всего, своими задачами.
Признаться, уже не припомню откуда появился термин «чаша», толи у Горбунова подсмотрел прочёл, толи в ходе обсуждения родился термин, толи сам придумал,… не важно. Главное, что термин наглядно и довольно точно отражает концепцию.
Перейдём к делу. Условимся, что ось абсцисс (x) — это условный уровень прокаченности специалиста, а ось ординат (y) — это условное количество сотрудников данного уровня.
Представим отдел, в котором основная масса сотрудников — это юниоры. Посмотрим на «чашу» отражающую данную ситуацию.
Видим сильно перегруженную левую часть. Данный вариант самый дорогой с точки зрения управления и тестирования. Но дешёвый с точки зрения ежемесячных затрат на оплату труда. Что касается общей стоимости разработки, то она будет напрямую зависеть от качества кода. И разброс тут может быть значителен. Время разработки при такой схеме большое.
Обратная ситуация, если основу команды составляют ведущие специалисты. Одно дело, когда общий/средний уровень рядового специалиста высок, другое — когда эти специалисты занимают высокие позиции внутри команды/проекта.
Да, существуют команды состоящие из одних бородатых специалистов, но в таком случае, в команде должна быть запредельная мотивация на продукт/компанию и т.п. Должен быть объединяющий фактор, который будет выше всего. Данная атмосфера более характерна стартапам, нежели состоявшимся продуктам.
Вспоминаем, что основную реальную работу делают рядовые специалисты. Посмотрим на «чашу» в таком случае.
Обратите внимание, что суммарное количество специалистов во всех графиках одинаковое. Для наглядности продемонстрируем различные ситуации на одном изображении.
Основная часть сотрудников — рядовые специалисты. Юниоры и ведущие есть, но без избытка. Юниорам есть куда расти, у специалистов есть среда для развития (есть кого учить, есть у кого учиться), у ведущих есть достаточная зона ответственности и контроля.
Молодых специалистов может быть много, вы не сможете адекватно управлять большим количеством юниоров при отсутствии сотрудников с высокими управленческими навыками. Крутых разработчиков тоже может быть много, им может не хватить крутых задач.
Замечу, что вероятность ухода сотрудника максимальна именно на краях чаши: юниор может устать, понять что «не моё», либо не пройти испытательный срок, а поводом ухода ведущего может стать достижение предела в развитии внутри данного проекта/отдела/компании.
Используйте и развивайте!
Автор: apian
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-personalom/102700
Ссылки в тексте:
[1] Ссылка на заметку: https://artgorbunov.ru/bb/soviet/20090824/
[2] Human Resource: https://en.wikipedia.org/wiki/Human_resources
[3] Источник: http://megamozg.ru/post/20978/
Нажмите здесь для печати.