- PVSM.RU - https://www.pvsm.ru -
Это вторая часть истории о маленькой стажировке в маленькой компании. В этой части рассказываю про то, как прошла стажировка 2013 года в действительности относительно разработанного ранее плана, здесь собраны наблюдения и результаты.
Первую часть можно прочитать по этой ссылке [1].
Предыдущая часть статьи была чисто теоретическая. Результатом теоретических измышлений стал план стажировки. Далее нужно было расставить дедлайны готовности каждого из пунктов и воплощать план в жизнь:
Все даты были завязаны на начале стажировки, 1 июля нельзя было никуда подвинуть: ни в сторону июня из-за сессии студентов, ни в сторону сентября, поскольку закончить стажировку планировалось до начала учёбы, и сокращение длительности неминуемо привело бы к снижению её качества.
В этом разделе приведены результаты подготовки к стажировке вплоть до выхода стажёров. Для удобства изложения активности сгруппированы относительно пунктов плана, но с сохранением общего хронологического порядка (почти).
Текст печатного объявления в целом был похож на текст обычной вакансии с той лишь разницей, что мы предлагали оплачиваемую стажировку. В объявлении на матмехе УрГУ был сделан акцент на близости офиса к университетскому корпусу (пешком 2–5 минут).
Наблюдение № 1
Первые отклики выявили потребность студентов в обязательной производственной практике. В результате мы вынуждены были оперативно разбираться и согласовывать, что нужно с нашей стороны для закрытия такой потребности (этот вопрос был полностью делегирован HR'у). Получив ясность по этому вопросу, мы быстро заменили все объявления — в новых написали, что закроем практику для студентов.
Наблюдение № 2
Осознав, что студентам нужна обязательная практика, мы пришли в некоторое уныние. Попробуйте ответить на вопрос: кто будет искать себе практику на лето летом? Вероятно, вы представите себе последних раздолбаев. Так эту картину рисовали и мы. К счастью, спойлер, всё оказалось намного лучше.
Заявки принимались с середины мая по середину июня. Если правильно помню, было много непрофильных заявок (иногородние, 1–2 курс, нетехнические специальности и прочее). Среди кандидатов было 16 человек, подходящих под профиль.
Наблюдение № 3
То, чего мы опасались, когда полностью делегировали телефонные собеседования HR, случилось: в ответах у нас появлялись новые принципы ООП наподобие «полимарксизма», новая топология «все не со всеми» и прочее. К счастью, простая постобработка ответов решала проблему.
Собеседования проводились примерно со сдвигом 3–7 дней, если считать от контакта с HR. На собеседования приглашали на основании данных из опросника и представленного резюме.
Наблюдение № 4
Неискушённые в собеседованиях студенты в своём резюме в ключевые навыки пишут вообще всё, что когда-либо слышали / видели / использовали вне зависимости от степени владения указанным инструментом. Так, если верить резюме, каждый второй пришедший студент обладал всеми этими навыками: HTML, CSS, JavaScript, jQuery, Perl, C++, C, Java, C#, Python, PHP, Assembler, SQL, MS SQL, MySQL, UML, Linux… После третьего собеседования мы поняли, что с этой целью в резюме можно даже не заглядывать.
Приглашение на стажировку или отказ мы давали в течение недели. Во-первых, мы хотели сперва собрать статистику, чтобы понимать средний уровень кандидатов. Во-вторых, хотели набрать наиболее крутых студентов, а до окончания набора ещё оставалось время.
К середине июня мы определились с четырьмя будущими стажёрами. Так выглядела воронка отбора:
Пятого стажёра мы взяли в последнюю неделю июня: он пришёл к нам по рекомендации уже взятого кандидата, миновав общение с HR. В итоге всего на стажировку были взяты пять человек:
Из позитивного: студенты не искали стажировку по двум причинам: думали, что надо выходить сразу после собеседования, а у них учёба-сессия; по каким-то организационным причинам студенты не знали про обязательную летнюю практику. Получилось, что благодаря такой неосведомлённости студентов, мы «подгадали» нужный момент.
Наблюдение № 5
Всех стажёров беспокоили следующие вещи:
- сколько минимально часов нужно будет работать после окончания стажировки;
- можно ли работать в выходные дни;
- можно ли частично работать удалённо.
Так мы отвечали на эти вопросы: нужно ориентироваться на 32 часа, но минимум — 24; можно работать в выходные дни и удалённо.
Наибольшей эффективностью с точки зрения итогового результата оказался ВКонтакте + личные связи: один кандидат, выловленный через социальную сеть, порекомендовал ещё троих.
На втором и последнем месте оказались объявления на матмехе УрГУ — они привели ещё одного стажёра.
В середине июня, когда мы определились только с четырьмя стажёрами, от нас потребовали точное количество будущих стажёров, мотивируя это тем, что мебель и технику нужно заказать заранее. Тут у нас возникла трилемма, поскольку было ещё три кандидата на два потенциальных места — выбор с тремя исходами: никого больше не возьмём, возьмём только одного, возьмём двоих. В итоге оформили заявку на пять рабочих мест — если бы взяли шестого стажёра, то думать над решением проблемы стали бы по факту.
Наблюдение № 6
В маленькой компании с ограниченными ресурсами важно заранее составлять план расходов — нельзя прийти к руководству и сказать, что завтра у нас будет N стажёров и для них нужны рабочие места.
Состав рабочего места стажёра:
Наблюдение № 7
Если явно не указывать точные характеристики заказываемой техники либо не согласовывать выбранную технику, то в итоге можно получить совсем не то, что ожидалось. Нужно учитывать, что между вашей заявкой и её реализацией будет по меньшей мере два человека: один выбирает технику, другой — согласовывает смету, и оба они могут быть далеки от понимания потребностей разработчиков в мощности железа.
В принципе, полученных ноутбуков для обучения и сносной в плане удобства разработки было достаточно.
Череда всяких случайностей, включая «внезапные» экзамены и неготовность рабочих мест, и «несдвигаемое» начало стажировки сдвинулось с первого июля на восьмое, а мы получили ещё одну неделю для подготовки лекций и практики на стажировку.
Получив ноутбуки, стажёры первым делом принялись ставить и настраивать все инфраструктурные вещи. В общей сложности этот процесс занял один-два рабочих дня.
Нам повезло, что все наши стажёры закончили шесть семестров матмеха, поскольку у всех у них были плюс/минус одни и те же «IT-шные» предметы. Все наши стажёры были знакомы с Java на уровне студенческого курса «ООП: Java».
Теоретическую часть решено было разбить на четыре блока:
Я взял на себя два первых пункта, последние два достались коллегам.
В своём проекте мы использовали следующие инструменты:
Прежде чем рассказывать про непосредственно код, нужно было погрузить в процесс разработки. Для этого на лекции было рассказано про каждый из инструментов из списка, его роль в разработке.
Большее внимание, конечно, было уделено Git:
В остальном же рассказ про инструменты был больше похож на сборник рецептов. А работа со всеми инструментами была продемонстрирована на примере нашего проекта. В сумме на эту часть ушло порядка одного рабочего дня.
Неполный список использованной литературы:
На бэкенде у нас был следующий стек технологий:
На тот момент в качестве сервера приложений мы использовали Oracle GlassFish Server, а основным хранилищем была реляционная база PostgreSQL.
С учётом этого был разработан план лекций:
Для закрепления этого материала был подготовлен репозиторий, в котором по шагам добавлялись новые компоненты.
На эту часть теории пришлось, что не удивительно, больше всего времени — больше двух недель. Чистой теории (без учёта практики) получилось около восьми рабочих дней.
Неполный список использованной литературы:
В клиентский стек входили:
Если с jQuery знакомы практически все, а Bootstrap CSS был больше важен верстальщику (в нашем проекте вёрсткой занимался отдельный человек на удалёнке), то по остальным пунктам нужно было дать вводную.
Таким образом, по фронтовой части были следующие темы:
В действительности тема с основами Angular была выжимкой официального руководства разработчика [18] и состояла из кучи мелких тем. Лекция про TypeScript была построена на основе документации [19].
На фронтенд-теорию потребовалось три рабочих дня.
С коллегой договорились о следующих темах:
Также требовалось рассказать про используемые нами инструменты:
Все затронутые аспекты тестирования уложились в два рабочих дня.
Наблюдение № 8
Опытным путём было установлено, что теоретическая тема дольше двух часов подряд даётся стажёрам тяжело. Нужно либо разбавлять практическими задачками, либо дробить большую тему на части и делать перерывы между ними.
Практические задачи были направлены на закрепление теоретического материала и выдавались либо после завершения темы, либо после целого блока.
В инфраструктурном блоке была задача освоиться с git — для этого каждому стажёру был предложен некоторый сценарий создания проекта, который нужно было воспроизвести на своём репозитории (ветки, коммиты, мёрджи, ...).
Для блока бэкенда, как я уже писал выше, был подготовлен репозиторий со скелетом приложения, на котором можно было поделать простые задачи: DI, взаимодействие с базой данных, REST API и прочее.
В качестве практики по Angular предлагалось пройти стандартный туториал [20], но с использованием TypeScript.
Финальная задача заключалась в том, чтобы создать полноценное web-приложение, соединив серверную и клиентскую части. Это приложение необходимо было тестировать с использованием изученных инструментов: JUnit + Mockito для серверной части и Karma + Selenium — для клиентской.
Сложно оценить суммарное время, потраченное на практику; кажется, что в сумме практика заняла две полные рабочие недели, то есть порядка десяти дней.
Наблюдение № 9
Не знаю, ошибкой это было или нет, но, имея некоторый преподавательский опыт за спиной, я подошёл к обучению с разделением на теорию и практику, по аналогии с университетскими парами. Со временем мне показалось, что в некоторых случаях лучше не разделять теорию и практику: рассказываешь что-нибудь, а в это же самое время стажёры решают связанную задачу у себя на ноутбуках.
До начала стажировки в проектном таск-трекере был заведён подпроект «Стажировка», где наставники вели как собственные задачи, связанные со стажировкой (подготовка материалов и задач), так и задачи стажёров, где можно было отслеживать успешность выполнения задач и изучение материала.
Наблюдение № 10
Ведение задач стажировки в таск-трекере делает процесс прозрачнее для всех участников: стажёр видит свой прогресс и прогресс коллег, без дополнительного участия наставника может увидеть, где есть косяки; для наставников таск-трекер становится точкой синхронизации по всем стажёрам, когда можно без проблем восстановить контекст текущей работы каждого из стажёров.
Наблюдение № 11
Студенты привыкли на лекциях слушать, но не задавать вопросы. Поэтому призыв «задавайте вопросы, если что-то непонятно» редко находит отзыв.
Так пришло понимание, что нужно обязательно собирать обратную связь со стажёров, чтобы своевременно исправлять косяки в процессе и подстраивать работу под ребят.
Для сбора обратной связи использовались гугло-анкеты с вопросами по каждому наставнику:
Наставник №2:
Наставник №3:
В первом и третьем случае ничего интересного — никаких выбросов. А вот по второму идём в комментарии к лекциям:
Проблема: часть материала мы не смогли подготовить в достаточно простом изложении, из-за этого возникли проблемы с пониманием.
Решение: дополнительно разобрали часть вопросов на практических задачах.
Весь базовый курс (теория + практика) уложился ровно в месяц. Все пять стажёров слушали одни лекции, решали одни задачи.
Наблюдение № 12
Студенты, приходя на стажировку, часто заявляют о выбранной ими специализации. Например, уверены, что хотят стать backend-разработчиком. При этом лишь единицы по-настоящему понимают, что стоит за выбранной специализацией, и могут объяснить свой выбор. Лишь практические задачи, приближенные к проектным, или непосредственно проектные задачи позволят понять свои возможности и мотивацию.
Спустя месяц стажёров можно было разделить на три группы — backend (2), frontend (2) и QA (1).
Стажёры были готовы начать работу над задачами проекта со второй недели августа. Для них был выделен целый модуль разрабатываемой системы со своими server- и client-side.
С этого момента они покинули песочницу «Стажировка» нашего таск-трекера и влились в работу над основным проектом: начали принимать участие в проектных митингах, вникать в детали проекта, общаться с менеджером проекта и аналитиками.
Кто-то из стажёров заговорил об этом в конце июля, кто-то — в начале августа. Перед началом учебного года 4/5 наших стажёров захотели в конце августа уйти в отпуск.
Наблюдение № 13
У стажёра, в отличие от сотрудника, принимаемого на испытательный срок, есть несколько особенностей: он не привык работать по полгода (а то и дольше) пять дней в неделю, у него есть учёба, приоритет которой выше, часто он рассматривает работу в компании, как источник опыта, а потом уже — денег.
Не скрою — для нас было очень важно удержать студентов после прохождения стажировки, поэтому мы понимали, что нужно поддерживать их лояльность как к нам (наставникам), так и к компании. К счастью, мы смогли это донести до руководства компании, поэтому все стажёры благополучно ушли по отпускам. Дополнительным условием с нашей стороны стало автоматическое продление стажировки на две недели.
Незадолго до окончания стажировки в день выхода из отпуска нас покинул один из стажёров. Просто пришёл и без объяснения причин сообщил, что уходит навсегда.
Вообще говоря, причина такого исхода может быть либо в рабочей плоскости:
либо вне рабочей плоскости (как обычно принято говорить в таких случаях — по семейным обстоятельствам). В нашем случае проблема лежала вне рабочей плоскости.
Наблюдение № 14
Необходимо выстраивать работу со стажёрами таким образом, чтобы не случалось сюрпризов (внезапные расставания, отпуска и прочее): строить планы работ на месяц-два, интересоваться собственными планами стажёра, поддерживать непрерывное общение.
Наиболее распространённый способ вовлечения неопытного разработчика в командную работу — это работа в паре с опытным коллегой. Такой подход имеет существенный недостаток, когда очевидным образом инициатива находится на стороне опытного сотрудника.
В нашем случае не хватало опытных на всех неопытных, поэтому все стажёры были объединены в общую группу для работы над целым модулем системы. В каком-то смысле это было вынужденной мерой, но давало положительные результаты: стажёры учились принимать решения, брать инициативу на себя, формировать свою зону ответственности. При этом наставники контролировали общую работу, верифицировали принимаемые группой решения и проводили code review.
Со временем стажёры научились разбиваться на пары для работы над отдельными частями модуля. Например, один стажёр отвечал за бэкенд какой-либо функциональности, а второй делал для неё фронтенд, при этом совместно работали над разработкой API, рисовали картинки на доске, решали вопросы интеграции с другими частями системы.
Самым большим моим косяком за время стажировки была ситуация, когда я выдал задачу стажёрам со всеми сопутствующими материалами и отлучился на несколько дней. По возвращении выяснилось, что стажёры сами с задачей не справились, а наставники толком в ней не разобрались.
Наблюдение № 15
Важно правильно передать всю необходимую информацию от одного наставника другому на случай длительного отсутствия первого: постановку задачи, все имеющиеся материалы, договорённости по работе и прочее. После возвращения наставника эту же процедуру необходимо проводить в обратную сторону.
Четверо из пяти стажёров успешно прошли стажировку и всех их нам удалось сохранить в команде — как мне кажется, это успех!
В общей сложности у нас вся стажировка заняла 5 месяцев:
Как показала практика, можно вот так собраться и организовать хорошую стажировку. Для этого нужен самый главный ресурс — время, а главное условие для успеха — мотивация наставников. Мотивация может быть любой: научить ребят чему-то хорошему, подготовить кадры со схожими взглядами на разработку и, в конце концов, просто не облажаться.
Все так называемые «наблюдения» являются небольшими выводами сами по себе. Теперь их можно учитывать при планировании. Это здорово уменьшит энтропию. В общем, советы для тех, кто хочет всё держать под контролем.
А напоследок мотивационные опросы!
Автор: gnkoshelev
Источник [21]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/java/249824
Ссылки в тексте:
[1] этой ссылке: https://habrahabr.ru/company/skbkontur/blog/321614/
[2] Apache Maven Documentation: http://maven.apache.org/guides/
[3] «Про Git на пальцах»: https://habrahabr.ru/post/68341/
[4] vitamin: https://habrahabr.ru/users/vitamin/
[5] Оригинальная статья: http://nvie.com/posts/a-successful-git-branching-model/
[6] «Удачная модель ветвления для Git»: https://habrahabr.ru/post/106912/
[7] zloddey: https://habrahabr.ru/users/zloddey/
[8] Continuous Integration: https://martinfowler.com/articles/continuousIntegration.html
[9] The Java Language Specification: http://docs.oracle.com/javase/specs/jls/se7/html/index.html
[10] Java EE 6 Technologies: http://www.oracle.com/technetwork/java/javaee/tech/javaee6technologies-1955512.html
[11] Spring Framework Reference Documentation 3.2.2: https://docs.spring.io/spring/docs/3.2.2.RELEASE/spring-framework-reference/htmlsingle/
[12] Spring in Action 3rd edition: https://www.manning.com/books/spring-in-action-third-edition
[13] Pro Spring 3: http://www.apress.com/us/book/9781430241072
[14] Just Spring Data Access: http://shop.oreilly.com/product/0636920025405.do
[15] Pro Spring MVC: with Web Flow: http://www.apress.com/us/book/9781430241553
[16] Spring Security 3.1: http://shop.oreilly.com/product/9781849518260.do
[17] FreeMarker Documentation: http://freemarker.org/docs/
[18] руководства разработчика: https://docs.angularjs.org/guide
[19] документации: https://www.typescriptlang.org/docs/tutorial.html
[20] туториал: https://docs.angularjs.org/tutorial
[21] Источник: https://habrahabr.ru/post/322096/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.