Управление персоналом *

В апреле 2016 года Алекс Сент-Джон, один из разработчиков технологической платформы DirectX Microsoft, написал статью, в которой он защищал восьмидесятичасовую рабочую неделю, презрительно отзывался о балансировании работы и личной жизни, а фарфоровые унитазы назвал «невероятно декадентской роскошью». Статью Сент-Джона сильно критиковали за поддержку того, что многими считается эксплуатацией трудовой деятельности и отношений в индустрии видеоигр.

На волне критики всплыла написанная Сент-Джоном презентация PowerPoint, на одном из слайдов которой инженеры с синдромом Аспергера называются «священным Граалем» для нанимателей. «Они работают как механизмы», — написал он. «Не интересуются политикой, не ввязываются в отношения и никогда не меняют место работы».

Представляем наш ежемесячный отчёт о результативности «Моего круга». В феврале у нас было размещено 670 вакансий, на каждую за месяц в среднем откликнулось по 11 специалистов.

А теперь более подробно об откликах на вакансии в самых популярных сферах деятельности.

Наш блог мы начали с десерта, рассказав вам на той неделе о том, какими же красивыми, высокотехнологичными и крутыми бывают HR-инструменты. Но так уж случилось, что это блог про HR-технологии в России, так что новую статью мы посвящаем реалиям и ожиданиям от HR-tech в России и о том, как непросто этот рынок поворачивать.

Есть такое условное правило оценки эффективности труда и его оплаты. Первый год сотрудникам переплачивают, со второго по четвертый год — недоплачивают, с пятого года платят уже за стабильность системы — внутреннюю и внешнюю, результатом которых является в конечном итоге стабильная позиция компании на рынке. Чем больше от вас зависит стабильность процессов на фирме, тем надежнее ваше положение и финансовый доход.

Другое дело — когда фирма меняется по любым причинам, тогда гарантия сохранения места в системе не так прочна. Чего стоят стабилизирующие элементы в реформируемой структуре? Чуть больше, чем стоит труд способного новичка. А привычки у старожил уже барские, любой конфликт и терпение у работодателя кончится гораздо быстрее — издержки принятия решений об увольнении ниже. Но и снизить пафос своего поведения нельзя. В любой стае внезапно заробевший авторитет будет съеден. Вкратце вот и причина почему топ-менеджеры сопротивляются большинству изменений.

История женщин в американском бизнесе начинается давно, ещё в XVIII веке, когда Элизабет Лукас Пинкни начала выращивать и обрабатывать индигоферу красильную для производства красителя индиго. В 16 лет Пинкни уже управляла тремя плантациями, а к началу войны за независимость её продукция составляла треть всего экспорта из штата Южная Каролина. Гроб Пинкни в 1793 году нёс президент США Джордж Вашингтон. И даже несмотря на это консерватизм долгие годы не позволял смотреть на женщин-предпринимателей всерьёз.

Сегодня хотим рассказать, как мы отбираем и готовим для своих дата-центров дежурных инженеров. Эта позиция важна для нас по двум причинам:

• это наша первая линия технической поддержки. Дежурные следят за стеной мониторинга, общаются с клиентами, которые приходят в наши дата-центры, помогают устанавливать новое оборудование. Их четкая работа, доброжелательное отношение к клиентам, внимание к мелочам значат для нашего сервиса не меньше, чем работа инфраструктуры дата-центра: превысил время ответа на запрос, позволил пройти в дата-центр без бахил, просто не поздоровался – минус в нашу карму.
  
  
• это наша “кузница кадров”. Некоторые ребята потом вырастают до ведущих инженеров профильных технических групп и даже до руководителей отделов.

Но обо всем по порядку.

Привет! Это новый блог платформы для оптимизации рекрутмента potok. Вот уже около 3 лет мы следим за рынком HR-технологий в России. Мы не только следим, мы пытаемся его менять.

В этом году я уже в третий раз буду наставником на контуровской летней стажировке, но первый опыт проведения стажировки я получил в маленькой компании до Контура. Сейчас, спустя почти четыре года, я хочу поделиться этим опытом и провести некоторые параллели с тем, как проходит стажировка в большой компании. Надеюсь, прочитав этот текст, вы тоже решитесь на организацию стажировки. Буду рад, если мой опыт вам в этом поможет!

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

Во второй части расскажу о том, как всё получилось на самом деле, какие выводы мы сделали и чему научились. Здесь продолжение статьи.

Большинство организаций проходит этап Цифровой Трансформации. Она затрагивает многие срезы и департаменты в организации. Какие-то могут допустить ошибку, и ее цена будет невелика. Другим просто нельзя ошибиться и допустить потери продуктивности, знаний или репутации организации.

Разные организации находятся на разных стартовых позициях. От «у нас нет Интранета» до «у нас полноценный мобильный личный кабинет». Мы видели много таких разных отправных точек. В этой статье я хочу их перечислить. На самом деле, понимая свою отправную точку, вы можете видеть и обойти разложенные перед вами мины. Ниже приведены некоторые сценарии. Возможно увидите здесь что-то знакомое…

Дэвид Хэнссон, создатель Ruby on Rails, признался в своём твиттере, что не написал бы сортировку пузырьком на доске. Дэвид подсматривает код в интернете всё время:

Привет, Хабр. Меня зовут Владимир Разуваев, я руководитель департамента бизнес-консалтинга. Наша команда занимается тем, что помогает клиентам понимать значимость программных активов и управлять ими. В этом посте я предлагаю поговорить о внутренних разработках, которые в той или иной мере есть практически в любой компании.

Текст разделен на три части. В первой я расскажу о пяти важных шагах по формализации таких разработок. Эта формализация поможет не только закрепить за компанией права на эти разработки, но и сократить юридические риски, связанные с «перехватом» прав на ПО бывшими сотрудниками, а также экономические риски неправильного учёта ПО как актива. Из второй части станет понятно, какими правами на программный продукт, созданный для компании, обладают непосредственно программисты. И в третьей части я поясню, почему так важно правильно оформлять документы и с какими рисками может столкнуться компания-разработчик.

Считается, что в детстве формируется наша будущая специальность. Любители собирать головоломки должны попасть в ученые, программисты или шифровальщики, а тем, у кого есть способности к рисованию, прямой путь в дизайнеры или художники. Но мы почему-то делаем все возможное, чтобы «что-то пошло не так».

Сейчас я работаю программистом в Яндекс.Деньгах и занимаюсь интеграцией с транспортными решениями. Можно подумать, что я — джавист в пятом поколении, с вытянутым свитером и бородой до пояса. Но все еще интереснее, ведь карьера моя началась с журналистики.

Это реальная история, она — не только про Google. Я нередко получаю письма от рекрутёров Amazon, Facebook, а также небольших стартапов Кремниевой долины. Они как-то находят меня — наиболее вероятно через этот блог, через мои книги или через аккаунт на GitHub. Они всегда начинают с фразы: «Ваш профиль нас сильно впечатлил», — а заканчивают: «Давайте назначим собеседование». Я всегда отвечаю одинаково, а они всегда после этого исчезают, возвращаясь нередко через несколько месяцев под другим именем. Попробую здесь объяснить мои соображения. Возможно, вы будете делать то же, и мы сможем изменить ситуацию.


«Охотник на оленей» (1978), режиссёр Майкл Чимино

Сделано в соавторстве с Анной Перовой.

Ввиду того, что в бизнесе часто «один в поле не воин», а в ИТ-области для создания чего-либо значимого коллектив (команда) является тем самым инструментом и душой, которые создают продукт и позволяют продвинуть его в жить, каждый участник должен разделять ценности и стремиться к общему результату. Но эти слова — хотя и правда, но теория, доступная в интернете и из уст консультантов по развитию бизнеса. Здесь важный вопрос — "как". Как конкретно, имея ограниченные возможности быстро сформировать команду? Почему он важен? Да как минимум потому, что идеи склонны стареть и утекать к конкурентам, а без команды постоянные расходы идут, а продукта генерирующего доход нет.

Для решения указанного вопроса делимся простой и практичной схемой, которая работает при сборе команды «на заказ» и, с одной стороны, позволяет обеспечить достаточный поток кандидатов, а с другой стороны, отобрать среди них наиболее подходящих, затратив на это разумный объём финансовых и душевных сил.

В этой статье я поделюсь очень простым, «на троечку», способом ухода от рутины для владельца или руководителя любой компании, отработанным на практике. Чтобы, наконец, можно было пойти в тренажерный зал, слетать с любимым человеком в ОАЭ или поиграть в любимую компьютерную игру. Или чем вы там давно хотели заняться без страха потери бизнеса?

Чтобы успешно построить работу в команде (коллективе) и добиться высоких результатов, важно уметь продуктивно общаться с подчиненными и задавать правильные вопросы. Профессионализм заключается не только в нахождении нужного времени, места и момента для беседы с сотрудником, но и в получении и доведении нужной информации.

Если вы на пути к проведению регулярных индивидуальных встреч с сотрудником или уже практикуете их, но не знаете, о чем еще спросить, наша статья будет полезна! Ниже вы найдете список вопросов, ответы на которые помогут улучшить взаимодействие в командах, повысить лояльность к компании, узнать проблемы, волнующие ваших коллег. Эта подборка должна быть для вас не столько готовыми формулировками, сколько обозначением направления, опираясь на которые вы можете сформулировать более точные и подходящие вопросы, с учетом личностных особенностей собеседника, особенностей работы именно в вашей компании.

«В старом мире, мы тратили 30% нашего времени на создание хорошего сервиса и 70% времени на то, чтобы рассказать о нём. В современном мире всё наоборот» — Джефф Безос, CEO, Amazon

“Это самый ужасный сервис на свете! Верните мне мои деньги немедленно!” — каждый инженер техподдержки хотя бы раз, но слышал такое от пользователя. Да что и говорить, чаще всего высказываются самые недовольные: “Я 27 минут висел на телефоне", “Мою проблему не могут решить уже четвертый день!”. Те, кто никогда не работал в саппорте судят о качестве предоставляемого сервиса по своему личному опыту. А как о нем судим мы, те, кто отвечает на звонки и решает проблемы? Как определить, хороший ли сервис вы предоставляете своим пользователям?

С чего начинается любой проект по ИТ-инфраструктуре? Если вы подумали о чем-то вроде: админы собрались, обсудили и кто-то предложил решение, — то с высокой вероятностью попали в точку. Именно так обстоят дела с эксплуатацией в российских компаниях, и у нас до недавнего времени тоже.

В статье расскажу о том, как мы потратили 5 миллионов и почти полгода на то, чтобы убедиться: отличных специалистов и энтузиазма недостаточно для внедрения чего-либо масштабного.

От переводчика:

Оригинал данного текста был написан разработчиком программного обеспечения из Швейцарии Адрианом akosma Космачевским. Другой его текст «Каково это — быть разработчиком, когда тебе сорок» уже переводился для Хабра. В первую очередь, все написанное ниже обращено к рекрутерам «по найму» — рекрутинговым агенствам, предоставляющим услуги поиска работников другим компаниям. Но в целом, он применим и для обычных HR-департаментов в нашем регионе.

Приятного чтения.

---

Мой рабочий день всегда начинается с просмотра сайтов, чтобы быть в курсе последних бед и катастроф, от которых страдает наш мир, но сегодня одну из этих бед я обнаружил в своем ящике электронной почты. Это было очередное письмо от рекрутера.

Мне иногда кажется, что преследование со стороны рекрутеров всех мастей является неотъемлемой частью бытности разработчика программного обеспечения. Я получаю по три-четыре письма в неделю на свой e-mail, постоянно отвечаю на телефонные звонки и даже получаю почту (знаете, эти старые-добрые пакеты, конверты, с такими марками на них), с предложениями вакансий по всей Европе.

Мои навыки пользуются спросом и мне кажется, я должен радоваться этому. Но есть проблема, и состоит она в том, что 99% всех попыток контакта со мной со стороны рекрутеров были тем или иным образом провалены. За 19 лет работы разработчиком ПО у меня сложилось не самое хорошее представления обо всех этих «возможностях», призывах «индустрии» и связанными со всем этим методами.

Так что, дамы и господа (рекрутеры), чтя стандартный стиль ваших сообщений, пожалуйста, ознакомьтесь с моим Top Five List некорректных моделей коммуникации рекрутеров с разработчиками программного обеспечения.

Исследования удовлетворённости клиентов чрезвычайно распространены. Каждый раз, когда вы посещаете банк, отправляете запрос интернет-поставщику, отправляетесь в поездку или нанимаете фрилансера для какой-то задачи, вы затем с железной последовательностью получаете запросы по электронной почте с предложением оценить взаимодействие.

На первый взгляд, это хорошая идея. Учитывая практическую вездесущность интернета и электронной почты в сочетании с низкой стоимостью отправки этих писем, возможность понять суть дела «изнутри», которую ваша фирма может получить от клиентов, — что может не нравиться в этой практике?

Обратная связь «магазин/наём -> оценка -> вознаграждение» стала просто неотъемлемой частью некоторых систем. Многие интерактивные торговые площадки включают эти операции обратной связи в рейтинги, которые затем становятся оценкой, влияющей на перспективы оцениваемой персоны.

И вот здесь-то и начинаются проблемы.

Имеется точка, где этот подход перестаёт быть полезным и прямые эффекты системы оценки, основанной на результатах обратной связи, становятся контрпродуктивными. Такой точкой является ситуация, когда рейтинг становится целью.