×

Менеджерско-программистская выжимка за 17 лет в отрасли

[Об авторе: Владимир Железняк — пишет код, управляет проектами. Два раза дауншифтился с менеджерских позиций в чистый код, потом обратно вырастал. Вёл бесплатные курсы, консультировал джунов и бизнес, работал в офисе и удаленно].

Итак:

— Люди меняются медленно. Ты делаешь лучшее из возможного с теми, кто есть, или увольняешь, или даже увольняешься. Первое требует самообучения.

— Люди развиваются неравномерно. Кто-то качает код, кто-то разговоры, кто-то английский. Идеала не будет — ни у тебя, ни у сотрудников, ни у твоих детей.

— Найм подходящих — это твоя задача, а не рекрутеров. Они могут помочь, но не более.

— И программисты, и бизнес любят связь в своём формате: «С меня код, с вас деньги и уважение» и «С меня список задач и деньги, с вас работающая программа». Люди неосознанно избегают общения сверх этого. Чем выше человек в иерархии, тем проще ему оградить себя от тревожных сигналов и тем вреднее это для компании.

— Программисты не знают, насколько хорошо они работают (нет связи от менеджеров) — от этого нервы и выгорание/пофигизм/увольнения. Бизнес не понимает, над чем работают сотрудники — от этого страх обмана и дурные KPI. Плохая обратная связь — самая частая проблема в известных мне компаниях.

— Менять процесс нужно только в том случае, если результат кого-то не устраивает и этот кто-то готов за это заплатить. Желание должно быть не «Ну ладно, давайте попробуем», а «Мы косячим в <...>, это проявляется в <узнаваемые всеми ситуации>, я готов к сложностям времени внедрения».

— Конфликты будут всегда, и это хорошо.

— Учи на крови. Пока у тебя на руках есть горячий провал, и всё чувствуют, как это больно — тут и можно внедрить изменения. На крови гораздо проще перейти с программистами от мутного «Мы будем внимательнее» к «Любой код ревьювится», а с бизнесом от «Мы им деньги платим, пусть работают» к «Они люди. И не всегда предсказуемы, нужно вкладываться в мотивацию, отдых, резервирование критичных знаний»

Это самое важное из моего личного опыта управления проектами. Большую часть я выкладывал у себя на Facebook, сюда выношу выжимку. В этой статье — мои субъективные наблюдения и гипотезы. Я не социолог и не проводил развернутых исследований. Есть что дополнить, особенно в реальных примерах, — пишите в комментах. Я убрал всю воду, а её больше всего было на стыках.

О найме

«Пришлите пример вашего кода» — нужно спрашивать перед собеседованием. Кто пришлет код с коммерческого проекта — тех не брать на проекты с важным NDA. Кто пришлет код с публичного гитхаба — смотреть частоту коммитов и задавать вопросы про рабочий график и скорость переключения с проекта на проект.

Такой вопрос — дурная практика, не нужно спрашивать. Я вообще пока не видел ни одного хорошего способа эффективного собеседования миддл+.

Хороший vs Плохой. Все менеджеры знают, чем хороший программист отличается от плохого. Причем это знание не совпадает между менеджерами. Мне сейчас удобно определение: «Джун — приносит хоть какую-то пользу компании выше своей зарплаты, синьор — может написать проект от и до, а что не сумеет (например, дизайн или тексты) — сможет поставить ТЗ».

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

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

Программист должен писать код. Это самое главное. Неумение разобраться в ТЗ, плохой английский, конфликтность — снижают ценность и зарплату, но при нехватке программистов на рынке труда не будут стопором.

Note: если сбудутся мечты работодателей, и кандидатов станет больше, чем вакансий — всё поменяется. Если за одно место будут бороться пять синьор-джавистов, то рекрутеры начнут перебирать, вплоть до: «Фи, он свою поэму на английском не проверил спеллчекером, а внимательность — важный признак для нашего сотрудника».

Фрилансеры и удаленщики. Самые лучшие и самые худшие сотрудники мне попадались именно на фрилансе/удаленке.

«С++ за 21 день», «HTML за месяц» и другие сказочные курсы. После IT-курсов только от 5% до 20% поступивших находят работу. Остальные зря тратят время. Хотя вот буквально на днях слышал о результате в 60% — буду смотреть детальнее.

По моему опыту, на обучение с нуля до уровня «может приносить пользу работодателю» уходит от 400 до 900 качественных часов. Редко кто вытягивает больше 10 качественных часов в неделю на обучение без отрыва от основной работы. Больше 30 не вытягивает даже с отрывом. «Качественный час» — это когда таймтрекер останавливается при проверке почты/новостей/чай заварить, то есть любых прерываниях. У каждого есть свой предел «сколько я могу выучить/сделать для себя нового за день», при приближении к этому пределу КПД падает — и дальше есть смысл сидеть только для однотипной хорошо известной работы. Ну и бэкап заранее сделать.

Трудоустройство с нуля. Затраты на джуна — это не столько его зарплата, сколько время менеджера + рабочее место. И не важно, джун попросит 300 или 400 долларов. Фирме он будет стоить, к примеру 600 или 700. Не так уж и существенная разница, в общем-то.

О деньгах

Зарплата. Зарплата зависит от рынка труда куда больше, чем от кандидата. При растущем рынке наибольшей прирост ставки можно получить при смене работодателя. При падающем рынке — можно дольше удерживаться у старого работодателя. Примеры падающего рынка — кризис 2008-го и застывший сейчас рынок IT-труда в России.

Работодатель с удовольствием введет грейды, KPI и любую систему оценок, но... Зарплата по-прежнему будет зависеть от рынка, а не от KPI.

Прокрустово ложе аутсорсера. За $100 в час можно взять американца, который будет ходить в офис, жить по времени заказчика, говорить на отличном английском и понимать массу непонятных нам нюансов. Нас чаще выбирают не за суперзнания, превосходящие выпускников MIT, а за цену. Это очень важно для стартаперов, например.

Украинским аутсорсерам удается продавать сотрудников пусть за классные $40. Выше уже заказчики начинают крутить носом и смотреть на Индию — там уровень программистов здорово подрос за последние годы, а цены куда ниже наших.

Экономика аутсорсера. Разница между внешним и внутренним рейтом обычно в два раза. Но при этом прибыльность аутсорс-компании — 10-15%. Остальное уходит на офис, отпуска, праздники, больничные, бенч, найм, менеджмент, железо, софт и еще десяток мелких пунктов.

Числа проверены из трех независимых источников. Владелец небольшой фирмы запросто получает меньше своих топовых сотрудников и несет больше рисков.

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

Мотивация

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

Тема заезжена вдоль и поперек, пошла и баяниста, как анекдоты про Ржевского. Но если собрать десяток тимлидов и PM-ов и спросить: «Что болит?», то мотивация — самый частый ответ.

Свой/чужой. Большинство программистов ассоциирует себя с программистами. Поэтому при описании любого конфликта между программистами и бизнесом, угадайте, какую сторону выбирают программисты? :) Это нормально, это естественно, эффект «защиты своих» нужно учитывать при любых действиях, которые могут выглядеть как наезд.

Топ-менеджеры и бизнес тоже друг на друга равняются.

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

Diff. Люди ведут себя по-разному. Кто-то ноет с самого начала, кто-то молча работает, кто-то прибегает с вопросом два раза в день. Не так важно, как они себя ведут, важно, если поведение меняется. Тут стоит придумать две-три гипотезы, почему так:
— Раньше ныл, теперь перестал? Может, что-то отрефакторил втихаря, а может, тупо забил и ходит по собеседованиям?
— Раньше молча работал, а теперь начал говорить на отвлеченные темы? Стал доверять? А может, хочет поделиться наболевшим, но не знает, как начать?
— Бегал с вопросами два раза в день, а теперь — раз в два дня? Либо научился, либо поставил на себе крест.

Следующий вопрос — что с этой гипотезой делать и как обрабатывать возможные последствия. Но начинается всё с отслеживания изменений.

Похвала. Нужно хвалить. Если не за что хвалить, то зачем такой сотрудник? Без похвалы за конкретные действия мотивации нет. А любое порицание воспринимается как ужас-ужас-ужас. Гуглить «Линию Лосадо».

Две смертельных ошибки менеджеров. Желание нравится всем и перфекционизм — два самых частых греха начинающего IT-менеджера.

Менеджер-хамелеон принимает ту точку зрения, которая сейчас популярна среди собравшихся. Всем кажется, что он их поддерживает, и всё идёт хорошо. Поначалу.

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

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

Перфекционизм программистов. Перфекционизм у сотрудников поганит жизнь менеджеру:
— Бесконечные доделки;
— Перфекциониста на смежную задачу не перекинешь;
— Нытье: «Аааа, мне опять не дали отрефакторить нормально!»;
— Выгорание и увольнение.

Перфекционизм самому носителю тоже мешает жить. Когда кругом есть только серое «нормальное качество» и обычное черно-депрессивное «полное Г», то радоваться жизни как-то не от чего. Кроме того:
— Вечно задач больше, чем времени;
— Нифига не успеваешь;
— Окружающие делают всё не так, приходится проверять.

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

Прерывания. Одно прерывание человеку обходится в 20-40 минут рабочего времени. И не важно — вы отвлекли человека на 30 секунд, либо на один час — вспоминать задачу и разгоняться он будет всё равно примерно полчаса. Более подробно можно почитать тут — «Не будите программиста».

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

У меня получается либо писать код, либо менеджить в один момент времени.

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

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

Кстати, подавленный гнев часто вылазит в сарказм и насмешки.

Вместо выводов

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


В следующей части будет про обучение, людей и их мотивы, детей и суперов, а также про софт скилы.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




74 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дякую!
Этой я горжусь больше всего.

Спасибо! Позанудствую про раздел: по каким критериям отбирать? Это очень личное получится)

Про линию Лосада лучше не упоминать, это псевдонаука. blogs.discovermagazine.com/.../07/16/death-of-a-theory

В науке не бывает теорий без критики. Вон, Общество Плоской Земли до сих пор существует, и критикует теорию «Земля — геоид»
Я здесь предпочитаю обращаться к авторитетам. Для меня здесь достижимый авторитет — Дима Снисарь. Он психолог-практик с отличной научной подготовкой и следит за англоязычными новинками. Я попросил его прокомментировать:
----------
Фредриксон очень уважаемый в науке человек и имеет множество публикаций (en.wikipedia.org/wiki/Barbara_Fredrickson ), критика это нормальное явление в науке. Критику и основную концепцию можно прочитать даже на вике (en.wikipedia.org/...Critical_positivity_ratio ). Но дискуссия — это нормальное состояние для науки и критика идет больше не в сторону принципа, а в сторону математической модели. Поэтому тут важно как мы будем использовать эти знания, если просто как идею что «позитива должно быть больше негатива», то критика этой стороны даже не касалась (можно прочитать на вике о чем идет речь). Если цифры 2,9 или 3 то тут есть два мнения Фредриксон и Лосада и критика этой цифры.

Без критики действительно редко обходится. Но на адекватную критику отвечают. Сама Барбара писала, что у неё нет ни экспертизы, ни проницательности защищать математическую основу Лосады, используемую для исследования. А сам Лосада сослался на занятость как бизнес-консультанта и не стал отвечать.

We do not here call into question the idea that positive emotions are more likely to build resilience than negative emotions, or that a higher positivity ratio is ordinarily more desirable than a lower one. But to suggest that some form of discontinuity sets in at some special value of the positivity ratio — especially one that is independent of all demographic and cultural factors — seems far-fetched. We cannot, of course, prove that no such „tipping point” exists; but we believe that we have adequately demonstrated here that even if it does, Fredrickson and Losada’s (2005) article — based on a series of erroneous and, for the most part, completely illusory „applications” of mathematics — has not moved science any nearer to finding it.
Печально, что исследование с ошибочной математикой внутри цитируется сотнями научных изданий год за годом. Многим (да и мне лично) гораздо приятнее хвалить и быть хвалимым. Видимо поэтому идея превалирования позитивных транзакций получила такую распространённость. К сожалению, научных доказательств этому сейчас нет. Посмотрим через пару десятелетий, к чему эта вера приведёт.

Отличная статья, по поводу пункта — Прерывания. — советую почитать, что такое Фокус фактор и как его считать.

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

У меня одно прерывание пол дня может отожрать.

Лаконичная статья, почти и добавить нечего.

Но я бы добавил про поиски компромиса, по-моему опыту люди с восточно Европы редко ищут компромиса, а больше своей выгоды и унижение оппонента (им это доставляет удовольствия). А англичанин с англичанином договоряться о компромиссе намного быстрей, видимо по этому они и лучшие менеджеры.

Личный опыт говорит, что exUSSR чаще прижимисты и кинуть хотят. И я не готов обобщать на базе своего опыта, и не видел вменяемой статистики.

Zero sum game гуглите. Запад — это христиане, потому они склонны к кооперации — тоже теория Игр.

Прекрасный материал. Это дейвительно уникальная информация, которая отлично подана. Всегда стараюсь оценивать знания человека, по тому, как он преподносит информацию. Один вопрос, насколько высока мотивация людей, которые управляют твоим бизнесом?

Моим бизнесом или своим бизнесом?
Если именно моим — то я сейчас наемный сотрудник, который иногда «для души» пишет статьи и проводит тренинги и консультации. У меня нет именно моих сотрудников.

А «в поля» поменджить пойти? Или опыта хватит еще на 10 лет тренинга? :)

Я сейчас наемный менеджер-программист.

Крутая статья. Очень заметно, что все пройдено на своем опыте. Обычно такие статьи хочется разобрать на цитаты

Спасибо, готовлю продолжение

Отличная статья. Пишите еще

одна из самых толковых статей за последнее время. Спасибо.

Спасибо за отзыв, 400 шарингов и пара сотен фолловеров в FB очень мотивируют продолжить :)

«Пришлите пример вашего кода» — нужно спрашивать перед собеседованием. Кто пришлет код с коммерческого проекта — тех не брать на проекты с важным NDA. Кто пришлет код с публичного гитхаба — смотреть частоту коммитов и задавать вопросы про рабочий график и скорость переключения с проекта на проект.
Такой вопрос — дурная практика, не нужно спрашивать. Я вообще пока не видел ни одного хорошего способа эффективного собеседования миддл+.

Я с этим не согласен.
Конечно если человек пришлет код из проекта под NDA — это плохо :)

Но есть множество других вариантов:
1) Хороший программист должен развиваться и самосовершенствоваться — для этого есть pet projects, участие в чемпионатах (UaWebChallenge и т.д.), хакатонах — все это конечно же во вне рабочее время.
Если человеку не интересно в свое свободное время программировать и развиваться — у меня есть сомнения в том, на сколько ему интересно программировать в принципе. А еще на сколько его знания соответствуют последним трендам на рынке.

2) Программисты делают тестовые задания. И можно спросить — хочет он сделать тестовое задание (небольшое, часа на 4-6), или например показать пример кода с каких-то прошлых ТЗ в другие компании :)

3) Если это человек уровня Senior+, то ему надо уметь читать код библиотек/фреймворков и иногда в них что-то править, делать pull requests и так далее :)
Особенно это касается JavaScript, но думаю в других языках аналогично. Можно спросить делал ли он какие-то pull requests в open source (иногда это вполне ок и в рабочее время, если это надо для проекта)

Поэтому мое мнение — перед тем как нанимать человека — важно посмотреть на его код.
Недавний пример — нам (на должность Senior JS developer) прислал решение тестового задания человек с должностями тимлид/техлид в предыдущих компаниях.
Но уровень решения был на том же уровне, как я писал 3 года назад будучи джуно-миддлом :(

Поэтому мне кажется важно увидеть у человека или классный код на гитхабе — учебные проекты, чемпионаты, хакатоны, open source контрибьюшены, pet проекты, в общем что угодно :)
Или пусть делает тестовое задание :)

Хороший программист должен развиваться и самосовершенствоваться — для этого есть pet projects, участие в чемпионатах (UaWebChallenge и т.д.), хакатонах — все это конечно же во вне рабочее время.
и что примечательно, подавляющее большинство программистов этого не делают! а развиваются — сооовсем по другому.
особенно наивно ожидать от программиста, у которого есть семья, больших трат на всякие хакатоны. я сам пару раз думал потусоваться. но почитал отчеты... ну малоинтересны уже «молодежные дискотеки с кислотной музыкой».
Если человеку не интересно в свое свободное время программировать и развиваться
развиваться в программировании != программировать
, начиная с некоторого уровня, ессно.

я тут слежу за несколькими блогами программистов высокого класса. у них и pet projects нет, не говоря о том что аргументировано доказывают что нет смысла тратить время на посещение различных «Java days».
однако, то что они читают, и пробуют в паре строчек баловства на диковинных ЯП, а потом на своем основном — ого-го развитие.

то есть то что вы написали по бОльшей части рецепты для джуна желающего стать мидлом.

Программисты делают тестовые задания. И можно спросить — хочет он сделать тестовое задание (небольшое, часа на 4-6),
если оно такое простое — то зачем тратить на него время?
Если это человек уровня Senior+, то ему надо уметь читать код библиотек/фреймворков и иногда в них что-то править, делать pull requests и так далее :)
не считаю себя уровнем Senior+, но пробовал. и оказывается, одно дело написать что-то в раздел Issues, с описанием как получить этот баг.
а другое — предложить его решение не заплаткой, а в парадигме продукта, с тестами.
тут нередко и получается — «небольшое тестовое задание» на 4-6 часов минимум.

насчет читать код библиотек/фреймворков — то это обязан делать уже толковый джун.

Поэтому мне кажется важно увидеть у человека или классный код на гитхабе — учебные проекты
ну разве что. тут да, если человек что-то изучает пробуя прорабатывать примеры в коде, то почему бы и не выложить.
это идея, надо будет выложить парочку тестовых заданий, который успешно выполнены. за давностью лет условия не публиковать их думаю уже прошла. правда думаю, сейчас я уже делал несколько по другому, и такие задания покажут прошлый уровень, а не нынешний.
чемпионаты, хакатоны, open source контрибьюшены, pet проекты, в общем что угодно :)
«обычно мидл+ не может показать свой код» потому что: dou.ua/...umns/tips-for-pm/#1010189

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

развиваться в программировании != программировать, начиная с некоторого уровня, ессно.
я тут слежу за несколькими блогами программистов высокого класса. у них и pet projects нет, не говоря о том что аргументировано доказывают что нет смысла тратить время на посещение различных «Java days».

Если у программиста есть свой блог, где он пишет на технические темы, и пишет толково — это намного лучше тестового задания!

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

не считаю себя уровнем Senior+, но пробовал. и оказывается, одно дело написать что-то в раздел Issues, с описанием как получить этот баг.а другое — предложить его решение не заплаткой, а в парадигме продукта, с тестами.
тут нередко и получается — «небольшое тестовое задание» на 4-6 часов минимум.
Опять же это намного лучше выполнения тестового задания и позволяет оценить, как человек умеет мыслить, а не только писать код.

П.С.
Не обязательно педалить код в свободное время, но надо интересовать тем, что происходит в мире — эксперементировать с новыми технологиями, яп и т.д.

И это опять же круче тестового задания. А тестовое надо, если человек считает себя senior, но у него нету ни контрибьюшенов в open source, не гитхаба, не блога, не докладов на конференциях и т.д.

Если у программиста есть свой блог, где он пишет на технические темы, и пишет толково — это намного лучше тестового задания!
в упомянутых блогах многие программисты пишут только в комментах. и своих блогов не имеют.
Опять же если человек выступал на конференции на тему связанную с проектом, на который его собеседуют — то это намного лучше тестового задания!
потерей времени на конференции потому и считают — а выступления в большинстве случаев — слабые. ценного на 10 минут. «я бы это смог прочесть и понять прочитавши где-то в комментах»
на который его собеседуют — то это намного лучше тестового задания!
вот тут мы и приходим к реалиям:
конечно собеседуют так или иначе всех.
но синьору уже нет смысла светиться, его и так хантят.
вот джуну перешедшему в мидлы, но почему-то недооцененному на текущем месте работы — да.
А тестовое надо, если человек считает себя senior,
синьору как раз точно не надо.
разве что в случаях когда он из обычной компании решил прийти в «IBM R&D division »

синьор, если он уже знает о себе что он не один год реальный синьор — уже избавился от комплексов, чтобы доказывать кому-то или себе что он синьор :)
а если он еще и уперся в «стеклянный потолок» по зарплате в отрасли — так вообще, на кой тратить столько усилий, чтобы кому-то показывать что он синьор?
больше все равно уже никто не заплатит.

Если у программиста есть свой блог, где он пишет на технические темы, и пишет толково — это намного лучше тестового задания!

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

кому лучше?) обычно такие люди особо не программируют, а пишут статьи и выступают
Не обязательно педалить код в свободное время, но надо интересовать тем, что происходит в мире — эксперементировать с новыми технологиями, яп и т.д.
для этого 99% людей используют рабочее время
А тестовое надо, если человек считает себя senior, но у него нету ни контрибьюшенов в open source, не гитхаба, не блога, не докладов на конференциях и т.д.
глупости

Рынок все порешает и возьмет на больший рейт тех, кто в свободное время педалит код :)

он уже это порешал.

и — НЕ доплачивает за код пет проектов, посещение конференций, участие в опен сорс проектах, и т.д. и т.п.

и именно поэтому подавляющее большинство мидл± НЕ тратят на это время.

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

и с рейтами — тоже самое.

И можно спросить — хочет он сделать тестовое задание (небольшое, часа на 4-6)

А можно спросить — будут ли эти часы оплачены?)

как-то взялся делать одно тестовое задание только потому что — ну очень вычурное, далекое от реалий.
сам не заставишь себя решать такую задачку. а так — повод был :)
офер по его результатам дали, но я уже принял на тот момент в другой компании.
где задавались вопросы типа — а вот такое — как бы делал? и за 15 минут мы выясняли — а тем ли путем пошел, а что я знаю из ассортимента методик решения подобных задач.
и не жалко было потраченного времени на выполнение того тестового задания.
а вот если еще раз подобное же зададут, то наверное уже не буду тратить время.

конечно, компанию можно понять — тратить 1 час своего специалиста хорошего уровня, вместо предложить потратить 4-6 часов соискателю своего — компании не выгодно.

но тут уже и вопрос о том — а как хантили? если искали синьора — который наверняка сейчас вполне успешно трудоустроен, то вы ему еще и 4-6 часов предлагаете потратить на незнамо что? то есть — значит вы не уверены что он синьор? ну так ищите такого, в уровне которого уверены.

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

Процитирую автора

Note: если сбудутся мечты работодателей, и кандидатов станет больше, чем вакансий — всё поменяется. Если за одно место будут бороться пять синьор-джавистов
А так, конечно, код посмотреть хорошо.

Формат выбран идеально, кмк: коротко и провоцирует подумать/почитать по каждому пункту отдельно. Полезная подборка для начинающих менеджеров и опытных технических специалистов.

Спасибо. Лайк и репост )

Все по делу, спасибо.

В сторону: эффективные менеджеры без знания предметной области, по-моему — что тот Чайник Рассела.

Я работал на проектах, в которых я ничего не понимаю в бизнес-области, и не мог себе позволить несколько лет обучения. Мне получалось скомпенсировать тесной работой с бизнес-аналитиками.
Не претендую здесь на всеобъемлющее знание.

Марк Твен, «Как я редактировал сельскохозяйственную газету», ага.
Но я б доверял сугубо умеющим отличить синглтон от border-radius менеджерам.

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

Да-да, дуб — дерево, смерть — неизбежна. Согласен.
Только вот как менеджер найдет баланс, если он не понимает, в чем именно этот баланс заключается? См. Шекли, «Рейс молочного фургона».

Все еще остаюсь при своем мнении: менеджер без знания предметной области не эффективен в этой области. Нужно менять или менеджера, или область, благо их нонче многое множество развелось. Закручивать отверткой под филлипс шуруп со шлицем позидрив, конечно, можно, но от этого будет плохо и шурупу, и отвертке. Не говоря уж о закручивании шурупов мясорубкой, котенком или радиотелескопом РАТАН-600.

Предметная область не имеет значения, менеджеры только для того чтобы ее знать вообще не нужны, заказчик всегда может сформулировать что он хочет, иначе у него бы просто ничего не получилось в своем бизнесе

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

знание предметной области на уровне навыков абстрагированного, формализованного описания ее частей — это роль аналитика.

часто, а может и обычно — человека аналитика на проекте — нет. и эта роль размазывается между человеками — представитель заказчика, пиэм и (тим/тех лид + коллегия программистов).

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

если человек менеджер с этой ролью менеджера справляется хорошо, то то что он плохо справляется с ролью аналитика — вторично.

«программиста уволят не за плохое знание английского — а за регулярно плохой или постоянно не вовремя код»
а менеджера уволят не за то что он плохой аналитик, плавает в предметной области, а за то что он не умеет организовать, проконтрилировать выполнение, конструктивно разрулить конфликты (возникающие всегда!)

пиэм — это частный случай, квалификция роли менеджера.

конечно, идеальный человек-работник для компании, который одинаково успешно выполняет роли
аналитика, менеджера, программиста-синьора и литературного переводчика+копирайтера(для написания юзер гайдов и доки)

и поэтому любая компания ищет таких.

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

и поэтому и рационально в требованиях к работнику ставить не И, а ИЛИ.

как по вашему, если вы свой список требований к менеджеру разобъете с помощью исключающего ИЛИ, и, гипотетически предположите что существуют люди только с одним каким качеством из получившегося списка
с КАКИМ единственным качеством вы возьмете на работу человека на должность — менеджера?

Наверное, один из лучших топиков за последнее время.
Спасибо.

Очень толково изложено и без воды.
Пишите ещё, пожалуйста.

Теорий мотивации чуть более, чем дофига. Мне кажется, что эту я уже в какой-то разновидности видел. Ричи-Мартин или что-то подобное.

Примеры падающего рынка — кризис 2008-го и застывший сейчас рынок IT-труда в России.
Работодатель с удовольствием введет грейды, KPI и любую систему оценок, но... Зарплата по-прежнему будет зависеть от рынка, а не от KPI.
KPI и систему оценок обычно как раз и вводят, чтобы платить меньше, тем более при «падающем рынке»

Это очень частая причина, хотя и не единственная. Еще одна причина — это необходимость стандартизации между разными офисами.

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

Прочитал и прозрел, без шуток.

Спасибо :)
Здорово мотивирует на написание продолжения

Два раза дауншифтился с менеджерских позиций в чистый код, потом обратно вырастал.
У меня сие было трижды, и мысли в категории «Итак:» , с которой началась статья, совпадают до безобразия :8) Утверждаюсь в мнении, что как ведущему деву, так и хорошему манагеру, очень полезно побывать по «другую сторону баррикад» и оценить свою же работу с иной позиции. Тогда приходит четкое понимание, что (а) все работаем в команде (б) каждый делает свою очень необходимую, но недостаточную для общего успеха, часть работы. Соответственно меньше места остается мнениям, что только синьор-девелоперы (манагеры, аналитики, сейлзы, топы и т.п.) есть надёжа и основа нашей конторы, а всех остальных можно наццать раз выгнать и перекупить на рынке труда.

Отличная статья. Чем-то напомнило выжимку из книги «45 татуировок менеджера» Максим Батырев. Если решите расширит до книги, то я первый в очереди )))

Это уже четвертое предложение написать книгу с начала осени )))
Трудоемко и немонетизируемо, мы на проекте it-boost.com уже пробовали в эту сторону.
Да и лонгриды резко сокращают количество читателей. Так что лучше всё-таки в сторону статей.

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

Это месяцы работы FT. Сложно.

"

кризис 2008-го и застывший сейчас рынок IT-труда в России
" — а это тут причем?

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

«Сон программиста» — это пять! )))

Фрилансеры и удаленщики. Самые лучшие и самые худшие сотрудники мне попадались именно на фрилансе/удаленке.
вот да.

сам сталкивался с этим фактом, и мое объяснение ему про лучших (с худшими очевидно)
лучшие плохо вписываются в общепринятые практики процессов разработки, а карьеру строить по этим правилам- не умеют/не хотят.

Я вообще пока не видел ни одного хорошего способа эффективного собеседования миддл+.
и в этом тоже да.
и собеседовался, и собеседовал, — и сколько не читал и как проходить собеседования, и как собеседование... только для джунов есть приемлимой надежности чек листы.
в остальных случаях — «как повезет». будет импровизация :)
лучшие практики в кучки корпоративной культуры — ... это уже будет во второй части.
да, очень интересно. ждем :)

1ая часть однозначно удалась.

спасибо!

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

лучшие плохо вписываются в общепринятые практики процессов разработки, а карьеру строить по этим правилам- не умеют/не хотят.
Да, это очень хорошо подмечено. У лучшых часто есть strong opinion как делать вещи и на другие подходи к разработке они размениваться не хотят. С моего опыта таким намного лучше выделять отдельный модуль, ставить бизнес требования и не лезть в то как они работают.

Автору плюс за здравость мысли.

Спасибо. Очень мотивирует к продолжению. А сколько фолловеров в FB набежало... :)

«Пришлите пример вашего кода» — нужно спрашивать перед собеседованием. Кто пришлет код с коммерческого проекта — тех не брать на проекты с важным NDA. Кто пришлет код с публичного гитхаба — смотреть частоту коммитов и задавать вопросы про рабочий график и скорость переключения с проекта на проект.
Я что-то не понял. Это пример того, как надо делать или не надо, по вашему мнению?

Так делать НЕ надо. Смысла не вижу.

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

да, это было бы хорошо.

но на своем программерском опыте — а как его показать то, свой код?
не только в NDA дело.
часто нет никакого «своего» кода, а есть много точечных правок — чужого.
а тот что есть — выполнен не как бы писал сам, а как в неписанных стайл гайдах компании положено.
то есть код то мой, но и не мой даже по стилю :)

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

грубо, примерно как:
начинающий напишет свой развесистый класс.
а продвинутый — наследуется, перекроет один метод,
потом
потом пару строчек для регистрации в DI контейнере.
потом пару строчек подцепить или подцепиться к слушателям.
да и все. вот и весь код.

а как показать — рефакторинг, чтобы код позволял сделать как в примере выше?

Программистам платят за код
как бы да.
но думаю слышали про «индийские метрики» — оплата привязанная к количеству выдаваемого на гора кода :)

и получается программистам платят — не за код. по крайней мере мидл+ :)

в целом я конечно с вами согласен.

но как метко подмечено

Я вообще пока не видел ни одного хорошего способа эффективного собеседования миддл+.

и вот по этой причине тоже — а нету обычно у миддл+ кода который можно показать :)

Я тоже так одно время делал. А потом мне подсунули чужой код. Хотя да, тут есть тоже варианты с авторством по гитхабу.

Підписатись на коментарі