Редко встретишь человека, который идеально вписывается в команду: он знает до мелочей необходимый язык программирования и его основные фреймворки, с детского сада работает с базой данных, которая, о сюрприз, используется в вашем проекте, и привык именно к вашим шуткам. Это утопия, в реальности такого не бывает.
Стоит сказать, что все вокруг меняется, и те технологии, которые используются сегодня, завтра уже будут находками археологов.
Стоит сказать, что все вокруг меняется, и те технологии, которые используются сегодня, завтра уже будут находками археологов.
Поэтому важной задачей является обучение и развитие сотрудников. И что важно - регулярное. По моему мнению, чем более актуальные и широкие знания у работников, тем более эффективно они работают, что, в свою очередь, дает компании конкурентное преимущество.
Однако, если эта идея достаточно проста, то вопрос “а что прокачивать, софт или хард скиллы?” уже не так тривиален.
Был бы у нас под рукой какой-нибудь простой критерий, который позволит безболезненно ответить на этот вопрос… Вот он!
Однако, если эта идея достаточно проста, то вопрос “а что прокачивать, софт или хард скиллы?” уже не так тривиален.
Был бы у нас под рукой какой-нибудь простой критерий, который позволит безболезненно ответить на этот вопрос… Вот он!
На этой схеме в центре (1) можно увидеть шкалу, на что стоит обратить большее внимание - софт скиллы или хард скиллы.
Теперь рассмотрим шкалы по осям.
Теперь рассмотрим шкалы по осям.
Шкала №2 применяется для инженеров, т.е. рядовые разработчики, тестировщики, системные аналитики
Здесь основной критерий в следующем: чем ближе к конечному пользователю (или партнеру) находится инженер, тем больше ему необходимо развивать софт скиллы.
Пара примеров:
Здесь же можно привести пример системных администраторов. Можно подумать, что у них нет ни пользователей, ни партнеров. Однако в некоторых компаниях инфраструктура позиционируется как платформа или продукт, а ее потребителями (читай клиентами), являются разработчики, тестировщики. И уже с этой точки зрения многим админам стоит развивать как раз таки скиллы коммуникации, решения проблем и даже конфликтов.
Пара примеров:
- В одной из моих команд был С++ разработчик, сеньор, которому я доверял сложные архитектурные задачи. Он мало общался с нашими партнерами, поэтому он в основном развивал технические навыки - проектирование, многопоточное программирование, низкоуровневое программирование и так далее.
- В той же команде у меня был middle-разработчик, который часто консультировал наших партнеров по вопросам интеграции, часто коммуницировал с аккаунт-менеджерами. Так вот с ним мы много обращали внимание на софт скиллы и связанные вещи (например, английский).
Здесь же можно привести пример системных администраторов. Можно подумать, что у них нет ни пользователей, ни партнеров. Однако в некоторых компаниях инфраструктура позиционируется как платформа или продукт, а ее потребителями (читай клиентами), являются разработчики, тестировщики. И уже с этой точки зрения многим админам стоит развивать как раз таки скиллы коммуникации, решения проблем и даже конфликтов.
Шкала №3: количество коммуникаций
Это более универсальная шкала. Она применима и к разработчикам, и ко всем остальным, в том числе к тимлидам.
Если у сотрудника множество задач завязано на коммуникациях, он должен эти вести коммуникации максимально эффективно. Самый яркий пример - это аналитики, кому приходится работать с большим количеством людей в рамках сбора требований, а также менеджеры проектов.
Эти две шкалы помогают в самых общих случаях и являются основной для принятия решений.
Следующие 2 приема помогают более точно определить, в какую сторону стоит копать.
Если у сотрудника множество задач завязано на коммуникациях, он должен эти вести коммуникации максимально эффективно. Самый яркий пример - это аналитики, кому приходится работать с большим количеством людей в рамках сбора требований, а также менеджеры проектов.
Эти две шкалы помогают в самых общих случаях и являются основной для принятия решений.
Следующие 2 приема помогают более точно определить, в какую сторону стоит копать.
Цели команды/компании
Тут можно даже сказать, что не цели, а курс, которым идет команда/компания. Например, раньше мы много работали с аутсорсерами, из-за чего мы много коммуницировали с внешними командами. (тут нужно больше софт скиллов). Теперь же мы больше смотрим в сторону in-house разработки для более качественных технических решений. Здесь фокус уже смещается на хард скиллы.
Результаты ревью
Берутся в расчет как результаты self-review, так и 360 review. Именно подобная оценка показывает, какие есть просадки у человека.
В рамках одного из подобных процессов я обратил внимание на то, что один из моих разработчиков плохо выполняет задачи в одной из областей:у него не очень клеилось именно с сетевыми запросами, по всем остальным аспектам было вполне адекватно. Это был яркий индикатор того, что надо обратить внимание на технические навыки. Как итог, мы добавили ему в план обучения сетевое программирование на С++, и к следующему ревью, примерно, через квартал, ситуация в этой области выровнялась.
Чтобы добиться таких результатов, руководителям и тимлидам важно регулярно проводить комплексную оценку своих сотрдуников, на основе которой составлять персонализированные и актуальные планы развития.
Многие коллеги из индустрии обращались ко мне с вопросами, как я это делаю? какие инструменты использую?
На основе своего опыта и стандартов индустрии, я собрал лучшие практики в комплексном тулките по управлению командой, где представлены шаблон и форма 360 review, шаблон плана развития сотрудника, и многое другое.
Идея проста: вы покупаете тулкит и можете незамедлительно начать им пользоваться, так как гайды легко адаптируются под ваш бизнес и роли.
Тут можно даже сказать, что не цели, а курс, которым идет команда/компания. Например, раньше мы много работали с аутсорсерами, из-за чего мы много коммуницировали с внешними командами. (тут нужно больше софт скиллов). Теперь же мы больше смотрим в сторону in-house разработки для более качественных технических решений. Здесь фокус уже смещается на хард скиллы.
Результаты ревью
Берутся в расчет как результаты self-review, так и 360 review. Именно подобная оценка показывает, какие есть просадки у человека.
В рамках одного из подобных процессов я обратил внимание на то, что один из моих разработчиков плохо выполняет задачи в одной из областей:у него не очень клеилось именно с сетевыми запросами, по всем остальным аспектам было вполне адекватно. Это был яркий индикатор того, что надо обратить внимание на технические навыки. Как итог, мы добавили ему в план обучения сетевое программирование на С++, и к следующему ревью, примерно, через квартал, ситуация в этой области выровнялась.
Чтобы добиться таких результатов, руководителям и тимлидам важно регулярно проводить комплексную оценку своих сотрдуников, на основе которой составлять персонализированные и актуальные планы развития.
Многие коллеги из индустрии обращались ко мне с вопросами, как я это делаю? какие инструменты использую?
На основе своего опыта и стандартов индустрии, я собрал лучшие практики в комплексном тулките по управлению командой, где представлены шаблон и форма 360 review, шаблон плана развития сотрудника, и многое другое.
Идея проста: вы покупаете тулкит и можете незамедлительно начать им пользоваться, так как гайды легко адаптируются под ваш бизнес и роли.
