Набирая It-специалистов для решения разного рода задач, компании или департаменты стараются брать от middle и выше, казалось бы, это удобно. Вот придёт такой человек в компанию, рассказали о структуре - он вник в структуру, разъяснили как коммуницировать - коммуницирует, описали задачу - сразу приступит к работе над своим блоком и решает. В том числе и все имеющиеся подзадачи - закрывает, и кампания (департамент / компания) идет семимильными шагами к релизу продукта. А потом?!

Но где их набраться, таких специалистов, которые сразу станут не только "пломбировочным материалом в дырах проекта", но и в дальнейшем станут заниматься развитием проекта!?

На такие задачи есть HR-мудрецы!, - скажете Вы.

Да. Они могут найти решение, но им заявку кто подаёт?! Тот кому нужны ответы на вопросы: Сможешь? - Смогу. Как..? - Вот так. Ок, берём.

В последствии получаем результаты нечитаемости кода, решает только узкий круг задач, не вникает в проект целиком и подобное... Кейсовое мышление, привело к узко мыслящим специалистам.

А! А, разносторонние интересы = ширина взглядов!!!

Разносторонние интересы = ширина взглядов.

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

Далее примерно так:

1. одобрение персонажа, которого как правило долго ищут (что влияет на сроки реализации задачи);

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

3. хотя и другие варианты есть, но я не про это.`

А вот про что, вернее кого…

Берём junior специалиста. И именно специалиста - Да он спец, просто без опыта. Страх, что он будет тянуть кампанию вниз или замедлять её работу - оставьте блогерам, это их "хлеб". Важно! - берём такого, который уверен, что выбрал для себя правильный путь развития, сферу деятельности, тут как раз HR-магия выявить такого поможет, они это хорошо умеют делать (если они не случайные люди в этой важной профессии).

Когда этот профессионал Junior (ProfiJun) к ИТ плюсом имеет опыт не смежной работы, а увлечения из совсем другой сферы, то это клад.

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

А если для начала его энергию пустить в другое русло, Он больше напоминает чистый проверочный код JuniORtestCode.

И вот уже не так печально выглядит начинающий, ведь начинающий - это человек, который придёт к вам в команду с новым взглядом, ведь он может дать новый вариант решения. Очень важно, чтобы ему верно объяснили задачу, саму идею проекта и дали возможность нарисовать её в голове.

Наверняка, знаете историю с изобретением матового света, когда специалисты знали, что это невозможно, а новичок просто взял и сделал…

Не рассказать ему, как вы (команда) пришли к тому что есть, а рассказать идею, которую реализуете. Не загромождать его голову всеми этапами в хронологическом порядке с самого начала проекта, когда высказывали различные мнения и "лучшие" мнения, остались в голове у каждого в группе.

Особенно полезна роль Junior-а будет в группе, если он приходит не в самом начале проекта, а в середине проекта и для того, чтобы ему начать работать над проектом, ему нужно изучить имеющийся материал. А именно всё, что написано ранее: инструкции, документацию процессов, к этому нужно установить на свой новый П.К. какие-то программы, нужно запустить какие-то тесты и человек как конечный пользователь, но только имея опыт программирование, в отличии от конечного пользователя, начинает разбираться в программе как более продвинутый, глубоко понимающий пользователь и, видя какие-то нестыковки, начинается. Сообщать об этом своему наставнику / куратору.

И вот тут его «свежий взгляд» и отсутствие «установок от команды» принесут огромную пользу.

Вот здесь, на мой взгляд, лучше письменно декларировать поток мыслей, это позволит и опытному специалисту прочитав, осмыслить, взглянуть со своей точки зрения на то, что увидел junior, как специалист другого уровня.

Вы ведь тоже когда-то были начинающими.

Основной посыл — это изменение отношения к Junior специалистам, их лучше нагружать задачами иного толка, чем копирование имеющегося специалиста(ов), конечно если это, неосновная задача руководителя и / или HR. Junior – младший, он незагружен задачами как другие, но имеет знания как видеть нужное или замечать ненужное и имеет возможность приносить пользу всему проекту в реальном времени.

Junior разработчик – эдакий специалист-критик, но не тот, который говорит: "Всё плохо, надо по-другому", а на вопрос "Как?" - отвечает: "Вы спецы вам и думать", опуская уровень духа кампании. А вот именно тот критик, который предлагает иные варианты, своего видения, решения имеющихся задач, своим взглядом созидателя, инженера, творца.

Можно поругать... Можно покритиковать... Можно воспользоваться!

Вам решать.

Этот пост с надеждой на качественный рост. Всех компаний и профессионалов.

Успехов всем нам!