Рубрика «управление персоналом» - 26

image

В 1998 г. мало кому известный стартап под названием Netflix, только что запустивший собственный сайт, платил своим сотрудникам значительно меньше рынка: в фирму семейного типа шли не за большими и быстрыми деньгами.

Сегодня всё иначе. Netflix — крупнейшая международная IT-компания и крайне щедрый работодатель с необычной, даже по меркам Кремниевой долины, системой оплаты труда. В 2018 году стриминговый сервис стал самым популярным местом работы среди соискателей, опредив Google и Apple.

Мотивационные схемы — часть и продолжение корпоративной культуры Netflix. За прошедшие десятилетия она серьёзно эволюционировала и к 2010-ым окончательно выкристаллизовалась в стройную систему. Сначала — в виде опубликованного в Сети “Корпоративного справочника Netflix” из 127 слайдов, затем — как манифест Netflix Culture, а недавно — как книга с громким названием “Никаких правил” (No Rules Rules).

В этой статье мы рассказали самую интересную часть из этой книги: как именно устроена система мотивации в Netflix и что нужно делать компании, чтобы рок-звезды в ней выкладывались по полной?

И почему отказ от премий сотрудникам стал фактором роста компании?
Читать полностью »

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

Позвали Григория Петрова, DevRel’а Evrone.com (ex. Voximplant, Radmin, Digital October Center) и вдохновителя сообщества Moscow Python, рассказать, как писать хороший код самому и научить команду. А еще обсудили, как понять, какие механизмы нас тормозят, и как посмотреть на нейрофизиологию через призму прикладной разработки и руководства технической командой. Разговор оказался настолько интересным, что сделали статью по его следам.

Наш гость сам себя называет генералистом. Пишет на большинстве мейнстримовых языков разработки, кроме Haskell, и интересуется нейрофизиологией. В какой-то момент он посмотрел на свой предыдущий опыт работы и понял, что ему нравится писать документацию, объяснять сложные вещи простым языком и общаться с разработчиками, но не руководить. Поэтому позиция DevRel (Developer Relations) оказалась для него оптимальной.

Почему бухгалтеров мы можем обучать, а программистов — нет - 1
Читать полностью »

Ежедневные сложности сениор-разработчика - 1

Больше десятка лет я работал на одну из крупнейших в мире компаний по разработке ПО. Выполняя множество задач, я видел многие аспекты бизнеса: от быстрого «ковбойского» кодинга до серьёзных покупок конкурентов и стартапов.

1. Планёрки

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

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

Однако митинги и сосредоточенность — настоящие враги. Я уже сбился со счёту, сколько раз мой планировщик отвлекал меня, сообщая, что через 15 минут мне нужно явиться на планёрку, пока я пытался разобраться в сложной концепции, которую недавно придумал. Разумеется, я заранее знал, что будет планёрка. Когда я смотрел своё расписание в понедельник, чтобы оценить время, которое у меня будет на написание кода на этой неделе, у меня не было никаких сомнений: мои рабочие дни заполнены совещаниями.

Чем дольше ты работаешь, и чем лучше вы с коллегами справляетесь, тем больше знаний вы получаете. Ценных знаний. Или опыта, как их называют некоторые.

И знаете что? Эти знания в основном передаются на совещаниях. Поймите меня правильно, само по себе это хорошо.

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

Настала пора ещё одного совещания.Читать полностью »

image

Мы на Хабр Карьере решили поднять одну важную тему — найм людей с инвалидностью в ИТ. Несправедливо считается, что у таких сотрудников низкая эффективность, что они плохо мотивированы и с трудом встраиваются в команду. Чтобы понять, как с этим обстоят дела в российском ИТ (есть ощущение, что не очень), хотим пообщаться с компаниями и специалистами.

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

Почти наверняка вам кажется, что реклама или пропаганда действуют на кого угодно, но точно не на вас. Вы всегда действуете рационально и не подвержены подобному влиянию. Но, скорее всего, это не так. Люди подвержены когнитивным искажениям. И это нормально.

Если вы спросите у любого эйчара, уделяет ли он внимание фотке и внешности кандидата, 10 из 10 скажут: «Конечно же нет, мы смотрим только на опыт!» Ну, ещё на софт-скиллы и вот это всё. Ведь смотреть на внешность и оценивать человека по этому критерию — это шаг к дискриминации. Но даже если эйчар (или прямой наниматель) хочет быть предельно беспристрастен, то бессознательно он всё равно воспринимает и учитывает свои ощущения от фото. Даже если не говорит вам об этом. Даже если не говорит об этом самому себе.

Как фотка в портфолио влияет на получение работы и заказов. Обзор исследований - 1

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

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

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

  • Обучение и онбординг новичков.
  • Шеринг кода/процессов и обмен опытом.
  • Пара решает проблему быстрее и реже обращаются за помощью.
  • Повышение производительности.
  • Сплочение коллектива.
  • Увеличение скорости ревью.

Последний пункт стоит пояснить отдельно. Так как при работе в паре процесс ревью, фактически, проходит в фоновом режиме, то и часть ошибок отсеивается еще на этапе написания кода. Благодаря этому итераций на ревью становится значительно меньше. Тут хорошо подходит вот эта картинка:
Как начать программировать в парах - 1

Но давайте начнем с грустного и поговорим о том, что может помешать начать внедрять парное программирование в своей команде.
Читать полностью »

TL;DR сочиняйте статью на Хабр.

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

Текст составлен при участии юриста Санкт-Петербургской коллегии адвокатов.

Читать полностью »

Собеседование инженера программиста сегодня часто включает в себя некий тест или упражнение на программирование, и я думаю, что это очень плохая вещь. Вот почему.

Почему вы никогда не должны соглашаться на собеседования с программированием - 1


Читать полностью »

Олды в ИТ - 1

Читать полностью »

Маленькие задачи, а доверия ещё меньше - 1

Почему делегирование обязанностей лучше, чем распределение задач

Доверие — высочайшая форма мотивации. Оно выявляет в людях самое лучшее.

Стивен Р. Кови, «Семь навыков высокоэффективных людей»

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

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

«Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M».

Самое важное здесь то, что A и B были крупными задачами, например, целыми продуктами или большими системными библиотеками. На их создание и поддержку уходило всё твоё время. Они были делегированной ответственностью, а не просто задачами. Было просто при этом и управлять людьми. Если ты не справляешься, то начальник тебе об этом скажет.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js