План наставничества: как вести и где отпускать

План для наставника, не для ученика. Как довести архитектора с физматом от «переписываю номера листов» до «умею измерить здание и обосновать решение данными» — за 10–12 недель, по 4–6 часов в неделю.

Главное решение: чего мы НЕ делаем

Соблазн — научить всему: микроконтроллеры, Linux, серверы, SQL, брокеры, оркестрация. Это ошибка, и вот почему.

Аутентичная задача (по вашей же методике) звучит так:

Архитектор приходит на объект и может инструментально ответить, как помещение используется на самом деле, а не как предполагалось при проектировании.

Из этой задачи следует, что ему нужно, а что нет:

Цель — архитектор, усиленный данными. Не второй вы.

Если он через год захочет глубже — дорога открыта. Но начинать с широкого фронта значит гарантированно утопить его и себя.

Стартовая точка

Что у него уже есть (не начинаем с нуля):

• физмат — математика, графики, порядки величин, понятие погрешности;
• год в профессии — понимает, что такое проект, сроки, заказчик;
• мотивация — ему плохо от текущей работы, это топливо;
• предметная область — знает про помещения больше вас.

Что отсутствует: командная строка, БД, любой бэкенд. Скорее всего — стадия 1–2 по SSDL (зависимый / заинтересованный) в технике, при этом стадия 3–4 в архитектуре. Это важно: в своей области он взрослый, и обращаться с ним как с новичком в целом — ошибка рассогласования.

Фаза 1 · Недели 1–2. Данные (ведём за ручку)

Начинаем не с железа и не с Linux, а с SQL. Это против интуиции «сначала основы», и это правильно: SQL даёт результат в первый вечер, работает в его голове как математика и сразу отвечает на его вопросы о помещении.

Что делает

Подключается к вашей БД через GUI (DBeaver / VSCode), под ролью grafana_ro — только чтение. Ломать нечего, страха нет.

Задачи (по нарастанию)

-- 1. Сколько у нас вообще данных?
SELECT count(*), min(time), max(time) FROM sensor_data;

-- 2. Какие метрики есть?
SELECT metric, count(*) FROM sensor_data GROUP BY metric;

-- 3. Занятость по часам суток — первый содержательный вопрос
SELECT extract(hour from time) AS h, round(avg(value)::numeric, 2)
  FROM sensor_data WHERE metric = 'occupancy'
 GROUP BY h ORDER BY h;

-- 4. По дням недели: в какой день переговорка загружена сильнее?
SELECT to_char(time, 'Dy') AS d, round(avg(value)::numeric, 2)
  FROM sensor_data WHERE metric = 'occupancy'
 GROUP BY d;

-- 5. Его собственный вопрос — пусть придумает сам

Задача 5 — ключевая. Момент, когда он перестаёт выполнять упражнения и начинает задавать вопросы данным. Если не придумал — не подсказывать сразу, дать день.

Где ведём за ручку

Подключение к БД, синтаксис GROUP BY, что такое агрегат. Первые два вечера — рядом.

Где отпускаем

Задачи 3–5 — сам, с документацией. avg, count, extract он найдёт.

Срезаем углы

• Не объясняем нормализацию, индексы, планы запросов, транзакции.
• Не даём права на запись — только SELECT.
• Не рассказываем про EAV vs широкую схему. Пока просто «таблица показаний».

Критерий фазы

Сам написал запрос, который отвечает на его вопрос о помещении.

Фаза 2 · Недели 3–4. Визуализация и метод (отпускаем)

Что делает

Строит в Grafana дашборд по своим запросам. Затем — главное: выгружает CSV и считает в Excel/Python то, что Grafana не умеет.

Задачи

1. Панель «занятость по часам» — своими руками, не по вашему шаблону.
2. Выгрузить месяц в CSV.
3. Ответить: насколько мы уверены в этих числах?
   • сколько часов с неполными данными (samples < 100)?
   • что будет с выводом, если их исключить?
4. Написать полстраницы: что видно в данных и чего не видно.

Где нажать

Задача 3 — здесь давим. Это самое ценное во всём плане.

Физмат даёт ему готовый аппарат — погрешность, выборка, доверие к данным. Он просто никогда не применял это к своей профессии. Момент, когда он поймёт, что «данные с датчика» — это измерение со всеми свойствами измерения, и есть переход из энтузиаста в инженера.

Здесь не срезать. Здесь — до дна.

Где отпускаем

Grafana осваивается кликами, помощь не нужна. Пусть мучается — так запоминается.

Срезаем углы

• Не provisioning дашбордов через YAML — кликами.
• Не переменные, шаблоны, аннотации Grafana.
• Не оптимизация запросов.

Критерий

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

Фаза 3 · Недели 5–6. Микроконтроллер (ведём, потом резко отпускаем)

Теперь железо — когда уже понятно, зачем оно.

Что делает

Разбирает существующую прошивку. Не пишет с нуля.

Разбор шести файлов — по одному вопросу к каждому

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

Для человека с физматом и архитектурным образованием это ложится мгновенно, и после этого «шесть файлов» перестают пугать.

Задача: поменять датчик

Дать другой датчик (DHT22 / BME280 из ваших Sensors/) и попросить завести его в ту же систему.

Здесь ведём за ручку в начале (распиновка, библиотека, первый Serial.print) и резко отпускаем дальше: пусть сам доведёт до графика в Grafana.

Это его первое сквозное прохождение всей цепочки — датчик → MQTT → БД → график. Момент, когда система перестаёт быть чёрным ящиком.

Срезаем углы

• Не прерывания, DMA, watchdog, сон, энергопотребление.
• Не OTA-обновление.
• Не разработка своего протокола.
• Не пайка, если можно на макетке.

Критерий

Его датчик пишет в базу и рисуется на графике. Он сделал это сам.

Фаза 4 · Неделя 7. Linux и сервер (минимум, осознанно)

Самая короткая фаза. Ему нужно не сломать и посмотреть, а не администрировать.

Что даём — ровно это

ssh user@host                       # зайти
systemctl status nodered            # что живо
sudo podman ps                      # что крутится
journalctl -u nodered -n 50         # что в логах
sudo systemctl restart nodered      # перезапустить
bash checkup.sh                     # ваша диагностика одной командой
df -h && free -g                    # место и память

Семь команд. Больше не надо.

Где нажать

Одна мысль: «если сломалось — сначала посмотри логи, потом спрашивай». Это профессиональная привычка, которая переносится куда угодно.

Срезаем углы жёстко

• Не права, владельцы, chmod/chown (кроме «бывает, что UID не совпал»).
• Не сеть, фаервол, маршрутизация.
• Не systemd-юниты, quadlet, зависимости.
• Не установка чего-либо. Только смотреть и перезапускать.

Дать sudo на боевой машине — риск. Вариант: отдельный пользователь без sudo, кроме systemctl restart конкретных сервисов. Либо ваша тестовая VM, которую не жалко.

Критерий

Зашёл, увидел, что сервис упал, перезапустил, посмотрел логи. Без вас.

Фаза 5 · Недели 8–10. Календарь — его собственный проект

Кульминация. Здесь он работает самостоятельно, вы — консультант по запросу (стадия 4 SSDL).

Что делает

Реализует синк календаря и метрику — от источника ICS до страницы выводов.

Где ведём

Только два места:

1. Почему составной PK (booking_uid, starts_at) — объяснить про RRULE один раз, иначе он потратит дни на непонятный баг.
2. Окно разворачивания = окно пометки отмен — назвать заранее, это неочевидно.

Где отпускаем полностью

Парсер ICS, upsert, SQL метрики, дашборд, текст выводов. Пусть спотыкается — на этом этапе ошибки уже дешёвые, а опыт дорогой.

Где нажать

Раздел «Ограничения» в отчёте. Не принимать работу без него. Проверка чувствительности к порогу no-show — обязательна.

Это то, что отличает его отчёт от красивой картинки, и то, что заметят на собеседовании.

Срезаем углы

• Не обработка всех крайних случаев RFC 5545 (VTIMEZONE, EXRULE, вложенные исключения). Достаточно RRULE + EXDATE + отмены.
• Не высокая доступность синка. Упал — перезапустили.
• Не свой UI. Grafana.

Критерий

Есть страница выводов с цифрой, методом и ограничениями. Его собственная.

Фаза 6 · Недели 11–12. Упаковка (отпускаем, страхуем)

Что делает

Готовит портфолио: три уровня рассказа, дашборд, страница выводов.

Где нажать

Репетиция вслух. Пусть расскажет вам за 30 секунд, потом за 3 минуты. Первый раз выйдет про технологии («я взял MQTT и Postgres») — это нормально и это надо поправить: рассказ начинается с задачи и результата, технологии в конце и только если спросят.

Критерий

Рассказал так, что непрофильный человек понял, зачем это и что получилось.

Сводка: где ручка, где отпускаем, где углы

Где нажимать (не уступать):

1. Достоверность данных — что мы не знаем (фаза 2)
2. Раздел «Ограничения» в отчёте (фаза 5)
3. Рассказ начинается с задачи, а не с технологий (фаза 6)

Три пункта. Всё остальное — можно мягко.

Риски наставничества (честно)

Первый и последний — самые вероятные, и оба про вас, а не про него.

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

Про последний: у вас 29 часов в неделю и 90к. Наставничество не должно стать третьей работой. 1–2 часа в неделю, регулярно — этого достаточно, если план выстроен. Больше — не героизм, а прямой путь к тому состоянию, из которого вы сейчас выбираетесь.

Что получится на выходе

Через 10–12 недель у него:

• ✅ работающий проект с измеримым результатом
• ✅ понимание сквозного пути данных: датчик → сеть → БД → график → вывод
• ✅ SQL на рабочем уровне
• ✅ умение сказать, чему в данных не верить
• ✅ рассказ на три уровня глубины
• ✅ термин post-occupancy evaluation в профессиональном словаре

Чего не будет — и это нормально: он не развернёт стек с нуля, не настроит Podman, не поднимет headscale. Ему это и не нужно. Он архитектор, который умеет в данные — редкая и дорогая комбинация.

А у вас — первое за долгое время подтверждение, что построенное работает на живом человеке.