Срок жизни разработчика в проекте

[metaclass]

Кстати, вот недавно мне еще рассказали странного: средний срок участия разработчика(джуниора, вроде бы?) в проекте - около года. Потом он начинает считать себя опытным и уходит на другую работу, причем никакие стимулы не помогают его задержать.
Из-за этого кольчатые черви-менеджеры и прочие коллаборационисты на службе у бизнеса не желают инвестировать время и ресурсы в обучение работников, что, в свою очередь, приводит к нежеланию делать проекты нормальными способами (отличными от "наговнякать на жабаскриптах силами десятка недоучек то, что в норме можно сделать парой человек и аккуратно")

Лично мне мерещится, что тут причина и следствие перепутаны. Сначала идет экономия, страх за свою задницу и нежелание инвестировать в работников, а потом работники либо деградируют от такого отношения, либо сваливают куда подальше.

Мы тут имеем какой-то вариант на тему трагедии общин - бизнес нещадно эксплуатирует общественный ресурс (вменяемых разработчиков) не поддерживая его самовоспроизводство (в каком угодно виде, самообучения, обучения других, да и вообще тупо физического размножения). Отношения же между бизнесом и разработчиками - это дилемма заключенного, одни не хотят вкладываться в потенциального "изменника", второй видел в гробу интересы бизнеса, потому что у него дома дети не кормлены и жена мозг кушает.

Comments

[eleon.livejournal.com]

М, ты из рассказа про джуниоров выделил ключевые слова, их переосмыслил и выдал свою теорию :)
Все на самом деле так:
1. Уходят джуниоры. Кто поопытней - меняют проекты, но скорее всего останутся в компании.
2. Уходят потому, что их внутренняя оценка своих навыков, основанная на поверхностном знании языка, фреймворка и вообще технологии разработки ПО, находится в конфликте с оценкой остальной команды. Не манагера, не владельца конторы, не заказчика - именно команды.
3. Поверхностных знаний джуниору хватит, чтобы пройти интервью на позицию мида. Их еще недостаточно, чтобы реально качественно выполнять работу мида, но интервью он пройти уже сможет.
4. Джуниоры, в силу молодости, резки, как понос и идут увольняться уже имея оффер от другой конторы. Потому, даже если очень хочется предложить джуниору больше, чтобы не терять человека, которого уже _почти_ обучили, скорее всего предложить вы ничего не успеете.

Есть волшебные конторы, которые умеют грамотно утилизировать джуниоров, удерживая их контрактами и т.п. Остальные. нанимая жуниора, играют в лотерею: успеют обучить или нет, после обучения сумеют удержать или нет.

[alll]

П.4 лечится пересмотром з\п раз в год. С доведением этого факта до работников ещё на стадии оффера. Часть из них по итогу года всё-равно уйдёт, но это уже будет скорее up-or-out, чем тупое жлобство.

[eleon.livejournal.com]

п.4 у жуниоров не лечится, потому что они бегут не столько из-за денег, сколько из-за названия позиции и содержания работы. Потому что, повторюсь оценка себя, как спеца, не совпадает с оценкой команды. Да и с объективной реальностью - тоже.
Опять же, "год" - это средняя температура по больнице. На моей памяти рекордсменом был жуниор, сбежавший через 4 месяца.

[alll]

> бегут не столько из-за денег, сколько из-за названия позиции и содержания работы. Потому что, повторюсь оценка себя, как спеца, не совпадает с оценкой команды.

А это уже п.2. Тоже, кстати частично лечится - просто позицию не называют "юниор" или там "самый глупый человек на свете". :) Например заводится N грейдов (если мало N, то К грейдов :), первые несколько грейдов соотвествует тому, что в обиходе называют "юниор", но при очередной аттестации человеку говорят: вот ты был программист первого грейда, но за год круто вырос, так что теперь будешь программист аж второго грейда и зарплату мы тебе повышаем соотвественно, ну а область ответственности у тебя и так выросла, сам видишь. Если, конечно, человек действительно вырос и оказался нужен. И так N раз. Ну а грейду к энному всё это писькомерство человеку уже и не нужно становится. :)

[nicka-startcev.livejournal.com]

главное забыли.

в вакансии что-то типа "новый проект, новые технологии, удачный дизайн проекта, разработка свежая, с нуля", а на практике выясняется, что у проекта огромный "технический долг", с которым никто не хочет бороться.

но есть волшебные конторы, где такого рода трэш минимален.