Комментарии 31
Что происходит после senior+? Может ли senior+ получать больше тимлида?
Статья классная. Мне только одно непонятно - зачем с Ангуляра переезжать на Реакт? (Ангуляр же, не AngularJS?)
Спасибо ) Пардону прошу, AngularJS как раз
Видел этот процесс уже несколько раз в разных энтерпрайзах. Мотивируют снижением стоимости и ускорением разработки. Перехода с Реакт на Ангулар еще не видел ни разу.
На самом деле ситуация интересная, angularjs сильно подпортил жизнь angular2+, возможно тут нужен был более глобальный ребрендинг. Подходы react ближе frontend разработчикам, но если backend разработчик берётся за фронт то тут ближе angular с его dependency injection, особенно это касается dotnet разработчиков, хотя там и прочей ереси хватает типа blazor. Так же в пользу react выступает чуть меньший размер итогового приложения. Не знаю как сейчас с этим в angular, перестал за ним следить с версии 5-6. Сейчас сам хоть и являюсь backend разработчиком, смотрю на реакт из-за react native, для angular, к сожалению такого нет, nativeScript увы не то
Да я тоже "идентифицирую" себя бэком. Просто с фронтом последние лет двенадцать тоже приходится довольно плотно работать. И в плане дружелюбности для бэка комбинация Реакт + MobX это имба. Ангуляр рядом не стоял. Имею опыт и с тем и с другим и ещё куча разного. MobX позволяет красиво развязывать по слоям без протекания абстракций - API (аналог слоя репозиториев в бэке), сервисный слой (здесь сидит MobX) и слой представления (компоненты Реакт). Подумывал даже сделать здесь статейку как пример Spring Boot 3.x + React SPA, но что-то не могу определиться с темой примера.
Я тоже сначала так прочитал, удивился)) на самом деле там написано: переход НА реакт С angularjs
Проблема описанная в статье не нова и копий на эту тему сломано не мало. Если уходить в пределы, то <root cause> можно описать как "невозможно объективно и воспроизводимо замерить эффективность разработчика".
За почти 20 лет в разработке я так и не видел сколь-нибудь удовлетворительного ответа на "главный вопрос". Ближе всего на мой взгляд оказалась одна игровая студия, не помню ее имя - они тупо сделали конкуренцию на уровне команд. Одна и та же задача спускалась в параллель 2-3 командам, первая которая сделала, та и молодец (не знаю как было с контролем качества кода, но контролировать качество того, что уже написано, гораздо проще чем то что не написано). Код остальных просто выкидывался и скидывали новую задачу. На первый взгляд выглядит тупо, но я столько раз видел когда сроки по задаче в десятки раз превышали "разумные". Из личного примера - сервис разрабатывался аутсорсерами, более 6 месяцев в разработке плюс еще более 4 месяцев попытка дотащить на прод - результат пока нулевой. Этот же сервис был переписан сеньором, которого ситуация задолбала. За менее чем 2 недели была написана альтернативная реализация и проведена живая демонстрация на тестовой среде. По результатам которой принято решение "оставляем как есть, зря что ли столько бабла заплатили".
интересная затея, мне она как-то тоже приходила в голову в качестве эксперимента, но как-то звучит очень дорого, хоть и дешевле, чем во втором примере)))
ну и кстати попадание сроков задач в оценки у нас в грейдах учитывается. А так конечно, серебрянной пули не существует, тем более в разных компаниях разная специфика
Да понятно что у аутсорсеров других мотивов кроме бабла не прослеживается. Пока инвойсы ходят нормально, нет проблем. Насчет менеджмента в доле тут хз - все-таки Европа и территориально распределенные команды. Я бы предположил что менеджменту удобно иметь кого-то на кого можно кивать в случае косяков. Наказания за невыполнение планов нет, награды за перевыполнение - тоже нет. Вот и сидят на попе ровно.
Сотрудники в режиме потогонки перегорят со временем... И начнут уходить. Как думаю из той студии))
Никогда не понимал как это работает.
Вот вам нужен разработчик, на определенный кусок проекта. Выходите вы в рынок за этим разработчиком и начинаете искать... Проводите одно интервью, другое интервью, что-то никто не идёт. А сроки начинают подгорать... В этот моменты вы решаете увеличить зарплату и в итоге находите того, кого надо. И вот у вас есть грейд, в котором написано, что Вася должен получать 100к, а вот у вас есть единстенный найденный Вася, который говорит: либо 150, либо гори ваш проект огнем.
Стоимость ещё очень зависит от HR брэнда. Чтобы попасть в некоторые фирмы люди ещё доплачивать готовы, а в другие ни за какие деньги не пойдут.
Это немного другая проблема - проблема найма, про нее тоже можно целую статью написать. Но если вкратце - у нас разработчик в большинстве случаев ищется не под конкретный проект, а в компанию в целом. А потом он уже попадает в несколько команд, где есть задачи под разработчика определенного грейда, и выбирает из них (и его выбирают тоже).
А если сроки подгорают под конкретный проект - есть вариант взять уже имеющегося разработчика из другой команды, чтоб запилить этот проект, а потом вернуть) Опять же и для человека рост будет и проект не пострадает
Этих систем грейдов я видел немало, несколько делал сам. Скажу со свонй точки зрения "ну еще одна система грейдов. На 2% отличающаяся от таких же". И как у всех таких одна проблема ну пришел человек, я хочу, все изучил и задач новых набрал и решил, давайте мне медаль. А медали нет, у вас есть например работа для миддла на которой он сидит, а для синьора не ни ставки ни задач. Но человек то уже понял про себя, ог говорит вам досвидания и уходит на рынок. Или сидит печально выгорает. Ну или у вас штат разработчиков тысяч 20, тогда конечно место для движения есть всегда. Так что статья года через три была бы полезна мы сделали систему грейдов и за три года (дальше рассказ с примерами как все хорошо). А так статья, скорее всего, будет "мв сделали [в очередной раз] новую систему грейдов.
P.S. но это лучше чем совсем без системы
да, согласна, риски ухода на рынок всегда есть, к сожалению. Но как раз в новой системе поощряется помощь комьюнити, в котором ну практически всегда есть сеньорские задачи, для которых не хватало рук. И вместо рынка у нас существует механизм ротации внутри компании, можно найти команду, в которой есть эти самые сеньорские задачи, если человек действительно хочет расти - этот вопрос в 99% случаях решаемый, пусть не моментально, но решаемый.
Ну и я уже указала в статье в сторону чего мы смотрим, возможно и будет статья, что мы сделали в очередной раз систему грейдов, но я почему-то верю в то, что рано или поздно мы эволюционно дойдем до того, чтобы однажды написать статью с примерами, как все хорошо)))
А если на проекте нет синьорских задач, то как с менеджерами согласовывается занятие помощью комьюнити? Или это в личное время предполагается?)
Это очень хороший вопрос, серьезно, мы много думали об этом. У нас не один проект и команда, есть возможность помогать другим, а не только комьюнити. Но, в целом, это все равно сводится к тому, как согласовывается с менеджером. Сейчас попробую кратко объяснить:
В командах есть тимлиды, которые понимают уровень задач в команде, и если там действительно все слишком просто, то при выборе - разработчик выходит на рынок/идет помогать комьюнити или другой команде - выбирают помощь. Дальше уже можно все согласовать, процент времени с учетом текущей загрузки, возможно поиск другого человека, который будет делать мидловые задачи, чтоб освободить первого для сеньорских. Конечно, не все на 100% идеально, бывают случаи, когда вот прямщаз возможности нет, но тогда можно договориться о сроках. Рабство то в любом случае отменили )))
Но хочу подсветить еще одну штуку, на грейдах в том числе бывает, что человек приходит и говорит, нет у нас сеньорских задач, некуда мне развиваться в текущей команде. А копнешь поглубже, оказывается есть, можно еще очень сильно и глубоко заниматься инфраструктурой, архитектурой, техдолгом, процессами, это все тоже очень важные штуки и в портрете разработчика они есть. У человека глаза открываются и дальше он может пойти разговаривать с менеджером, со словами, уважаемый, у нас тут смотри сколько еще всего, давай ка на это время выделять, вот будет такая-то польза команде и проекту, например, меньше сбоев, багов если мы тут техдолг наконец сделаем. А вот тут надо рефакторинг провести такой приличный, дай сделаю, код будет в дальнейшем быстрее писаться. А тут вот у нас процесс странный, мы на него тратим кучу времени, а могли бы в это время делать больше полезного. Ну и менеджер, если ему внятно все это объяснить, соглашается и начинаются прекрасные изменения, от которых выигрывают все
Давно присматриваюсь к вакансиям Точки и интересует мнение сотрудников в ней работающих: поставьте ЛАЙК этому комментарию, если в этой компании вам НЕ НРАВИТСЯ работать разработчиком
крутая идея, спасибо! меня тоже очень интересует, буду следить)))
Есть нюансы как и везде. Грейд на старте блокирует рост зп, нужно идти подтверждать грейд (фактически ещё раз пройти собес или то, что указано в статье в зависимости от профиля). Если так вышло, что подтверждаешь грейд выше, то для тебя ничего не меняется, у тебя просто появляется новый потолок в зп, а твой уровень дохода всё равно растёт от отметки прошлого грейда. Соответственно компания получает условно сеньёра по цене мидла, выводы делайте сами.
Что означает фраза "хождение на грейды за зарплатой"? Они же именно для этого и нужны.
Они нужны не только для этого (хотя и не буду отрицать, что для этого в том числе), но и для развития. Первые были как раз в основном про зарплату, выучил теорию, сдал, получил стопицот к/сек и дальше делаешь свои мидловые задачи. А в текущей системе они подталкивают именно выполнять более сложные задачи и показывать вклад, в том числе в процессы, в команду, в комьюнити, в развитие всей Точки, и получать деньги уже за это
Вот выше был пример https://habr.com/ru/companies/tochka/articles/811649/#comment_26808137, когда человек нахватал задач, все сделал, медали нет, и он грустит. А придет на грейды, ему скажут, что именно надо сделать полезного и ценного, больше того, как именно это можно сделать. По сути, план развития составят. И у человека появляется понимание, в какую сторону то в компании и своем развитии ему надо идти, вместо выхода на рынок.
Мы же не зря вместе с бизнесом согласовывали этот портрет разработчика, бизнес готов платить деньги, но не за теоретическую теорию, а за реальную работу и вклад.
Про зарплату такой вопрос: пришел к вам мидл, на среднерыночную ЗП. Есть у него возможность расти по зарплате на 30% год к году на протяжении следующих 5 лет? Разумеется он проходит все оценки/измерилки и т.д. на отлично
а откуда взялась цифра в 30%?
на протяжении следующих 5 лет - это получается через 5 лет после прихода он должен получать в 3.7129 раз больше чем в начале, верно?
и я если честно не знаю, какая точно средняя зп мидла сейчас. И какие там ценники будут и инфляция через 5 лет я понятия не имею, так что это вопрос с подвохом
Но попробую ответить исходя из данных с первой вкладки гугла про зп)
первые три года точно да, потом 30% уже слишком большие цифры, у меня в калькулятор не вмещаются и прыгают сразу через вилки))) Но в целом реально, поскольку вилка сеньор+ ничем не ограничена
На своем примере (я пришла джуном, на границе вилки с мидлом) как раз чуть больше 5 лет назад, туда попала и пандемия, и падение рубля, и все на свете. За это время зп выросла больше, чем в 3.7129 раз.
Когда Вы первый раз используете аббревиатуру ФОТ, хорошо рядом дать расшифровку. Не все могут знать, что имеется ввиду.
Кажется, что версия 2024 года - это то, что изначально задумывалось в 2019 (или 2020, скорее). Потому что в грейдах было прописано - оценка за практическую работу а не то, что человек знает теоретически :)
Знать в теории и не применять на практике - бесполезные знания :)
ну, лучше поздно, чем никогда )) вот в 2023 еще на этапе обсуждения новой системы новые идеи появились про практическую работу и грейды за занимаемые роли, но это слишком резкие и большие изменения, к которым нужна огромная подготовка. Поэтому идем по шагам. Соберем статистику по этим грейдам, еще подумаем и сделаем еще один шаг ;)
Как мы строили систему грейдов разработчиков