• Почему не работают системы развития сотрудников

    Posted on January 28th, 2009 Александр Орлов 14 comments

    Рано или поздно любая компания размером от стартапа и выше начинает понимать, что надо как-то сделать так, чтобы сотрудники развивались. Без развития сотрудников, понимает компания, настанет неминуемый трындец.

    А как это сделать? А вот как – прочесть всем тренинг по развитию и составить каждому инженеру индивидуальный план развития. Personal Development Plan. В руководстве почему-то считают, что если сделаны эти два шага – то всё, 100% сотрудников придут в поступательное движение и таки вырастут в лидеров.

    Поскольку я сам проходил через таковые тренинги, процедуру внедрения Personal Development Plan’ов и, вообще говоря, занимаюсь смежной темой :) , то я могу объяснить, почему это не срабатывает. И как делать правильно.

    Причина №1. Не всех сотрудников можно развить. Более того, не всех нужно. Очень редко встретишь компанию, где подобрались сплошь правильные программисты. Обычно в компании есть некоторое количество классных сотрудников, которые делают, условно говоря, 80% работы. Есть группа серядняков, которые делают 30% работы. И есть группа балласта, которая делает -10% работы. -10% – это отнимает время первых двух групп своими косяками, глупыми вопросами и прочей несуразицей.

    Так вот есть такая парадоксальная мысль, что менеджеру надо тратить 80% своего времени на тех сотрудников, которые дают 80% результата. Не на тех, кого надо тянуть за уши, а на тех, кто и так уже умеет летать. Заниматься развитие балласта – все равно, что поливать карликовую березку в надежде, что из нее вырастет нормальная.

    Причина №2. Недоверие к менеджеру. В процессе развития, ключевую роль играет менеджер человека. Он помогает составлять план развития, он дает обратную связь, он помогает с движением по плану. Короче говоря, менеджер играет роль наставника. И успешно играть эту роль он может только в одном случае. Если инженер воспринимает его как наставника.

    То есть, банально, должно быть хотя бы доверие инженера к менеджеру. Если доверия нет, если инженер считает, что ему просто промывают мозги, потому что “у менеджера работа такая”, то никакой Personal Development Plan не сработает.

    Причина №3. Общее недоверие к массовым инициативам компании. Любое изменение неминуемо встречает сопротивление. В частности, любая инициатива сверху, которая предлагает человеку не получать больше денег, а делать что-то дополнительно. :) К тому же редко какая компания зарекомендовала себя изнутри исключительно здравыми инициативами. Большинство инициатив снизу выглядят довольно дурацкими. “Ну вот теперь всем развиваться надо. Господи, когда уже это кончится, и дадут, наконец, поработать…”

    Причина №4. Недоверие к системе. Довольно часто тренинги по развитию карьеры читаются специалистами широкого профиля. Которые аналогичные программы читают для продажников в “Эльдорадо”, производителей сгущеного молока и работников туристического бизнеса. Программисты, естественно, считают себя исключительными людьми, на которых общие методы развития не действуют.

    Иногда читают западные тренеры, которые не могут понять “душу отечественного инженера”. “У них там на Западе все на голову ударенные в плане карьеры. У нас все по-другому.”

    На все это накладывается недоверие к инструктору. Иногда тренинги по развитию карьеры для программистов читает HR специалист, которого научили читать этот тренинг. Это не работает. Если бы тренинг читал Джэймс Гослинг или там Линус Торвальдс – тогда да, тот же материал воспринимался бы по-другому. Парни бы еще примеры из своей жизни на него наложили – и получилось бы вообще отлично. А HR специалист обычно не воспринимается программерами как лидер, которому можно доверять.

    (Чтобы не обижать своих знакомых HR специалистов, скажу, что допускаю, что кто-то из HRщиков может зажечь огонь унутре сотрудника. Буду рад, если это окажется так. Но пока – то, что видел, не работало.)

    Резюме. Системы развития инженеров работают. Работают хорошо. Но не всегда и не со всеми. Чтобы от всего это был какой-то толк, нужно сначала:

    • Обратить внимание на процессы найма. Чтобы в компанию рвались работать толковые люди, и только они и проходили сквозь сито отбора. Правильные люди к тому же имеют ярко выраженную склонность к саморазвитию. Они и без тренингов по развитию движутся вперед ого-го как.
    • Сократить балласт. Кризис -  довольно удачный момент для того, чтобы отпустить тех людей, для которых программирование – это не их дело. Освободившиеся позиции сейчас будет довольно легко занять.
    • Вкладываться в развитие менеджеров. Это те люди, которые осуществляют процесс найма. Это те люди, которые имеют массу рычагов влияния на инженеров. Это те люди, которые должны уметь завоевывать доверие команды и быть лидерами. Линейные менеджеры – это ключевые игроки во всей этой схеме.
    • Приглашать экспертов и не допускать чтения того же материала не-экспертами и людьми, которые не вызывают уважения инженеров.
     

    14 responses to “Почему не работают системы развития сотрудников”

    1. Очень своевременный пост. У нас как раз начали этим болеть!

    2. Антон, ты засылай своим ссылку на пост. Или можно отправлять прямо ко мне с вопросами. :) Бесплатно расскажу в картинках, как это выглядит, когда делается неправильно. :)

    3. прочитал сначала резюме, все хорошо, но насторожила фраза

      >Приглашать экспертов и не допускать чтения того же материала не-экспертами и людьми, которые не вызывают уважения инженеров.

      чтоб понять, пришлось читать все целиком
      не сразу понял что речь про тренинги :-)

    4. :) ) Да там не только тренинги иногда. Там еще всякие формы бывают.

    5. Константин Иванов

      Добрый день!
      Пост интересный. И актуальный для меня.. Я начинающий манагер по проектам.. У меня всего 2 человечка в команде и обоих сейчас обучаю сам.. Но ни кто из них после работы не хочет ничего дополнительно читать учить и т.д. В общем то понимаю в чем то они правы но их обучение очень много времени у меня отнимает и получается даже так что за весь день сам я могу ничего не сделать.. А задач ставят постоянно все больше, сроки короче…. Начальство периодически настаивает навести порядок в команде и либо научить их все таки чтобы это давало результат либо перевести куда то и набрать новых людей.. Я в замешательстве что делать! Новых набирать боюсь – никогда этого не делал, и не уверен что наберу кого то правильно.. А текущие 2-е оч медленно обучаются… Но в общем то что то у них получается и какие то проекты они уже реализуют..Но опять же пугает тот факт что сами они ничего не стремятся учить а научиваются только когда я им на работе это объясняю.. Посоветуйте что нибудь если не сложно..

    6. Помнится по моему в MotivateMeRight была фраза о том, что даже профессионалу в IT не нравится заниматься всем, чем его заставляют – ибо не его это, хоть и спектр “его” шире, чем у новичка. Проблема мотивации, это вообще отдельная тема :) Пара советов – во-первых знаете ли вы как эти люди попали в компанию и хотели ли они к вам на направление, и вообще чем они бы хотели заниматься :) Ну а во вторых почитайте обязательно это – http://moti.vate.me/book/ – в сжатом виде очень хорошая вещь – и очень полезная

    7. Согласен со многим.
      С избирательным развитием сотрудников есть только одна проблема.
      Представь что ты послал Петю на семинар по каким-то кунштукам №1. Взял и послал, и об этом пост-фактум узнали все. И начинаются:
      1) вопросы “а почему не я”
      2) претензии “опять обманули” и “где же ваша хваленая открытость”
      3) обиды “всё, меня не любят”
      А ты им и говоришь “я, мол, развиваю только правильных людей” :) вот тут и начнутся колоссальные процессы в бессознательном программистов (а оно бездонно).

      В поддержку скажу, что я (несмотря на слова Антона про “болезнь”) почти принял решение и намеренно развиваю только 2 категории сотрудников – новичков и менеджеров. Инициативу по саморазвитию остальных – поддерживаю. Но только к 2м категориям сотрудников я считаю нужным предъявлять _требования_ по постоянному развитию (по вполне понятным причинам).

    8. 2 Dennis. Да, есть такие проблемы, куда без них. )

      А собственно “почему не он”? Мне встречались два варианта:
      – Можно было бы послать на семинар больше людей, но есть ограничение по бюджету.
      – Бюджет тут ни при чем, просто посылают того, кто круче остальных.

      В первом случае таки надо соблюдать равноправие. Послали Петю туда, в следующий раз пошлем Васю вот туда. Это можно декларировать открыто.

      Во втором случае непосланные люди делятся на две категории. Первые понимают, что Петя реально круче них, поэтому его и послали на семинар по кунштукам. Вторые действительно не понимают, почему Петя круче них, и приходят с вопросом “почему не я”.

      Таки надо уметь объяснить им, почему не они. Я говорил, что это просто? :) Ни фига это не просто. Но я считаю, что это, возможно, одна из самых сложных и нужных задач менеджера – объяснить человеку, что ты от него ждешь. И что ему нужно сделать чтобы стать “Петей”.

      То есть, недостаточно сказать человеку, что он неправильный. Тут бессознательное программиста стартанет свои процессы. Нужно объяснить ему, что конкретно не так, и что конкретно от него надо.

      Примерно как с зарплатой, когда надо ответить на вопрос: “Почему Пете подняли зарплату на 100 долларов, а мне только на 50?” :-)

    9. 2 Константин Иванов. Как обычно очень сложно что-то советовать, я это называю “лечить по фотографии”. :) Слишком много переменных. Общее ощущение, что вам достались неправильные люди, но… 100% диагноз можно поставить только наблюдая больного. :)

      Поэтому буду рассуждать и задавать вопросы, возможно, это натолкнет Вас на правильное решение.

      Пункт №1. У вас бывают встречи 1:1 с этими программистами, где вы обсуждаете эти проблемы? Скажем, так – озвучивали ли вы свое недовольство сотрудникам, или же они пока о нем догадываются по вторичным признакам? :)

      Дайте людям возможность обучиться самостоятельно. Рано или поздно им нужно научиться это делать. Если Вы сами не хотите всегда все делать за них. Скажите им ЧТО делать, и пусть они сами придумают КАК.

      Пункт №2. При самостоятельном обучении – какова скорость обучения? Я так понимаю, что люди учатся медленно. Что не является хорошим признаком. “Не учите свинью летать – вы не достигнете своей цели и измучаете свинью.” :)

      Пункт №3. Бюджет позволяет нанять более зрелых людей на эти позиции?

      Пункт №4. Обсудите ситуацию с начальством – оно тоже заинтересовано в том, чтобы вы делали больше и лучше. Более того, у начальства есть опыт, и оно видит гораздо больше, находясь рядом.

      Пункт №5. Не надо бояться проведения собеседований. Все, конечно, приходит с опытом, но… Читаем:
      – Книгу т. Орлова про секреты управления программистами
      – статью т. Джоэла Спольски: http://local.joelonsoftware.com/wiki/%D0%98%D1%81%D0%BA%D1%83%D1%81%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B2%D1%8C%D1%8E

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

    10. Zhanna Bitukova

      2 Константин Иванов. К написанному Александром Орловым добавлю свои вопросы:

      №7: Самостоятельная работа, которой Вы ожидаете от программистов, это овладение знаниями/умениями необходимыми для решения поставленных задач, или развитие сверх того? Судя по Вашему посту имеются в виду навыки, нужные для выполнения их непосредственных обязанностей. Если так, речь идет не о развитии сотрудников, а уже скорее о соответствии занимаемой должности. Действительно ли они ей соответствуют?

      №8. Какой срок у Вашего проекта или проектов? Какой объем задач? Может для их решения в заданное время двух человек в принципе недостаточно. Тогда, чем раньше Вы доукомплектуете команду, тем лучше. Какое-то время понадобится для вхождения в проект и притирки, поэтому лучше этим заняться сейчас, чем потом, когда перед глазами уже замаячит срыв сроков и невыполение других обязательств.

    11. По поводу собеседований еще очень хорошо написано у Сергея Архипенкова в “Руководство командой разработчиков ПО”.

    12. Константин Иванов

      2 Александр Орлов:

      к П1 – Разговоры 1 на 1 бывают, проводятся все там же на работе.. Открыто недовольство не высказывал..
      к П2 – Сложно сказать что конкретно медленно.. 1 человек понимает все быстро, но он работает на пол ставки.. а 2-й человек работает на полный день но разбирается во всем медленно..
      к П3/П4 – с бюджетом сейчас грустно, кризис блин маячит ещё…. Нанять кого то ещё мне сейчас точно не дадут – в общем то с задачами мы справляемся, с теми которые сейчас ставятся.. Но получается как – начальство знает что мы можем и ставит задачи благо в пределах возможного. Но я знаю что я могу и больше, а вот мои люде не могут..
      В том насколько мое начальство хорошо знает управление программистами я засомневался после нескольких случаев.. Например недавно зашла речь о новом человеке в отделе, в группе моего коллеги. Человек реально был нужен, я сказал да отлично, давайте устроим “кастинг” и выберем хорошего человечка. (единственным условием было что этот человек уже должен работать в компании в соседних отделах -поскольку группа коллеги занимается информационным наполнение ресурсов и там нужно знать специфику компании). Начальство сказало – да давайте.. Но через 2 дня я узнаю что человек в наш отдел уже выбран без нашего участия! Выбран по принципу – самый ненужный человек из соседнего отдела – увольнять пока не охота а вам нужен человек – вот и получайте! Этот человек женщина которая никогда не была связана с программированием и она оч слабый пользователь ПК.. А весь наш отдел это так или иначе программисты и в коллектив она не вписывается вообще!
      Вот как то так..

      2 Zhanna Bitukova

      к П7 – Сложно начать мыслить подругому чем все вокруг.. В наш отдел люди набирались всегда как попало, и с какими попало навыками..Сильных программистов там никогда не было да и потребности в них тоже.. Но Специфика поменялась, задачи стали другими вот теперь и появилась моя группа. Но люди туда попали из старого набора. В общем то все они имеют высшее техническое образование в программировании, только вот практики не было пока их не отдали мне.. Я думаю они не безнадежны всетаки)

      к п8 – Сроки у нас всегда были оч маленькими.. Мы отдел который задуман как те кто должен оч быстро создавать не особо сложные приложения для обслуживания.. Больше месяца сроков никогда не было. В проекте сложно задействовать несколько человек из-за того что он обычно маленький.. Но если вдруг понадобится новый человек – вводить его в старые проекты долго не придется

      PS: Всем спасибо за вопросы. Все это натолкнуло на определенные мысли в надеюсь верную сторону)

    13. 2 Константин. Добавлю немного. Принцип набора в команду “как попало” надо изживать. Если его не изжить, то все время будет тратиться на воспитание сотрудников. Обсуждали с начальством эту проблему? В частности, вопиющий случай найма тетеньки без вашего ведома.

      Серьезно, зачастую начальство может лаже не догадываться, что менеджер может быть против того, чтобы без его ведома набирали народ. “А чего он недоволен? Мы же всегда так делали. Даже и не думали…”

      Лучше озвучить эту проблему, если еще не. Сделав акцент на том, что волнует начальство. Если начальство волнует бизнес – то надо рассказывать, как тетенька не тянет с точки зрения бизнеса. Если начальство волнуют люди, то надо рассказывать, как рассыпается ваша команда под воздействием неквалифицированного новичка.

    14. 2 anton_nix. Точно, у Сергея хорошо написано.

    Leave a reply

    You must be logged in to post a comment.