YD
Полтора-два года без повышения? Сейчас многие компании готовы хоть каждые пол года повышать
Пересматривать зп не значит повышать зп
Size: a a a
2020 June 16
RE
Мы вроде как не кассиры на кассе
не вижу связи.
Кассир на кассе, по умолчанию имеет константную полезность для компании.
Разработчик, в теории, может своей полезностью управлять. Но это другой уровень
Кассир на кассе, по умолчанию имеет константную полезность для компании.
Разработчик, в теории, может своей полезностью управлять. Но это другой уровень
KR
не вижу связи.
Кассир на кассе, по умолчанию имеет константную полезность для компании.
Разработчик, в теории, может своей полезностью управлять. Но это другой уровень
Кассир на кассе, по умолчанию имеет константную полезность для компании.
Разработчик, в теории, может своей полезностью управлять. Но это другой уровень
ну вот об этом и говорю, делает больше полезной и сложной работы - хочет больше денег, не дадут - найдет тех кто даст, все просто
👨M
Пересматривать зп не значит повышать зп
возможно понижать
S
- ты стал делать больше полезного для проекта, твои компетенции расширились
Вот интересно услышать от опытного разработчика, да ещё и с такими скиллами как у тебя, Стас.
Как измерить полезность для компании?
Как измерить компетенции?
И снова, наверняка уже набивший аскомину вопрос. Почему хорошо выполняемая работа в рамках трудового договора должна как-то дополнительного поощряться повышением зп? Да ещё и желанием разработчика, который вдруг сам решил, что стал вдруг делать больше "полезного".
Вот интересно услышать от опытного разработчика, да ещё и с такими скиллами как у тебя, Стас.
Как измерить полезность для компании?
Как измерить компетенции?
И снова, наверняка уже набивший аскомину вопрос. Почему хорошо выполняемая работа в рамках трудового договора должна как-то дополнительного поощряться повышением зп? Да ещё и желанием разработчика, который вдруг сам решил, что стал вдруг делать больше "полезного".
Например, такие две метрики:
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
RE
Например, такие две метрики:
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
определение - "Хорошая работа"
RE
как мне кажется здесь мы являемся заложниками определения, по-моему глубокому убеждению являющемуся большим заблуждением
код == полезность
код == полезность
RE
Например, такие две метрики:
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
а если тикеты бы закрывались не в срок или рос технический долг, то зп стоить понизить?
Ведь если есть повышение, значит должна быть и обратная сторона медали.
Только вот тикеты могут закрываться не в срок не из-за разработчика, да и технический долг может расти из-за неверных менеджерских решений
Ведь если есть повышение, значит должна быть и обратная сторона медали.
Только вот тикеты могут закрываться не в срок не из-за разработчика, да и технический долг может расти из-за неверных менеджерских решений
YD
возможно понижать
Ну понижать хз, но вполне можно услышать, что ты работаешь на свои деньги и встретимся через след полгода
b
Например, такие две метрики:
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
а если тикеты уровня "подвинуть картинку на 2px влево" и таких дохрена. ты их выполняешь в срок, как семочки, стоит ли тебе за это поднимать зп?
KR
а если тикеты бы закрывались не в срок или рос технический долг, то зп стоить понизить?
Ведь если есть повышение, значит должна быть и обратная сторона медали.
Только вот тикеты могут закрываться не в срок не из-за разработчика, да и технический долг может расти из-за неверных менеджерских решений
Ведь если есть повышение, значит должна быть и обратная сторона медали.
Только вот тикеты могут закрываться не в срок не из-за разработчика, да и технический долг может расти из-за неверных менеджерских решений
мы вроде как говорили о джуне который растет, редко какой джун будет расти в обратную сторону
👨M
Ну понижать хз, но вполне можно услышать, что ты работаешь на свои деньги и встретимся через след полгода
ни разу не был в такой ситуации, не знаю как это
S
а если тикеты бы закрывались не в срок или рос технический долг, то зп стоить понизить?
Ведь если есть повышение, значит должна быть и обратная сторона медали.
Только вот тикеты могут закрываться не в срок не из-за разработчика, да и технический долг может расти из-за неверных менеджерских решений
Ведь если есть повышение, значит должна быть и обратная сторона медали.
Только вот тикеты могут закрываться не в срок не из-за разработчика, да и технический долг может расти из-за неверных менеджерских решений
Полезность !== код, всё верно
Полезность - это зона твоей ответственности в проекте, и чем она больше, тем больше тебе будут платить
Полезность - это зона твоей ответственности в проекте, и чем она больше, тем больше тебе будут платить
YD
ни разу не был в такой ситуации, не знаю как это
У нас так бэку сказали как-то
👨M
… а потом ты становишься ответственный за всё, и всё летит к чертям, потому-что тебе хотя бы иногда надо спать
RE
Например, такие две метрики:
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
- закрываешь тикеты (менеджер доволен сроками, качеством)
- малый технический долг или его отсутствие, проактивность в решении технических проблем проекта (тех лид, сто довольны)
менеджер доволен сроками, качеством
Это всё не метрики. Сегодня он тобой доволен, потому что вы вместе пивко пили, а завтра недоволен, потому что ты ему 1000 до зп не одолжил
Метрики - это то, что можно померять количественно
Это всё не метрики. Сегодня он тобой доволен, потому что вы вместе пивко пили, а завтра недоволен, потому что ты ему 1000 до зп не одолжил
Метрики - это то, что можно померять количественно
👨M
У нас так бэку сказали как-то
теперь вы ищете нового бэка?
S
а если тикеты уровня "подвинуть картинку на 2px влево" и таких дохрена. ты их выполняешь в срок, как семочки, стоит ли тебе за это поднимать зп?
Нет, потому что зона твоей отвественности не меняется
YD
теперь вы ищете нового бэка?
Вообще мы ищем фуллстека, но ушел не тот которому отказали в повышении
S
менеджер доволен сроками, качеством
Это всё не метрики. Сегодня он тобой доволен, потому что вы вместе пивко пили, а завтра недоволен, потому что ты ему 1000 до зп не одолжил
Метрики - это то, что можно померять количественно
Это всё не метрики. Сегодня он тобой доволен, потому что вы вместе пивко пили, а завтра недоволен, потому что ты ему 1000 до зп не одолжил
Метрики - это то, что можно померять количественно
Оба твоих примера не относятся к работе от слова совсем)