[Управление разработкой, Управление персоналом] Кто там выше тимлида?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Не так давно я прочитал интересную статью о том, как стать тимлидом и что нужно делать в этой роли. И мне захотелось рассказать про следующую ступень развития — в качестве менеджера и руководителя IT-отдела или IT-директора в небольшой компании.
Стоит отметить, что для разработчика существует несколько векторов развития, которые хорошо описаны в статье Три дороги для программиста: эксперт, руководитель, основатель. Я же сосредоточусь на втором направлении — руководителе.
За свою карьеру я проработал тимлидом более 5 лет и чуть меньше года — в роли руководителя фронтенда. Да, руководящего опыта у меня не так уж много, но будучи тимлидом я пристально наблюдал за работой своего начальства. На основе этих наблюдений и попытаюсь рассказать, чем же занимаются эти непоседливые менеджеры.
В этой статье хочу рассказать о некоторых задачах и зонах ответственности руководителя и чем они отличаются от задач тимлида.
Чтобы далее не писать длинное «руководитель отдела», буду писать просто «руководитель». В тексте я буду оперировать в основном двумя ролями: «руководитель» и «тимлид». Под «руководителем» я подразумеваю начальника «тимлида». Между этими ролями может быть достаточно много ступеней иерархии, в зависимости от размера компании.
У руководителя и тимлида много схожих задач — различия лишь в масштабах. Про то, как стать тимлидом и что нужно делать в этой роли, написано много статей (например, та, которую я упоминал выше).
На самом деле список задач руководителя практически бесконечен, но попробуем выбрать те, которые больше всего отличаются от задач тимлида:
- Стратегия.
- Организационная структура.
- Правила целеполагания.
- Фонд оплаты труда.
- Наем.
Стратегия
Зрелым тимлидам тоже приходится задумывать о стратегии, но только в меньшем масштабе — в пределах команды. Тимлид должен думать о том, как повысить тестовое покрытие на проекте, как прокачать джунов, как ускорить код-ревью и так далее.
В масштабе отдела/компании приходится думать более абстрактно. И чем выше руководитель, тем абстрактнее ему приходится думать.
Если сравнивать с задачей тимлида, например — увеличение тестового покрытия. То для руководителя это должна быть другая цель — увеличение качества продукта. Тесты — это уже тактика, один из инструментов достижения цели.
Уровень абстрактности может варьироваться в зависимости от масштабов и задач. В какой-нибудь большой компании руководитель может просто задать цель и критерии ее достижения. Например, цель — уменьшить количество сбоев в два раза, критерием ее достижения будет уменьшение количества плохих отзывов на «Банки-ру» до 10 в месяц.
Также в небольшой компании руководитель может задать цель в виде конкретных задач: внедрить e2e-тесты, настроить мониторинг и алерты. Но это очень тонкая грань. Довольно часто выходит боком, когда руководитель пытается решать за лидов или разработчиков, с какими инструментами им работать и как. Для руководителя с бэкграундом разработчика это большой соблазн, потому что это интересная работа — выбирать инструменты и внедрять их.
В общем, вырастая в руководителя, нужно учиться отрываться от реализаций и больше заниматься целеполаганием, делегируя остальное.
Организационная структура
Каждая компания или отдел — это небольшое государство, и, как в любом государстве, здесь должна быть определенная система управления.
Задача руководителя — формализовать эту систему: описать, по каким критериям должны группироваться сотрудники, как должен происходить карьерный рост и так далее.
По мере роста компании эта система всегда меняется. Например, когда в компании было 50 человек, система представляла собой иерархию: руководитель → тимлиды → разработчики. Но, когда штат вырастает до 200 человек, одних тимлидов недостаточно. Появляются руководители отделов, кураторы, менторы и так далее. Вместо плоской структуры из команд выстраиваются пирамиды из юнитов, отделов, управлений.
Если в масштабе 50 сотрудников руководитель может ситуативно или по запросу заниматься пересмотром должностей, то в большем масштабе это приходится делать по расписанию — например, раз в полгода.
Если говорить в общем, то менять структуру по мере роста необходимо, чтобы иметь возможность делегировать и контролировать. Да, это всем привычная система, выглядит она просто и естественно. Но основная работа здесь ложится именно на руководителя: он должен решить, в какой момент и как поменять организационную структуру.
Это же касается и общих процессов, которые позволяют сокращать издержки за счет унификации. Как пример — процесс создания и контроля индивидуального плана развития сотрудников. Без четкой структуры будет сложно запускать и развивать этот процесс. Но если вы заранее выстроили организационную структуру, выделили тимлидов, наладили с ними коммуникацию и регулярные встречи по синхронизации, то это будет достаточно легко.
Существует много других общих процессов, которые руководитель должен создавать и делегировать. Если начать их все перечислять, это выльется в отдельную статью.
Правила целеполагания
Руководителю необходимо разработать правила, по которым тимлиды могут устанавливать свои собственные цели и делегировать их ниже. Также важно контролировать промежуточные результаты — без этого сотрудники могут работать совершенно не в том направлении.
Есть несколько конкретных инструментов для решения этой задачи:
- план — в смысле как плановая экономика;
- должностные обязанности — те самые, что прописываются в трудовом договоре;
- OKR (Objectives and Key Results).
Не будем вдаваться в сравнения эффективности этих инструментов: важно понять, что задача, которую они решают, — описать формат целей и способ их делегирования. Часто это необходимо, когда организационная структура разветвленная и есть требуется сравнивать эти ветви.
Если у вас пять отделов и они живут в разных системах целеполагания, то будет очень сложно объективно сравнивать их между собой или делегировать им типовые задачи.
Фонд оплаты труда
Изначально я хотел рассмотреть задачу по оценке работы сотрудников. Но этой задачей занимаются как тимлиды, так и руководители — каждый в своих плоскостях. Разница лишь в том, что решение о пересмотре заработной платы принимает именно руководитель, он же в той или иной мере заведует фондом оплаты труда ФОТ).
Раздать каждому по справедливости — довольно сложная задача, особенно если ты не работаешь непосредственно с теми, кому пересматриваешь зарплату.
Для пересмотров есть несколько ограничений:
- размер ФОТ, который обычно спускается свыше;
- баланс ЗП между сотрудниками на равных должностях;
- постепенный и запланированный рост ЗП.
С размером ФОТ на первый взгляд кажется все просто: ты меняешь ЗП сотрудников и смотришь, вписываются они в ФОТ или нет. Но сложность в том, чтобы подогнать эти изменения ровно под размер ФОТ, особенно если ты его не знаешь.
Например, я руковожу отделом фронтенда, ФОТ на всю компанию один. CTO просит меня сделать пересмотр моим сотрудникам и отправить ему список с коэффициентами. Так как я не знаю размер ФОТ, я буду опираться только на заслуги сотрудников и их должности (мне это кажется даже более правильным, чем если бы я знал размер ФОТ и ориентировался на него). Далее я отправляю результат CTO, он складывает его с результатами других отделов, и оказывается, что мы вышли за рамки ФОТ. Какой-то отдел больше, какой-то меньше. И тогда мы начинаем «подгонять», это может занять несколько итераций.
Соблюдение баланса ЗП между сотрудниками не всегда является приоритетной задачей, так как зачастую размер ЗП не разглашается и это регулируется соответствующими соглашениями. Но, если допустить большой дисбаланс, это может вылиться в трудности с наймом новых и удержанием текущих сотрудников.
Также поддержание баланса может помочь в вопросе пересмотра должностей. Например, ЗП сеньора в компании варьируется от 180 до 220 попугаев. Пришло время пересматривать ЗП сеньора Иванова: сейчас он уже получает 220, а хочет 250. Зная границы ЗП для сеньоров, этот момент должен вызвать у вас вопрос, а ту ли должность занимает Иванов? Может, пора его повысить до архитектора?
Рост ЗП в основном должен соответствовать рынку и возможностям компании. Поэтому важно делать пересмотры постепенно и своевременно. Например, рост ЗП может зависеть от должности. Сейчас джуны вырастают до мидлов очень быстро, поэтому их нужно пересматривать чаще. Так как конкуренция на рынке труда достаточно высокая, велик шанс потерять сотрудника, если не сделать пересмотр вовремя.
Даже если сотрудник сам не просит о пересмотре ЗП, лучше это делать с определенной периодичностью, изменяя ЗП постепенно. Иначе может возникнуть ситуация, что вы не пересматривали сотрудника два года и теперь он просит +150 тысяч рублей. В лучшем случае это вызовет вопросы у вашего руководства, в худшем — вы не сможете себе этого позволить и потеряете сотрудника.
Наем
Процесс найма очень обширный и требует тщательного контроля. В небольших компаниях за наем может напрямую отвечать руководитель, в больших компаниях этим занимаются целые HR-отделы. Так или иначе руководитель обязан быть вовлеченным в процесс найма: HR сами по себе не могут этим заниматься.
Чтобы понять, зачем именно в этом процессе нужен руководитель, рассмотрим задачи связанные с наймом:
- формирование группы экспертов, которым можно доверять;
- управление приоритетами между отделами;
- анализ и прогнозирование.
Найти хорошего техспециалиста несложно — сложно найти и обучить эксперта, мнению которого вы смогли бы доверять. Ведь портрет кандидата не ограничивается хард-скиллами, интервьюер должен уметь понимать мотивацию кандидата, его амбиции, характер и т. д. Эта тема хорошо раскрыта в статье Резюме глазами интервьюера — советую ознакомиться.
Всему этому интервьюеров должен научить именно руководитель. Необязательно напрямую, чаще это делегируется сверху вниз. В итоге самое важное — это доверие к интервьюерам, ведь ошибки при найме могут обходиться достаточно дорого.
На мой взгляд, сложности начинаются тогда, когда из одного источника кандидатов появляется несколько потребителей. В этот момент руководителю приходится заниматься управлением приоритетами для этих самых потребителей. Работа с приоритетами требует большого внимания, анализа и информации о текущих делах в компании. Нельзя один раз задать правила, по которым наем будет работать продолжительное время.
Этот процесс живой и зависит от очень многих показателей, которые часто меняются: текучка кадров, приоритеты бизнеса, изменения рынка, рост сотрудников и так далее. В нашей компании есть отличное решение для разделения потока кандидатов под разные отделы — сегрегация рынка по технологическому стеку. Например, на продукты для обслуживания физлиц мы нанимаем React-разработчиков, для юрлиц — Angular. Это позволяет избежать конфликта приоритетов найма между разными отделами.
Наем требует непрерывного анализа и прогнозирования, так как задержки при найме могут сильно повлиять на развитие бизнеса и компании в целом, особенно в высококонкурентной среде. Поэтому хорошим навыком является умение прогнозировать, когда вырастет объем задач, и быть готовым к этому.
Не стоит забывать, что для новых сотрудников нужен период адаптации, который может длиться несколько недель. Также кандидаты могут не пройти испытательный срок, не сработаться с командой и много-много других факторов риска.
К сожалению, владение актуальной информацией о потребностях в сотрудниках не всегда спасает. Наем сильно зависит от рынка: поток кандидатов может в момент прекратиться и вы никак не сможете на это повлиять. Одним из хороших примеров решения таких ситуаций (не всегда) является аутсорсинг. Нас не раз выручали подрядные организации, которые выводили разработчиков на наши проекты за считанные дни.
Также есть пример более зрелого и дальновидного решения проблем с наймом — открытие центров разработки. По мере роста компании Тинькофф было принято решение открывать центры разработки в разных уголках России, сейчас их около 12. Москва не резиновая и далеко не все хотят сюда переезжать, поэтому решение полностью оправдало себя, и сейчас я даже не могу представить, как бы мы выжили без этого.
Конечно, пример достаточно специфичный и справедлив для больших компаний, но из него стоит вынести, что даже для проблем, которые кажутся временными, стоит искать долгосрочные решения.
Вывод
Приведенные выше примеры не сильно связаны между собой, я использовал их, чтобы показать, чем же именно занимается руководитель и чем его задачи отличаются от задач тимлида.
Как можно заметить, разница заключается в том, что тимлид большую часть времени занимается непосредственным управлением людьми и проектом. А руководитель в основном сосредоточен на создании окружения, структур и правил. Существует еще очень много интересных и важных задач руководителя: исследования, обучение сотрудников, развитие тимлидов, ротации в командах, презентации работы и т. д. Но об этом как-нибудь в другой раз :-)
Теперь мне интересно, что же там после руководителя? Но пока я не знаю ответа на этот вопрос.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. Позиционирование продукта
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. От реализации идей — к проверке гипотез
- [Тестирование IT-систем, Тестирование веб-сервисов] Меньше, чем пара. Еще один способ сокращения количества тестов
- [Управление персоналом, Карьера в IT-индустрии] Бесплатные образовательные курсы: бэкенд-разработка
- [Управление персоналом, Карьера в IT-индустрии, Лайфхаки для гиков, Удалённая работа] Что кроется за “проактивностью” в ИТ-вакансиях?
- [Управление персоналом, Здоровье] Психологические границы
- [Венчурные инвестиции, Управление e-commerce, Развитие стартапа, Управление продажами, Управление персоналом] Зачем нужны 100 000 электрофургонов Rivian и почему Amazon финансирует ИТ-курсы для учащихся из неблагополучных семей? (перевод)
- [GTD, Управление персоналом] Кто такие шизоиды, где они обитают, и почему вам может быть полезно о них узнать
- [Управление персоналом, Здоровье] Синдром самозванца и эмоциональное выгорание
- [Высокая производительность, Мозг, Управление проектами, Управление разработкой] Как создать KPI по стрессу — и превратить его из врага в помощника
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_menedzhment (менеджмент), #_timlid (тимлид), #_upravlenie_razrabotkoj (управление разработкой), #_organizatsija_protsessov (организация процессов), #_blog_kompanii_tinkoff (
Блог компании Tinkoff
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 03:34
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Не так давно я прочитал интересную статью о том, как стать тимлидом и что нужно делать в этой роли. И мне захотелось рассказать про следующую ступень развития — в качестве менеджера и руководителя IT-отдела или IT-директора в небольшой компании. Стоит отметить, что для разработчика существует несколько векторов развития, которые хорошо описаны в статье Три дороги для программиста: эксперт, руководитель, основатель. Я же сосредоточусь на втором направлении — руководителе. За свою карьеру я проработал тимлидом более 5 лет и чуть меньше года — в роли руководителя фронтенда. Да, руководящего опыта у меня не так уж много, но будучи тимлидом я пристально наблюдал за работой своего начальства. На основе этих наблюдений и попытаюсь рассказать, чем же занимаются эти непоседливые менеджеры. В этой статье хочу рассказать о некоторых задачах и зонах ответственности руководителя и чем они отличаются от задач тимлида. Чтобы далее не писать длинное «руководитель отдела», буду писать просто «руководитель». В тексте я буду оперировать в основном двумя ролями: «руководитель» и «тимлид». Под «руководителем» я подразумеваю начальника «тимлида». Между этими ролями может быть достаточно много ступеней иерархии, в зависимости от размера компании. У руководителя и тимлида много схожих задач — различия лишь в масштабах. Про то, как стать тимлидом и что нужно делать в этой роли, написано много статей (например, та, которую я упоминал выше). На самом деле список задач руководителя практически бесконечен, но попробуем выбрать те, которые больше всего отличаются от задач тимлида:
Стратегия Зрелым тимлидам тоже приходится задумывать о стратегии, но только в меньшем масштабе — в пределах команды. Тимлид должен думать о том, как повысить тестовое покрытие на проекте, как прокачать джунов, как ускорить код-ревью и так далее. В масштабе отдела/компании приходится думать более абстрактно. И чем выше руководитель, тем абстрактнее ему приходится думать. Если сравнивать с задачей тимлида, например — увеличение тестового покрытия. То для руководителя это должна быть другая цель — увеличение качества продукта. Тесты — это уже тактика, один из инструментов достижения цели. Уровень абстрактности может варьироваться в зависимости от масштабов и задач. В какой-нибудь большой компании руководитель может просто задать цель и критерии ее достижения. Например, цель — уменьшить количество сбоев в два раза, критерием ее достижения будет уменьшение количества плохих отзывов на «Банки-ру» до 10 в месяц. Также в небольшой компании руководитель может задать цель в виде конкретных задач: внедрить e2e-тесты, настроить мониторинг и алерты. Но это очень тонкая грань. Довольно часто выходит боком, когда руководитель пытается решать за лидов или разработчиков, с какими инструментами им работать и как. Для руководителя с бэкграундом разработчика это большой соблазн, потому что это интересная работа — выбирать инструменты и внедрять их. В общем, вырастая в руководителя, нужно учиться отрываться от реализаций и больше заниматься целеполаганием, делегируя остальное. Организационная структура Каждая компания или отдел — это небольшое государство, и, как в любом государстве, здесь должна быть определенная система управления. Задача руководителя — формализовать эту систему: описать, по каким критериям должны группироваться сотрудники, как должен происходить карьерный рост и так далее. По мере роста компании эта система всегда меняется. Например, когда в компании было 50 человек, система представляла собой иерархию: руководитель → тимлиды → разработчики. Но, когда штат вырастает до 200 человек, одних тимлидов недостаточно. Появляются руководители отделов, кураторы, менторы и так далее. Вместо плоской структуры из команд выстраиваются пирамиды из юнитов, отделов, управлений. Если в масштабе 50 сотрудников руководитель может ситуативно или по запросу заниматься пересмотром должностей, то в большем масштабе это приходится делать по расписанию — например, раз в полгода. Если говорить в общем, то менять структуру по мере роста необходимо, чтобы иметь возможность делегировать и контролировать. Да, это всем привычная система, выглядит она просто и естественно. Но основная работа здесь ложится именно на руководителя: он должен решить, в какой момент и как поменять организационную структуру. Это же касается и общих процессов, которые позволяют сокращать издержки за счет унификации. Как пример — процесс создания и контроля индивидуального плана развития сотрудников. Без четкой структуры будет сложно запускать и развивать этот процесс. Но если вы заранее выстроили организационную структуру, выделили тимлидов, наладили с ними коммуникацию и регулярные встречи по синхронизации, то это будет достаточно легко. Существует много других общих процессов, которые руководитель должен создавать и делегировать. Если начать их все перечислять, это выльется в отдельную статью. Правила целеполагания Руководителю необходимо разработать правила, по которым тимлиды могут устанавливать свои собственные цели и делегировать их ниже. Также важно контролировать промежуточные результаты — без этого сотрудники могут работать совершенно не в том направлении. Есть несколько конкретных инструментов для решения этой задачи:
Не будем вдаваться в сравнения эффективности этих инструментов: важно понять, что задача, которую они решают, — описать формат целей и способ их делегирования. Часто это необходимо, когда организационная структура разветвленная и есть требуется сравнивать эти ветви. Если у вас пять отделов и они живут в разных системах целеполагания, то будет очень сложно объективно сравнивать их между собой или делегировать им типовые задачи. Фонд оплаты труда Изначально я хотел рассмотреть задачу по оценке работы сотрудников. Но этой задачей занимаются как тимлиды, так и руководители — каждый в своих плоскостях. Разница лишь в том, что решение о пересмотре заработной платы принимает именно руководитель, он же в той или иной мере заведует фондом оплаты труда ФОТ). Раздать каждому по справедливости — довольно сложная задача, особенно если ты не работаешь непосредственно с теми, кому пересматриваешь зарплату. Для пересмотров есть несколько ограничений:
С размером ФОТ на первый взгляд кажется все просто: ты меняешь ЗП сотрудников и смотришь, вписываются они в ФОТ или нет. Но сложность в том, чтобы подогнать эти изменения ровно под размер ФОТ, особенно если ты его не знаешь. Например, я руковожу отделом фронтенда, ФОТ на всю компанию один. CTO просит меня сделать пересмотр моим сотрудникам и отправить ему список с коэффициентами. Так как я не знаю размер ФОТ, я буду опираться только на заслуги сотрудников и их должности (мне это кажется даже более правильным, чем если бы я знал размер ФОТ и ориентировался на него). Далее я отправляю результат CTO, он складывает его с результатами других отделов, и оказывается, что мы вышли за рамки ФОТ. Какой-то отдел больше, какой-то меньше. И тогда мы начинаем «подгонять», это может занять несколько итераций. Соблюдение баланса ЗП между сотрудниками не всегда является приоритетной задачей, так как зачастую размер ЗП не разглашается и это регулируется соответствующими соглашениями. Но, если допустить большой дисбаланс, это может вылиться в трудности с наймом новых и удержанием текущих сотрудников. Также поддержание баланса может помочь в вопросе пересмотра должностей. Например, ЗП сеньора в компании варьируется от 180 до 220 попугаев. Пришло время пересматривать ЗП сеньора Иванова: сейчас он уже получает 220, а хочет 250. Зная границы ЗП для сеньоров, этот момент должен вызвать у вас вопрос, а ту ли должность занимает Иванов? Может, пора его повысить до архитектора? Рост ЗП в основном должен соответствовать рынку и возможностям компании. Поэтому важно делать пересмотры постепенно и своевременно. Например, рост ЗП может зависеть от должности. Сейчас джуны вырастают до мидлов очень быстро, поэтому их нужно пересматривать чаще. Так как конкуренция на рынке труда достаточно высокая, велик шанс потерять сотрудника, если не сделать пересмотр вовремя. Даже если сотрудник сам не просит о пересмотре ЗП, лучше это делать с определенной периодичностью, изменяя ЗП постепенно. Иначе может возникнуть ситуация, что вы не пересматривали сотрудника два года и теперь он просит +150 тысяч рублей. В лучшем случае это вызовет вопросы у вашего руководства, в худшем — вы не сможете себе этого позволить и потеряете сотрудника. Наем Процесс найма очень обширный и требует тщательного контроля. В небольших компаниях за наем может напрямую отвечать руководитель, в больших компаниях этим занимаются целые HR-отделы. Так или иначе руководитель обязан быть вовлеченным в процесс найма: HR сами по себе не могут этим заниматься. Чтобы понять, зачем именно в этом процессе нужен руководитель, рассмотрим задачи связанные с наймом:
Найти хорошего техспециалиста несложно — сложно найти и обучить эксперта, мнению которого вы смогли бы доверять. Ведь портрет кандидата не ограничивается хард-скиллами, интервьюер должен уметь понимать мотивацию кандидата, его амбиции, характер и т. д. Эта тема хорошо раскрыта в статье Резюме глазами интервьюера — советую ознакомиться. Всему этому интервьюеров должен научить именно руководитель. Необязательно напрямую, чаще это делегируется сверху вниз. В итоге самое важное — это доверие к интервьюерам, ведь ошибки при найме могут обходиться достаточно дорого. На мой взгляд, сложности начинаются тогда, когда из одного источника кандидатов появляется несколько потребителей. В этот момент руководителю приходится заниматься управлением приоритетами для этих самых потребителей. Работа с приоритетами требует большого внимания, анализа и информации о текущих делах в компании. Нельзя один раз задать правила, по которым наем будет работать продолжительное время. Этот процесс живой и зависит от очень многих показателей, которые часто меняются: текучка кадров, приоритеты бизнеса, изменения рынка, рост сотрудников и так далее. В нашей компании есть отличное решение для разделения потока кандидатов под разные отделы — сегрегация рынка по технологическому стеку. Например, на продукты для обслуживания физлиц мы нанимаем React-разработчиков, для юрлиц — Angular. Это позволяет избежать конфликта приоритетов найма между разными отделами. Наем требует непрерывного анализа и прогнозирования, так как задержки при найме могут сильно повлиять на развитие бизнеса и компании в целом, особенно в высококонкурентной среде. Поэтому хорошим навыком является умение прогнозировать, когда вырастет объем задач, и быть готовым к этому. Не стоит забывать, что для новых сотрудников нужен период адаптации, который может длиться несколько недель. Также кандидаты могут не пройти испытательный срок, не сработаться с командой и много-много других факторов риска. К сожалению, владение актуальной информацией о потребностях в сотрудниках не всегда спасает. Наем сильно зависит от рынка: поток кандидатов может в момент прекратиться и вы никак не сможете на это повлиять. Одним из хороших примеров решения таких ситуаций (не всегда) является аутсорсинг. Нас не раз выручали подрядные организации, которые выводили разработчиков на наши проекты за считанные дни. Также есть пример более зрелого и дальновидного решения проблем с наймом — открытие центров разработки. По мере роста компании Тинькофф было принято решение открывать центры разработки в разных уголках России, сейчас их около 12. Москва не резиновая и далеко не все хотят сюда переезжать, поэтому решение полностью оправдало себя, и сейчас я даже не могу представить, как бы мы выжили без этого. Конечно, пример достаточно специфичный и справедлив для больших компаний, но из него стоит вынести, что даже для проблем, которые кажутся временными, стоит искать долгосрочные решения. Вывод Приведенные выше примеры не сильно связаны между собой, я использовал их, чтобы показать, чем же именно занимается руководитель и чем его задачи отличаются от задач тимлида. Как можно заметить, разница заключается в том, что тимлид большую часть времени занимается непосредственным управлением людьми и проектом. А руководитель в основном сосредоточен на создании окружения, структур и правил. Существует еще очень много интересных и важных задач руководителя: исследования, обучение сотрудников, развитие тимлидов, ротации в командах, презентации работы и т. д. Но об этом как-нибудь в другой раз :-) Теперь мне интересно, что же там после руководителя? Но пока я не знаю ответа на этот вопрос. =========== Источник: habr.com =========== Похожие новости:
Блог компании Tinkoff ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 03:34
Часовой пояс: UTC + 5