Пытаемся снизу (ну может из середины) наладить рабочие процессы в конторе. Поделитесь опытом, как у кого происходит формальная аттестация, повышение статуса разработчика?
До этого директор собирал "топ менеджмент" и решали: этот долго работает вроде опытный чувак пусть будет инженером второй категории, а этот ведущим программистом. А вот Вася может свалить, давайте его назначим "главным по тарелочкам". И т.д. Притом сами по себе как то решали, что пора.
Меня продвигали путем долгих one-to-one с директором, иногда подключались начальник отдела и HR. Заполнял анкетную простыню с дурацкими вопросами, типа, кем ты видишь себя через...
Теперь настала моя очередь оказаться по ту сторону баррикад. HR нашего давно сманили. Ждать когда начальство созреет чтобы промоутить моих джунов - так они раньше разбегутся, просто назначить и повысить зарплату, как-то неправильно. Хочется чтобы не было обид, почему Мишу повысили, а Петю нет. Чтобы все понимали, надо сделать 1,2,3... научиться а, b и c. И тогда всё будет.
Основную разработку ведём на C++.
Не прошу готовых решений. Хотя это было бы идеально. Просто накидать идей, свой реальный опыт, ссылок на нормальные статьи и т.д.
То что до сих пор удавалось найти на том же хабре например. Идиотские простыни со списками всех технологий о которых слышал составляющий этот список манагер.
Сначала вам необходимо подготовить максимально полную классификацию, кто есть кто в вашей компании. Например, абстракный джун обладает такими-то скилами, реашет такие-то задачи и т.п. Мидл, умеет и знает всё тоже самое, что и джун + что-то ещё по каждому из пунктов + возможно дополнительные пункты. Начиная со старших разработчиков уже должно быть прописано, как сотрудник влияет на бизнес и т.п.
После того, как у вас есть классификация, определитесь с системой перехода между уровнями. Это может быть что угодно, начиная с интервью один на один, заканчивая тестами. Лучше, чтобы решения принимал не один человек, а два-три.
Далее, необходимо чётко прописать зарплатную вилку для каждой должности, с учётом всех бонусов и прочих плюшек. Эти данные могут не быть публичными, но лучше чтобы все знали, на что они могут рассчитывать.
Вот пожалуй и весь нехитрый набор рекомендаций. Важно, на мой взгляд подходить к реалзиации каждого этапа итеративно и командно. Выносить на всеобщее обсуждение, дорабатывать и т.п.
Эти вещи понятны и достаточно очевидны. Проблемы как раз созданием классификации, интересен чужой опыт, и что уж греха таить надеюсь у кого-то что-то сдуть.
Пока к сожалению, кроме субъективной оценки по коду, соблюдению и оценке сроков (тоже часто субъективная оценка), умения общаться с коллегами ( и этот навык не померить).
Эти вещи понятны и достаточно очевидны. Проблемы как раз созданием классификации, интересен чужой опыт, и что уж греха таить надеюсь у кого-то что-то сдуть.
Сдуть не получится к сожалению, т.к. всё очень субъективно.
+ обычно это очень времязатратно, т.к. реально непростая работа и не для одного специалиста
+ это чаще всего приватная информация, которую нельзя разглашать
Разумеется, всё что я написал выше, справделиво для того случая, когда вы реально хотите проработать все детали, и сделать полезную вещь. Если вы хотите оставить старый процесс и просто навесить немного бумажек сверху, то ничем не могу помочь.
Советую взять листок бумаги и ручку и попробовать формализовать все те критерии, по которым вы повышаете людей. Это хороший начальный шаг. Социальные навыки тоже можно объективно оценить на самом деле, вот про это статей вроде хватает.
Vitaly, Глобальная цель проработать все детали, и скорее всего это будет некое коллективное решение, на всё инженерное подразделение фирмы. Но для начала, что-то решить для команды. Когда не могу конкретно ответить на вопрос сотрудника, что нужно сделать чтобы больше зарабатывать - мой косяк. Хотя мне на это всегда отвечали - сам подумай и предложи. Но я начинал тут работать когда сотрудников было около 20 человек, наверное так можно было. Теперь нас на порядок больше, а процессы нормально построены только на производстве, хотя и так есть косяки, как говорят...
Василий Мельников, Сама по себе команда -- это слишком маленькая единица (5-8 человек обычно, большим количеством сложнее управлять одному), в рамках одной команды нас самом деле не слишком много путей для вертикального роста, разве что горизонтального. Я поэтому рекомендую разработать сначала более глобальную классфикацию, метрики, методики перехода и т.п.
Vitaly, Глобальную когда-то пробовали, руководители департаментов "написали" документ, про то что, то хвост ломит то лапы мёрзнут. Каждый со своей колокольни с упором на софтскилы (гуманитарии хреновы). Так еще и без четких метрик. По большому счету руководство о чем поговорить с желающим повышения, набор тем.
Я готов эту часть для успокоения совести отдать нашему стажеру от HR пусть тренируется. А вот как бы проверить технические скилы да еще и наиболее объективно / прозрачно.
PS: Блин смотрю наши доблестные модераторы тостера выкорчевали, теги связанные с предметной областью....
А вот как бы проверить технические скилы да еще и наиболее объективно / прозрачно.
Ну допустим человека три независимо дают качественную оценку, и на основании этого принимается решение.
Можно конечно и количественные оценки давать: пофиксли n багов уровня k, провёл m code-review и т.п. Только это всё как-то искуственно.
У нас в компании недавно сделали открытые требования к грейду. Младший спец должен делать узкий круг задач, но под контролем своего руководителя. Чуть выше грейд- это уже самостоятельный чел. Старший спец - это уже тот кому может потребоваться делегирование своих полномочий. Т.е уже выше уровень. Ещё выше ведущий специалист. Так же идёт расчёт, работник движется в сторону менеджера или тех спеца. К примеру Тим лид - это больше менеджер и движется в управление. Тех спец движется в сторону консультанта и архитектора. Каждому сотруднику задаются цели на год. Потом проводится аттестация по результатам. Как правило цели выбираются для достижения грейда и зарплаты.
Это конечно всё здорово, но если бы вы могли поделиться конкретными метриками, был бы признателен. Потому как на пальцах с субъективной оценкой такая конструкция понятна, и достаточно очевидна.
Есть критерии:
1) вклад в фин результаты компании, т.е. умение оценивать задачи. Например, старший спец уже берет ответственность за оценку задачи в человеко/часах, т.е. бюджет. Вначале своих, а затем при росте должен уметь планировать бюджет с делегированием задач на своих подчиненных.
2) вклад в развитие интеллектуального капитала. Младший должен изучить материалы, а старший должен написать регламенты, инструкции. Еще выше - это систематизация данных материалов в рамках проекта.
3) развитие команды. Тут уже наставничество, составление плана обучения новых сотрудников, либо обучение работника при переходе на другой проект. Далее уже планирование в управлении командой в вертикальной иерархии.
4) Вклад в эффективность команды. Т.е. младший должен просто укладываться в отведенный бюджет при решении задач, но под контролем наставника. Далее тоже самое, но без регулярного контроля. Далее вклад в оптимизацию рутиных задач.
Может все слишком сжато получилось. Но тогда пришлось бы писать огромную статью. Но я думаю вы поймете ход мыслей и сами доработаете таблицу грейдов.
Владимир Дементьев, Спасибо. Хотя действительно сжато. А главное основано на субъективных оценках, руководителя или других сотрудников.
Для большой компании это подходящий вариант. Есть знакомый в одной конторе где 10+ уровней для программистов.
И там чтобы, перейти на следующий нужно пройти аттестацию у трех человек, два с целевого уровня и один еще на уровень выше. Притом сотрудникам вменено в обязанности участвовать в аттестации.
Но у нас не столько народу и лишком разные направления, хотя что-то такое в итоге и получается, только комиссия будет почти неизменная для всех.
Собственно, вопрос я задал для того чтобы получить описание чужого опыта, и в идеале некоторое количество объективных оценок / метрик.
Может я преувеличиваю но как кажется, завал промоутинга, это офигенный минус к морали и почти 100% повод для поиска новой работы. Зависит от скилов тех кто проводит аттестацию, если сумеют показать что чел сам не тянет. Но критерий "мы считаем что Вы пока не готовы" явно не годится, если чел подал заявку....
У нас в компании система построена таким образом, что каждый сотрудник заинтересован в активном участии на проекте. Так он заинтересован, в своем sla, так как вся инфа потом собирается к аттестации. Так как работник понимает, что если начнет выясняться, что он очень много волынил и перекладывал свою работу на других, то вопрос о повышении ему зарплаты встанет под большим вопросом. А чтобы наверняка он остался незамеченным, то есть мотивация действовать проактивно. Проявление любой инициативы приветствуется и может даже быть учтена на аттестации. А не как в армии, инициатива наказуема.
Василий Мажекин, нет. Если "не осилил", то это джун. Я про то, что когда поступает большая задача, и её необходимо разбить на подзадачи и распределить между джунами. Вы же не будете в одну харю тащить большой проект?
Абстракции абстрактны -- ну примерно так оно и происходит, вы вкладываете смысл в термины "мидл" и "джун", вы и решаете кого ими наградить, нет критериев....
Чтобы обид не было -- давайте с разной переодичностью разработчику мини-проект или библиотеку для разработки (улучшения/развития) и после некоторого времени давайте оценку с повышением на базисе результата
Вопрос как раз в этом. У меня нет формального понимания. Количественного, скажем так
Есть качественное. Способен ли принимать адекватные архитектурные решения, разбираться в документации, оценивать сроки, Какой код пишет, как даёт имена, делает коммиты и т.д. По софтскилам, как общается с коллегами, с другими подразделениями, с заказчиками если вдруг надо.
И качественно я могу для себя сказать, кто в чём лучше или хуже.
Но это субъективное суждение.
На интервью при приеме на работу, такое годится. Там не будет непонимания почему ему дали, а мне нет.
На моей прошлой работе в последнее время той же целью задались (там и раньше были критерии, но тут прям конкретно решили). В общем опросили вообще всех программистов какие навыки важны с их точки зрения, владение какими инструментами, какие знания, какой опыт и т.п. и сейчас насколько я знаю пытаются +- рабочую модель составить по результату.
Была такая идея, но у нас слишком сильно отличается профили команд. Встраиваемые системы требуют совсем других навыков недели прикладная или системная разработка. Хотя базовые вещи можно подобным образом собрать. Спасибо.
Василий Мельников, ну у нас в общем тоже не совсем профили совпадали и внутри каждой команды по факту своя почти матрица получалась. Команды по 6-8 программистов.
А по-моему не с того Вы конца.
Вы так будете что-то делать-делать-делать, Вам будет нравиться и казаться, что Вы делаете Благо.
А бизнесу это нафиг не нужно (может быть), а так как бизнесу не нужно - денег не дадут (ЗП не повысят), а как следствие - джун получит максимум что некий формальный грейд.
Потому более верный путь, ИМХО, будет: заявить "короткий доклад на совещании", где Бизнесу преподнести идею и план "па пальцах" что Вы хотите сделать (описать категории, экзамены...), но пока не сделали. Какой ожидаете результат (документы такие-то, система мотивации такая-то) от своей работы и как средствие от преобразований (мотивация, текучка...) Скорее всего все с умным видом кивнут головами и тут уже есть смысл заниматься. А если скажут "да у нас и так всё норм" - видимо, это совсем не нужно.
С бизнесом принципиально согласовано. Ему как раз на грейды пофиг. Но хотят понятные правила. Понятные технорям.
От нас за последние годы ушли несколько важных разработчиков. Один 20+ лет отработал.
Василий Мельников, то, что на грейды пофиг - оно понятно. Примерно всем пофиг. Исключение - если надо как-то где-то показать, что "у нас 100500 сеньоров".
Знаете... Я человек бизнесовый - в том смысле, что человек скорее ценностный, чем разработка. Я не к тому ,что разработка это не ценно, просто у меня другой подход. Заметили, что я много пишу про деньги? Вот на грейды, может, и разрабу пофиг. Зрелому человеку вообще это не так важно и на пирамиде Маслоу Вы видите не про грейды (та часть, что про уважение), а про самоощущение. Если человека называют Императором, то само по себе это сработает на того, кто находится на другой ступеньке - ниже. А человека зрелого интересует его видение - считают ли его Императором.
Отвлёкся? И да и нет. Смотрите... Ярлык - пофиг. Не всем, но большинству интересующих Вас. Бизнесу, работникам, партнёрам. Бизнесу нужна отдача от этой движухи. Например, снижение текучки. Бизнес может не понимать этого вот так буквально - это важно. Подумайте, что ещё это может дать бизнесу. Рост проффесионализма - не то. Если клиенты приходят в офис, а он у вас крутой-гиковский - подойдёт.
тут что-то происходит и у Вас появляется список из 5-7 преимуществ, которые Вы можете привнести бизнесу. Крайне желательно с метриками. Думаю, Вы в курсе, что это такое, но на всякий случай - я подразумеваю под этим любые цифры
Например:
1. Снижение текучки. Меньше простоев. Метрика - кол-во доступных человекочасов в неделю/месяц/год.
2. Ускорение найма. Метрика - средняя прождолжительность собственно с открытия вакансии до закрытия. Берёте старые цифры, считаете новые.
3. Ускорение адаптации к новым технологиям. ХЗ как Вы обоснуете, сам по себе пункт липовый, бизнесу новые технологии сами по себе практически никогда не нужны.
4. Принцип Вы поняли, думаю... Что угодно, что измеримо цифрами и можно притянуть в бизнес-пассивы (репутация не меряяется, но она хороший пассив. Кол-во строчек кода меряется, но пассив для большинства бизнесов так себе.)
Далее... Тут уже во мне говорит мой сервисный хомяк. Я, видите ли, обычно беру кусок каких-то дел и хочу деньги, которые этот кусок кушает. Не себе лично, но в распоряжение. Этот язык бизнесу прекрасно понятен, а мне профитообразующ.
Пример. У Вас отдел разработки из 10 чел. Офис, техника, обеды, интернет... CAPEX не так важен, смотрите скорее на OPEX (сколько денег кушают или проворачивают в единицу времени. Вообще на всё.) НУ, пусть 150 т.р. на зарплату/чел, 100 т.р. за офис, 100 т.р. на уборщицу и гардеробщика, 100 т.р. на печеньки. Ну, и ещё 200 на что-то. Всё в месяц. Итого 2 млн./мес. Немного, но уже что-то. Просите эти деньги в распоряжение, взамен через полгода вернётесь с подробным докладом, но раз в месяц будете обновлять текущее положение дел (не в курсе как это у Вас принято. Пусть листик на доске объявлений - не суть). Разумеется, Бизнес от вас (а теперь уже не "вас", а "Вас" - Вы же лично вписались за это) будет хотеть чего-то измеримого. Смотрите назад - чего раньше хотели - и прикидываете, что будет лучше. Кол-во строк кода не подойдёт. Скорость выкатки фичи - да.
Погнали! Крутитесь, делая 146% этих самых бизнес-ожиданий. Ускоряете скорость выкатки, снижаете AVG жизни проблемы в учётной системе... Теперь это Ваш гемор. Зато Вы сами решаете кого из разрабов назвать "полубог" и дать ему +50% денег, можете набрать 100500 джунов-удалёнщиков. Возможностей море, если у бизнеса жизнь, а не болото. Это отлично работает на росте бизнеса, а иначе Вам придётся придумывать себе работу (ну или искать новые задачи. Именно этим Ops`ы обычно и занимаются на совещаниях - а Вы что думали?). Если вы вообще отдельное юрлицо можно и заказы брать (правда, не забывайте, кто "папа") со стороны. Попутно мелочи под себя можно подгрести типа админства, но опять же - смещивать Dev и Ops в DevOps надо уметь и не забывать, что этимивашимикубернейтсами Ops не ограничивается.
Фух... Прошло полгода, Вы в хроническом стрессе, хоть и третий месяц тусите на Кипре на удалёнке. ФинДир и пара руководителей направлений на совещаниях жужжат про рейдерство и хвала Разуму, если Главный человек слова и не дал обратку. Собираете ЛПР`ов с темой доклада "как я провёл полгода и что это дало". Отчитываетесь о том, сколько денег сэкономили, не потеряв (а то и сильно увеличив) бизнес-эффект. Сколько уволилось людей - неважно. Сколько наняли - неважно. Грейды - неважно. Вы выкатили 100 бизнес-фич в 2 раза быстрее каждую, а в среднем в 2,6 раз. При этом сэкономили - ну, допустим, 10% реально практически всегда, в любом болоте, на любом росте - (2 млн/10)*6=1,2 млн.
Это реально, я много раз такое делал. Серьёзно. Грозит это тем, что Вас могут перестать любить. Все. Ваши работники потому как Вы относитесь прагматично - завалил мою выкатку фичи в срок? Не будет премии. Сеньору обидно, он же крут, у него грейд. Но наплевательски отнёсся к рекомендации привлечь пару джунов. ИТ-директор - потому как он такого (возможно) не может повторить и Вы можете его "скушать". ФинДир - потому как Вы нарушаете правила жизни в болоте и делаете вид, что финдир не так сильно нужен. ГлавБуха раздражает трансвестит, которого Вы наняли гардеробщиком. Да в общем не любят практически ВСЕ. И все льют это в уши Главному. Тут очень важно, чтобы он не соскочил. Но соскакивает часто и на моём личном опыте приходится нередко менять место работы, потому как на словах-то все эти бизнес-люди готовы, а вот на деле - пшик.
Но если всё прошло нормально и на этом самом отчётном собрании Вы рассказываете, что со всем справились, подтверждаете это проверяемыми цифрами, а само собрание происходит в спа-центре, которых Вы сняли на треть сэкономленных денег - это Успех.
Простой
