Да, для того чтобы вкладывая в них время и деньги, со временем получить хороших спецов. Джуны — инвестиции в будущее. Если вы растете — необходимые инвестиции.
Если у вас джуны приносят прибыль с места возможны 3 варианта.
Вы и ваша компания научилась сверхбыстро адаптировать джунов так, чтобы они быстро и хорошо решали задачи. Тогда ваша компания должна быть лидером рынка и зарабатывать много денег.
Вы даете джунам самые простые задачи и таких задач у вас много. Тогда вы занимаетесь чем то не особо сложным.
Вы не считаете косвенные затраты на работу джуна. Тогда наверное получается что на регулярах и сеньорах вы получаете прибыль меньше.
Есть ещё один вариант — вы лукавите) Но я даже боюсь представить, зачем это вам может быть нужно.
Вы ошибаетесь насчёт внешнего заказчика. Они зачастую сами не могут сформулировать требования для водопада (или меняют их постоянно, что суть то же самое), поэтому приходится работать итерациями. Поэтому итеративная разработка набирает популярность, даже в гос.проектах(!)
С точки зрения прагматизма большого бизнеса все так.
Но хочется построить команду единомышленников, а не очередную бюрократическую машину. И эффективность выше и работать приятнее.
1. Уверен, что существуют разные точки зрения на эту проблему. Не думаю что одна статья, даже такого замечательного человека, сможет меня переубедить. Я уверен, что разработчики должны видеть картину в целом и понимать смысл.
2. Вы сейчас с легкой руки сравнили разработчиков и токарей, совершенно забыв, что в работе разработчика неопределенности на порядки больше. Уверен, что токарям крайне редко ставят задачу — «посмотри как мы делали это год назад в другом проекте и сделай также, что нужно поменяй». Я немного работал на заводе, и знаю как там все устроено.
3. Я сам довольно долго считал, что достаточно четко поставить задачу — а дальше пусть разбираются. Этот подход раз за разом приносил мне разочарование в человечестве. А вот когда я стал объяснять людям смысл — все заиграло другими красками.
Руководители не хотят учить разработчиков, а хотят чтобы проект запилили быстро — статья призывает их заняться обучением. Выделять время. Тратить деньги бизнеса.
Руководитель сам "знает" как что делать — статья призывает прислушаться к разработчикам.
Руководитель хочет сам принимать решения — статья призывает его делегировать разработчикам. Предварительно добившись от них понимания и осознанности.
Руководитель хочет ставить задачи — а статья призывает его воспитывать в людях правильные установки.
Это вовсе не мелкие исключения, как мне кажется. Это дополнительная и непростая работа, особенно для тех, кто привык только "руками водить".
С другой стороны, может быть кто-то напишет статью — про карьеру руководителя глазами разработчика, и в ней будет несколько другой фокус.
У нас сейчас обучение имеет непрерывный характер. Мы постоянно формируем группы и чему-то их учим. Новые разработчики в обязательном порядке проходят первичное обучение. В общем готовимся заранее.
С пунктом 1 согласен на 99%.
С пунктом 2 — не согласен совсем. Дело не в гуманности. Я обучаю своих людей, чтобы они были более эффективны, быстрее и лучше решали поставленные задачи. Кроме того, это ценится разработчиками, а значит они более охотно будут со мной работать. А к конкурентам кто угодно может уйти и без обучения, таков сегодня рынок труда.
Здесь все упирается в качество планирования. И на мой взгляд короткий спринт спланировать проще, чем разработку на полгода. Соответственно и вернуть техдолг также проще, просто надо про него не забывать (что происходит сплошь и рядом).
Кроме того, существует вариант пригласить профессиональных разработчиков, которые под ключ разработают уникальное решение.
Ну как неважно? Вы же сравниваете жизнь IT-специалиста? Значит налоги интересны не любого гражданина, а именно IT-специалистов. Верно?
Обычная IT-организация от 7 человек в России будет на этом льготном режиме в 99% случаев. Это необходимо учитывать.
В РФ есть налоговые льготы IT организациям, суммарный налог с ними получается примерно 21% если я не ошибаюсь. 13% НДФЛ и на прочее процентов 8.
Скажите пожалуйста пару слов — почему нет выделенных QA и DevOps?
Прошу прощения за любопытство — а подпроцессов в битриксе нет? Они по идее должны повышать уровень абстракции и упрощать схему визуально.
Да, для того чтобы вкладывая в них время и деньги, со временем получить хороших спецов. Джуны — инвестиции в будущее. Если вы растете — необходимые инвестиции.
Если у вас джуны приносят прибыль с места возможны 3 варианта.
Есть ещё один вариант — вы лукавите) Но я даже боюсь представить, зачем это вам может быть нужно.
Вы ошибаетесь насчёт внешнего заказчика. Они зачастую сами не могут сформулировать требования для водопада (или меняют их постоянно, что суть то же самое), поэтому приходится работать итерациями. Поэтому итеративная разработка набирает популярность, даже в гос.проектах(!)
Но хочется построить команду единомышленников, а не очередную бюрократическую машину. И эффективность выше и работать приятнее.
2. Вы сейчас с легкой руки сравнили разработчиков и токарей, совершенно забыв, что в работе разработчика неопределенности на порядки больше. Уверен, что токарям крайне редко ставят задачу — «посмотри как мы делали это год назад в другом проекте и сделай также, что нужно поменяй». Я немного работал на заводе, и знаю как там все устроено.
3. Я сам довольно долго считал, что достаточно четко поставить задачу — а дальше пусть разбираются. Этот подход раз за разом приносил мне разочарование в человечестве. А вот когда я стал объяснять людям смысл — все заиграло другими красками.
Это вовсе не мелкие исключения, как мне кажется. Это дополнительная и непростая работа, особенно для тех, кто привык только "руками водить".
С другой стороны, может быть кто-то напишет статью — про карьеру руководителя глазами разработчика, и в ней будет несколько другой фокус.
У нас сейчас обучение имеет непрерывный характер. Мы постоянно формируем группы и чему-то их учим. Новые разработчики в обязательном порядке проходят первичное обучение. В общем готовимся заранее.
В этой статье ничего нет про работу за опыт без денег. Вы к чему это пишете?
Вот я здесь в России, не в Москве. И у нас тут конкуренция огого.
С пунктом 1 согласен на 99%.
С пунктом 2 — не согласен совсем. Дело не в гуманности. Я обучаю своих людей, чтобы они были более эффективны, быстрее и лучше решали поставленные задачи. Кроме того, это ценится разработчиками, а значит они более охотно будут со мной работать. А к конкурентам кто угодно может уйти и без обучения, таков сегодня рынок труда.
del
Я такого не говорил, это вы сами. Но с другой стороны, разработчику полезно быть востребованным, это конвертируется в деньги.