Жуткие баталии разворачиваются вокруг минских ИТ компаний. Уволенные/уволившиеся сотрудники, тонко язвя, пытаются опустить предыдущие места работы, а заодно и всех, кто там работает ниже плинтуса. Те, кто остался, во главе с руководством компаний, не менее тонко язвя, пытаются порвать обидчиков на британский флаг. Я наблюдаю эту картину уже много лет и dev.by/companies не внес в это противостояние ничего нового. Откуда такая многолетняя вражда? Как человек, радостно принятый в ряды коллег, через три месяца становится заклятым врагом? С моей точки зрения есть две несколько причин.
1. Противоположный взгляд на проекты.
Все, кто работают в оффшорном аутсорсинге работают в сфере обслуживания. Звучит конечно странно и непривычно (сразу перед глазами вырастает некий советский дом быта...), но это так. Высокие технологии, языки программирования, платформы, методики, сертификаты и прочее - всего лишь инструменты обслуживания клиентов. Любой продавец знает, что в нашем случае, в первую очередь покупают личные взаимоотношения. Если нет личных взаимоотношений, то до технологии дело уже не дойдет, даже если ваша компания трижды ИСО сертифицирована, CMMI сертифицирована и все ваши сотрудники имеют по медали от Microsoft.
Личные взаимоотношения могут быть установлены тогда, когда компания понимает что такое customer service, стремится понять что нужно клиенту и найти решение для его проблем. Если оно в этом преуспевает, то бизнес развивается, довольные клиенты рекомендуют компанию своим знакомым, компания растет. Проблемы начинаются тогда, когда проект получен и ушел в разработку.
Разработчикам интересно делать интересные проекты. Все остальное им не интересно и запас терпения на не интересных проектах в большинстве случаев равен где то 6ти месяцам. Maintenance проекты - неинтересны. PHP уже не модно. VB - ой меня сейчас вырвет прямо вам на туфли! Конфликтная ситуация налицо и, в большинстве случаев, дело кончается конфликтом и увольненями.
2. Ошибки HRов.
Есть старое правило - если есть доля сомнений, не надо брать кандидата на работу. Лучше не взять хорошего, чем взять плохого. Сегодня, во время дефицита кадров, это правило для большинства компаний не работает. Не работает и ладно, есть способы выкрутится: набрать толковую молодежь, организовать коучинг, обучение внутри компании, четко прописать правила жизни и работы в компании, структурировать карьеру и прописать от чего она зависит. И все это надо показать человеку на собеседовании, добиться от него понимания и предложить подумать - подходит ли ему такая жизнь. Если подходит и технически человек подготовлен к работе (или может быть подготовлен в допустимые сроки) его можно брать. Скажите, кому из вас на собеседовании дали всю необходимую информацию о работе в компании? Кто знал заранее на какой проект идет и, главное, что будет если он на этот проект не попадет?
Далее, испытательный срок. Сотрудник должен очень точно знать каковы критерии прохождения испытательного срока. Он должен знать кто примет решение о успешном либо неспешном прохождении испытательного срока. ПО окончании испытательного срока сотруднику в любом случае должны предоставить возможность высказаться и ОБСУДИТЬ с ним результаты "испытаний".
Работа после испытательного срока. Сотрудник должен получать feedback от своей компании. Понятно что он получает его ежедневно от своего руководителя проекта, но ведь есть еще и "Высшая сила", которая руководит самим руководителем проекта. А что она думает о нас? А она вообще знает о нас? Как часто она с нами здоровается? Высшая сила как правило ОЧЕНЬ занята иначе она бы не стала Высшей. :) Организовать регулярные фидбэки, обмен информацией и мнениями между верхами и низами должны HRы.
Увольнение. Это один из самых драматичных и нервных моментов в жизни любого сотрудника и его менеджера. Как бы плохо не работал сотрудник, он остается человеком. У него может быть семья, дети, собачка, ремонт дома, больная мама - что угодно. Даже если всего этого нет и сотрудник - накачанный фанатик страйкбола, которому на все плевать, подойдите к нему как к человеку. Во первых, увольнение не должно быть неожиданным (см выше про фидбэк). Во вторых, сотруднику надо дать время найти другую работу. В третьих, его ни в коем случае нельзя оскорблять, лишать денег напоследок и подвергать прочим измывательствам. Начните думать, кто от вас уходит: ненавидящий вас человек или бывший сотрудник.
3. Сертификации.
Ну тут не совсем сертификации... Где-то в одной из баталий мелькнули слова про крутых сертифицированных спецов, которые в одночасье покинули компанию. Давайте не путать "мух с котлетами". Крутой спец - не обязательно имеет сертификаты. Сертифицированный спец - не обязательно крут. Сертификат это все го лишь подтверждение ваших знаний о предмете сертификации, но это ничего не говорит о том, что вы умеете применять эти знания на пользу проекту. Сегодня у вас успешно прошла сертификация, в чем разница между вами "вчера" и "сегодня"? С точки зрения руководства компании ее, извините, пока нет. Она появится тогда когда вы поможете компании заработать больше денег.
Однако с точки зрения разработчика она есть, ведь он теперь СЕРТИФИЦИРОВАННЫЙ девлопер! Вам должны больше платить, вас должны всюду звать на работу, вам вообще теперь все должны. :) А на вашем текущем месте работы вам просто жали руку... и все... Конфликт? Конфликт! И мы, крутые технические спецы, свалим из этого отстойника для идиотов, пойдем туда, где интересно, где нас оценят, где солнце встает утром и люди улыбаются друг другу до самого вечера! Не будем вспоминать о том, что эта отстойная компания инвестировала в нас деньги, научила нас и полагает что было бы логично получить свой ROI на свои инвестиции. Нам скучно про это думать.
Я думаю минским компаниям вполне по силам решить все три проблемы, в конце концов, научили же они своих сотрудников не воспринимать клиентов как идиотов. Те компании, кто быстрее справится с этой непростой задачей вырвутся вперед в борьбе за таланты. Буду раз услышать ваши мнения на сей счет.
1. Противоположный взгляд на проекты.
Итак, весь оффшорный аутсорсинг это работа на конкретного клиента, это выполнение его пожеланий и предпочтений. Его деньги - наш сервис. Как верно замечает jonas, успешное развитие аутсорсинговой компании в данном случае возможно лишь при установлении практически личных отношений с клиентом, превращении Джона Джефферсона Смита в просто Джона. Вы будете отправлять ему в аттаче к репортам поздравления ко Дню Благодарения и Рождеству, а он порекомендует компанию своим знакомым, да и сам при случае будет обращаться за выполнением очередного проекта именно к вам.
Сэйлсы, как могут, обхаживают такого потенциально милого клиента, менеджмент планирует расширение офиса, сам Джон считает сэкономленные за счёт найма аутсорсеров деньги, и в результате все довольны - и продавец и покупатель. Осталось только разработчика представить и дело в шляпе. Но вот оказывается, что проект совсем неинтересный, и девелопер водит носом и занудничает, что ваш PHP он ещё в детстве отлюбил, а от на maintenance даже хомячки через пару месяцев с тоски дохнут. "Конфликтная ситуация налицо и, в большинстве случаев, дело кончается конфликтом и увольнениями". С одной стороны да, разработчик вполне вероятно несколько потерял связь с реальностью, и ему самооценка уже ходить мешает. Но с другой стороны, если человек действительно перерос этот уровень, если его используют, грубо выражаясь, для затыкания дырок? Если квалификация работника выше или хотя бы банально отличается от необходимой, как очень часто бывает?
Или наоборот, сколько случаев - когда один разработчик висит сразу на пяти проектах, так что голова кругом идёт, или сидит в командировках месяцами, про которые никто, кстати, не спешил упоминать. У менеджмента на всё это ответ обычно прост и ясен - тебя, парень, наняли работать, а не выбирать, так что иди, сынок, работай, пока солнце ещё высоко.
Ну и поработает нормальный человек над этим унылым "не своим" проектом, достанет он его в конец, и пойдёт он искать новое место работы. Но проблема в том, что его то не отпустят просто так. Где же ещё найдёшь второго такого, да и как клиенту объяснишь? Начинаются попытки удержания, какие-то аспекты выплаты зарплаты или там распределения всплывают и т.д. В результате, скандал, разборки и взаимная ненависть. А ведь можно было предугадать ситуацию, попытаться или подобрать более подходящий кадр на проект, или просто всё-таки заинтересовать человека. Хотя бы деньгами, ведь в нашем мире материалистов это тоже важно, не только в интересностях дело.
В конце концов, что в данном случае вообще делал менеджмент до самого конфликта?
2. Сертификация
"Сертифицированный спец - не обязательно крут. Сертификат это всего лишь подтверждение ваших знаний о предмете сертификации, но это ничего не говорит о том, что вы умеете применять эти знания на пользу проекту. Сегодня у вас успешно прошла сертификация, в чем разница между вами "вчера" и "сегодня"? С точки зрения руководства компании ее, извините, пока нет. Она появится тогда, когда вы поможете, компании заработать больше денег." Не стоит забывать, что сертифицированный специалист - более востребованный товар на рынке, и любой клиент с гораздо большим удовольствием будет платить за сертифицированного разработчика, чем просто за какого-то классного кодера Васю из далёкой и неведомой Беларуси. Вполне вероятно и платить согласятся за сертифицированного девелопера больше. Так что выгодна компании сертификация сотрудников и деньги ей она дополнительные приносит, здесь не надо лукавить :). А во избежание конфликтов, стоит чётко разъяснить программисту все условия, бонусы и минусы прохождениям им сертификации, о чём у нас тоже как-то иногда забывают.
3. Процессы
Сейчас стало модно говорить про налаженные процессы и сертификацию компании по всевозможным ИСО 9001, CMMI и т.д. Именно эти процессы разработки проектов, документации, коммуникации внутри компании и должны определять эффективность её работы. Насчёт самого девелопмента, то здесь при желании можно неплохо всё задокументировать и воплотить в жизнь, а вот организовать удачную коммуникацию зачастую оказывается гораздо сложнее. В результате и получается ситуация, когда HR фидбек не донёс, прожект менеджер не рассказал ситуацию, а высшая сила была занята и не в курсе. На выходе - конфликты, провалы, непредвиденные овертаймы и т.д.
Задача всё это правильно организовать лежит именно на менеджменте, и если количество конфликтов и всевозможно обиженных в компании достаточно велико, значит, тут уже не HR виноваты или программисты зарвались, а что-то у высшей силы не в порядке, где-то она не дорабатывает.
Я, кстати, не отрицаю, что за последние пару лет с в связи с дефицитом специалистов число не очень адекватно оценивающих свои знания, умения, а главное амбиции разработчиков значительно увеличилось, и иногда просто жалко проектов и коллег, которые вынуждены мучиться с такими недокодерами. Но, тем не менее, менеджмент, и в первую очередь топ, в данном случае не просто высшая власть, а также ещё и обслуживающий персонал, который должен организовать и работу девелоперов и сейлсов и HR. Не просто свести между собой заказчика и девелопера, и пускай дальше сами в своём коде разбираются, а организовать процесс.
Так что в конфликтах, текучке кадров и провале проектов виноваты не только разработчики, но и менеджмент тоже не в последнюю очередь.