Информирование новичков при приеме на работу
Компаниям, работающим в сфере ИТ, так или иначе приходится сталкиваться с поиском новых кадров. Но, чем бы ни занималась организация, найти готовый персонал, который в курсе всех аспектов и особенностей работы, практически не реально. Какой бы квалифицированный «новичок» не пришел на заявленную вакансию, его придется обучать или хотя бы вводить в курс дела. Существуют ли пути сделать это максимально быстро и безболезненно?
Информирование включает в себя два процесса. Первый – доведение до новичка информации о том, как принято работать в компании. Кто закупает печенье для кухни, где можно покурить, насколько охотно даются отпуска за свой счет по семейным обстоятельствам. Этот набор гласных или негласных правил часто представляют в виде заученной заранее речи кадрового работника, короткой экскурсии по офису в исполнении секретаря или небольшого сборника «Часто Задаваемых Вопросов» на внутреннем сайте компании.
Вторая, более сложная задача – введение новичка в курс дела относительно работы, на которую его приняли. Эта часть процесса информирования традиционно ложиться на менеджера проектов или руководителей отделов. Им речи учить, к сожалению, бесполезно, ведь, если речь идет о найме квалифицированных сотрудников, то там не такая уж высокая текучка. И каждый раз приходят люди с разными обязанностями (на разные должности).
Кто-то предпочитает тактику «с места в карьер», и, на мой взгляд, это наиболее правильный подход. Человеку дают реальные «боевые» задачи с расчетом на то, что ему поначалу потребуется немного больше времени на их выполнение. В этом случае нужную по ходу дела информацию новичок должен добыть самостоятельно, и для этого ему нужны будут минимальные данные о распределении обязанностей в коллективе. Т.е. какой-то предварительный инструктаж и некое сопровождение в процессе выполнения задачи все-таки нужны. Но совершенно излишним оказывается 100%-ый контроль. Значит, необходимо небольшое, но зарезервированное на новичка время менеджера проекта / прямого руководителя. Такой подход, тестирует не только способности нового сотрудника, но и его коммуникацию с менеджером. Идеальный программист, тестер и т.п., у которого не сложилось общение с руководителем, все равно будет относительно бесполезен, если речь идет о командной работе.
К сожалению, гораздо чаще приходится видеть (и испытывать на собственной шкуре), что поначалу на человека вешают либо никому не интересные, либо вовсе не нужные задачи, а еще и постоянно донимают микроменеджментом, контролируя каждый шаг, вздох и мысль.
На начальном этапе, да и потом в «боевом» режиме нового сотрудника контроль, безусловно, нужен. Но на начальном этапе рекомендуют контролировать даже не то, что он делает, а то, как он это делает, чтобы потом не выяснилось, что на испытательном сроке человек работал в таком темпе, который не выдержит в более далекой перспективе. Кроме того, способ, избранный исполнителем, должен находиться в соответствии с общей политикой команды или организации (в зависимости от уровня, на который пришел человек). Короче, «ложка» в виде нового специалиста, должна быть «к обеду», и она должна уметь общаться с другими составляющими команды.
Мне также доводилось работать в организации, где новичкам в отделах программистов, тестировщиков и технической поддержки предлагалось потратить 2 недели рабочего времени на изучение мануала по существующему софту. Текст был написан вовсе не в жанре fiction, это как-никак было справочное издание. Так что о моральных усилиях, которые приходилось прилагать сотрудникам, чтобы осилить 200-страничную подборку текстов и не заснуть на середине, можно было только догадываться (я устраивалась в ту организацию до введения такого правила, и, будучи техническим писателем, принимала непосредственное участие в создании этого справочника… как вы можете догадаться, стояла задача описания возможностей при отсутствии «растеканий мысли по древу», а не популяризации системы среди массового читателя). Параллельно сотрудник, конечно, мог провести ревизию текста на предмет устаревшей информации, сравнить его с существующей на тот момент версией программы, но о его навыках такое «испытание» не говорило ровным счетом ничего. Конечно, ситуация там была относительно безвыходная – сложная система автоматизации в узкой отрасли, специалистов по которой точно не найти. А запросы в ту же техническую поддержку поступают ежедневно. Причем, если проблема и возникает, то глобальная, где необходимо знание системы. Но я бы, честно говоря, необходимое обучение в виде чтения мануала в данном случае заменила бы, например, на задачу развертывания комплекса на своей же рабочей системе. И админу отдых, и новичку вполне рабочая задача. При этом, если задача «зацепит», то он сам себя мотивирует и на прочтение мануала, и на изучение всех запросов, поступавших ранее в службу поддержки. Плюс набьет шишки, с которыми обращаются заказчики на начальном этапе работы с системой.
