Сказ о маленькой стажировке в маленькой компании [Часть II]

Это вторая часть истории о маленькой стажировке в маленькой компании. В этой части рассказываю про то, как прошла стажировка 2013 года в действительности относительно разработанного ранее плана, здесь собраны наблюдения и результаты.

Первую часть можно прочитать по этой ссылке.

Вступление

Предыдущая часть статьи была чисто теоретическая. Результатом теоретических измышлений стал план стажировки. Далее нужно было расставить дедлайны готовности каждого из пунктов и воплощать план в жизнь:

1. Готовим тексты объявлений для поиска (к середине мая).
2. Запускаем объявления по всем выбранным каналам (в середине мая).
3. Немного ждём (все заявки обрабатывает HR в кратчайшие сроки, начать приглашать на собеседования планировали, когда наберётся некоторое количество заявок).
4. HR проводит телефонные собеседования (до середины июня).
5. В середине июня проводим очные собеседования (за неделю-две до начала стажировки).
6. Отбираем по результатам собеседования стажёров (за неделю до начала стажировки).
7. Разрабатываем план лекций с учётом технического уровня стажёров (к началу стажировки).
8. Придумываем практические задачки по каждой теме (в первую неделю стажировки).
9. К началу стажировки готовим ноутбуки для новичков (за день до начала стажировки).
10. Запускаем двухмесячную стажировку (с 1 июля).
11. Следим за прогрессом стажёров (на всём протяжении стажировки).
12. По необходимости разбираем некоторые темы подробнее (на всём протяжении стажировки).
13. В начале сентября подводим итоги стажировки и проводим назначения в команду (в первую неделю сентября).

Все даты были завязаны на начале стажировки, 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… После третьего собеседования мы поняли, что с этой целью в резюме можно даже не заглядывать.

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

Воронка отбора

К середине июня мы определились с четырьмя будущими стажёрами. Так выглядела воронка отбора:

• ?? телефонных собеседований
• 16 заполненных опросников
• 10 очных собеседований
• 4 стажёра

Пятого стажёра мы взяли в последнюю неделю июня: он пришёл к нам по рекомендации уже взятого кандидата, миновав общение с HR. В итоге всего на стажировку были взяты пять человек:

• матмех УрГУ;
• окончили 3-й курс.

Наблюдение № 5

Всех стажёров беспокоили следующие вещи:

• сколько минимально часов нужно будет работать после окончания стажировки;
• можно ли работать в выходные дни;
• можно ли частично работать удалённо.

Так мы отвечали на эти вопросы: нужно ориентироваться на 32 часа, но минимум — 24; можно работать в выходные дни и удалённо.

Про рекламные каналы

Наибольшей эффективностью с точки зрения итогового результата оказался ВКонтакте + личные связи: один кандидат, выловленный через социальную сеть, порекомендовал ещё троих.

На втором и последнем месте оказались объявления на матмехе УрГУ — они привели ещё одного стажёра.

Подготовка рабочих мест

В середине июня, когда мы определились только с четырьмя стажёрами, от нас потребовали точное количество будущих стажёров, мотивируя это тем, что мебель и технику нужно заказать заранее. Тут у нас возникла трилемма, поскольку было ещё три кандидата на два потенциальных места — выбор с тремя исходами: никого больше не возьмём, возьмём только одного, возьмём двоих. В итоге оформили заявку на пять рабочих мест — если бы взяли шестого стажёра, то думать над решением проблемы стали бы по факту.

Наблюдение № 6

В маленькой компании с ограниченными ресурсами важно заранее составлять план расходов — нельзя прийти к руководству и сказать, что завтра у нас будет N стажёров и для них нужны рабочие места.

Состав рабочего места стажёра:

• Разношёрстные ноутбуки с ОС Windows 7 и Windows 8 (не очень мощные процессоры до i-5, 3-4 ГБ ОЗУ)
• Монитор 19"
• Проводные мышь + клавиатура
• Офисный стол
• Офисный крутящийся стул на колёсиках

Наблюдение № 7

Если явно не указывать точные характеристики заказываемой техники либо не согласовывать выбранную технику, то в итоге можно получить совсем не то, что ожидалось. Нужно учитывать, что между вашей заявкой и её реализацией будет по меньшей мере два человека: один выбирает технику, другой — согласовывает смету, и оба они могут быть далеки от понимания потребностей разработчиков в мощности железа.

В принципе, полученных ноутбуков для обучения и сносной в плане удобства разработки было достаточно.

Стажировка

Начало

Череда всяких случайностей, включая «внезапные» экзамены и неготовность рабочих мест, и «несдвигаемое» начало стажировки сдвинулось с первого июля на восьмое, а мы получили ещё одну неделю для подготовки лекций и практики на стажировку.

Настройка рабочего места

Получив ноутбуки, стажёры первым делом принялись ставить и настраивать все инфраструктурные вещи. В общей сложности этот процесс занял один-два рабочих дня.

Лекции

Нам повезло, что все наши стажёры закончили шесть семестров матмеха, поскольку у всех у них были плюс/минус одни и те же «IT-шные» предметы. Все наши стажёры были знакомы с Java на уровне студенческого курса «ООП: Java».

Теоретическую часть решено было разбить на четыре блока:

1. Инфраструктура
2. Бэкенд
3. Фронтенд
4. Тестирование ПО

Я взял на себя два первых пункта, последние два достались коллегам.

Инфраструктура

В своём проекте мы использовали следующие инструменты:

• Apache Maven
• Git / Git Extensions, gitolite
• Jenkins CI
• Nexus OSS
• Redmine

Прежде чем рассказывать про непосредственно код, нужно было погрузить в процесс разработки. Для этого на лекции было рассказано про каждый из инструментов из списка, его роль в разработке.

Большее внимание, конечно, было уделено Git:

• Назначение систем контроля версий, основные типы VCS
• Основные команды для работы с репозиторием
• Организация веток в проекте

В остальном же рассказ про инструменты был больше похож на сборник рецептов. А работа со всеми инструментами была продемонстрирована на примере нашего проекта. В сумме на эту часть ушло порядка одного рабочего дня.

Неполный список использованной литературы:

1. Apache Maven Documentation.
2. Статья «Про Git на пальцах» от vitamin.
3. Оригинальная статья и её перевод — «Удачная модель ветвления для Git» от zloddey.
4. Статья Continuous Integration (Martin Fowler).

Бэкенд

На бэкенде у нас был следующий стек технологий:

• Java 7
• Spring Framework
• Spring MVC
• Spring Security
• Hibernate
• Jackson
• FreeMarker

На тот момент в качестве сервера приложений мы использовали Oracle GlassFish Server, а основным хранилищем была реляционная база PostgreSQL.

С учётом этого был разработан план лекций:

1. Java: вспомнить всё!
2. SOLID, DI и другие акронимы.
3. JEE: не SE единым.
4. web-app: сервер приложений, сервлеты.
5. Spring Framework: основы.
6. JPA: ормизация и хибернизация.
7. Spring MVC: немного о главном.
8. FreeMarker: шаблонизируй это.
9. Spring Security.

Для закрепления этого материала был подготовлен репозиторий, в котором по шагам добавлялись новые компоненты.

На эту часть теории пришлось, что не удивительно, больше всего времени — больше двух недель. Чистой теории (без учёта практики) получилось около восьми рабочих дней.

Неполный список использованной литературы:

1. The Java Language Specification (James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Alex Buckley).
2. Java EE 6 Technologies.
3. Spring Framework Reference Documentation 3.2.2.
4. Spring in Action 3rd edition (Craig Walls).
5. Pro Spring 3 (Clarence Ho, Rob Harrop).
6. Just Spring Data Access (Madhusudhan Konda).
7. Pro Spring MVC: with Web Flow (Marten Deinum, Koen Serneels).
8. Spring Security 3.1 (Robert Winch, Peter Mularien).
9. FreeMarker Documentation.

Фронтенд

В клиентский стек входили:

• TypeScript
• AngularJS
• jQuery
• (Twitter) Bootstrap CSS
• Angular UI (Bootstrap)
• RequireJS
• Ещё некоторое количество библиотечек
• Инструменты для тестирования (о них в следующем блоке)

Если с jQuery знакомы практически все, а Bootstrap CSS был больше важен верстальщику (в нашем проекте вёрсткой занимался отдельный человек на удалёнке), то по остальным пунктам нужно было дать вводную.

Таким образом, по фронтовой части были следующие темы:

1. TypeScript vs JavaScript.
2. AngularJS: основы.
3. AngularJS: директивы.
4. AMD и RequireJS.

В действительности тема с основами Angular была выжимкой официального руководства разработчика и состояла из кучи мелких тем. Лекция про TypeScript была построена на основе документации.

На фронтенд-теорию потребовалось три рабочих дня.

Тестирование ПО

С коллегой договорились о следующих темах:

1. Функциональное тестирование
   1. Модульные тесты
   2. Интеграционные тесты
2. Нефункциональное тестирование
   1. Нагрузочные тесты
   2. Стресс-тесты
   3. Usability-тесты
3. Тестирование изменений
   1. Smoke-тесты
   2. Регрессионные тесты

Также требовалось рассказать про используемые нами инструменты:

• JUnit
• Mockito
• SeleniumHQ
• KarmaJS
• Jasmine

Все затронутые аспекты тестирования уложились в два рабочих дня.

Наблюдение № 8

Опытным путём было установлено, что теоретическая тема дольше двух часов подряд даётся стажёрам тяжело. Нужно либо разбавлять практическими задачками, либо дробить большую тему на части и делать перерывы между ними.

Практические задачи

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

В инфраструктурном блоке была задача освоиться с git — для этого каждому стажёру был предложен некоторый сценарий создания проекта, который нужно было воспроизвести на своём репозитории (ветки, коммиты, мёрджи, ...).

Для блока бэкенда, как я уже писал выше, был подготовлен репозиторий со скелетом приложения, на котором можно было поделать простые задачи: DI, взаимодействие с базой данных, REST API и прочее.

В качестве практики по Angular предлагалось пройти стандартный туториал, но с использованием TypeScript.

Финальная задача заключалась в том, чтобы создать полноценное web-приложение, соединив серверную и клиентскую части. Это приложение необходимо было тестировать с использованием изученных инструментов: JUnit + Mockito для серверной части и Karma + Selenium — для клиентской.

Сложно оценить суммарное время, потраченное на практику; кажется, что в сумме практика заняла две полные рабочие недели, то есть порядка десяти дней.

Наблюдение № 9

Не знаю, ошибкой это было или нет, но, имея некоторый преподавательский опыт за спиной, я подошёл к обучению с разделением на теорию и практику, по аналогии с университетскими парами. Со временем мне показалось, что в некоторых случаях лучше не разделять теорию и практику: рассказываешь что-нибудь, а в это же самое время стажёры решают связанную задачу у себя на ноутбуках.

Workflow-стажировки

До начала стажировки в проектном таск-трекере был заведён подпроект «Стажировка», где наставники вели как собственные задачи, связанные со стажировкой (подготовка материалов и задач), так и задачи стажёров, где можно было отслеживать успешность выполнения задач и изучение материала.

Наблюдение № 10

Ведение задач стажировки в таск-трекере делает процесс прозрачнее для всех участников: стажёр видит свой прогресс и прогресс коллег, без дополнительного участия наставника может увидеть, где есть косяки; для наставников таск-трекер становится точкой синхронизации по всем стажёрам, когда можно без проблем восстановить контекст текущей работы каждого из стажёров.

Обратная связь от стажёров

Наблюдение № 11

Студенты привыкли на лекциях слушать, но не задавать вопросы. Поэтому призыв «задавайте вопросы, если что-то непонятно» редко находит отзыв.

Так пришло понимание, что нужно обязательно собирать обратную связь со стажёров, чтобы своевременно исправлять косяки в процессе и подстраивать работу под ребят.

Для сбора обратной связи использовались гугло-анкеты с вопросами по каждому наставнику:

1. Оцените степень «понятности» лекций Имя_наставника_i (от 0 до 5).
2. Оцените степень интересности лекций Имя_наставника_i (от 0 до 5).
3. Дайте общую оценку лекций Имя_наставника_i.
4. Оцените помощь Имя_наставника_i в разрешении возникающих вопросов (от 0 до 5).
5. Комментарии о Имя_наставника_i.

Специализация

Весь базовый курс (теория + практика) уложился ровно в месяц. Все пять стажёров слушали одни лекции, решали одни задачи.

Наблюдение № 12

Студенты, приходя на стажировку, часто заявляют о выбранной ими специализации. Например, уверены, что хотят стать backend-разработчиком. При этом лишь единицы по-настоящему понимают, что стоит за выбранной специализацией, и могут объяснить свой выбор. Лишь практические задачи, приближенные к проектным, или непосредственно проектные задачи позволят понять свои возможности и мотивацию.

Спустя месяц стажёров можно было разделить на три группы — backend (2), frontend (2) и QA (1).

Проект

Стажёры были готовы начать работу над задачами проекта со второй недели августа. Для них был выделен целый модуль разрабатываемой системы со своими server- и client-side.

С этого момента они покинули песочницу «Стажировка» нашего таск-трекера и влились в работу над основным проектом: начали принимать участие в проектных митингах, вникать в детали проекта, общаться с менеджером проекта и аналитиками.

А мы тут, это, в отпуск собрались

Кто-то из стажёров заговорил об этом в конце июля, кто-то — в начале августа. Перед началом учебного года 4/5 наших стажёров захотели в конце августа уйти в отпуск.

Наблюдение № 13

У стажёра, в отличие от сотрудника, принимаемого на испытательный срок, есть несколько особенностей: он не привык работать по полгода (а то и дольше) пять дней в неделю, у него есть учёба, приоритет которой выше, часто он рассматривает работу в компании, как источник опыта, а потом уже — денег.

Не скрою — для нас было очень важно удержать студентов после прохождения стажировки, поэтому мы понимали, что нужно поддерживать их лояльность как к нам (наставникам), так и к компании. К счастью, мы смогли это донести до руководства компании, поэтому все стажёры благополучно ушли по отпускам. Дополнительным условием с нашей стороны стало автоматическое продление стажировки на две недели.

Иногда они уходят

Незадолго до окончания стажировки в день выхода из отпуска нас покинул один из стажёров. Просто пришёл и без объяснения причин сообщил, что уходит навсегда.

Вообще говоря, причина такого исхода может быть либо в рабочей плоскости:

• проблема в компании;
• проблема в нас (наставниках);
• проблема в стажёре;

либо вне рабочей плоскости (как обычно принято говорить в таких случаях — по семейным обстоятельствам). В нашем случае проблема лежала вне рабочей плоскости.

Наблюдение № 14

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

Работа в команде

Наиболее распространённый способ вовлечения неопытного разработчика в командную работу — это работа в паре с опытным коллегой. Такой подход имеет существенный недостаток, когда очевидным образом инициатива находится на стороне опытного сотрудника.

В нашем случае не хватало опытных на всех неопытных, поэтому все стажёры были объединены в общую группу для работы над целым модулем системы. В каком-то смысле это было вынужденной мерой, но давало положительные результаты: стажёры учились принимать решения, брать инициативу на себя, формировать свою зону ответственности. При этом наставники контролировали общую работу, верифицировали принимаемые группой решения и проводили code review.

Со временем стажёры научились разбиваться на пары для работы над отдельными частями модуля. Например, один стажёр отвечал за бэкенд какой-либо функциональности, а второй делал для неё фронтенд, при этом совместно работали над разработкой API, рисовали картинки на доске, решали вопросы интеграции с другими частями системы.

Из рук в руки

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

Наблюдение № 15

Важно правильно передать всю необходимую информацию от одного наставника другому на случай длительного отсутствия первого: постановку задачи, все имеющиеся материалы, договорённости по работе и прочее. После возвращения наставника эту же процедуру необходимо проводить в обратную сторону.

Итоги стажировки

Четверо из пяти стажёров успешно прошли стажировку и всех их нам удалось сохранить в команде — как мне кажется, это успех!

В общей сложности у нас вся стажировка заняла 5 месяцев:

• 0,5 месяца на согласование и планирование
• 1,5 месяца на поиск стажёров и подготовку
• 1 месяц теоретического обучения и не связанных с проектом задач
• 1 месяц командной работы над модулем системы
• 0,5 месяца на стажёрские отпуска
• 0,5 месяца на подведение итогов, планирование дальнейшей работы.

Выводы

Как показала практика, можно вот так собраться и организовать хорошую стажировку. Для этого нужен самый главный ресурс — время, а главное условие для успеха — мотивация наставников. Мотивация может быть любой: научить ребят чему-то хорошему, подготовить кадры со схожими взглядами на разработку и, в конце концов, просто не облажаться.

Все так называемые «наблюдения» являются небольшими выводами сами по себе. Теперь их можно учитывать при планировании. Это здорово уменьшит энтропию. В общем, советы для тех, кто хочет всё держать под контролем.

А напоследок мотивационные опросы!

Автор: gnkoshelev

Источник