Привет, Хабр!
Предыдущим летом семеро студентов прошли трехмесячную стажировку в Учебном центре НТЦ «Вулкан» с задачей, которая на первый взгляд кажется простой: создать устройство дистанционного управления для рулонных штор в офисном опенспейсе.
В этой статье мы — команда наставников — рассказываем, как был устроен процесс стажировки и каким образом было организовано взаимодействие со стажерами.
В конце будет много‑много выводов, которые сэкономят время тем, кто захочет использовать наш опыт воспитания молодых специалистов (или просто сам впервые возьмется за аппаратный проект). Начнем!
Этап № 0. Подготовка к стажировке
Стажировки в НТЦ «Вулкан» — это своеобразный поиск талантов из числа студентов, которые в реальной проектной среде получают первый опыт самостоятельной работы в команде, и затем наиболее «отличившиеся» заключают с компанией бессрочный трудовой договор.
В 2023 году мы провели первую такую командную стажировку: собрали группы студентов по интересам, определили для каждой группы свой проект, назначили наставников, ответственных за результат и полностью контролировавших процесс, — фактически руководили учебными проектами. Стажеры этого выпуска, к сожалению, так и не научились работать самостоятельно: уже будучи принятыми в штат компании, они ждали четких указаний «что делать?», не проявляли инициативы... Мы сами не дали им пространства для этого.
В 2024 году мы кардинально сменили формат стажировки — теперь у каждого студента был свой наставник и свой проект. Последующее трудоустройство выявило существенные проблемы с их интеграцией в командный формат работы
И вот настал 2025 год. Мы снова вернулись к командной работе, но радикально поменяли подход. Набрали команду так, чтобы у каждого студента была четкая проектная роль: аналитик, схемотехник, разработчик ПО, дизайнер 3D‑моделей, DevOps‑инженер... А главное — роль руководителя проекта впервые отдали студенту, которого выбрали еще на этапе собеседований. Мы не ставили рамок и не диктовали условия. Мы сопровождали, подсказывали, направляли вопросами, но прямо не указывали, что и как делать.
Этап № 1. «А о чем будет стажировка?»
На этапе подготовки стажировки возник вопрос формирования темы. Во‑первых, нам хотелось, чтобы стажировка дала возможность студентам прокачать практические навыки. Сегодня в образовательных учреждениях большое внимание уделяется теоретическому материалу, а стажировка — это отличный шанс на базе полученной теории попробовать себя в решении прикладных задач. Во‑вторых, мы хотели сделать стажировку интересной. Будем честны, никто не хочет делать работу, которая не увлекает. В‑третьих, мы стремились, чтобы результаты стажировки принесли пользу компании. После обсуждений мы согласовали тему, которая отвечала всем нашим критериям. Формально она звучит так: «Создание устройства управления рулонными шторами».
В офисе компании большие окна с рулонными шторами, которые управляются вручную.
Разработка программно‑аппаратного комплекса для их автоматического управления повысила бы уровень комфорта сотрудников и освободила бы от «физической нагрузки» ?
Этап № 2. «В поисках команды»
В любом сложном и комплексном проекте задачи разделяются по направлениям, и наша стажировка не стала исключением. Проанализировав предполагаемый объем работ и специфику, мы предположили, что для реализации проекта потребуется команда из 7 человек с четким разделением ролей и обязанностей.
Поскольку речь шла о создании программно‑аппаратного решения, в первую очередь нужны были схемотехники и разработчики ПО под микроконтроллеры. При этом мы понимали, что задачи по аппаратной части потребуют больше времени и сил. Вузовская подготовка в основном теоретическая, и студенты с реальным опытом сборки схем — редкость. В итоге было решено выделить три места в команде для студентов, которые будут заниматься схемотехнической частью проекта. А вот для реализации ПО выделили одну позицию, изначально ориентируясь на кандидата с опытом разработки подобных решений.
Для того чтобы решение было не только рабочим, но и красивым, открыли позицию дизайнера 3D‑моделей — ведь для готового продукта нужно спроектировать эргономичный корпус.
Чтобы студенты «не потерялись» во всем многообразии задач, добавили позицию системного аналитика с функционалом менторства, то есть в своем роде руководителя всего проекта. Поскольку команда должна была работать в обособленной инфраструктуре, то добавили также роль DevOps‑инженера.
После ряда собеседований была набрана команда стажеров, которым предстояло пройти нелегкий путь от концепции на бумаге до итоговой реализации.
Изначально мы планировали стажировку сроком на 3 месяца, за которую студенты должны были:
провести опрос сотрудников по части предложений для проекта;
изучить рынок устройств для управления рулонными шторами;
составить ТЗ;
«поднять» инфраструктуру на базе учебного центра для совместной работы команды. В частности, предполагалось использовать таск‑трекер, облачное хранилище для документов, git‑репозиторий и пр.;
поэтапно разработать устройство на основании ТЗ, обосновав выбор компонентов;
протестировать устройство;
презентовать готовое решение.
Этап № 3. «Начинаем работу»
Мы не стали давать команде готовую концепцию. Вместо этого сформулировали три вопроса:
Как будет выглядеть система?
Как она будет выполнять свои функции?
Какой способ управления выбрать?
Для поиска ответов на эти вопросы мы дали студентам неделю на предварительные исследования. Стажеры изучили аналоги и предложили варианты управления: голос, хлопок, приложение на телефоне, дистанционный пульт. Первые два мы вместе отклонили, так как дополнительный шум в опенспейсе привносит хаос. Создание приложения — слишком объемная задача, чтобы уложиться в сроки стажировки, поэтому остановились на пульте дистанционного управления.
Для аппаратной части выбрали ESP-32 — у одного из схемотехников уже был опыт работы с этим семейством. Для передачи данных рассмотрели инфракрасный канал, Wi‑Fi, Thread и Bluetooth. Конечно же, в современном мире существуют и другие популярные решения, например ZigBee или Z‑Wave, но мы не стали нагружать ребят дополнительными исследованиями, так как задач и так было много, а времени, увы, мало.
ИК‑канал отпал из‑за перегородок в опенспейсе — приемник не находился бы в зоне прямой видимости. Wi‑Fi и Thread не подошли по другим причинам. Остановились на Bluetooth — у одного из участников команды был опыт работы с этой технологией.
Итоговая концепция на данном этапе стала звучать так: устройство‑приемник с редукторным бесколлекторным двигателем, крепящееся рядом с цепью шторы, и пульт‑передатчик. Связь по Bluetooth.
Дальше встал вопрос электропитания. Команда решила, что устройство и пульт в качестве источника электропитания будут использовать аккумуляторы 18650. На вопрос «Почему?» мы получили ответ: «Это популярный форм‑фактор». Мы понимали, что выбор неоптимален, но не стали указывать на это сразу. Наше решение как наставников — не давать готовых ответов, а позволить команде столкнуться с последствиями принятых решений и найти выход самостоятельно. Забегая вперед, скажем: до полноценного решения проблемы дело так и не дошло — проект двигался дальше, а вопрос электропитания остался в зоне «можно улучшить». Это тоже урок для нас: нужно уметь находить баланс — не давать команде готовых решений, но и не оставлять ее в тупике, когда она не знает, что делать.
Для тестирования выбрали сервопривод, но из‑за низкой скорости подъема/опускания шторы в итоге заменили его на редукторный бесколлекторный двигатель. Почему не протестировали сразу? Вопрос к команде, который — спойлер! — аукнулся за два часа до финальной презентации.
Этап № 4. «Пока все хорошо»
Наступил этап систематизации всех идей и составления ТЗ. Концепцию реализации устройства оформили в виде небольшого документа, где описали планируемый функционал, а потом направили его потенциальным пользователям — сотрудникам офиса. Получив обратную связь, ребята выделили самые частые пожелания к системе:
функция конечных положений шторы (достижение крайнего верхнего и крайнего нижнего положения одним нажатием кнопки);
функция «мастер‑пульт» (подключение одного пульта ко многим устройствам);
длительная работа без подзарядки.
Все изменения были внесены в изначальную концепцию, и получилось подобие ТЗ, которое наиболее точно отражало требования к итоговому продукту. Данный подход позволил сфокусироваться на ключевых задачах и сэкономить ценное время.
Таким образом, командная работа стартовала. Инженеры‑схемотехники приступили к разработке функциональных схем приемника и передатчика. DevOps‑инженер настраивал инструменты для командной работы: разворачивал и конфигурировал платформу для совместной работы Forgejo, корпоративную WIKI Outline и платформу для управления проектами OpenProject. Разработчик ПО писал код, настраивал способ передачи между приемником и передатчиком на макетной плате, исправлял ошибки в коде после ревью.
Раз в неделю мы проводили отчетные встречи‑синки. Формат был следующим: подводим итоги работ за неделю и выстраиваем примерный план на следующую. Мы хотели, чтобы студенты максимально приблизились к рабочим процессам и почувствовали себя не просто стажерами, а полноценными специалистами компании.
Идеальный план был такой, что с каждой неделей ребята приближаются к готовому результату. Мы ожидали, что весь понедельный процесс будет выглядеть так: функциональная схема готова → проверка на макетной плате прошла успешно → инфраструктура работает. Каждая неделя — шаг к готовому продукту.
Этап № 5. «Кажется, что‑то пошло не так»
На деле все получилось не совсем так, как было запланировано. Каждый из этапов разработки схем занял немало времени: больше недели ушло на функциональную схему, две — на принципиальную, а трассировка и вовсе заняла три недели. В результате пришлось приостановить разработку корпусов для приемника и передатчика, поскольку не были известны нужные размеры.
Работа команды была очень разрозненной: ПО было полностью готово к тестированию на аппаратной платформе, а инженеры‑схемотехники все еще делали трассировку плат. Идеальный план потерпел крах!
Дальше приведем самые серьезные ошибки команды и расскажем, что мы делали как наставники и почему ?
Ошибка № 1. Эпопея с заказом компонентов и плат
Стажеры думали, что с заказом плат и компонентов все просто: составил список, отправил — и завтра все привезут. В реальности же почти все компоненты, включая микроконтроллер и микросхемы, пришли с задержкой.
Мы не стали искать обходные пути за команду. Вместо этого организовали мастер‑класс по пайке. Сначала показали, как работать с паяльником, паяльной станцией, оплеткой, потом стажеры тренировались сами. Когда платы наконец пришли, этот навык оказался бесценным: команда оперативно запаяла все элементы, а еще это сплотило коллектив. Наше решение как наставников: не спасать, делая все за команду, а обучать. Простой — это не потерянное время, если использовать его правильно.
Ошибка № 2. Проблема с выводами под I2C
Интерфейс I2C на микроконтроллере ESP-32 поддерживает только контакты GPIO 8 (SDA) и GPIO 9 (SCL). Во время трассировки платы устройства была допущена ошибка, в результате которой дорожки, ведущие к датчику тока, были смещены на контакты GPIO 6 и GPIO 7.
Ждать новые платы не было времени, поэтому пришлось решать проблему грубой силой: стажеры физически перерезали контакты на плате и повесили «сопли» к нужным контактам. Наше решение: мы видели ошибку еще на этапе трассировки, но не указали на нее сразу. Нам было важно, чтобы команда сама прошла цикл «ошибка → диагностика → исправление». Когда пришло время фиксить, мы были рядом, но паяльник в руки не брали.
Ошибка № 3. Проблема с посадочным местом IP2326
Трассировка платы устройства осуществлялась в САПР Altium Designer. В этой программе для проектирования радиоэлектронных устройств можно скачать библиотеку из Интернета под определенный корпус микросхемы. Ребята скачали первую попавшуюся, не проверив ее на наличие нужного типа корпуса. После получения готовой платы выяснилось, что посадочное место под микросхему IP2326 было большего размера, чем фактические размеры микросхемы.
Наше решение: здесь пришлось вмешаться напрямую. Работа была нетривиальной, пришлось напаивать медные дорожки для корректного положения микросхемы. Риск испортить плату был выше, чем ценность получения командой самостоятельного решения.
Ошибка № 4. Не совпали контакты ввода/вывода
Нумерация контактов GPIO на готовой плате с производства не совпала с той, что была при тестировании кода на макетной плате. Поэтому было решено поменять в коде выводы GPIO, после чего микроконтроллер заработал корректно. Наше решение: не вмешиваться, так как ошибка тривиальная и команда нашла ее сама.
Ошибка № 5. Скачок напряжения во время прошивки микроконтроллера
При подключении платы пульта к ноутбуку для ее прошивки возникла внезапная проблема: микросхема MCP73812T сгорела?. По техническим характеристикам максимальное напряжение, на которое рассчитана микросхема, равно 6 В. На входе микросхемы, в соответствии с документацией, был установлен конденсатор номиналом 1 мкФ. Однако его оказалось недостаточно: скачок напряжения на входе пульта был таким большим, что конденсатор не смог его сгладить. Выявить ошибку получилось только после просмотра уровня напряжения на осциллографе. Выяснилось, что при подключении платы ноутбук подавал напряжение, превышающее 10 В, в течение нескольких микросекунд, после чего устанавливал нужное напряжение питания. Но этого времени было достаточно для вывода микросхемы из строя, так как она не рассчитана на такое напряжение. Мы помогли с осциллографом и диагностикой, но решение — нарастить емкость вторым конденсатором до 2 мкФ — команда приняла сама.
Ошибка № 6. Члены команды не договорились между собой
В ходе разработки пульта на макетной плате обработка разрыва цепи кнопками была выполнена по низкому уровню. То есть через цепь всегда шел сигнал, а при нажатии кнопки сигнал прерывался, что и фиксировал ESP-32. На плате же была сделана активация по высокому уровню. То есть через цепь не шел сигнал, а при нажатии кнопки он появлялся, что и фиксировал ESP-32. Схемотехник и разработчик ПО не согласовали это между собой.
Наше решение: мы сознательно не проверяли согласованность между ролями, это был их процесс и их ошибка. На ретроспективе разобрали проблему и ввели правило: любое изменение уровня сигнала фиксируется в общем документе. В итоге пришлось модифицировать ПО под активацию кнопки по высокому уровню.
Финал. Конец проекта — переделываем все
После исправления схемотехнических ошибок, сборки приемника и передатчика настал этап проверки работоспособности на реальной шторе. И… двигатель не потянул штору. Оставалось 2 часа до финальной презентации, надо было что‑то делать. На то, чтобы купить новый двигатель и все поменять, времени точно не хватило бы. А сдвинуть сдачу проекта не было возможности.
Пришлось разбирать другое готовое решение, которым пользовались коллеги из соседнего отдела. Его закупали для тестирования, но скорость работы оставляла желать лучшего, поэтому потеря была не так страшна. Корпус оперативно исправили и перепечатали на 3D‑принтере. Новый двигатель мог питаться от 6 В, что позволило практически без помех внедрить его в конечное решение. Тестирование осуществлялось в последние 5 минут до финальной презентации. Ура! Заработало!!!
Наше решение: мы знали, что двигатель не был протестирован, могли настоять на проверке еще месяц назад, но это было решением команды, и мы не стали вмешиваться. Когда пришел момент «все сломалось», мы правильными вопросами помогли найти «план Б» и спасти проект.
Этап № 6. «Чему научились?»
Проект завершен, шторы открываются по нажатию кнопки. Но главная ценность стажировки — не устройство, а шишки, набитые по дороге. Пять выводов, которые стоит забрать с собой будущим стажерам:
Аппаратная разработка — марафон, а не спринт. Функциональная схема — неделя, принципиальная — две, трассировка — три. Плюс ожидание плат и компонентов. Если впервые беретесь за «железо», умножайте сроки минимум на два.
Тестируйтесь на реальном «железе» как можно раньше. Двигатель не проверили сразу, и за два часа до презентации выяснилось, что он не тянет штору. Если что‑то можно проверить сегодня — не откладывайте на завтра.
Схемотехник и разработчик ПО должны разговаривать, все участники проектной команды должны быть «в теме». Схемотехник развел кнопки по высокому уровню, разработчик написал код под низкий, никто никого не спросил и ничего не уточнил. Короткий ежедневный синк (возможно, с фиксацией результатов) между смежными ролями экономит дни работы. Коммуникация — наше все!
Двойная проверка трассировки перед заказом — не паранойя. Смещенные выводы I2C, несовпавшее посадочное место IP2326, перепутанная нумерация GPIO — каждая ошибка исправлялась паяльником и нервными клетками. Дешевле перепроверить на бумаге, чем перепаивать на плате.
Всегда имейте «план Б». Когда двигатель не потянул штору, спас мотор из чужого устройства в соседнем отделе. Без запасного варианта проект бы не состоялся.
В результате стажировки мы получили не просто работающее устройство — мы получили команду, которая знает, что между «схемой на бумаге» и «устройством на столе» лежат исследования, аналитика, пайка, логистика и ежедневные коммуникации.
Для нас, наставников, эта стажировка тоже стала проверкой: мы учились не давать готовые ответы, а направлять, и доверять команде там, где хотелось вмешаться. Пять выводов для нас как наставников:
Свобода работает лучше контроля. В 2023 году мы полностью вели команду за руку — двое из пяти трудоустроенных ушли через несколько месяцев, потому что не научились быть самостоятельными. В 2025 году мы отступили на позицию наблюдателей, и шестеро стажеров плавно вошли в рабочие команды компании.
Роль руководителя проекта можно и нужно отдавать студенту. Это освобождает наставников от рутинной работы и учит стажера видеть картину целиком, правильно расставлять приоритеты и нести ответственность за принятые решения.
Не давать готовых ответов очень тяжело, но правильно — так команда учится гораздо эффективнее. Хотелось вмешаться, когда команда выбрала 18650, когда не тестировала двигатель, когда не согласовала уровни GPIO. Мы сдержались в большинстве случаев, и это сработало.
Иногда вмешиваться все же нужно. Посадочное место IP2326, скачок напряжения — это ситуации, где цена ошибки слишком высока, а опыта команды недостаточно. Умение определить, где уместно сказать «пусть набьют шишку», а где «тут мы поможем» — это тоже навык наставника.
Стажеры учат нас. Студенты, которые еще не знают, как «принято», иногда выдают нестандартные решения. Мы пару раз ловили себя на мысли: так не делают, а потом понимали: а почему бы, собственно, и нет? Свежий взгляд — недооцененный ресурс.
В этом году мы снова проводим стажировку командного формата и продолжаем искать идеальную формулу наставничества. Пробуем новые гипотезы, исправляем старые ошибки и в очередной раз не только учим, но и учимся сами.
Спасибо, что дочитали. Если у вас есть опыт — поделитесь в комментариях.