679
Простые мысли простого человека
На работе спросили есть ли у меня Roadmap для собственного развития.
Конечно есть!
На мой взгляд показывают не совсем глубокое понимание того, что такое "мотивируют профессиональный рост". Конференция - это развлекуха, нетворкинг и просто пощекотать нейрончики, сбросить пар и пивка на афтерпати попить, это не про профессиональный рост.
Попробовать новую технологию - это искусственная попытка удержать, при этом тонкая грань - кто потом будет эти 'новые технологии' поддерживать? А если не зайдет новая технология - человек может еще больше подумать, что 'фу болото', может в следующий раз снова быстро заскучать и потребовать еще новую технологию (сколько я встречал на работах непонятных сервисов, написанных на стеке, который никто не понимает, потому что автор таки ушел, а наследие как-то работает и заносится в техдолг, чтоб на основной стек переписать).
И все эти искусственные попытки удержания - они заканчиваются почти всегда одним - сотрудник все равно уходит, оставив гору кое-как работающего софта.
Исходить надо (на мой взгляд) не от 'попробуй новый твикс технологию' а от того, что может сотруднику надо прямо целину дать в предметной области, с вот этими целями - чтоб вот вырост был в сторону техлида, где ты именно за процесс весь отвечаешь разработки. А вот эти новая или старая технология - это вторично, но пусть расскажет/подумает, как будет это именно поддерживать/тестировать/деплоить и какие плюсы будут для задачи-целины .
Ну и последнее: Лайфхаки 1-1
Имхо, формальный 1-1 это такое себе, с одной стороны эдакая встреча честности, с другой стороны которая повторяется раз в неделю.
На мой взгляд это должно быть более точечной встречей, при этом лучше прививать даже культуру (хотя это сложно), чтобы инициация была в том числе и со стороны разработчика о встрече.
Отнесение же "Помогайте решать рабочие проблемы, о которых услышали при общении и подсвечивайте ход решения этих проблем" в лайфхаки - это что-то формата "Делайте свою работу, с вас 5000р за консультацию, не благодарите".
Имхо, самое главное, что не учтено во всех этих лайфхаках 1-1 - это то, что встреча на двоих, а написано только про одного. Вы сами человеку покажите искренность и открытость, прежде чем от него это ждать. Сами поделитесь с ним проблемой, спросите совета, расскажите новости, подсветите сложные места, которые вы видите - неформально, а там уже глядишь и доверие выстроится, без "смотреть в глаза через камеру сквозь ноутбук на 1-1".
В общем, мысли какие-то такие всплыли, когда прочитал это. Ну а вы что думаете, товарищи, по этому поводу?
Слушаю такие старые песни, что даже Яндекс.Музыка откатилась на прошлую версию.
Читать полностью…
Еще чем хотел поделиться: пришел как-то я на проект и мне тоже все как в один голос говорили: «у нас стартап-стартап». Проекту уже год.
И я понимаю, что да, не так уж и много, но и не так уж и мало, с другой стороны?
Вообще, это слово «у нас стартап» - звучит будто бы в салках, когда до тебя добегают, а ты во что бы то ни было орешь «Я НЕ ИГРАЮ».
То же и тут: стартап это как стоп-слово для всего. Не умеют в ответственностью и нет документации - у нас стартап. Нет онбординга - у нас стартап. Нет %чтотугодно% - у нас стартап.
Кажется, что спроси где туалет у вас, ответят: какой туалет? У нас стартап.
Понятно, что есть период турбулентности, но как и ко всему - человек привыкает, так и тут: к плохому и не выстроенному человек привыкает, апеллируя тем, что у нас стартап.
Дошло до того, что когда я попросил девопсов подежурить, они всерьез начали думать как будут дежурить в выходные бесплатно. Это был такой шок, что я до сих пор не могу себя успокоить.
И первое что я всем пытался донести: что хватит, у нас уже не стартап. Ну а девопсам запретил даже думать о таком, либо механизм компенсаций за такие дежурства - либо только в рабочее время.
Здесь все как в жизни: почувствуй момент, когда ты уже не малыш и перестань вести себя также. Капризы когда ты ребенок - ок, а когда ты детина - уже выглядит неприятно.
Хоть этот момент сложно прочувствовать - но надо. Как минимум задаваться вопросом (из фильма «семь»): ух ты, а не псих ли я?
Наткнулся на две статьи: раз и два.
Что забавного в них:
1) Вторая статья - это перевод, при этом есть ссылка на оригинал, где (по старой доброй традиции) выясняется, что статья имеет еще и приписку (которую почему-то не стали в перевод включать): 28 year olds can be senior, words have no meaning
2) Возраст паренька с первой статьи вообще 22 года
Но обе они, хоть и написаны разными людьми, а также несмотря на то, что вторая явно имеет некоторый 'набросовый' формат, затрагивают важную тему: грейдов и оценки в ИТ.
Мы тут с вами прожженные пироги, поэтому давно уже не смотрим на эти лычки 'сеньор' или 'помидор', мы смотрим на опыт, стек и задачи, которые делал человек.
Но эти вот лычки - это во-первых, элемент сдерживания в зарплате иногда (потому что вот зарплату повысим на 10т, зато будешь АРХИТЕКТОРОМ), а во-вторых увеличивают хаос в ИТ еще больше.
Сейчас ИТ в целом такая область, где реально за 5 лет стать, что называется from zero to hero даже с перерывами на обед. При этом, будем честны, за 5 лет с нуля не стать по настоящему сеньорским сеньором (мы говорим про среднее по больнице - понятно, что есть уникумы, типа гениев (ГЕНА ТЫ ЗДЕСЬ?), как например, паренек с мейла - который там ботов клепал в 16 лет, а уже в 19 в мыле закрывал там какие-то позиции в соло). Но таких - реально единицы, мы же не такие - мы нормальные (хотя где нормальность-то - она только в БД и то не во всех).
И вот недавно же был на работе моей пример, что пришел паренек тоже сеньор, чисто как по второй статье -странная выдуманная архитектура, опасные решения и полное непонимание проблем в будущем, а работет это все гигообраие потому что там 5 rps на ДЦ. Тоже сеньор.
Так вот, к чему это я? А пишу это все я к тому, что подобное системное раздувание, эдакий сбой, порождает пока что легкое противодействие, которое выливается в полнейшем недоверии к кандидатам. А со стороны кандидатов - некоторое выгорание и тупик, ибо вот вы в свои 20 лет достигли по сути лычки сеньор, а дальше куда? Это на самом деле будет задевать ваш мозг, путь непонятен, кто бы подсказал - куда дальше!
Ну а Бизнес - это огромный маховик, который постепенно начинает идти уже в другую сторону. И силы, что ведут его туда - они в том числе и такие, что, грубо говоря, ситуация в которой за 5 лет мы приходим к вершине в карьере и зарплата вырастает в N раз - это нездоровая тема. Просто потому что - ну слишком быстро, особенно за такие деньги. Когда Бизнес окончательно сформулирует эту мысль себе, начнутся меры противодействия реальные и неприятные для разработчиков.
Вы можете сказать, что это все из-за EPAM, там бодишоп (недаром автор первой статьи из фитнеса кекв), но старина David Tate из второй статьи мой контраргумент.
P.S. Тем не менее поздравляю автора первой статьи с повышением, его совет хорош для всех:
"Мой совет — просто нарабатывай скилл и не теряй веру в себя."
Ну и накидали ему там минусов за воротник почему я не понял.
FYI
Забавная тема опять всплыла в комментариях, ровно то же, что я обсуждал со своими студентами:
"22 года, нет опыта работы, не могу работать фулл тайм, только парт тайм, закончил топовый вуз бакалавриат по ИТ, сейчас в ИТМО в маге, компаниям нужно только фулл тайм"
My sweet summer child, конечно всем нужен фулл тайм, кто ж будет бегать за тобой и дополнительно дедлайны/сроки примерять на твои сессии.
Старина, ты либо потерпи чуть-чуть, доучись и все пойдет (а с ИТМО пойдет, я уверен), либо воткни вилку (в глаз найму) поменьше денежно, чтоб тоже какие-то плюсы дать бизнесу - маленькие зарплаты программистам возбуждают многих менеджеров побольше женщин (или мужчин, смотря какой у вас менеджер).
Сегодня, кстати, понял то самое требование 'уверенное владение Java Core'.
Пришлось по работе с сервака на винде (как обычно сверх защищенного, бункер, черви, слой свинца) сделать пару запросов по http. Все лагает, ну как обычно мы любим.
Так вот нужно было простенький запрос отправить с него, ну я взял и по памяти накидал в блокноте джава код с http url connection (благо там она была поставлена) и думаю вот я шарю! Недаром преподавал в ВУЗ-е, просто по наитию могу в блокноте даже написать!
Решил я значит javaс запустить, а оказалось его и нет - там только JRE! А я только версию Java и проверял.
Пришлось разбираться в powershell этом и ругаться на всех, весь мир и посылать лучи поноса тем, кто это делал (наверняка они уже умерли от обезвоживания)
Но настроение себе этим кодингом в блокноте поднял!
Мораль: Учите Java, чтобы чувствовать себя хорошо даже с блокнотом в бункере!
Прочитал тут статью на Хабре.
Итак, человек пишет:
Меня всегда тянуло к обучению людей и шарингу знаний. Когда я был разработчиком, то охотно становился ментором у стажеров. И даже сейчас, работая тимлидом, я являюсь пипл‑менеджером уже у senior‑разработчиков. Но у меня никогда не было опыта работы преподавателем или наставником сразу для большой аудитории. Мне всегда казалось это чем‑то интересным и вдохновляющим. Но мои ожидания не оправдались, как вы уже поняли из названия статьи.
Заметили, кстати, что последнее на одного разработчика приходится как минимум по одному, а то и два начальника? Я как-то считал, что у нас ровно два руководителя в среднем на программиста получалось (в одной большой компании)
Как вам тенденция?
Что может спасти в такой ситуации?
На мой взгляд: система выращивания кадров (умение), умение развивать сотрудников (привет, кстати преподаванию). И хорошая документация по проекту/разработке.
План прост и надежен как швейцарские часы, мы ищем крепкого (проактивного) джуна, берем его под определенные задачи и учим на них, выращивая себе того самого мидла-сеньора, которого никак не могли нанять.
Нанять джуна можно, просит он немного (по сравнению с зарплатами тех, у кого несколько лет опыта уже), а некоторые из них готовы впахивать так, что мама не горюй (особенно сейчас).
Найм джуна писихологически убирает этот затык с "боязнью ошибиться", джун на то и джун, что от него пока рано требовать "быть как я". Да и денег мало получает (тоже не как мы тут все)
Растут джуны при должной работе с ними очень даже быстро.
Собеседования с ними можно подстраивать под команду, например, просить решить тестовое задание (хоть я и не люблю этого), потому что там, где сеньор развернется и у виска покрутит, джун вполне себе сядет и решит.
Тут разумеется, все зависит от проекта и области, понятно, что многие задачи не решаются такими способами. Но и у нас там был не Rocket Computer Science!
Важно понять, что сейчас, нанимая сотрудника мы нагружаем разработку и того самого ментора (которого выделить надо на парт тайм даже может на эту задачу). Однако, в достаточно близкой перспективе, мы закрываем ту самую потребность от которой страдали и никак не могли решить.
В идеале, должен быть выделен некий трек задач под джуна и ментор, при этом выделять (имхо) лучше даже тогда, когда вы еще не отчаялись нанять другого. И брать сразу двух (деда понесло), чтобы и друг друга менторили/кросс ревью/обсуждали там и прочее.
Какие выводы?
Как оказалось, вы не поверите!, но требования к тому, чтобы в проекте велась хорошая документация и культура ее поддержания - очень важна. Вход в задачи более прост, а каждый кто входит может еще и улучшить доки.
При этом как кодовой базы, так и вики.
Найм крепкого джуна может окупиться, если у вас есть сотрудники, умеющие с ними работать. Либо у вас есть план и вы его придерживаетесь.
И уже через эти 6-8 месяцев вы действительно сможете почувствовать разницу, получив неплохого сотрудника. Он не закроет все ваши проблемы, но начнет решать, а если вы продавите еще один найм такого - уже постепенно будет наращивание даже мышечной массы команды (второй пройдет по стопам первого более просто, сможете отдебажить проблемы, первый поможет второму и на выходе у вас уже даже пара неплохих сотрудников будет).
В общем, иногда стоит пересмотреть требования к кандидатам, посмотреть обходные пути и продумать их. Это может оказаться действительно работающей схемой, нежели упираться в найм именно вон того двухметрового метросексуала, который к вам никак не идет.
У меня подобная схема сработала дважды.
Суть: нанять крутого разработчика - это мучительно тяжело, многие даже подписной бонус или бонус за рекомендации готовы давать.
Продуманная работа с джунами может решить этот вопрос (но тоже через боль - но решить!). И тут как раз вам поможет в том числе умение/опыт/навык в преподавании. Еще один плюсик!
В общем, я довольно сумбурно вылил мыслительный процесс сюда свой, но мысль вы поняли. Решил поделиться мыслью, которая вдруг ударила в голову и я из-за этого упал на диван и взял ноутбук в руки.
Выбери жизнь. Выбери работу. Выбери карьеру. Выбери семью. Выбери телевизор с большим экраном. Выбери стиральную машину, музыкальный центр, автомобиль и электрический консервный нож. Выбери друзей. Выбери курорты и шикарные чемоданы. Выбери костюм-тройку в самой лучшей фирме из самой дорогой материи. В свой выходной выбери диван, чтобы развалиться и смотреть отупляющее шоу. Набивай брюхо всякой всячиной. Выбери загнивание, в конце концов, и со стыдом вспомни как писал на питоне. Выбери своё будущее. Выбери жизнь.
Но зачем мне всё это? Я не стал выбирать жизнь, я выбрал кое-что другое. Почему? Да ни почему. Какие могут быть «почему», когда есть Java?
Привет! На этой неделе выпуск!
В четверг, 05.10, в 18-00 по Мск будем продолжать говорить про МФТИ и ФПМИ. В гостях в этот раз заместитель директора ФПМИ по учебной работе Александр Ширяев!
Обсудим, почему учебные программы на ФПМИ выглядят именно так (в этот раз с точки зрения составителей), как дирекция ФПМИ помогает студентам справляться с нагрузкой и зададим все оставшиеся у нас вопросы. Помогать нам будет наш постоянный слушатель и гость прошлого выпуска, @ihateacm.
Подключайтесь, будет интересно: https://youtu.be/4Tyiyo2woyE
Проснитесь, посмотрите на часы и день недели. Увидите, что сегодня только вторник.
Результат:
Ты почувствуешь боль.
Как выглядит типичный отзыв кандидата на вакансию тимлида.
Читать полностью…
Очередной внеочередной поток мыслей на тему статьи (скорее заголовка, что попалась мне на глаза)
Скипаем очевидные и уже всем надоевшие SMART, как ставить задачи - там все как обычно, из каждого утюга кокосового интернета это льется патокой так, что клавиатура липкая и клавиши заедают.
Посмотрим именно на то, что меня зацепило и начнем с темы: Фидбэк
Цитата:
> «Спасибо за разработку бота. Я думаю, что тебе, как человеку, который регулярно выполняет роль релиз-менеджера, самому будет удобнее, когда значительная часть рутиной работы будет выполняться автоматически. И не только тебе - я помню немало просьб автоматизировать эти действия. Это нововведение важно и для бизнеса, потому что это экономит часы релиз-менеджеров, а это дорогое время на фоне других специалистов. Также отмечу, что решение такой задачи такой сложности подходит под требование следующего грейда, так что ещё 1-2 примера задач такой сложности - и на следующем ревью мы сможем обсуждать повышение»
Вообще, удивительно, но все эти ребята всегда забывают старое-доброе правило: хвали публично, ругай лично
Звать куда-то человека (по сути - дергать из рабочего процесса, чтобы вдруг неожиданно похвалить - это очень странно, а для некоторых может быть и стресс.
Да и (будем честны) похвала от вашего менеджера где-то в подсобке на 1-1 сразу после выполнения задачи - это даже звучит подозрительно и странно.
Хвали при всех, скажи, что Саша Кучук - красава, сделал и поднял эту автоматизацию, попроси прийти может кого-то от этого бизнеса (или кто там у них страдал - релиз менеджер?) и тоже поблагодарить, всякие ретро встречи, презентации работы разработки - они же по сути для этого и введены.
Вот эти забросы про 1-2 примера задач такой сложности и поднимем ЗП - вообще звучит как манипуляция, такой реверанс с морковкой. Такие моменты, на мой взгляд, вообще не очень красиво выглядят. Еще вот чуть-чуть и будет повышение! Вон оно, счастье уже совсееем рядом.
Это ладно, если бы человек САМ взял бы , определил, сформулировал, показал выгоду бизнесу и сделал это, но это же ты ему задачу дал, если ты говоришь такие слова - так может сразу все карты раскроешь, старина, и роадмап до повышения сделаешь мне? Раз еще 1-2 задачи такого уровня - эти задачи с нами в одной комнате? Может они будут мне поставлены сейчас?
Следующий пункт: Выявление мотивации и работа с ней
Автор говорит , что сущуствует несколько разных классификаций мотивации, среди которых выделяет в том числе и: Безопасность: быть уверенным, что вовремя придет зарплата, члеовек не попадет под сокращения, компания не закроется и так далее;
Я бы, честно сказать, к прямо мотивации это бы не отнес, это скорее выбор места труда и риски, сложно себе представить мотивацию формата: "зато зарплата приходит во время".
Слова же из разряда:
"Например, в случае, если человека мотивирует профессиональный рост, можно сказать, что задача - отличный повод попробовать новую технологию. Компания может ему помочь, оплатив курсы по новой технологии, или отправить его на конференцию."
Сейчас в самолете слева от меня проснулся пьяный мужик и поинтересовался: нет ли у меня коммерческой недвижимости?
Я сказал есть, вот только закатилась под сиденье, по прилету достану.
Этот ответ его полностью удовлетворил и он спокойно уснул дальше.
Наблюдаю уже неделю-другую как на работе по одному из проектов всплывают все новые и новые баги, при этом прямо в продакшене.
Отличительной чертой всего этого является то, что практически все участники процесса до конца не понимают что нужно и как должно работать на самом деле. Отсюда почти все баги на этой неделе - катим один фикс/заводим задачу и появляется другой, потому что опять костыль/опять не до конца поняли что надо, это как карточный домик валится.
А мысль простая:
Нет проблем с этими всеми практиками, тестами, TDD, DDD, D&D (где менеджер - это мастер, а ты его fu*ckin slave), функциональные и прочие парадигмы - это все ок.
Есть проблемы с самым главным: понимания что мы делаем, зачем и почему это надо делать.
Большинство проектов, которые я вижу (сейчас вокруг) - это проекты либо еще, либо бывшие прототипами, сделанными как завещал нам Олег Тиньков "мне пох я так чувствую".
При этом "я" здесь обычно именно почти в единственном числе: скорее всего это или лид, или менеджер.
Выращенные в такой парадигме проекты обречены на множество проблем и багов, просто потому что:
a) Погружать других просто нет времени и желания - ведь новые задачи уже горят, текучка кадров и так далее
б) Как погружать тоже непонятно - а чтобы понять, надо остановиться и подумать, а на это нет времени
в) Нет понимания что дальше (и оно заканчивается постепенно даже у тех, кто понимал)
Осложняется еще эта ситуация тем, что большинство разработчиков не пользуются тем, что делают вообще. Т.е. они смотрят только со стороны разработки на вещи, для них что там у белых господ там - темный лес.
Этим занимаются СПЕЦИАЛЬНО ОБУЧЕННЫЕ ЛЮДИ, хотя на самом деле (как показывает практика) не всегда они и обученные, часто они сами подходят к продукту не как пользователь, а как по практикам каким-то (которые в целом могут вообще не подходить к нам).
При этом еще и СПЕЦИАЛЬНО ОБУЧЕННЫЕ ЛЮДИ сами могут не очень хорошо доносить обратную связь, формулировать мысли.
Вот и получаем, что у нас как проект вышел из прототипа так все время и остается им: вектор развития хаотический, бросает нас из стороны в сторону, мы меняем дизайны, пилим непонятные никому фичи (на которые даже жалуются сами пользователи). Пример не заставит себя ждать: посмотрите вот как шатает некоторые сервисы Яндекса, где то НЕОЖИДАННАЯ смена дизайна, или Алиса начинает вам рекламу врубать, а уж в сервисах по меньше там вообще раздрай.
Отсюда (на мой взгляд) очень важно, чтобы ваши разработчики/аналитики/тестировщики и вообще вся разработка пользовались тем, что делают (по возможности). Видели обратную связь, иногда даже может даже на поддержку отправлять (на вторую/третью/ первую линии). Звучит как бред - что разработчика (или даже тимлида) отправляют пройти путь пользователя, но вот поди ты - не всегда. Ну а у нас, как можно понять, все это не так. Пока не так.
Есть даже термин такой KYC - Know Your Customer. В банковской сфере считается, что такая практика препятствует отмыванию денег, финансированию терроризма и уклонению от уплаты налогов. Все также и у нас, только отмывание денег - это просто растрата на фичи ради фичи, финансирование терроризма - это раздувание менеджерского звена и некомпетенций,а уплата от налогов - это то, что таким разработчикам можно платить сэкономленные деньги!
9 сентября 1947 года Грейс Хоппер, которая работала в Гарвардском университете с вычислительной машиной Harvard Mark ||. Проследив возникшую ошибку в работе программы до электромеханического реле машины, она нашла между замкнувшими контактами сгоревшего мотылька.
Отсюда, как считается некоторыми, и пошло название для программных ошибок - баг.
Так вот, представьте как бы изменился мир, если бы там обнаружили бабочку! Мы бы с вами в программировании ловили бы бабочек, а не вот это все.
Когда решил зайти к джуну и спросить как там задача, которую он обещал сделать два дня назад.
Каждый раз, когда работаешь с начинающим или не очень опытным разработчиком - одно и то же. Оценки, будто бы ты его семью в заложниках держишь и если он вот НЕ ПОТОРОПИТСЯ, то будет искать новую.
Доходит до смешного: людям иногда говоришь: аккуратно, здесь долго, интеграция будет - все равно, человек берет и чуть ли не пару дней назначает.
Это наверное одно из самых броских отличий мидла крепкого от джуна: там где мидл скажет 'тэкс, надо тут покурить, доку поделать, тестики - ну это работа для ведьмака на недельку крепкого кода только по задаче', то джуниор скажет ' пара дней, но можно за один без обеда если'.
Но самое ужасное не в этом, а в том, что как раз менеджеры (наши касатики, мы!) зачастую так и соглашаются: ну день так день! Отлично!
Отсюда идут часто и переработки и прочее.
Вывод: оцениваете как видите, добавьте денек на непредвиденные вещи, не надо торопиться, ваша семья в безопасности, менеджер не доберется туда. Нужно время на оценку - так и скажите, не держите в себе.
Коллеги ждут на ретро, чтобы донести негативную обратную связь
Читать полностью…
На самом деле последнее, что сделал верного - это уволился с прошлой работы. На текущей проблем тоже хватает, но хотя бы не настолько скучно. Вообще, когда скучно - хуже всего, с ума сходишь. Лучше даже переработать где-то, но с интересом. А так, мир ИТ (по крайней мере на который я смотрю) все тот же - наеб, что одних, что с другой стороны, никакой ответственности, непрофессионализм и , даже как бы ни было смешно, старание. Как говорится, прости господи, что мы творим, ибо не ведаем мы.
Что заметил: поднимаясь выше (не важно в какой компании) реально становится хуже видно то, что происходит внизу. Грубо говоря уже по другому видишь разработку. Отсюда вдвойне хуже, когда снизу не могут пожаловаться на проблемы (а вы удивитесь насколько люди(по крайней мере в рф ит) не любят выносить проблемы наверх).
Второй пункт: какие есть интересные люди, оказывается, и какие забитые. Гении в теле человека!
Выводы: вы не бойтесь своему тимлиду или кто там у вас рассказать что не так на проекте, не бойтесь даже напрямую пойти выше, иногда. Но помните, что это как ульт в доте- кулдаун большой.
Второй вывод:ищите интересных людей вокруг, коллектив реально либо тащит вверх, либо тянет вниз, но после какого-то момента будьте готовы, что вы сами уже - тот самый тащер, аминь!
Когда зашел к HR спросить каких кандидатов можно ждать на техническом собеседовании.
Читать полностью…
Проблемы найма
На проекте не хватает рук, есть некий костяк (в проектах, о которых пойдет речь, этот костяк составляет 2-3 человека) и задач становится больше. Разумеется выливается это в то, что стартует найм. При описании портрета кого хотим нанять, все, разумеется, ждут сильного сотрудника, описывается серьезный двухметровый метросексуал с 0% подкожного жира.
Наблюдение номер 0:
Обычно, когда кто-то стартует найм сильного сотрудника - это ситуация, когда он нужен уже вчера (в крайнем случае - позавчера).
Т.е. мы уже опзадываем/отстаем. Очень редко, когда найм стартует во время. Виной тут я вижу то, что менеджмент и разработка бояться ошибиться - найм уверенно можно просить, когда ты уже перед пропастью проблем - их легче обосновать. Заранее редко кто думает/видит риски/готов рискнуть на найм и продавить его.
И вот мы сталкиваемся с проблемой: портрет есть, а сотрудника нет. Время идет, проблемы проекта увеличиваются, а найм только-только раскочегариватеся (ну мы же тут в этом чате взрослые - машина найма - это что твоя девятка под окном, вросшая в асфальт, пока ты ее заведешь - уже и в графе "год" будет другое число).
Ну так вот, мы (кто мы, кто мы, я один здесь) никак не можем найти кандидата, который нас устраивает.
На одном проекте мы искали и готовы были платить плюс-минус по рынку, но те кто шел ну никак не устраивал по техническим навыкам за желаемую зарплату, а кто-то сверх сильный не шел никак.
На другом месте мы и платить не готовы были по рынку, зарплатные возможности компании не поспевали за рынком.
Грубо говоря, мы выкладывали чемодан денег, но рынок уже перешел на L или XL размер чемоданов.
Наблюдение номер 1:
Найм сотрудника в таких организациях - это тяжело и сопряжено с большими рисками. Почему? Потому что раз мы не готовы платить по рынку, либо так долго не можем найти кандидата, то цена ошибки велика. Наймем перегретого сотрудника - заропщут другие, что почему вот Вася сеньор, а я мидл, хотя Вася по всем параметрам хуже (даже ростом). Вот как раз недавно, кстати, разговаривал про такой случай с приятелем из О(зон).
Понятно, что тех и этих собесом можно такие вещи минимизировать, но не исключить. Отсюда найм с опаской, уже начинают люди перестраховываться (задавая совсем уж вопросы из разряда "а если слон да на кита налезет - кто победит?"), в общем ситуация тяжелая. В таких ситуациях уже сам навык вести собеседования рушится. Ну и все сетуют на перегретый рынок, что дескать ну куда с такими знаниями свои чемоданы требовать? Типа вот я получаю X, а он хочет X-30, а я то получше! Куда лезет?
Почему все хотят сильного сотрудника понятно, обычно это для всех менеджеров (с которыми я работал по крайней мере) звучит как решение проблемы разработки, при чем - моментальное. В моей практике все кивают головами, когда говоришь о том, что минимум 3-6 месяцев будет погружение в проект, все делают вид, что это понимают, но на деле нет и уже через месяц-полтора кэш менеджера сбрасывается и он спрашивает, а что, а где, мы же наняли вон того громилу джейсонов?
При этом, без найма тоже нельзя, мы же его не от хорошей жизни то открыли? А дальше задач еще больше.
Дрова в этот огонь счастья подкидывает еще и тот факт, что многие с опытом 3-4-5 года, как показывает практика, не сильно то и подходят под определение этого самого сильного сотрудника. А просят много (для нас).
Плюс я не понаслышке знаю/видел/сталкивался с сеньорами-волками с их волчистостью (привет, твиттер) - что тоже не добавляет оптимизма.
И давайте еще раз тезисно (чтоб не все гнилые помидоры долетели до меня):
- Найм крепкого сотрудника для нас крайне тяжел по разным причинам
- Задачи на всех проектах не были уровня CS, мы решали обычные рутиные вещи из разряда гномов CRUD-окрадов
- Искали долго, найм 'того самого' уже превратился для собеседующих в некоторую ситуацию, где настолько боятся ошибится, что начинают жестить
- Поменять собеседующих не можем
Что хотели?
- Опытного сотрудника, который снизит нагрузку на команду разработки
Решил попробовать метод утёнка (англ. Rubber duck debugging) — психологический метод решения задачи за счёт делегирования её мысленному помощнику.
Мой утенок через пару дней:
Мужчина обещал - мужчина сделал.
Как я и говорил 23 сентября (с тех пор немного засосало и я отвлекся, но не забыл), пора перейти к плюсам преподавания и тем самым поставить в моем опусе точку.
Причина 1 Уча других - учишься сам
Как говорилось в какой-то пословице/поговорке умной настолько, что я не запомнил кто это говорил: Изучил что-то — пробуй это объяснить, пока не поймёшь сам.
И это действительно так. Когда я приходил в преподавание Java - я думал, что ну плюс-минус эти темы из курса я-то знаю, я же и собеседования проходил уже на Java разработчика!
Но как показала практика, студент всегда спросит такое "Почему так сделано?", что поставит тебя в тупик и заставит подумать с разных сторон о теме.
Студенты заставят вас изучить свой предмет.
При этом учиться вы будете не только своему предмету, а еще и руководству людьми (привет, тимлиды), как быть в конфликтных ситуациях, как находить подход к разным людям (действительно разным).
Вы прокачаете свой навык выступлений и пониманию "держать внимание аудитории" - ваши конференции и митапы скажут вам спасибо
Вы увидите, что такое манипуляции студентов с другой стороны, научитесь на них реагировать, поверьте, вы многому научитесь. Многому.
Причина 2 Студенты
Многие студенты - по настоящему крутые и талантливые люди, работать с которыми очень интересно.
Это невероятно круто смотреть как студент, которому вы помогли, подсказали, может где-то словом, где-то делом, где-то поддержав даже просто - и вот он просто берет, закатывает рукава и вы видите как он становится просто топом.
Наблюдать (прилагая к этому силы) за тем, как ваши студенты становятся гигачадами - это незабываемые чувства.
Когда в конце года вы видите как они выросли, какими были, вы понимаете - это было не зря.
Многие из них могут даже несколько лет спустя вдруг написать вам "спасибо", понимая только сейчас, как мы тогда работали и для чего.
Видеть, как ваш ученик ставит точки там, где вы ставили запятые - это очень сильно.
Я помню каждого своего студента, с кем работал за все эти годы, многим я помог (да и сейчас готов помочь) советом/рефералом и после, потому что мы стали по сути уже даже друзьями.
Они молодцы, я невероятно горд, что работал с ними (даже за раздолбаев моих!)
Вообще, привести в сферу IT умных и сильных ребят, сделать то место, где вы работаете лучше - это важно.
Это чувство - когда вы понимаете, что помогли человеку стать лучше, сильнее, умнее, улучшили сферу IT крутым специалистом, когда вы понимаете, что вы сделали хорошее дело - это все дает гамму чувств, которые стоит испытать.
Причина 3 Драйв (без гослинга)
У меня есть несколько знакомых, для которых преподавания - это именно этот молодежный драйв, когда кто-то из студентов скажет новую шутку, мем покажут, все посмеются, вы тоже кринжа навалите - это дает такой драйв и подъем, что прямо ух, пристегните ремни.
Всем моим ребяткам - удачи и счастья, обнимаю вас, вы - крутые! Горжусь вами!
Ну а читателю, если он еще колеблется, я желаю решимости. Преподавать - стоит. Даже несмотря на все минусы.
Помогать людям, нести знания и свет, поддерживать студентов (когда многие вокруг уже забыли, что такое быть студентом) - оно того стоит.
Не говоря уже о том, что вы наконец разберетесь в своем предмете!
Ну а на этом я, наконец, заканчиваю свою серию плюсов и минусов в преподавании IT.
Постараемся накинуть на альма-матер и узнать, как видят образование в ИТ в ФПМИ МФТИ(НИУ)
Не пропустите!
Друзья, возвращаюсь с новостями!
Как вы знаете, мы с Иваном Углянским делаем подкаст про second_retake?si=SHy6bN13rPu6bOfV">преподавание!
Он выходит не стабильно (как наша психика), но на следующей неделе в четверг собираемся говорить про преподавание в МФТИ с гостем из деканата! Ссылку и напоминание я еще скину непосредственно перед подкастом!
Так что накидайте своих вопросов и ожиданий!
А пока можно посмотреть выпуск про образование в ФПМИ МФТИ (для логопедов рай) глазами студента, дабы освежить контекст!
Видео отчет, объясняющий куда мы пропали, прикладываю!