Комментарии 38
Спасибо за статью, интересно.
1) Понятные цели и задачи (KPI) - работает всегда
2) Понятную и объективную систему оценки труда и постановки задач (SMART) - очень трудно, вот прям трудно
3) Заработную плату - сейчас полегче, но год-два назад это был прямо… ахтунг… по 5 оферов на человека, один выше другого…
4) Полную удаленку из любого угла - я вижу другое. Часть хочет быть в офисе, а другие удаленке с ослабленным контролем. Тут это ключевое…
5) Понятные карьерные перспективы
, на игровую модель в стиле RPG. Вот честно, не получилось. Работала только система плюшек и карты… в игрушки и рпг…
Спасибо за комментарий.
Основная мысль тезисов в том, что понятные и прозрачные критерии, нам мой взгляд, пытаются заменить на непонятную виртуальную вселенную.
И, видимо, это уже намеченный тренд.
Из моей практики такой подход не работает.
Заработная плата "в рынке" - это гигиенический фактор, он просто должен быть.
Если работодатель платит ниже рынка, то он должен быть готов к оттоку высококлассных кадров.
Удерживать сотрудника "вечно" даже при идеальных условиях сложно,
а при низкой ЗП - это просто "карусель кадров".
Однако и давать "плюшки" без достижений - тоже не стоит.
Это порождает кадровую инфляцию.
Те самые 5 офферов за год :)
И как итог появляется тот самый "рынок соискателя", который плох и для соискателя, тоже.
а) Вместо развития компании начинают вкидывать деньги в заработные платы,
б) которые провоцируют реальную инфляцию,
в) которая обесценивает высокую заработную плату,
г) как итог услуги компании становятся менее востребованы,
д) что ведет к сокращению штата,
е) что может привести к увольнению
По удаленке, да, наверное стоит давать выбор.
Согласен с утверждением
А то, что грядет "рынок соискателей", особенно в области IT ни у кого сомнений не вызывает.
Уже сейчас чувствуется дефицит качественных кадров, а далее "кадровый голод" будет становиться все сильнее.
Моя компания ожидает его пик в 2026 году.
кажется вы не всё учитываете и может не сможете предложить условия - двадцать лет назад уже пытались экранизировать настроения ... а (всегда были) 0xff уже с 2008-2012 отказываются работать чтобы им не предлагали
Да собственно ничего не изменилось в этом мире. Извиняюсь за грубость, но как есть. У всех этих практик фокус на то как "наебать" ближнего своего, а не сделать реально крутой продукт. А на рынке дефицит лохов, которые хавают эту лажу, со специалистами-то как раз проблем нет. Здесь есть ключевая подмена понятия "специалиста" на "обслугу".
Спасибо за комментарий.
Ваша мысль передана грубо, но мне понятна.
Однако, если вы пообщаетесь с HR, то поймете, что они действительно верят в то, что делают.
Я бы назвал это некоторым заблуждением с их стороны, когда вера в то, что "игра работает" доминирует над реальностью. А раз никто не дает отрицательных отзывов (запрещено, на это же средства были выделены) - значит все работает отлично.
Касательно подмены понятий "специалист" и "обслуга" - не соглашусь.
Не так давно мы искали разработчика.
Удалось найти нужный уровень кандидате лишь на 30-ом человеке.
Очень много тех, кто 3 дня учил язык на вебинарах и теперь хочет 300 000 в месяц.
Скорость работы без ущерба качеству нужно ценить и поощрять, а не нагружать сотрудника дополнительными рабочими часами, пусть даже в рамках игровой механики с попыткой выиграть кружку с логотипом.По крайней мере к этому нужно стремиться, на мой взгляд.
Ключевой момент в направлении HR. Из чего, интересно, вы исходите придерживаясь такой позиции? Своей функции в бизнесе или общечеловеческих ценностей? Тут придется выбирать.
Бизнес - это извлечение прибыли и из времени и труда работника. Даже если бизнес и рассказывает на каких-то мероприятиях о том, что сотрудников надо ценить и поощрять, то только для того, чтобы привлечь сотрудников и после этого отэксплуатировать их и в хвост, и в гриву (в среднем естественно). Оттуда нескончаемый стон отрасли о выгорании, токсичной рабочей среде и неадекватных требованиях к соискателям.
Вы вопросы красивые задаете, но ответ на них напрашивается простой: роль HR и PR, и их мероприятий - это обертывание праздничной бумагой того, что не меняется уже 150 лет.
Спасибо за вопрос.
Исхожу из того, как это работает у нас в компании и этот подход финансово обоснован, кстати.
Действительно, бизнес - это извлечение прибыли.
Однако, если владелец заточен строго на прибыль, а не на расширение бизнеса, то с высокой долей вероятности такой бизнес схлопнется со временем.
Владелец просто "обескровит" бизнес, забрав прибыль.
Если говорить о разработке, то инвестиция в бизнес там может быть лишь в ширину или в глубину.
Я сейчас не о продажах, а именно о разработке и разработчиках.
Ширина - это "раздуть" штат.
Глубина - это улучшить навыки тех, кто уже есть, чтоб работы производились лучше и быстрее.
Опыт стартапов показывает, что "ширина" быстро выедает бюджет.
И создает "токсичность", ведь все примерно равны в навыках и пытаются доказать друг-другу, кто круче.
Следом начинают требоваться тимлиды, которые тоже требуют ЗП и т.п.
Т.е. расходная часть растет очень быстро.
В отличии от "глубины".
Она позволяет делать продукт качественнее, снижая его стартовые и эксплуатационные расходы.
Там где сотрудник делал 1 продукт за месяц он начинает собирать тот же продукт за 2 недели.
При этом нет "притирочных" периодов, потому что не меняется штат.
Далее, когда придет новый сотрудник, его не будут "токсить", а помогут быстро адаптироваться сами разработчики, потому что новый сотрудник никакой угрозы им не представляет с точки зрения навыков.
Таким образом, если новые проекты приходят,
то сотрудники спокойно работают без горящих дедлайнов.
Соответственно и выгорать перестают.
А свободное время легально уходит на "свои интересы", что снижает уровень недоверия.
Или "на личные проекты", что тоже весьма интересно, ведь в это случае они являются архитекторами этого проекта, который далее можно будет развивать совместно с бизнесом.
Здесь нужно понимать, что удачные проекты бизнес в любом случае будет пытаться развить и "одиночки разработчики" нормальный проект не создадут, только в команде.
Это длительный процесс.
По PR - согласен.
Однако, лично у меня были ожидания новых продуктов, которые не оправдались.
Отсюда и статья о "странных" трендах.
Она позволяет делать продукт качественнее, снижая его стартовые и эксплуатационные расходы.Там где сотрудник делал 1 продукт за месяц он начинает собирать тот же продукт за 2 недели.
Таким образом, если новые проекты приходят,то сотрудники спокойно работают без горящих дедлайнов.
Значит сотрудник теперь может делать 2 продукта в месяц - тогда понятна выгода бизнесу. Но какая от этого выгода сотруднику?
И как все это выглядит в плане интенсивности труда: сотруднику выгодно интенсивность труда в среднем понижать, врать в эстимейтах и логировании, и делать продукт все тот же месяц, а бизнесу наоборот - интенсивность повышать (2 продукта/мес) - отчего в т.ч. и происходит выгорание.
А свободное время легально уходит на "свои интересы", что снижает уровень недоверия.Или "на личные проекты"
Похоже, что свои интересы позволены сотруднику до поры до времени пока отдел продаж не обеспечит команду 2 заказами в месяц, и тогда никакого свободного времени не останется. Сотрудники рано или поздно это поймут, и начнут внедрять "свободное время" скрытно от руководства, опять замедляя свою работу и провоцируя недоверие и токсичность.
Сотрудникам редко удается выдерживать Life Balance (LB) с работой с 9:00 до 18:00 без дополнительных вовлечений в процессы.
И заметьте, время выигранное от повышения квалификации сотрудника не достается ему для восполнения того самого лайф-баланса - так как же ему от этого не выгорать?
(Не понял про "вовлечение в процессы")
Или "на личные проекты", что тоже весьма интересно, ведь в это случае они являются архитекторами этого проекта, который далее можно будет развивать совместно с бизнесом.Здесь нужно понимать, что удачные проекты бизнес в любом случае будет пытаться развить и "одиночки разработчики" нормальный проект не создадут, только в команде.
Тут интересно подробней. Компания претендует на права на такие проекты, потому что они выполнялись в рабочее время? Или сотрудник имеет право выторговать себе преференции и наконец завоевать свой ворк-лайф-баланс выходом из роли наемного работника?
Похоже, что свои интересы позволены сотруднику до поры до времени
Кажется, Вы для себя начали открывать неустранимое противоречие между трудом и капиталом )))
С тем, что сотрудник должен приносить прибыль компании никто никогда не спорил.
Цель существования любой компании - извлечение прибыли.
Вопрос лишь в том, используется ли сотрудник "как расходник"
или это "самый ценный актив компании".
А вот тут мнения у всех расходятся )
Как пример Япония, где люди на работе умирают, а экономика не особо то и в рост идет сейчас.
Значит сотрудник теперь может делать 2 продукта в месяц - тогда понятна выгода бизнесу. Но какая от этого выгода сотруднику?
Как я писал выше, у сотрудника появляется период, когда новая задача еще не пришла и в этот период у него то, что у нас называется "свободная охота".
Сотрудник изучает то, что ему интересно и имеет потенциальную пользу где-то позже в проектах.
Иногда, проект сразу не приходит и состояние "охоты" может длиться порядка недели.
И как все это выглядит в плане интенсивности труда: сотруднику выгодно интенсивность труда в среднем понижать, врать в эстимейтах и логировании, и делать продукт все тот же месяц, а бизнесу наоборот - интенсивность повышать (2 продукта/мес) - отчего в т.ч. и происходит выгорание.
С какой целью занижать интенсивность, если после окончания проекта никто ничего "не накидывает"?
Как раз интенсивность идет в рост, так как сотрудник понимает, что может обеспечить себе легальную "свободную охоту", а это сразу означает отсутствие дедлайнов и пушей в git.
Бизнесу выгодно "заканчивать проекты", чем их будет больше завершено - тем выше прибыль.
И снижать стоимость поддержки тоже выгодно, а это достигается качеством кода.
Т.е. давая обучаться мы снижаем расходы, как я и писал выше.
Похоже, что свои интересы позволены сотруднику до поры до времени пока отдел продаж не обеспечит команду 2 заказами в месяц, и тогда никакого свободного времени не останется. Сотрудники рано или поздно это поймут, и начнут внедрять "свободное время" скрытно от руководства, опять замедляя свою работу и провоцируя недоверие и токсичность.
И да, и нет.
Мы изначально планируем времязатраты так, чтоб у сотрудника было примерно 20% времени на изучение дополнительных материалов.
Загнать сотрудника в рутину "делай-делай" - это прямой путь к выгоранию и увольнению.
Т.е. если заказов приходит больше, чем способна вытянуть команда, то это повод задуматься о "горизонтальном расширении" как раз, у нас такое уже случалось.
"Выжигать людей" - порочная практика хотя бы потому, что следом вы получите "-1" качественный сотрудник и "+1" человек в обучение, что явно выйдет дороже.
И заметьте, время выигранное от повышения квалификации сотрудника не достается ему для восполнения того самого лайф-баланса - так как же ему от этого не выгорать?(Не понял про "вовлечение в процессы")
Как раз далее в статье написано, что в мире IT вариант LB сложно реализуем и требуется переход к WLB.
Сам концепт WLB не дает выгорания, потому что работа становится не рутиной с 9 до 18, а процессом внутри жизни.
Работа становится высокооплачиваемым хобби, если так удобнее воспринимать.
Тут сразу оговорюсь, что если сотрудник попал "по ошибке" в IT, то для него такой режим станет каторгой :)
Тут интересно подробней. Компания претендует на права на такие проекты, потому что они выполнялись в рабочее время? Или сотрудник имеет право выторговать себе преференции и наконец завоевать свой ворк-лайф-баланс выходом из роли наемного работника?
Юридические детали раскрывать не буду, но суть сводится к тому, что хорошие задумки становятся собственностью компании юридически, на них передаются полные права.
Торговаться у нас не принято - это потеря времени.
Нужно что-то, сотрудник озвучивает и далее пытаемся решить вопрос.
Если он решаемый - соглашаемся.
Если нет - предлагаем варианты и думаем далее.
В частности, так решается вопрос платного доступа к тематическим ресурсам, например.
Выгода разработчика - проект может получить инвестирование в разработку и улучшение, если докажет жизнеспособность.
Однако, если разработчик хочет, может разрабатывать самостоятельно без передачи прав - никто мешать не будет.
Важно понимать, что большинство проектов "в одиночку" не делаются, а если и делаются, то заканчиваются в git open sourse без финансовой выгоды для разработчика.
Слишком много человеко-часов требуется, чтоб создать хотя бы MVP.
А следом идет внедрение, переговоры с потенциальными заказчиками и т.п.
Следом требуется UI/UX перенастройки под фокус группы, CI/CD и расчет мощностей и прочее.
Ни один человек не в силах изучить все, к сожалению.
Т.е. сотрудник превращается из разработчика в гендира с командой узких спецов и забывает про код.
Про LB и WLB можно забыть, это фактически запуск бизнеса с нуля.
Ну и про конфликт интересов не нужно забывать.
Мы же нанимаем разработчика, а не стартапера со своей независимой командой :)
Из нашей практики мало кто хочет менять профиль ради идеи,
которая не факт, что "выстрелит".
А компания как раз берет на себя этот риск, ей выгодно, чтоб идея сработала.
При этом разработчик рад тому, что идея жизнеспособна и над ней можно работать далее, развивая ее в рабочее время.
Надеюсь правильно понял ваши вопросы :)
Спасибо за развернутые ответы, тема интересная!
у сотрудника появляется период, когда новая задача еще не пришла и в этот период у него то, что у нас называется "свободная охота".
С какой целью занижать интенсивность, если после окончания проекта никто ничего "не накидывает"?
Если компания действительно может выделять время для личных проектов, то это было бы мощным преимуществом, о котором следует заявлять громко, ясно и прямо. Но громкое заявление обязывает эту политику потом действительно соблюдать, и тут возможно сама компания под это не подпишется, потому что высок соблазн покрывать ошибки планирования и накладки тем самым свободным временем, а то и вообще таким образом переваривать случайные всплески количества заказов.
Мы изначально планируем времязатраты так, чтоб у сотрудника было примерно 20% времени на изучение дополнительных материалов.
Тут я запутался. В планируемом 1-месячном проекте уже заложено 20% для себя? Или на эти 20% еще самому работнику нужно ускориться, чтобы иметь возможность заняться своими проектами?
А если скажем работа успешно сделана за 50% времени (2 недели), то как будет планироваться запас времени на следующий такой же типовой проект?
Сам концепт WLB не дает выгорания, потому что работа становится не рутиной с 9 до 18, а процессом внутри жизни.
Концепция work-life-blend похоже противоречит изложенному выше: в такой модели, если правильно понимаю, нет жесткого графика и рабочего места, а значит руководство не увидит сколько времени высвобождает сотрудник сделав проект быстрее, и тогда в нашем примере сотрудник сможет забрать себе не 20% а все 50% "рабочего" времени, и будет волен распорядится им хоть для свободной охоты или хоть для отдыха на свое усмотрение.
хорошие задумки становятся собственностью компании юридически, на них передаются полные права.
Однако, если разработчик хочет, может разрабатывать самостоятельно без передачи прав - никто мешать не будет.
Если тут на самом деле отсутствует кажущееся противоречие, то хорошо.
Если компания действительно может выделять время для личных проектов, то это было бы мощным преимуществом, о котором следует заявлять громко, ясно и прямо
Согласен частично.
В данном случае мы просто говорим "как есть",
скрывать нет смысла - это не тайна.
Пиарить тоже - штат уже полностью укомплектован :)
...высок соблазн покрывать ошибки планирования и накладки тем самым свободным временем...
Если это такие ошибки, то сотрудники начинают скучать и увольняются.
Знаю много примеров, когда мотивом перехода становилась именно "скука".
У нас за время существования компании 0 увольнений среди разработчиков :)
В планируемом 1-месячном проекте уже заложено 20% для себя.
Это верное утверждение.
Только не нужно воспринимать "для себя" как "пойду поиграю в футбол".
"Для себя" - это обучение за счет компании, а не отпуск :)
А если скажем работа успешно сделана за 50% времени (2 недели), то как будет планироваться запас времени на следующий такой же типовой проект?
Как встретим второй "типовой проект" - обязательно расскажем.
Из практики - ни одна задача ни разу не повторилась.
А то что повторяемо, например разворачивание сервера, уже давно заскриптовано :)
...а значит руководство не увидит сколько времени высвобождает сотрудник...
Попробую объяснить, есть срок сдачи продукта.
Предположим, что вам нужно реализовать 1 модуль за 5 рабочих дней.
В данном случае измеримый KPI - это 1 модуль.
Мы стараемся абстрагироваться от часов,
но если вам так удобнее мыслить, то пусть под это есть 40 рабочих часов.
Разложим задачу по SMART:
S - конкретная задача, модуль имеет четкое описание
M - измеримость, 1 модуль
A - достижимый, прежде чем ставить задачу ее детали проговариваются.
Собственно здесь бизнес-аналитик работает и его задача сделать задачу достижимой.
R - значимый, тут понятно, цель важна для бизнеса
T - ограничение во времени, есть лишь 5 дней.
Сотрудник сдал его за 4 рабочих дня, т.е. затратил 32 часа.
40 - 32 = 8 часов разницы.
Все вполне измеримо и прозрачно.
...и будет волен распорядится им хоть для свободной охоты или хоть для отдыха на свое усмотрение ...
Для свободной охоты - да.
Для отдыха - только если руководитель понимает, что через те самые 8 часов будет проект высокой сложности.
Такое редко, но бывает.
Хотя опять же, пока никто не жаловался, что обучение не дает отдохнуть.
Мозг переключается, дедлайна нет, можно пить кофе или слушать лекцию на прогулке в парке.
Обучение - это не всегда написание кода.
Если тут на самом деле отсутствует кажущееся противоречие, то хорошо.
Попробую перефразировать.
Компания готова выкупать права на хорошие pet-проекты сотрудников.
Возможно так стало понятнее :)
Попробую подытожить.
Компания (вероятно) обладает очень хорошим планированием (в условиях нетипичных задач).
20% времени в планировании заложено на свободное творчество.
(Вероятно) эти же 20% являются буфером компенсации накладок и ошибок планирования.
Свободное творчество помогает:
разработчику воплощать собственные задумки и продавать, обменивать или реализовать личные проекты с помощью компании;
компании генерировать полезные идеи и наработки благодаря потенциалу "корпоративного инкубатора" (плюсом является знакомство разработчиков с устройством и процессами компании).
WL-blend реализуется только в части собственного профессионального творческого потенциала в рабочее время. В остальном WL-blend нереализуем, т.к непрофессиональные дела находятся за регламентом рабочего времени (те же условные с 9:00 до 18:00).
Пожалуйста, поправьте или дополните.
И еще вопрос, если не секрет: каков масштаб команды разработчиков и менеджеров, чтобы компании такой подход шел на пользу?
Компания (вероятно) обладает очень хорошим планированием (в условиях нетипичных задач).
Верно
20% времени в планировании заложено на свободное творчество.(Вероятно) эти же 20% являются буфером компенсации накладок и ошибок планирования.
Верно, хотя именно как буфер этот запас используется крайне редко
Свободное творчество помогает:
разработчику воплощать собственные задумки и продавать, обменивать или реализовать личные проекты с помощью компании;
компании генерировать полезные идеи и наработки благодаря потенциалу "корпоративного инкубатора" (плюсом является знакомство разработчиков с устройством и процессами компании).
Не верно.
Основная задача этого временного отрезка - повышать навыки сотрудника.
Будем объективны, 99,9% всех идей и задумок никогда никем не будут воплощены по множеству разных причин.
Соответвенно получение идей / MVP - не самоцель.
WL-blend реализуется только в части собственного профессионального творческого потенциала в рабочее время. В остальном WL-blend нереализуем, т.к непрофессиональные дела находятся за регламентом рабочего времени (те же условные с 9:00 до 18:00).
Юридически - да.
Компания не может претендовать на нерабочее время и это правильно.
Но опять же, учет осуществляется не на базе времени ("спички не считаем"), а на базе задач.
Вероятно, что у вас пока не складывается разница между этими понятиями.
И еще вопрос, если не секрет: каков масштаб команды разработчиков и менеджеров, чтобы компании такой подход шел на пользу?
Из практики - любой.
Контроль осуществляется на базе линейных руководителей и, если выдержано корректное соотношение 1 руководитель к 7 сотрудникам, то такой подход легко масштабируется.
Если компания придерживается формата 1 управленец на 100 разработчиков, то этот формат применить не выйдет - все начнут просто отдыхать.
Здесь стоит отметить и то, что WLB накладывает серьезные ограничения на качество управляющего состава и сотрудников.
Как пример, не все могут работать в состоянии ослабленного контроля, некоторым всегда требуется пристальное внимание руководителя.
Т.е. не исключаю, что для ряда сотрудников такой подход вообще будет неприменим и придется делать выбор между "расстаться с сотрудником" или "контролировать по-старому".
Спасибо, предметный получился разговор.
Юридически - да.Компания не может претендовать на нерабочее время и это правильно.Но опять же, учет осуществляется не на базе времени ("спички не считаем"), а на базе задач.Вероятно, что у вас пока не складывается разница между этими понятиями.
Здесь стоит отметить и то, что WLB накладывает серьезные ограничения на качество управляющего состава и сотрудников.Как пример, не все могут работать в состоянии ослабленного контроля, некоторым всегда требуется пристальное внимание руководителя.
WLB - отдельная тема для разговора. Или было бы лучше развернуть в статье.
Потому что непонятно как это реализовывать в рамках назначения рабочего времени, отслеживания рода деятельности в это время, но при этом оценивать по результатам, а не по времени. Мне пока представляется это взаимоисключающим и не похожим на то, что пишут в статьях про WLB.
И поскольку самым главным условием является безупречное планирование - то этому тоже нужно учиться и учить, чтобы получились все "WLB" и прочие "современные" подходы к работе.
Вам тоже спасибо!
Действительно вышло конструктивно :)
Мысль развернуть в отдельной статье тему интересная,
подумаю, получится ли ее расписать так, чтоб было понятно как это "сходу" применить.
Правда впереди еще вторая часть "цифрового рубля" и "хакатон" ;)
Если не секрет, то вы в какой области работаете (направление деятельности компании) и почему возник такой интерес к этой тематике?
Если не секрет, то вы в какой области работаете (направление деятельности компании) и почему возник такой интерес к этой тематике?
Я сам своего рода разработчик). А темой интересуюсь, т.к. очевидно, назрел пересмотр всех старых подходов, будь ты наемник, фрилансер или сам руководитель. Интересно у кого получается, и что получается.
Мысль развернуть в отдельной статье тему интересная,подумаю, получится ли ее расписать так, чтоб было понятно как это "сходу" применить.
Лучший способ, думается, обсуждать идеи с корректными оппонентами. Особенно публично - это тонизирует)
В случае, если Разработчик выполнил задачу раньше срока - это прекрасно для всех.
РМ радуется экономии внутренних бюджетов,
Заказчик тому, что он получил продукт раньше срока.Свободное время позволяет изучить новый стэк технологий, что улучшит навыки самого сотрудника и возможности компании в плане оказания услуг.
Можно это прояснить?
За счёт чего происходит экономия бюджетов?
Зачем заказчику продукт раньше срока, если у него остальные процессы раньше срока не готовы?
Идея дать денег разработчику даже не рассматривается?
Спасибо за вопрос.
Если мы говорим о внешнем заказчике, то по сути он заказывает не часы работы,
а "услугу по разработке", иначе это уже аутсорс получается.
В этом случае окончание работ "до срока" - это прямая выгода РМ компании разработчика, так как сотрудники потенциально могут заняться другими проектами, т.е. приносить прибыль.
Справедливости ради, обычно возникает пауза хотя бы дня в 3 между ними, т.е. "есть время обучению".
Даже если разработчики 2 недели будут просто заниматься обучением - это уменьшит срок старта и затраты на эксплуатацию новых проектов, т.е. будет наблюдаться эффект отложенной прибыли.
А еще это дает хорошие гарантии того, что "проект успешно сдан",
поскольку остается время на дебаг, если он возникнет.
Т.е. PM закрывает свой KPI с гарантией и это ему выгодно.
Ну и никакого выгорания, все понимают, что укладываются в сроки.
Если заказчик получает продукт раньше срока, то он может начать ускорять остальные процессы.
В моей практике все заказчики коммерческого сектора приходят с запросами "нужно было вчера, чем быстрее - тем лучше".
Отсюда и вывод, что им это тоже выгодно.
Если под "идея дать денег разработчику" подразумевается премия, то она тоже выписывается, но реже.
Мы предпочитаем индексирование ЗП - это эффективнее и понятнее.
По крайней мере у нас всех устраивает такой подход :)
Пару лет пытаюсь воспользоваться "рынком соискателя", да всё как-то не получается. Хотя стек самый распространенный, плюс освоен модный ныне фреймворк. И опыта уже 3+ - самый сок. Так что "все не так однозначно".
Если расскажете чуть подробнее о вашем стеке и фреймворке - возможно,
что смогу дать рекомендации.
Но самое вероятное - ваш стек "узкий" и как итог компаний, которые готовы вас принять, будет не очень много и в них высокий порог входа.
Как пример,
для ООО "Ромашка" у вас не хватает навыков из смежных областей (там часто хотят кросс-возможности, например фулл-стек, бек + DevOps и т.п.),
а для IBM у вас не хватает уровня - им нужны узкопрофильные Боги Разработки.
Вот и получается "мертвая долина", где, вроде бы навыки у вас есть, но ощущение, что они никому не нужны.
Да просто таких как Вы легион. Войти в ИТ. И на собесах происходит отсев. Вы, условно, джун, а зарплату хотите как мидл. Вот и вся неоднозначность.
Частично с вами соглашусь.
Действительно, джунов с ожиданиями по ЗП как у мидлов - прорва.
Ожидания "входа в ИТ" начинаются от 150к, даже если это интерн полный, которого еще учить и учить.
Но не всегда дело в этом.
Еще бывает:
1) Нецелевой стэк технологий.
Если вы умете в Java, а нужен С++, то вы не нужны.
Если в компании используется фрейм 1, а вы знаете фрейм 2, то вас не возьмут.
Никто не хочет вкладываться в обучение сотрудника, потому что есть страх "обучится и уйдет".
2) HR со странностями.
Данный персонаж оценивает соискателя не по навыкам,
а по тому, нравитесь вы ему или нет.
Половину вопросов такой HR не понимает, другую половину перефразирует во что-то типа
"HTML знаете?
Вот вам листочек - напишите страницу"
или
"Java знаете? Значит JavaScript вам близок" :)
3) Руководитель с детской травмой.
Тоже встречается на просторах вселенной случай, когда руководитель боится брать более скилловых подчиненных.
На мой взгляд должно быть наоборот, ведь руководитель по определению "широкий спец", который "в глубину" не умеет, у него задачи другие.
Вот и получается, что он набирает "слабеньких", чтоб на их фоне быть "умным".
В этом случае, чем выше ваш уровень - тем ниже шанс быть принятым на работу.
Любопытно. Опять всё про софты и героическое спасение мира жертвами людей и ничего про организацию.
Спасибо
Спасибо за комментарий.
А как на ваш взгляд должна быть построена организация процесса?
Исходя из финансовой направленности вашей деятельности - было бы интересно выслушать ваш взгляд на эту проблему.
Я только что, 2 часа назад, выдал 7 рабочих техник, как диагностировать проблемы в организации и перестраивать организацию, чтобы люди не выгорали
Но меня здесь заминусовали.
Так что никак. Ссылки не приведу. Хотя у меня примерно ещё 7 публикаций есть в схожей теме.
Посмотрю )
Прочитал, действительно хорошая публикация.
Если кто-то будет читать коменты, то рекомендую ознакомиться со статьей автора:
https://habr.com/ru/articles/851506/
Сложно воспринимается, но статья по делу и хорошо дополняет мои выводы о трендовых системах мотивации сотрудников.
Спасибо.
Да, статью я вернул, как видели
У меня, в принципе требования к читателю высокие.
И это по плану был лонгрид на 60+ минут чтения с кучей прочих вещей. Но Хабр недавно поломал свой редактор, потому лонгриды очень долго редактировались. И пока Хабр чинил, я уже часть повесил про бредовую идею, решил и это выложить кусочком
Я только Маслоу в реале не отрабатывал.
Новые тенденции в управлении персоналом