Подойдет любой инструмент, который умеет по базе данных используемого таск-трекера рисовать графики, можно хоть свой отдельный сервис сделать для этого или плагин для хрома, если чисто по апи данные брать
Это задачи, которые разработке приходится делать руками. Одно время у нас были задачки по пересинхронизации базы, там нужно было выбрать определенных юзеров руками и запустить переподтягивание данные из других источников. Или задачи на ручные правки багов по конкретным юзерам, когда в базе по каким-то неведомым причинам что-то съехало.
Бывают такие штуки, когда надо срочно что-то выкатить, а админку к этому еще не приделали и пока данные в базу (какой-нибудь контент, например) пишет сам разраб.
Упоминала в комментарии выше, что за полтора года существования продуктов там накопился большой техдолг, который надо было долго исправлять и вот пока время на этот техдолг не выделялось, правили руками. Собственно увеличение количества этого самого ручника (да и вообще его наличие) - это повод задуматься о выделении времени на техдолг
3 года на текущий момент. Но в начале 2023 было полтора года. И вот в тот момент там как раз накопился техдолг за эти полтора года, которому особо не уделялось внимание. К сожалению, метрик тогда еще не было и мы не полностью понимали, сколько техдолга мы берем в работу.
На графике в статье есть данные за июнь, но они еще немного искажены, поскольку метрики появились с июля 2023 и там еще шла доработка процесса. Но по памяти в районе апреля-мая у нас на техдолг уходило около 50% времени. Можно увидеть, что до марта 2024 уходило 15-30% времени на техдолг. Сейчас процент снизился. Но хочу отметить, что график в статье показывает, сколько времени реально выделяется на техдолг, а для количества накопленного техдолга и наблюдения его в динамике нужен другой график. Типа такого (это уже с другого дашборда другой команды, про него можно еще одну отдельную статью написать). На нем уже видно, что техдолг копится и надо уделять ему больше времени
да примерно то же, что и у собачек )) "Причесывание" бэклога - уточнение формулировок задач, критериев готовности, декомпозиция, оценка, приоритизация.
В контексте статьи - если совсем просто - командная встреча по подготовке задачи к разработке до того состояния, когда каждый член команды одинаково понимает, что надо сделать
ну, лучше поздно, чем никогда )) вот в 2023 еще на этапе обсуждения новой системы новые идеи появились про практическую работу и грейды за занимаемые роли, но это слишком резкие и большие изменения, к которым нужна огромная подготовка. Поэтому идем по шагам. Соберем статистику по этим грейдам, еще подумаем и сделаем еще один шаг ;)
на протяжении следующих 5 лет - это получается через 5 лет после прихода он должен получать в 3.7129 раз больше чем в начале, верно?
и я если честно не знаю, какая точно средняя зп мидла сейчас. И какие там ценники будут и инфляция через 5 лет я понятия не имею, так что это вопрос с подвохом
Но попробую ответить исходя из данных с первой вкладки гугла про зп)
первые три года точно да, потом 30% уже слишком большие цифры, у меня в калькулятор не вмещаются и прыгают сразу через вилки))) Но в целом реально, поскольку вилка сеньор+ ничем не ограничена
На своем примере (я пришла джуном, на границе вилки с мидлом) как раз чуть больше 5 лет назад, туда попала и пандемия, и падение рубля, и все на свете. За это время зп выросла больше, чем в 3.7129 раз.
Это очень хороший вопрос, серьезно, мы много думали об этом. У нас не один проект и команда, есть возможность помогать другим, а не только комьюнити. Но, в целом, это все равно сводится к тому, как согласовывается с менеджером. Сейчас попробую кратко объяснить:
В командах есть тимлиды, которые понимают уровень задач в команде, и если там действительно все слишком просто, то при выборе - разработчик выходит на рынок/идет помогать комьюнити или другой команде - выбирают помощь. Дальше уже можно все согласовать, процент времени с учетом текущей загрузки, возможно поиск другого человека, который будет делать мидловые задачи, чтоб освободить первого для сеньорских. Конечно, не все на 100% идеально, бывают случаи, когда вот прямщаз возможности нет, но тогда можно договориться о сроках. Рабство то в любом случае отменили )))
Но хочу подсветить еще одну штуку, на грейдах в том числе бывает, что человек приходит и говорит, нет у нас сеньорских задач, некуда мне развиваться в текущей команде. А копнешь поглубже, оказывается есть, можно еще очень сильно и глубоко заниматься инфраструктурой, архитектурой, техдолгом, процессами, это все тоже очень важные штуки и в портрете разработчика они есть. У человека глаза открываются и дальше он может пойти разговаривать с менеджером, со словами, уважаемый, у нас тут смотри сколько еще всего, давай ка на это время выделять, вот будет такая-то польза команде и проекту, например, меньше сбоев, багов если мы тут техдолг наконец сделаем. А вот тут надо рефакторинг провести такой приличный, дай сделаю, код будет в дальнейшем быстрее писаться. А тут вот у нас процесс странный, мы на него тратим кучу времени, а могли бы в это время делать больше полезного. Ну и менеджер, если ему внятно все это объяснить, соглашается и начинаются прекрасные изменения, от которых выигрывают все
Они нужны не только для этого (хотя и не буду отрицать, что для этого в том числе), но и для развития. Первые были как раз в основном про зарплату, выучил теорию, сдал, получил стопицот к/сек и дальше делаешь свои мидловые задачи. А в текущей системе они подталкивают именно выполнять более сложные задачи и показывать вклад, в том числе в процессы, в команду, в комьюнити, в развитие всей Точки, и получать деньги уже за это
Вот выше был пример https://habr.com/ru/companies/tochka/articles/811649/#comment_26808137, когда человек нахватал задач, все сделал, медали нет, и он грустит. А придет на грейды, ему скажут, что именно надо сделать полезного и ценного, больше того, как именно это можно сделать. По сути, план развития составят. И у человека появляется понимание, в какую сторону то в компании и своем развитии ему надо идти, вместо выхода на рынок.
Мы же не зря вместе с бизнесом согласовывали этот портрет разработчика, бизнес готов платить деньги, но не за теоретическую теорию, а за реальную работу и вклад.
Это немного другая проблема - проблема найма, про нее тоже можно целую статью написать. Но если вкратце - у нас разработчик в большинстве случаев ищется не под конкретный проект, а в компанию в целом. А потом он уже попадает в несколько команд, где есть задачи под разработчика определенного грейда, и выбирает из них (и его выбирают тоже).
А если сроки подгорают под конкретный проект - есть вариант взять уже имеющегося разработчика из другой команды, чтоб запилить этот проект, а потом вернуть) Опять же и для человека рост будет и проект не пострадает
да, согласна, риски ухода на рынок всегда есть, к сожалению. Но как раз в новой системе поощряется помощь комьюнити, в котором ну практически всегда есть сеньорские задачи, для которых не хватало рук. И вместо рынка у нас существует механизм ротации внутри компании, можно найти команду, в которой есть эти самые сеньорские задачи, если человек действительно хочет расти - этот вопрос в 99% случаях решаемый, пусть не моментально, но решаемый.
Ну и я уже указала в статье в сторону чего мы смотрим, возможно и будет статья, что мы сделали в очередной раз систему грейдов, но я почему-то верю в то, что рано или поздно мы эволюционно дойдем до того, чтобы однажды написать статью с примерами, как все хорошо)))
интересная затея, мне она как-то тоже приходила в голову в качестве эксперимента, но как-то звучит очень дорого, хоть и дешевле, чем во втором примере)))
ну и кстати попадание сроков задач в оценки у нас в грейдах учитывается. А так конечно, серебрянной пули не существует, тем более в разных компаниях разная специфика
Подойдет любой инструмент, который умеет по базе данных используемого таск-трекера рисовать графики, можно хоть свой отдельный сервис сделать для этого или плагин для хрома, если чисто по апи данные брать
Это задачи, которые разработке приходится делать руками. Одно время у нас были задачки по пересинхронизации базы, там нужно было выбрать определенных юзеров руками и запустить переподтягивание данные из других источников. Или задачи на ручные правки багов по конкретным юзерам, когда в базе по каким-то неведомым причинам что-то съехало.
Бывают такие штуки, когда надо срочно что-то выкатить, а админку к этому еще не приделали и пока данные в базу (какой-нибудь контент, например) пишет сам разраб.
Упоминала в комментарии выше, что за полтора года существования продуктов там накопился большой техдолг, который надо было долго исправлять и вот пока время на этот техдолг не выделялось, правили руками. Собственно увеличение количества этого самого ручника (да и вообще его наличие) - это повод задуматься о выделении времени на техдолг
хорошее замечание, спасибо
3 года на текущий момент. Но в начале 2023 было полтора года. И вот в тот момент там как раз накопился техдолг за эти полтора года, которому особо не уделялось внимание. К сожалению, метрик тогда еще не было и мы не полностью понимали, сколько техдолга мы берем в работу.
На графике в статье есть данные за июнь, но они еще немного искажены, поскольку метрики появились с июля 2023 и там еще шла доработка процесса. Но по памяти в районе апреля-мая у нас на техдолг уходило около 50% времени. Можно увидеть, что до марта 2024 уходило 15-30% времени на техдолг. Сейчас процент снизился. Но хочу отметить, что график в статье показывает, сколько времени реально выделяется на техдолг, а для количества накопленного техдолга и наблюдения его в динамике нужен другой график. Типа такого (это уже с другого дашборда другой команды, про него можно еще одну отдельную статью написать). На нем уже видно, что техдолг копится и надо уделять ему больше времени
да примерно то же, что и у собачек )) "Причесывание" бэклога - уточнение формулировок задач, критериев готовности, декомпозиция, оценка, приоритизация.
В контексте статьи - если совсем просто - командная встреча по подготовке задачи к разработке до того состояния, когда каждый член команды одинаково понимает, что надо сделать
ну, лучше поздно, чем никогда )) вот в 2023 еще на этапе обсуждения новой системы новые идеи появились про практическую работу и грейды за занимаемые роли, но это слишком резкие и большие изменения, к которым нужна огромная подготовка. Поэтому идем по шагам. Соберем статистику по этим грейдам, еще подумаем и сделаем еще один шаг ;)
а откуда взялась цифра в 30%?
на протяжении следующих 5 лет - это получается через 5 лет после прихода он должен получать в 3.7129 раз больше чем в начале, верно?
и я если честно не знаю, какая точно средняя зп мидла сейчас. И какие там ценники будут и инфляция через 5 лет я понятия не имею, так что это вопрос с подвохом
Но попробую ответить исходя из данных с первой вкладки гугла про зп)
первые три года точно да, потом 30% уже слишком большие цифры, у меня в калькулятор не вмещаются и прыгают сразу через вилки))) Но в целом реально, поскольку вилка сеньор+ ничем не ограничена
На своем примере (я пришла джуном, на границе вилки с мидлом) как раз чуть больше 5 лет назад, туда попала и пандемия, и падение рубля, и все на свете. За это время зп выросла больше, чем в 3.7129 раз.
Это очень хороший вопрос, серьезно, мы много думали об этом. У нас не один проект и команда, есть возможность помогать другим, а не только комьюнити. Но, в целом, это все равно сводится к тому, как согласовывается с менеджером. Сейчас попробую кратко объяснить:
В командах есть тимлиды, которые понимают уровень задач в команде, и если там действительно все слишком просто, то при выборе - разработчик выходит на рынок/идет помогать комьюнити или другой команде - выбирают помощь. Дальше уже можно все согласовать, процент времени с учетом текущей загрузки, возможно поиск другого человека, который будет делать мидловые задачи, чтоб освободить первого для сеньорских. Конечно, не все на 100% идеально, бывают случаи, когда вот прямщаз возможности нет, но тогда можно договориться о сроках. Рабство то в любом случае отменили )))
Но хочу подсветить еще одну штуку, на грейдах в том числе бывает, что человек приходит и говорит, нет у нас сеньорских задач, некуда мне развиваться в текущей команде. А копнешь поглубже, оказывается есть, можно еще очень сильно и глубоко заниматься инфраструктурой, архитектурой, техдолгом, процессами, это все тоже очень важные штуки и в портрете разработчика они есть. У человека глаза открываются и дальше он может пойти разговаривать с менеджером, со словами, уважаемый, у нас тут смотри сколько еще всего, давай ка на это время выделять, вот будет такая-то польза команде и проекту, например, меньше сбоев, багов если мы тут техдолг наконец сделаем. А вот тут надо рефакторинг провести такой приличный, дай сделаю, код будет в дальнейшем быстрее писаться. А тут вот у нас процесс странный, мы на него тратим кучу времени, а могли бы в это время делать больше полезного. Ну и менеджер, если ему внятно все это объяснить, соглашается и начинаются прекрасные изменения, от которых выигрывают все
Они нужны не только для этого (хотя и не буду отрицать, что для этого в том числе), но и для развития. Первые были как раз в основном про зарплату, выучил теорию, сдал, получил стопицот к/сек и дальше делаешь свои мидловые задачи. А в текущей системе они подталкивают именно выполнять более сложные задачи и показывать вклад, в том числе в процессы, в команду, в комьюнити, в развитие всей Точки, и получать деньги уже за это
Вот выше был пример https://habr.com/ru/companies/tochka/articles/811649/#comment_26808137, когда человек нахватал задач, все сделал, медали нет, и он грустит. А придет на грейды, ему скажут, что именно надо сделать полезного и ценного, больше того, как именно это можно сделать. По сути, план развития составят. И у человека появляется понимание, в какую сторону то в компании и своем развитии ему надо идти, вместо выхода на рынок.
Мы же не зря вместе с бизнесом согласовывали этот портрет разработчика, бизнес готов платить деньги, но не за теоретическую теорию, а за реальную работу и вклад.
крутая идея, спасибо! меня тоже очень интересует, буду следить)))
Это немного другая проблема - проблема найма, про нее тоже можно целую статью написать. Но если вкратце - у нас разработчик в большинстве случаев ищется не под конкретный проект, а в компанию в целом. А потом он уже попадает в несколько команд, где есть задачи под разработчика определенного грейда, и выбирает из них (и его выбирают тоже).
А если сроки подгорают под конкретный проект - есть вариант взять уже имеющегося разработчика из другой команды, чтоб запилить этот проект, а потом вернуть) Опять же и для человека рост будет и проект не пострадает
да, согласна, риски ухода на рынок всегда есть, к сожалению. Но как раз в новой системе поощряется помощь комьюнити, в котором ну практически всегда есть сеньорские задачи, для которых не хватало рук. И вместо рынка у нас существует механизм ротации внутри компании, можно найти команду, в которой есть эти самые сеньорские задачи, если человек действительно хочет расти - этот вопрос в 99% случаях решаемый, пусть не моментально, но решаемый.
Ну и я уже указала в статье в сторону чего мы смотрим, возможно и будет статья, что мы сделали в очередной раз систему грейдов, но я почему-то верю в то, что рано или поздно мы эволюционно дойдем до того, чтобы однажды написать статью с примерами, как все хорошо)))
интересная затея, мне она как-то тоже приходила в голову в качестве эксперимента, но как-то звучит очень дорого, хоть и дешевле, чем во втором примере)))
ну и кстати попадание сроков задач в оценки у нас в грейдах учитывается. А так конечно, серебрянной пули не существует, тем более в разных компаниях разная специфика
Ну и там был монолит, его разбили на микросервисы на реакте. Но это тема уже для вообще другого обсуждения )))
Спасибо ) Пардону прошу, AngularJS как раз
У senior+ уже нет ограничений сверху, там все зависит от вклада. Выше него грейда не предусмотрено.
Насчет тимлидов - там свои грейды и свои вилки, но да, senior+ и не только разработчик спокойно может получать больше тимлида