Набирая It-специалистов для решения разного рода задач, компании или департаменты стараются брать от middle и выше, казалось бы, это удобно. Вот придёт такой человек в компанию, рассказали о структуре - он вник в структуру, разъяснили как коммуницировать - коммуницирует, описали задачу - сразу приступит к работе над своим блоком и решает. В том числе и все имеющиеся подзадачи - закрывает, и кампания (департамент / компания) идет семимильными шагами к релизу продукта. А потом?!
Но где их набраться, таких специалистов, которые сразу станут не только "пломбировочным материалом в дырах проекта", но и в дальнейшем станут заниматься развитием проекта!?
На такие задачи есть HR-мудрецы!, - скажете Вы.
Да. Они могут найти решение, но им заявку кто подаёт?! Тот кому нужны ответы на вопросы: Сможешь? - Смогу. Как..? - Вот так. Ок, берём.
В последствии получаем результаты не читаемости кода, решает только узкий круг задач, не вникает в проект целиком и подобное... Кейсовое мышление, привело к узко мыслящим специалистам.
А! А, разносторонние интересы = ширина взглядов!!!
Разносторонние интересы = ширина взглядов.
Программисты народ логичный и когда возникает задача - её начинают решать привычным способом, а именно - путем наименьшего сопротивления. То есть, взять в команду сильного специалиста:
со знанием необходимых библиотек и умением применять их в проектах.
а точнее сказать, применяемых в данном проекте, который одобряет своими знаниями ведущий команды (TeamLid).
начинается приращивание со своими знаниями собеседуемого, который имеет своё мнение, но плюшки от компании ему нравятся, и он надеясь что изменится, иногда подавляет "истинного себя", рассказывает о "новом себе" которым даже не хотел быть, а то что хочет услышать собеседник.
Далее примерно так:
одобрение персонажа, которого как правило долго ищут (что влияет на сроки реализации задачи);
ещё бывает что спец - дороже чем планировали (и это я сейчас не бОльшей сумме за его умения, а о том что спец "дешевле" чем предлагают;
хотя и другие варианты есть, но я не про это.`
А вот про что, вернее кого…
Берём junior специалиста. И именно специалиста - Да он спец, просто без опыта. Страх, что он будет тянуть кампанию вниз или замедлять её работу - оставьте блогерам, это их "хлеб". Важно! - берём такого, который уверен, что выбрал для себя правильный путь развития, сферу деятельности, тут как раз HR-магия выявить такого поможет, они это хорошо умеют делать (если они не случайные люди в этой важной профессии).
Когда этот профессионал Junior (ProfiJun), к ИТ плюсом имеет опыт не смежной работы, а увлечения из совсем другой сферы, то это клад.
Такой знает чего хочет, какую науку двигать и понять её хочет, он знает теорию и не обременён опытом стереотипов. Он не специалист, который ничего больше не знает - кроме как кодить и мыслить математикой (кстати, это очень неплохо), а но как и Ломоносов, и Кулибин, и Королев, и Калашников и многие другие, у него нет предобученного отношения к решению задач, у него ещё нет своей стилистики. Но у него уже горит пламя идеей внести весомый вклад в дело, надо себя показать. Вот он и нужен.
А если для начала его энергию пустить в другое русло, Он больше напоминает чистый проверочный код JuniORtestCode.
И вот уже не так печально выглядит начинающий, ведь начинающий - это человек, который придёт к вам в команду с новым взглядом, ведь он может дать новый вариант решения. Очень важно чтобы ему верно объяснили задачу, саму идею проекта и дали возможность нарисовать её в голове.
Наверняка знаете историю с изобретением матового света, когда специалисты знали, что это невозможно, а новичок просто взял и сделал…
Не рассказать ему как вы (команда) пришли к тому, что есть, а рассказать идею, которую реализуете. Не загромождать его голову всеми этапами в хронологическом порядке с самого начала проекта, когда высказывали различные мнения и "лучшие" остались в голове у каждого в группе.
Особенно полезна роль Junior-а будет в группе если он приходит не в самом начале проекта, а в середине проекта и для того, чтобы ему начать работать над проектом, ему нужно изучить имеющийся материал. А именно всё что написано ранее: инструкции, документацию процессов, к этому нужно установить на свой новый П.К. какие-то программы, нужно запустить какие-то тесты и человек как конечный пользователь, но только имея опыт программирование, в отличии от конечного пользователя, начинает разбираться в программе как более продвинутый, глубоко понимающий пользователь и, видя какие-то нестыковки, начинается. Сообщать об этом своему наставнику / куратору.
И вот тут его «свежий взгляд» и отсутствие «установок от команды» принесут огромную пользу.
Вот здесь, на мой взгляд, лучше письменно декларировать поток мыслей, что позволит и опытному человеку прочитав осмыслить, взглянуть со своей точки зрения на то. Что Джун пишет?
Вы ведь тоже когда-то были начинающими.
Основной посыл — это изменение отношения к Junior специалистам, их лучше нагружать задачами иного толка, чем копирование имеющегося специалиста(ов), конечно если это не основная задача руководителя и / или HR. Junior – младший, он не загружен задачами как другие, но имеет знания как видеть нужное или замечать ненужное и имеет возможность приносить пользу всему проекту в реальном времени.
Junior разработчик – эдакий специалист-критик, но не тот, который говорит: "Всё плохо, надо по-другому", а на вопрос "Как?" - отвечает: "Вы спецы вам и думать", опуская уровень духа кампании. А вот именно тот критик, который предлагает иные варианты, своего видения, решения имеющихся задач, своим взглядом созидателя, инженера, творца.
Можно поругать... Можно покритиковать... Можно воспользоваться!
Вам решать.
Этот пост с надеждой на качественный рост. Всех компаний и профессионалов.
Успехов всем нам!
