Как мы учили студентов закрывать шторы: чему наставников научила командная стажировка
Летом 2025 года семь студентов прошли трехмесячную стажировку в Учебном центре НТЦ "Вулкан". Перед ними стояла практическая задача - разработать программно-аппаратный комплекс для дистанционного управления рулонными шторами в офисе.
На первый взгляд проект выглядел не слишком сложным: нужно было заставить шторы открываться и закрываться без ручного управления. Однако за этой бытовой функцией скрывался полноценный инженерный проект: требовалось продумать электрическую схему, подобрать компоненты, написать программное обеспечение для микроконтроллера, спроектировать корпус, организовать взаимодействие между участниками и довести решение до работоспособного прототипа.
В этой статье наставники рассказывают, как была организована стажировка, какие ошибки удалось обнаружить и почему иногда лучший способ научить студентов - не давать им готовых инструкций.
Зачем компании нужна командная стажировка
Стажировки в НТЦ "Вулкан" - это не только образовательная программа. Компания рассматривает их как способ найти перспективных специалистов и дать студентам возможность попробовать себя в реальной проектной среде. Участники работают над конкретной задачей, учатся взаимодействовать с коллегами, а наиболее успешные по итогам стажировки могут получить предложение о постоянной работе.
В 2023 году компания впервые провела командную стажировку. Студентов объединили в группы, каждой группе назначили отдельный проект и наставников. Наставники отвечали за результат и фактически руководили всей работой.
Такой подход позволил довести проекты до конца, но выявил серьезную проблему: участники почти не научились самостоятельности. После трудоустройства они продолжали ждать подробных указаний - что именно делать, в каком порядке и каким способом. Иными словами, наставники слишком сильно контролировали процесс и не оставили студентам пространства для принятия решений.
В 2024 году формат изменили: у каждого участника появился собственный проект и персональный наставник. Студенты получили больше свободы, однако возникла другая сложность - им было трудно включаться в командную работу и учитывать интересы коллег.
В 2025 году решили объединить оба опыта. Командную модель сохранили, но заранее распределили проектные роли. В группе появились схемотехники, разработчик программного обеспечения, дизайнер 3D-моделей, системный аналитик и специалист по инфраструктуре. Руководителем проекта назначили одного из студентов - его лидерские качества оценивали еще на собеседовании.
Наставники отказались от роли руководителей, которые постоянно раздают поручения. Их задача заключалась в другом: задавать вопросы, помогать увидеть риски, направлять обсуждение и вмешиваться только тогда, когда команда действительно заходила в тупик.
Как выбрали тему проекта
При выборе задания учитывали сразу три критерия.
Во-первых, проект должен был позволить студентам применить теоретические знания на практике. Университетская подготовка дает фундамент, но далеко не всегда учит собирать реальные устройства, учитывать ограничения компонентов и доводить разработку до рабочего состояния.
Во-вторых, задача должна была быть интересной. Монотонная работа редко вызывает у начинающих специалистов желание самостоятельно разбираться в проблемах и искать нестандартные решения.
В-третьих, результат должен был иметь практическую ценность для компании. Так появилась идея автоматизировать управление рулонными шторами в офисе.
Сейчас шторы открываются и закрываются вручную. Автоматизированная система должна была сделать управление удобнее, сократить количество ручных операций и стать полноценным учебным полигоном для студентов.
Почему в команде было семь человек
После оценки предполагаемого объема работ стало понятно, что один или два разработчика с задачей не справятся. Проект объединял несколько направлений, каждое из которых требовало отдельной компетенции.
Три места выделили под схемотехническую часть. Это объяснялось не только объемом работы, но и спецификой подготовки студентов: практический опыт проектирования и сборки электронных устройств встречается значительно реже, чем базовые знания программирования.
За программную часть отвечал один участник - предполагалось, что у него уже есть опыт разработки решений для микроконтроллеров.
Отдельно потребовался дизайнер 3D-моделей. Рабочее устройство должно было получить корпус, который защищает электронику, удобно устанавливается и выглядит аккуратно. Даже простой прототип нельзя считать завершенным, если все его компоненты лежат на столе и соединены проводами.
Еще одну роль отвели системному аналитику. Он должен был помогать команде формулировать требования, описывать сценарии использования и связывать аппаратную и программную части проекта в единую систему.
Руководитель проекта из числа студентов
Одним из главных экспериментов стало назначение студентского руководителя проекта. Раньше всю координацию брали на себя наставники, поэтому участники привыкали работать по готовому плану. В этот раз план предстояло создать самостоятельно.
Руководитель должен был организовать встречи, распределять задачи, отслеживать сроки, фиксировать договоренности и помогать команде разрешать конфликты. При этом формальных полномочий у него почти не было: он не являлся начальником остальных участников и не мог просто приказать выполнить работу.
Это создавало реалистичную рабочую ситуацию. В большинстве инженерных команд руководителю приходится добиваться результата не только за счет технических знаний, но и благодаря коммуникации, аргументации и умению договариваться.
Наставники намеренно не исправляли каждую ошибку сразу. Если студенты выбирали не самый эффективный путь, им предлагали самостоятельно оценить последствия. Такой подход требовал терпения: иногда быстрее было дать готовое решение, но тогда образовательный эффект оказался бы слабее.
От постановки задачи к первым результатам
В начале команда должна была самостоятельно уточнить, каким именно должно быть будущее устройство. Формулировка "управлять шторами дистанционно" слишком расплывчата. Необходимо было определить:
- каким способом будет передаваться команда;
- сколько штор сможет обслуживать система;
- нужно ли управлять каждой шторой отдельно;
- какие датчики понадобятся;
- как устройство будет питаться;
- где разместится электроника;
- что произойдет при отключении электричества;
- как пользователь поймет, что команда выполнена.
Именно на этом этапе проявляется разница между учебной задачей и настоящим проектом. В учебной работе условия обычно заданы заранее. В реальной разработке значительную часть времени занимает формирование самих требований.
Постепенно команда разделила проект на блоки. Схемотехники занялись силовой частью, приводами, защитой и подключением компонентов. Программист разрабатывал логику управления и обмен данными. Аналитик описывал сценарии использования и согласовывал интерфейсы между направлениями. Дизайнер проектировал корпус с учетом размеров платы, двигателя и креплений.
Что пошло не по плану
Почти сразу выяснилось, что разные участники по-разному понимают результат. Для одного человека готовым считался работающий мотор, для другого - собранное устройство с корпусом, а для третьего - полностью оформленный прототип с понятным сценарием управления.
Подобные разночтения часто становятся причиной задержек. Поэтому наставникам пришлось мягко возвращать команду к конкретным критериям готовности. Проект нельзя считать завершенным, если отдельные детали работают поодиночке, но не образуют единую систему.
Возникали и технические проблемы: не хватало точных данных о нагрузке, требовалось проверять совместимость компонентов, уточнять размеры и искать компромисс между надежностью, стоимостью и скоростью изготовления.
Наиболее полезными оказались не отдельные советы наставников, а регулярные обсуждения. Во время встреч студенты учились объяснять, почему выбрали конкретное решение, какие у него ограничения и что потребуется изменить при возникновении новых требований.
Чему научились студенты
Главный результат стажировки - не только созданный прототип. Участники получили опыт полного инженерного цикла:
1. анализа исходной задачи;
2. формирования требований;
3. распределения ролей;
4. проектирования аппаратной и программной частей;
5. сборки и тестирования;
6. поиска неисправностей;
7. подготовки демонстрации;
8. презентации результата.
Кроме технических навыков, студенты столкнулись с менее очевидными сторонами работы: необходимостью документировать решения, соблюдать договоренности, сообщать о проблемах заранее и учитывать зависимость своей задачи от работы коллег.
Для начинающего специалиста это особенно важно. В реальном проекте недостаточно быть хорошим программистом или инженером. Нужно уметь работать в условиях неполной информации, задавать вопросы, просить помощь и принимать ответственность за результат.
Чему научились наставники
Наставники также пересмотрели собственные представления о стажировках. Оказалось, что самостоятельность нельзя просто объявить требованием. Ее необходимо постепенно формировать.
Если студенту сразу предоставить полную свободу, он может потратить много времени на неверный путь. Если же постоянно подсказывать и контролировать каждый шаг, участник быстро привыкает к роли исполнителя. Поэтому важен баланс между поддержкой и самостоятельным выбором.
Еще один вывод касается состава команды. Даже сильные специалисты не всегда образуют эффективную группу. Важно заранее определить зоны ответственности, договориться о правилах коммуникации и назначить человека, который будет следить за общим движением проекта.
Полезно также оценивать не только индивидуальные знания, но и способность кандидата объяснять свои мысли, принимать обратную связь и договариваться. В командной разработке эти качества иногда оказываются важнее уже имеющегося опыта.
Практические рекомендации для будущих стажировок
Организация подобной программы требует значительной подготовки. До старта стоит заранее определить критерии успеха, предполагаемый объем работ, доступные ресурсы и формат отчетности.
Не менее важно подготовить промежуточные контрольные точки. Финальная демонстрация не должна быть первым моментом, когда наставники видят результат. Регулярные проверки позволяют обнаружить проблемы, но не превращают работу студентов в постоянный контроль.
Для каждой роли полезно составить зону ответственности, однако не следует изолировать участников друг от друга. Схемотехник должен понимать ограничения программной части, программист - особенности электроники, а дизайнер - требования к размещению компонентов.
Отдельное внимание необходимо уделить документации. Даже короткие описания интерфейсов, схем подключения, принятых решений и найденных проблем существенно упрощают взаимодействие и помогают команде не возвращаться к одним и тем же вопросам.
В итоге проект про автоматическое управление шторами оказался гораздо масштабнее, чем предполагалось в начале. Он стал проверкой не только технических навыков студентов, но и способности команды самостоятельно организовать работу. А для наставников стажировка превратилась в эксперимент по поиску правильного баланса между руководством и свободой.
Иногда, чтобы научить человека хорошо выполнять задачу, нужно не закрывать шторы за него, а лишь показать, где находится кнопка - и дать возможность самому разобраться, когда и зачем ее нажимать.
