Comments 66
Вопрос к иллюстрации: когда вы успели перейти с медведей на колобков? :)
Самая распространенная причина отказа в повышении — если тимлид в заявке не смог объяснить ценность конкретных выполненных кандидатом задач с точки зрения бизнеса.
А кто у вас задачи то выбирает? Сам разработчик что-ли придумывает? Или всё таки бизнес? А если бизнес, то почему этот бизнес не знает какую ценность эти задачи несут?
Здесь поднимается вопрос некомпетентности тимлида. Странно, что им может быть непонятна ценность выполняемой командой работы. Отсюда приходим к теме "Как понять, что ваш сотрудник готов стать тимлидом?"
Задачи возникают из различных источников. Что-то приходит от бизнеса, что-то от регуляторов (например, изменения Google Policy), что-то от самой команды (техдолг).
Приоритетами задач управляет продакт-менеджер, а задача команды помогать приоритеты определять. От технической команды представителем является как правило тимлид, но важно, чтобы разработчик сам интуитивно понимал важность той или иной задачи и мог внести свой инпут.
Парадигма "дали задачу и сказали что делать" - это мидл, а если мы говорим про синьера, то в этом случае он начинает активно организовывать работу команды, вставать в позицию девлида, проактивно митигировать проблемы, подсвечивать риски стейкхолдерам. И для того, чтобы эффективно это делать понимание бизнеса критично.
психологи называют это умным словом моральное стимулирование.
"А может, лучше деньгами?".
PS Эта фраза - из моей комсомольской юности. Конечно, к выводам всяких буржуазных наук тогда не прислушивались, но моральное стимулирование было хорошо изввестно и использовлось широко. Отношение людей - а мы были студентами, людьми умными - было к этому адекватное. И когда однажды у нас на местном собрании комсомольский босс начал втирать нам в уши очередную туфту про то, что мы там должны что-то сделать (не помню уже), а за это то ли грамоту дадут, то ли на Доску Почета поместят, один мой знакомый, там присутствующий сказал окржавшим его студентам эту самую фразу. Сказал он тихо, но босс услышал. Кароче, были тому студенту проблемы, но не фатальные - в деканате он был на хорошем счету, так что долг перед Родиной (а в те времена его запросто можно было отдать в Афгане, вместе с жизнью) ему отдавать не пришлось. Но фраза запомнилась.
Совка давно уж нет но его дух - как развести работников на работу забесплатно - гляжу, жив.
Обычно грейды взаимосвязаны с повышением зарплаты, и как раз вводятся для того, чтобы сотрудникам было прозрачно и понятно, как повысить уровень оплаты своего труда. Так что, думаю, такого нет, что просто вешается лычка senior-грейда без изменения уровня зарплаты. Иначе это было бы совсем уж странно.
"Моральное стимулирование" было про экспертов, которые оценивают потенциального сеньора.
Ну, я понимаю, что повышение грейда - это вполне честный процесс отбора тех работников, которые могут принести больше пользы предприятию, с целью навешивания на них дополнительных обязанностей, компенисруемы однако повышенной(обычно) зарплатой.
Но моральное стимулирование автор зачем-то упомянул.
Прежде чем перейду к теории: работа в крупной компании - это всегда трейдофф. В таких компаниях очень хорошо платят, а особенно людям, которым на уровне компании считаются синьерами+ (экспертами). Но при этом и задач приходится решать не мало, в том числе подобного рода (ревью кандидатов на синьерство). Ну и считаем, что по "пирамиде Маслоу" и прочих аналогов, базовые потребности у инженеров в крупных компаниях закрыты (или почти закрыты).
Есть замечательная книжка "Мотивация 3.0" или "Драйв: что на самом деле нас мотивирует".
Базовый тезис, что мотивация деньгами работает для скучных и рутинных задач, а вот для сотрудников, которые решают сложные задачи, мотивация строится на чувстве предназначения (делаешь классные штуки, которыми сам гордишься), автономности (сам выбираешь как работать, когда работать, где работать) и возможности прокачать свое мастерство/скилл.
При этом мы учитываем и знаем, что в разное время на людей действует разная мотивация, но в общем случае для экспертов эта активность не про деньги.
Ох уж эти идеалисты....
Вы говорите о закрытии базовых потребностей и всяких высших материях, вот скажите вы знаете сколько нужно получать в месяц для закрытия базовых потребностей уровня комфорт семье с двумя детьми, живя в Москве?
Базовый тезис, что мотивация деньгами работает для скучных и рутинных задач, а вот для сотрудников, которые решают сложные задачи, мотивация строится на чувстве предназначения (делаешь классные штуки, которыми сам гордишься), автономности (сам выбираешь как работать, когда работать, где работать) и возможности прокачать свое мастерство/скилл.
При работе рядовым наемным работником всё это "чувство предназначения" - это иллюзия. А не иллюзия - это сумма денег на счету. И я - не менеджер, поэтому в создании и поддержании иллюзий не заинтересован. И все эти уловки менеджеров наемным работникам вроде меня, возможно, надо знать - но чисто для того, чтобы понимать, в чем там ловушка, не более.
У кого по жизни более другие мотивации, типа, духовные - им стоит заняться их реализацией напрямую. То есть - организовать свое дело. Стртап, например замутить. И вот для этого всего как раз нужны деньги, и сильно больше денег, чем на закрытие базовых потребностей.
На крайняк, можно заняться деятельностью в организации, целью которой не является поднятие бабла для посторонних людей.
А удовлетворять свои духовыне потребности, работая на посторонних людей и удовлетворяя их хотелки ради того, чтобы они лавэ побольше намутили - это так себе стратегия. Все эти рассуждения о самореализации на службе кому-то вызывают в памяти военный афоризм Козьмы Пруткова "Да будет целью солдатской амбиции / Точная пригонка амуниции."
Ну, а что до автономности, то она - свобода выбора нанимателя - у наемных работников есть и так: это базовое условие работы нынешней экономической системы.
В Лаборатории Касперского своя атмосфера, достаточно почитать более раннее творчество.
Не увидел в статье пункту про "в первую очередь тимлид должен знать есть ли у конторы бюджет на повышение ЗП ещё одному работнику". Иначе, если контора не готова платить больше, все эти танцы вокруг повышения бессмысленная трата времени.
В остальном, тимлид должен пытаться тянуть каждого своего разраба в сеньоры, вне зависимости от того, хочет разраб этого или нет. Во-первых и люди не заскучают, т.к. будет цель, а во вторых будут объективные причины ЗП повышать.
Разумеется, если при таких попытках встречается сильно сопротивление со стороны сотрудника, темп этого продвижения нужно снизить, чтоб не душить человека. Но развитие в этом направлении должно быть по умолчанию. Кто не развивается - тот деградирует.
И ещё одна проблема в том, что большинство тим лидов не умеют правильно расставлять приоритеты и делегировать, отсюда возникает нехватка времени на действительно важную часть работы лида - наблюдение за командой, понимание ее слабых мест и сильных мест, и выстраивание стратегии развития исходя из этого. В общем, на бумаге все красиво, а по уму все это реализовать смогут единицы.
Согласен, что тимлиду необходимо знать информацию о хэдкаунте и планах. Еще ему важно работать с HR, своим руководителем и бизнесом, чтобы хэдкаунта на планы хватало, то есть помогать сводить планы и реальность.
Не соглашусь, что тимлид должен тянуть каждого разраба к синьер+. Тянуть нужно тех людей, у которых есть на это запрос. Синьерность подразумевает определенные навыки, умения, желания, а если человеку комфортно на текущей позиции, он справляется с работой, то и не надо трогать человек, не ломая композиция команды
Опять вода водой. Вот вы пишите, что нужно иметь прозрачный и понятный план, что нужно сделать, чтобы вырасти в грейде. А дальше пишите воду про понимание ценности для бизнеса, мотивацию и софт-скиллы. Что это значит? Даже джун может быть супер-мотивированным, иметь идеальные софт скиллы и даже понимать ценности бизнеса и зачем в конце концов он двигает такси в джире. Он уже может на этом основании стать сеньором?
Ладно, дальше получше - тимлид собирает список задач и проектов, которые сделал разработчик. А кто давал ему эти задачи и назначал на эти проекты? Наверное, не сам разработчик, особенно на уровне миддла. То есть если разработчик оказался на поддержке какого-то легаси, которое ещё никому и не нужно особо, то он не увидит повышение примерно никогда, потому что бизнесу он не принёс достаточно ценности.
А кто давал ему эти задачи и назначал на эти проекты? Наверное, не сам разработчик, особенно на уровне миддла.
Во, тоже хотел это спросить.
Привет.
В тексте есть важное упоминание, что разработчик должен успешно решать задачи, но просто решать задачи недостаточно чтобы стать старшим разработчиком.
Если мы смотрели бы на опыт MAANG-компаний, то разработчик на проектах, которые менее важны для бизнеса, не получил бы продвижения - факт. В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании. We live in society) Но и да мы активно промоутим людей с самых различных проектов.
В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании.
Что это значит?
По каким параметрам вы определите, есть понимание у кандидата или нет. Вот я условный разработчик, пишу какой-то внутренний сервис или продукт, он продается или помогает продавать другие продукты, чтобы принести деньги бизнесу. Я вам это сказал, вы сразу перевели меня в сеньоры? А если тоже самое скажет джун с 1 годом опыта, то он тоже пойдет в сеньоры?
Я могу понять оценку в количестве выполненных сторипоинтов или закрытых задач, в количестве МРов, которые проревьювил разработчик, в количестве разработчиков, которых он менторит. Я даже могу понять оценки в виде высокоуровневых и абстрактных задачах - мы слишком много денег тратим на поддержку клиентов; стоимость инфрастуктуры слишком большая; хотим, чтобы сейчас наш антивирус гнал трафик не по гигабайту в час от клиента, а в два раза меньше.
Тогда я могу прийти через полгода-год и сказать, вот, смотрите, тратили столько, стали на 30% меньше, я (наша команда) молодец. Или вот, раньше отвечали в поддержке в среднем в течении двух дней, а теперь в течении двух часов. Или даунтайм серверов обновления был 5% в год, стал 0.5%
А вот как мне доказать, что у меня за последний год стало больше какого-то мифического понимания, я не знаю.
Понимание смотрим на этапе ревью анкет, которая заполняется лидом и кандидатом на промоушн.
Если человек напишет, что вот мои артефакты, которыми я горжусь и в рамках их он опишет их output+outcome, то это и есть понимание.
Разработчик уровня миддла это не вольный охотник, который возвращается раз в год с докладом, что он придумал поделать, вы же сами давали ему конкретные задачи, если вы не выдали задач, которыми можно было бы гордиться или которые не были сильно полезны бизнесу, то получается разработчик вместо повышения будет сосать лапу?
И опять отмечу, что никаких конкретных критериев вы не озвучили (понимаю, что их нет и вы их сами не знаете и вам просто поручили написать статую в корпоративный блог) - например, мы ожидали, что разработчик сделает 30 сторипоинтов, а он сделал 20. Или наоборот, он сделал 50, поэтому он молодец и мы его повышаем
А кто тогда соглашается работать на проектах с которых не возможно продвижение? Зачем это делать? Опыта там никакого а боль и страдание как от задач так и от отсутствия какого либо роста гарантирована. Если у вас в касперском тоже так и нет возможности выбраться из этого то бедные ребята. Я сам работал в болоте в другой компании долгое время и не кому не пожелаю.
И как всегда самый простой и быстрый способ апнуться в сеньёры - это перейти в другую компанию, а не проходить смотрины в каком-то блат-комитете.
Согласен. Job hopping - один из самых понятных и быстрых способов в начале карьеры быстро забраться на синьера с отличной зарплатой.
Проблемы начинаются дальше. Например, у нас после синьера есть позиции ведущего разработчика, эксперта, старшего эксперта, ведущего эксперта и principal эксперта. Плюс есть возможность на этой карьерной лестнице сделать переход в менеджерскую ветку. Тут job hopping не помогает.
Мой личный опыт - 10 лет в компании. 5 лет от стажера до синьера и 5 лет на менеджерском треке. В целом очень рад, что не выбрал job hopping как карьерную стратегию
Вот именно. Вообще, как легче всего понять, что человек уже сеньор? - Он примерно соответствует тому, что индустрия думает про сеньоров. Или другими словами, может получить офер на стороне в качестве сеньора.
Если примерно на таком уровне разработчик у вас - так делайте его сеньором, чего ждать? Комитет, доказать...
Давайте я из своего управленческого опыта скажу - все эти грейд-комитеты, ассесменты, промоушн-кампании и прочее - сделаны с одной целью: ЗАТОРМОЗИТЬ рост грейдов и зарплат в компании и сделать его более предсказуемым. Особенно - в сочетании с практикой: сначала покажите что вы уже достигли уровня, а потом мы вам его повысим.
Все эти комитеты и процедуры - суть воротца, которые руководство может открывать и прикрывать в зависимости от финансового положения, текущего состояния пирамиды сеньорити, состояния рынка труда, желания своей левой пятки и тому подобного. Побочным эффектом такой системы повышений является невозможность в явном виде продвижения "своих людей" и уменьшения скорости образования клик в компании. Спойлер: они все-равно появятся, и повышения через комитеты нужных людей будут происходить через неофициальную торговлю "ты-мне, я-тебе", но несколько позже и несколько менее интенсивно, чем если бы решение о повышении просто принимал непосредственный руководитель.
Что об этом надо знать разработчику ? Эта система - не для вас, она - против вас. Есть только одно справедливое число, оценивающее вашу ценность для цивилизации: сколько за вас готовы заплатить на рынке труда. Поэтому, ради всего святого - ходите периодически на собеседования, и знайте свою цену. Если вы имеете оффер хотя бы на 20-30 процентов выше текущего места работы - идите к начальнику, и не размахивая шашкой (оффером) прямо спрашивайте, что надо сделать чтобы через три месяца получать вот столько (называете сумму из оффера). Если вам говорят "нет" или начинают съезжать с темы (а все эти промоушн-комитеты - это идеальный вариант как съехать с темы для начальника: он же хороший, написал заявку - а какие-то злые эксперты зарубили - ну ничего, пока поработай мидлом а через полгода попробуем еще раз...) - ваш моральный долг - перейти на другое место работы.
Ибо есть только одна причина для повышения зарплаты с точки зрения руководства крупной организации - и это дефицит кадров. Не производство ценности, не личные качества и даже не производительность. Есть кадры для текущих проектов - сосите лапу: то что вы воспринимаете как повышение после промоушена - скорее всего индексация на инфляцию (но сделанная хитро - миддлам не прошедшим промоушн индексируют чуть меньше чем на инфляцию, а прошедшим - чуть выше). Есть проблема со стаффингом проектов - пойдет повышение внутри компании, а на освободившиеся позиции начнется набор миддлов и джунов.
Написанное верно для больших (этак человек от 50-100) компаний. В малых компаниях можно достукиваться до первых лиц, вести переговоры (и даже успешно при - условии, конечно, что у компании есть деньги). Но тут ирония рынка: у крупных компаний есть деньги на повышение зарплат, но хрен они будут договариваться с рядовым разработчиком; у малых компаний договориться о повышении намного легче - но у них зачастую банально нет на это денег...
Хотел написать что-то подобное, но вы уже изложили мои мысли на 100%.
Отрадно видеть что в комментариях люди не готовы уплетать за обе щёки сервированное им на совковой лопате с дымком.
Да, мир сложный. Реальное продвижение по карьере зависит от сотен параметров: от уровня твоего руководителя до финансовых показателей компании. Любой процесс в крупной компании нужен, чтобы была управляемость, предсказуемость и общие понятные правила.
С позицией, что все построено против разработчиков, не соглашусь. Суть работы - это взаимный обмен. Ты нам x ютилей полезности, а мы тебе y рублей. Построить справедливую систему сложно, мы пытаемся.
Вот только компания заинтересована получить максимум полезности за минимум рублей, и рычагов давления у неё в общем случае — больше.
Всё остальное — это рассказы на тему того, «как мы покрасили мясорубку в розовый, чтобы уменьшить стресс для будущего фарша»
Суть работы - это взаимный обмен.
Только обмен этот неэквивалентный.
Мир очень сильно упрощается когда у тебя есть оффер от другой компании. Сразу становится пофиг, что компания сама себе написала в руководящих документах. Если менеджмент написал, что месяц перед повышением надо ходить в желтых штанах - теперь это проблема самого же менджмента. Точнее, нет никакой проблемы - составят бумагу (протокол, акт) что месяц ходили в желтых штанах, и вопрос закрыт. Бюрократия не оперирует фактами - она оперирует надлежаще составленными документами. Если же компания не хочет составить желаемые ею же документы - принимаем оффер и ага!
К компании в которой вы работаете надо относиться порядочно, но при этом предельно цинично: они вам не друзья. Какие бы ни были у вас хорошие отношения с коллегами, или даже с непосредственным начальником - как только изменятся экономические условия и/или поменяется ветер в голове высокого начальства - с вами сделают все, что сотчтут нужным: не повысят зарплату, не дадут обещанную должность, уволят, и т.д. И никто из руководства не будет страдать по этому поводу: "Бизнес, и ничего личного!". Нет у нас традиций пожизненной занятости как в Японии, восходящих в традиции к взаимным самурайским обязанностям вассала-господина...
P.S. Это не значит что надо становиться Вовочкой из анекдота: "...оденусь во все коричневое и вам все испорчу!". Надо сохранять нормальные рабочие отношения с максимальным количестком коллег - хотя бы для того чтобы работать было легче. Но вместе с тем, понимайте - имеют силу только те договоренности, которые вы письменно зафиксировали в трудовом договоре. Вы выполняете определенные обязанности - вам платят определенную зарплату. Все "договренности о будущем" - что вас повысят при определенных условиях, или увеличат грейд, или дадут премию - это тлен и пыль. И морковка, висящая перед носом чтобы тащить телегу было не так грустно... Что делать ? Развиваться и ходить на собеседования... Ходить на собеседования, и развиваться...
Если вы имеете оффер хотя бы на 20-30 процентов выше текущего места работы - идите к начальнику, и не размахивая шашкой (оффером) прямо спрашивайте, что надо сделать чтобы через три месяца получать вот столько (называете сумму из оффера).
Через 3 месяца ваш оффер уйдет в зрительный зал, а ситуация на рынке может измениться.
Лол, касперски - это ментовка в миниатюре, блат и кумовство там процветало и процветает. Кто жопу лижет начальству - повышение, остальным - ничего.
Для начала неплохо было бы определиться, кто такой тимлид, за что он отвечает и какие задачи решает - это технический эксперт или менеджер? А то по этой статье возникает ощущение, что от тимлидов слишком многого хотят и ожидают. Ну и неплохо было бы авторам знать, что могут быть орг структуры вообще без тимлидов в таком понимании, как у авторов, функции распределяются по более подходящим должностям - за бизнес интересы отвечают менеджеры, а за технологии - технические эксперты.
Игорь, согласен, что в терминологии мы забыли синхронизироваться. Спасибо, что подсветил. Я исходил из того, что тимлид - это роль, ответственная за профессиональный и карьерный рост сотрудников. Где-то это руководитель разработки, где-то прожект менеджер, где-то тех лид.
И конечно же подходов к топологии команд, ролям внутри жутко много. И все пытаются адаптировать их под себя.
Выглядит так, что ново-нанимаемому сеньору проще доказать что он сеньор, чем уже работающему сотруднику.
Интересно, осознанно ли сделана ситуация, в которой сотруднику проще найти новое место работы, чем поднять грейд внутри компании?
Я что-то пропустил или нам в трудовую уже пишут грейд? Недавно три оффера получил, и везде "разраб с зарплатой xyz".
Где у нас "черные пояса" раздают?
По опыту задумываться о повышениях начинают тогда, когда команды начинают расходиться, не один-два человека, а прямо один за другим уходят. А в целом повышение до рынка идёт, когда темп разработки уже значительно замедлился. Пока есть возможность как-то напрячь оставшихся без повышения и более менее сохранить темп разработки, будут напрягать. Поэтому стоит смотреть на то, комфортно ли лично вам с той зарплатой и нагрузкой, которая есть. Не комфортно - просим комфортные суммы и условия, не дают или может быть когда-нибудь при определенных условиях - идём туда, где дают. Как-то так.
У вас какое то неправильное понимание синьора. Задумываться о ценности для бизнеса это вообще-то задача менеджера а не сеньора. Если вы с мидла делаете промоушен человеку в лиды то да необходимо чтобы он это понимал. Ну а понять что человек дорос до сеньера очень просто что менеджменту что работнику. Открываем статистику в git lab и смотрим количество решенных задач с тегом 'high' и 'critical' если их сумма привалирует над 'low' и примерно эквивалентна 'medium' поздравляю у вас созрел сеньер-помидор и пора повышать. И созрел он не по абстрактным знаниям фреймворков и технологий а по общей пользе для вашего продукта. Найти ему замену будет уже очень дорого.
Интересный подход. Опираться только на количественные данные по решенным задачам точно недостаточно, но сигнал для будущих решений сильный.
В моей картине мира любой сотрудник получает зарплату за решаемые бизнес задачи. И пониманием зачем он это делает критично. Даже если ему задачу делегирует лид, то это не повод не разобраться в чем ценность и что на самом деле хотят.
А на что тогда опираться? Все остальное уже сильно субъективно и у собственника и разработчика может быть разный взгляд на бизнес модель компании и понимание того что приносит деньги(как уже писали и не раз любой разработчик на балансе компании это убыток, а продажник это прибыль). А метрика приведённая мной это не интересный подход а аварийная лампочка о том что давно пора. Дальше я рассматриваю ситуацию что человека выдвинули и комитет по промоушену отказал. Если не повысили человека по каким то субъективны причинам (луна не в той фазе, нет бюджета, ещё что то) то считаем последствия: от 2 недель до месяца человек крайне демотивирован и производительность снижена очень сильно, в это же время начинается на волне эмоций попытка оценить себя со стороны и походы по собесам. Если поход успешен контр офер этому человеку уже не нужен, уйдёт на эмоциях чисто из принципа. Что теряем в этоге: месяц производительности хорошего разработчика если останется то переодически как волк будет смотреть на сторону и общий перфоманс будет все равно снижен, или полностью разработчика в случае успешного прохождения им собеса в другой компании. Если отказывают в продвижении на грейд то хотя бы дают повышение зарплаты на текущей позиции за пользу и старания. Но все равно это мало кого мотивирует и чаще всего после неудавшегося промоушена люди уходят.
А как сотрудник может повлиять на то, какие задачи он берёт? Может ли он отобрать у коллеги "critical"? А что вообще говорят эти метки в плане оценки скиллов разработчика? У нас, допустим, так маркируются баги, по серьёзности для бизнеса, но с точки зрения кода все critical обычно самые лёгкие.
Если у вас канбан то разработчик может сам снять задачу с доски с любым приоритетом. А насчёт промоушена вы сами ответили на свой вопрос, как приводили в статье промоушен получает тот кто виден для бизнеса и решает самые ценные для него задачи а это критикал. При этом умение решить сложную задачу или написать сложный код скорее минус для промоушена он вас превращает в звезду и незаменимого специалиста а таких на верху не любят, слишком высокий риск иметь таких людей в команде. Вообщем хотите промоушена будьте на виду и решайте критические для бизнеса задачи. Сложность и трудность задачи здесь вообще не главное - в колхозе лошадь работала больше всех но председателем так и не стала 😀
Ну понятно. Вывод: развивайте язык, но не программирования
Вообще не обязательно. В этом подходе не нужно думать о бизнесе, менеджер подумал за разработчика и сам отмаркировал задачи по приоритету для бизнеса. Не нужно никому ничего говорить достаточно просто молча снимать с доски задачи. В конце статистика на промоушене скажет все за вас. Сдесь ценность максимальная и очевидна.
Я не понимаю механизма, как вы окажетесь лучше других или хотя бы достаточно хорошим для роста по грейду в таком случае?
Либо вы снимаете и закрываете задач больше других, фактически перерабатывая или некачественно, костылями делая работу. Либо вы срываете вкусные задачи, и может быть даже знаете о них заранее, ведь другие в команде тоже играют в эту игру.
Лучшим быть вообще не обязательно это бред, сравнивать себя с кем то прямой путь к выгоранию, только с самим сабой на определённом временном промежутке времени . Вы просто закрывает задачи важные для бизнеса и все, чаще всего это баги а не фичи они не сильно интересны для остальных и конкуренции за них практически нет.
Звучит как-будто "на доске есть важные и неважные задачи для бизнеса, бери только важные".
Кажется, в этой компании полный швах с планированием релизов, планированием ресурсов, если исполнители сами решают, что и когда брать. Также фактически постулируется, что разработчик может вообще брать неважные задачи и проедать на них бюджеты и время.
На доске представлен спринт(как временной отрезок, это не скрам с его ритуалами) а не общий бэклог и все задачи на ней важные для бизнеса, неважных на которые сливается время там нет, если такая и попадается то это проблема менеджера которые её туда поместил, и расходует ресурсы компании. Дальше эти задачи если спринт пройдёт нормально должны запилить. Но спринт может пойти не нормально и могут не запилить и вот тут сильно влияет приоритет задач а он обычно в пользу давайте восстановим работоспособность старого функционала(исправим баги) или добавим какую то критическую функциональность которой нет сейчас(допилить не до конца реализованую фичу), а потом уже идут фичи с мидл или лов приоритетом которые надо реализовать и которые могут растянутся на 2-3 спринта. Но для разработчика фича в приоритете, так как это возможность много покодить и поковырятся с интересной задачей с нуля. Допиливать за кем то кусок фичи(привет чужой код) или искать баг не интересно но иногда это важнее новой фичи.
А швах как мне кажется в вашей компании. Судя по вашему описанию у вас диктатура в стиле менеджер сам решает что копать нужно отсюда и до обеда. Ничего плохово в этом нет но это довольно низкая ступень развития организации и тим лида, и до бирюзовости вам далеко. Наш подход все таки ближе.
Позвольте крамольный вопрос: а зачем все эти грейды и лычки? Может было бы проще оценивать человека по вкладу в прибыль компании?
Встречал я как людей без священной приставки «синьор» или «тимлид», к столам которых выстраивались очереди жаждущих получить ответы на все вопросы, так и «синьоров» не знавших основ программирования (паттерны же основы программирования, не так ли?).
Может было бы проще оценивать человека по вкладу в прибыль компании?
Если бы можно было этот вклад взять и посчитать, но как?
Может просто посмотреть, что человек сделал за год: пофиксил столько-то ошибок, из которых столько-то критичных, закоммитил столько-то фич, отрефакторил столько-то классов, создал столько-то Unit тестов, сколько страниц документации написал, сколько рацпредложений сделал, сколько новых (и успешных) сотрудников собеседовал и принял. Всё же видно из репозитория, частично из переписки с начальством, ничего высасывать из пальца не надо. И выдавать премию/повышение зарплаты соответственно.
Гриды это тоже не измеряемая ни чем условность. В каких-то командах я буду едва джуном, а в каких-то просто гением (нет, я не гений, это была гипербола).
Так эти метрики не влияют на прибыль компании.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Извините за задержку, работа заела, отвечу по пунктам:
Так эти метрики не влияют на прибыль компании.
Как это не влияют? Очень даже влияют. Кривой код никому не хочется покупать, а кривизна кода сразу же видна по глюкам и ошибкам.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
А это уже вопрос к менеджерам, они же запросили фичу.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Тоже не к программерам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Если продукт достойный и приносит доход, то почему бы и нет? Вы же знаете, как создаются стартапы: минимальный MVP и понеслось. И так же понимаете, что в таком "продукте" баг на баге и багом погоняет. В какой-то момент возникает необходимость всё это пофиксить и отрефакторить.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
А это уже к организации процессов на фирме. Почему не все, кого это касается, читают документацию?
К тому же, грамотно составленная документация сокращает время на тех поддержку или на понимание кода, смотря для кого она была писана. Через год-два написанный код будет уже тёмным лесом даже для того, кто его писал.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Ой ли? Обычно для формирования нового отдела есть некие предпосылки, некий прототип, в идеале - MVP, который уже работает.
А так, да, если просто формировать отдел АИ просто потому что модно, то это только убытки.
Не стоит перекладывать ответственность бизнеса на реализаторов.
Вот уж чего не собирался делать. Сам работаю руками, иногда даже винты кручу (у нас много самодельных железяк и прочих моторов).
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела.
Итоговый результат отдела программистов всегда -запрлата, -стоимость компов, -стоимость лицензий, всегда минус, только без них не запустишь фичу и не исправишь бвг.
Я вот куда веду: оценивать работу разработчика нужно, и это важно самим разработчикам.
Важно потому что от этого зависит собственная оценка разработчика ("о! меня оценили!", "мой предложение оказалось полезным!") и его премия.
Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Если процессы в компании здоровые, то и разработчик может повлиять на руководство. Может быть не напрямую, а через тимлида или "серого кардинала".
Это все хорошо, но оценить вклад в прибыль компании это не может. Отрефакторил разраб 10 классов, а как это на прибыль повлияло? Делал фичи в проект, который не выстрелил, прибыли нет, это разве разработчик плохой? Все вами перечисленное это технические вещи.
Безусловно, можно и с технической стороны завалить дело, но разработчик это исполнитель. А исполнитель отвечать за организаторов не может. У него банально нет ни полномочий, ни полноты информации. В своей зоне ответственности, да, должен качественно работать. Но это техническая часть, которая на прибыль влияет опосредственно. Можно прибыль получать и с технически убогими решениями, а можно ничего не получить с прекрасно написанным кодом.
Вклад в прибыль компании осуществляют продажи, а IT - это одни расходы. Разогнать к чёртовой матери их, только прибыль проедают
Очевидно есть более простой, быстрый, понятный и прибыльный путь. Идёшь на собеседование, собеседуешься, получаешь оффер с ЗП сеньора. Готово, никаких ожиданий по пол года
Самая распространенная причина отказа в повышении — если тимлид в заявке не смог объяснить ценность конкретных выполненных кандидатом задач с точки зрения бизнеса. Поэтому я так сильно это подчеркиваю: это может быть сколь угодно эффективный и опытный спец, но если вам не удалось ввести в анкету кейсы, подтверждающие коммерческий профит, — шансов немного.
- это очень-очень печально, что так ставится вопрос. Хороший специалист может быть демотивирован, да и просто унижен на ровном месте.
Поделюсь своим опытом. Я тимлид, ко мне пришёл разработчик и сказал, что хочет расти выше. Никаких комитетов у нас нет, IT-департамент небольшой, всё создано относительно недавно.
Мы решили двигаться с двух сторон. Претендент представил своё видение, как он, миддл, считает, что вообще такое сеньор. Это очень важный документ, который попутно решает для тимлида другую задачу: сотрудник занимается качественной самооценкой в плане скиллов и честно пишет, где ему нужно подтянуться.
Также я представил своё видение, что такое сеньор. Оно сильно непохоже на то, что представил разработчик. Дальше в процессе беседы мы обсудили все эти наши пункты и выработали некий план. В его основе - предположение, что я уже считаю претендента сеньором. То есть даю более сложные задачи, требующие самостоятельности, коммуникации, творчества. Он справляется с ними сам, но запрашивает мою помощь. Если через три месяца такая работа приводит к положительному результату, то мы считаем его полноценным сеньором и повышаем зарплату.
Такой подход позволяет и проверить кандидата по пунктам, которые важны тимлиду, и проявить себя кандидату, показав, что он может восполнить недостающие знания и предъявить результат. Для этого главное согласовать крупные задачи, над которыми он будет трудиться, и какие инструменты он планирует освоить: он туда с удовольствием включит пункты из своего списка.
И ещё, что в вашей статье мне сильно не понравилось: ответственность как бы размазывается между тимлидом и экспертами, анонимными тем более. Это всё несерьёзно: растить людей - задача руководителя, а не комитетов. Как-будто у вас вся забота тимлида - правильно "продать" соискателя.
Доброе утро! Спасибо за классный комментарий и мне радостно за Вас, что двигаетесь с двух сторон. На 100% согласен, что задача тимлида растить людей.
Внесу маленькое уточнение в статью: анкета - это результат работы тимлида и кандидата. На самом деле заполняет ее как правило кандидат по предоставленному шаблону + опираясь на публичные анкеты коллег, которые ранее проходили успешный промоушн. Задача тимлида убедиться, что фактуры достаточно для того, чтобы кандидат считался синьером на уровне нашей компании. При этом желание, план перехода на синьера и прочие вопросы тимлид обсуждает с кандидатом в рамках регулярной работы (как правило встречи 1-1).
Дополнительно поясню зачем нужны эксперты - мы хотим выравнивать уровень разработчиков между разными департаментами. Например, сегодня ты занимаешься проектом А и (неожиданно) возникает потребность на твой проект найти людей, которые помогут его "затащить" => ты знаешь, что люди которые стали синьерами соответствуют некоему общему стандарту компании => c большей долей вероятности помогут тебе в проекте.
Как понять, что твой мидл готов стать сеньором? Гайд для тимлида (и не только)