Заметки после каждой встречи с наставником для программных менеджеров

Почему расплывчатые заметки снова приводят к тем же проблемам

Запись вроде «хорошая беседа» кажется безобидной. Через неделю она уже почти ничего не говорит.

Когда команда снова сталкивается с той же проблемой, люди редко помнят, что ее запустило. Найм затянулся, потому что была неясна роль, потому что зарплата была слишком низкой или потому что менеджер искал идеального кандидата? Объем продукта расползся, потому что sales что-то пообещали, потому что основатель поменял приоритеты или потому что никто не отрезал малополезную работу? Если триггер не записан, следующий шаг обычно оказывается неверным.

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

Сравните две записи:

• «Хорошо поговорили. У команды есть проблемы с наймом и поставкой».
• «Основатель отклонил двух кандидатов на backend-роль, потому что у обоих не было прямого опыта в fintech. После демо для клиента в продукт добавили три новых запроса. Релиз сдвинулся на пять дней, потому что QA по-прежнему идет в самом конце».

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

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

Когда вы фиксируете мелкие сигналы одинаковым способом, они быстро складываются в картину. Одна фраза о том, кто поменял объем работ, кто заблокировал найм или где застопорилась поставка, потом экономит часы.

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

Что записывать в первые пять минут

Начните с фактов, которые можно просканировать за десять секунд. Запишите дату, кто был на встрече, этап команды и текущую цель. «Этап команды» можно обозначить просто: до запуска, первые клиенты, быстрый найм или попытка стабилизировать поставку.

Затем зафиксируйте одну проблему, на которой держалась почти вся беседа. Не пишите три одинаково важные темы, если разговор снова и снова возвращался к одной. Если большую часть сессии занимали пропущенные передачи между продуктом и инженерией, запишите это как главную проблему, а остальное оставьте второстепенным.

Добавьте одну прямую цитату, которая передает настроение. Это важнее, чем кажется. Фраза вроде «Мы каждую неделю меняем план» говорит о другом, чем «План нормальный, но за релиз никто не отвечает». Обе фразы описывают боль, но первая указывает на объем работ, а вторая — на владение задачей.

Нужна и короткая заметка «что изменилось с прошлого раза». Пишите просто. Возможно, они наняли одного инженера, потеряли дизайнера, отложили функцию или перенесли дедлайн после обратной связи от клиента. Небольшие изменения часто объясняют, почему та же команда звучит спокойнее или, наоборот, напряженнее, чем на предыдущей сессии.

Не уходите со встречи без срока решения в записи. Если команде нужно выбрать между наймом product lead, сокращением объема работ или переносом запуска, запишите дату, когда это решение должно быть принято. Запись без дедлайна превращается в заметку из дневника. Запись с дедлайном помогает следующей сессии перейти к действию.

Полезная запись может быть настолько простой: 18 апреля, основатель + PM + инженерный lead, команда после запуска, цель — выпустить исправления для onboarding до следующего рывка продаж. Главная проблема: слишком много поздних запросов на функции. Цитата о настроении: «Каждую неделю будто все начинается заново». Что изменилось с прошлого раза: после запуска количество тикетов в support удвоилось. Дедлайн решения: в пятницу решить, какие запросы перейдут в следующий спринт.

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

Что отмечать по найму

Заметки по найму должны объяснять, почему роль остается открытой, а не просто констатировать, что она открыта. Запишите название роли, как долго она уже висит и простую причину, почему она все еще не закрыта. «Нужен senior engineer» — слишком мало. «Открыта девять недель, вилка зарплаты ниже рынка, а основатель ищет редкое сочетание Go, mobile и DevOps» уже дает материал, с которым можно работать.

Отмечайте, как найм движется на практике. Кто просматривает кандидатов, кто участвует в интервью, кто принимает финальное решение и где все стопорится на согласовании? Многие команды думают, что у них проблема с талантами, хотя на деле у них проблема с ожиданием. Если кандидаты по пять дней ждут между этапами, потому что один занятый руководитель должен утверждать каждый шаг, этот лаг тоже должен попасть в запись.

Отзывы кандидатов важнее, чем многие признают. Если одну и ту же жалобу вы слышите дважды, зафиксируйте ее. Роль может звучать слишком широко. Воронка интервью может занимать слишком много времени. Вилка зарплаты может появляться слишком поздно. Домашнее задание может восприниматься как неоплачиваемое и слишком тяжелое. Кандидаты могут переставать отвечать после определенного этапа. Такие детали делают заметки после сессии с наставником полезными позже, потому что можно сравнить одну встречу с другой и увидеть, исправила ли команда проблему или просто повторяет ее.

Также отмечайте пробелы в навыках, которые всплывают не один раз в словах самой команды. Если три человека говорят, что нужен более сильный testing, лучшее понимание продукта или человек, который возьмет на себя deployment, это сигнал. Один случайный комментарий — не тренд. Важна повторяемость.

Есть и еще одна типичная ловушка для program managers: команды часто просят больше людей, когда на самом деле им нужно более ясное владение задачами. Если product manager, tech lead и основатель все думают, что приоритизацию должен делать кто-то другой, найм еще одного инженера мало что исправит. Записывайте обе идеи отдельно. В одной строке — запрос на дополнительный ресурс. В следующей — есть ли проблема в том, что никто не принимает решения.

Лучший журнал по найму — простой и точный. Добавляйте даты, числа и короткие цитаты, если они помогают.

Что отмечать по объему продукта

Изменения объема работ редко приходят как формальные решения. Обычно они всплывают мимоходом. Основатель упоминает запрос клиента, lead просит еще неделю, или кто-то вставляет функцию, которая теперь кажется срочной. Если записать только название функции, вы потеряете давление, которое за ней стоит.

Хорошая заметка по объему продукта отвечает на несколько простых вопросов. Какой новый запрос появился? Кто его предложил? Почему он важен именно сейчас? Что команда из-за него задержит, уберет или уменьшит? Где люди не согласны?

Последний пункт важнее, чем многие program managers ожидают. Основатель может продавливать dashboard, потому что хорошо прошел sales-звонок. Product lead может считать, что важнее исправить onboarding. Запишите обе позиции. Не сглаживайте напряжение в расплывчатую фразу вроде «обсудили объем работ». Назовите компромисс.

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

Мелкие детали сильно повышают пользу заметок для program manager meeting notes, когда вы возвращаетесь к ним через месяц. Пишите запрос обычным языком, а не сокращениями. Если сессия дала три изменения, разделите их. Если один пункт вытеснил другой, запишите их парой, чтобы замена была видна.

Короткий пример показывает разницу. Представьте, что основатель просит кастомный отчет, потому что один потенциальный клиент хочет его уже на этой неделе. Engineering lead говорит, что команда и так с трудом закрывает исправления в login и ошибки billing. Ваша запись не должна останавливаться на «добавить кастомный отчет». Нужно написать, кто попросил, что это спровоцировало, какая работа теперь сдвигается и согласилась ли команда.

Так становится виден размыв объема продукта. После нескольких сессий заметки начинают показывать паттерны: один клиент постоянно двигает roadmap, дедлайны снова и снова заставляют брать наполовину готовую работу, или основатели и team leads постоянно расходятся по одному и тому же типу запроса. Когда этот паттерн становится очевидным, следующий разговор получается точнее и менее эмоциональным.

Что отмечать по проблемам с поставкой

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

Будьте конкретны. «Ждем design review для onboarding flow с вторника» — полезно. «Инженерия замедлилась» — нет. Хорошие заметки после сессии с наставником помогают легко представить задержку.

Чаще всего достаточно четырех фактов: сам блокер, кто или какая команда пострадала, какая работа сдвинулась и какова была причина.

Передачи задач между командами заслуживают отдельной строки. Очень часто проблемы с поставкой начинаются не внутри одной команды, а на границе между ними. Отмечайте, где продукт, дизайн и инженерия перестают понимать друг друга. Возможно, продукт меняет объем работ уже после старта дизайна. Возможно, инженерия получает макеты без edge cases. Возможно, дизайн три дня ждет обратной связи от продукта. Вот такую трение и нужно ловить.

Фиксируйте повторяющиеся сдвиги, а не только одну плохую неделю. Если одна и та же работа переносится снова и снова, запишите паттерн простыми словами. Например: «Мобильный релиз сдвигается уже третий спринт подряд. Первая причина: неясные требования. Вторая: поздно изменился API. Третья: большую часть работы тащил один senior engineer». Теперь есть с чем работать.

Отдельно держите проблемы с инструментами и проблемы с людьми. Команды часто смешивают их. Сломанный CI pipeline, шумные алерты или медленный staging-сервер создают один тип боли. Отсутствие backend lead, слабое покрытие QA или слишком много junior hires — другой. Если все это свалить в «проблемы с исполнением», следующее вмешательство промахнется.

Также фиксируйте, как команда измеряет прогресс сейчас. Одни считают закрытые тикеты. Другие — milestones, даты релизов или готовые для демо функции. Если метрика слабая, тоже запишите это. Команда может выглядеть занятой в Jira и при этом все равно пропускать реальный дедлайн.

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

Как превращать заметки в следующий шаг

Хорошая заметка должна менять то, что происходит на следующей сессии. Если она не приводит к понятному действию, это просто запись.

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

Потом ищите повторяющиеся сигналы. Одна жалоба на одной встрече может быть настроением. Та же проблема на двух и более сессиях — это паттерн. Отметьте его в заметках после сессии с наставником и поставьте выше остальных тем.

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

Перед тем как закрыть запись, полезна короткая проверка:

• К какой корзине относится каждая проблема?
• Какой паттерн повторился минимум дважды?
• Какое одно действие нужно на следующую сессию?
• Кого нужно пригласить в этот разговор?
• Какой результат покажет, что действие сработало?

Список людей важнее, чем думают многие program managers. Если проблема в объеме работ, зовите product owner или основателя. Если она в поставке, приглашайте engineering lead. Если найм снова тормозит работу, hiring manager должен увидеть те же факты, а не сводку через две недели.

Пишите результат простым языком. «Меньше блокеров» — слишком размыто. «Команда закрывает planning спринта за 45 минут» или «роль scorecard утверждается до старта интервью» дают то, что можно проверить.

Fractional CTO или наставник может помочь назвать паттерн, но в записи все равно нужен простой тест. Когда начнется следующая встреча, вы должны точно знать, что изменилось, кто за это отвечает и почувствовала ли команда разницу.

Простой пример из одной сессии наставника

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

Сначала это похоже на проблему найма. Backend-роли остаются открытыми неделями, интервью растягиваются, и команда не может выпускать продукт вовремя, потому что не хватает инженеров. Если program manager остановится на этом, следующий шаг, скорее всего, будет сводиться к новым инструментам найма или более длинной воронке кандидатов.

Полезная заметка идет на уровень глубже. В ней видно, что один дизайнер проводит первый скрининг backend-кандидатов, потому что engineering lead завален вопросами по продукту. Эта одна деталь меняет весь взгляд на ситуацию. Найм медленный, но корневая проблема — размытое владение задачами.

Та же сессия показывает и почему планы спринтов продолжают сдвигаться. Sales пообещали кастомный dashboard, чтобы закрыть сделку. После этого никто не пересобрал roadmap, и команда продолжила старые цели спринта, а dashboard просто добавили сверху. Объем работ расползся не случайно. Кто-то расширил его, не изменив приоритеты.

Запись после сессии может выглядеть так:

• Найм backend заблокирован из-за путаницы с ролью. Дизайнер делает первый скрининг технических кандидатов.
• Engineering lead тратит время на проверки продуктовых изменений, продиктованных sales.
• Sales пообещали кастомный dashboard без согласования по поставке.
• Сроки спринтов сдвигаются, потому что работу добавили, а не потому что команда стала медленнее.
• Следующая проверка должна показать, что владельцы и даты теперь зафиксированы.

Отсюда возникает другое вмешательство. Наставник не советует еще один hiring board, новый трекер или больше встреч. Наставник настаивает на четком владении ролями: кто скринит инженеров, кто утверждает кастомные запросы и кто может переносить дедлайн.

Следующая сессия простая. Проверьте, перестал ли дизайнер скринить backend-кандидатов. Проверьте, не делает ли sales продуктовые обещания в одиночку. Проверьте, остались ли сроки на месте в прошлом спринте. Если эти три вещи изменились, заметка выполнила свою работу.

Ошибки, из-за которых журнал трудно использовать

Хорошие заметки после сессии с наставником хороши своей скучностью. Их можно просканировать за минуту и увидеть, что произошло, что повторилось и что требует продолжения.

Самая частая ошибка — писать полный транскрипт. Кажется, что это тщательно, но полезная часть теряется под слишком большим количеством деталей. Через несколько встреч никто не захочет это читать. Короткие факты работают лучше, чем длинный пошаговый пересказ.

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

Action items часто записывают без причины, по которой они вообще нужны. Потом следующий разбор превращается в угадайку. «Добавить еженедельный продуктовый check-in» — недостаточно. Напишите, зачем это важно: «Две функции попали в разработку без четких требований, поэтому позже команде пришлось их переделывать».

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

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

Еще одна ошибка — менять шаблон каждую неделю. Если одна заметка отслеживает этапы найма, следующая — чувства, а третья использует свежий формат, паттерны исчезают. Держите структуру стабильной, чтобы можно было сравнивать записи со временем.

Эта стабильность особенно важна, когда одна и та же боль возвращается под разными названиями. Поздний релиз может сначала называться «проблемы QA», потом превратиться в «неясные решения по продукту», а потом снова всплыть как «задержка инженерии». При стабильном формате видно, что это та же проблема, только в новой одежде.

Краткая проверка перед сохранением заметки

Заметка помогает только тогда, когда ее можно быстро прочитать и применить. Перед тем как сохранить заметки после сессии с наставником, сделайте минутную проверку: если другой program manager откроет страницу с нуля, поймет ли он проблему команды, текущий риск и следующий шаг без дополнительного контекста?

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

Пользуйтесь короткой проверкой:

• Напишите одним простым предложением, что изменилось с прошлого раза.
• Зафиксируйте один сигнал по найму, даже если он небольшой.
• Зафиксируйте один сигнал по объему работ.
• Зафиксируйте один сигнал по поставке.
• Назовите следующее решение и человека, который за него отвечает.

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

Формулируйте жестко. «Нужен senior backend hire до планирования Q3» лучше, чем «Команда обсудила возможные потребности в найме». «Объем работ расширился за счет admin export» лучше, чем «Продолжился разговор о продукте».

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

Хорошая финальная строка часто самая полезная: «Что изменилось с прошлого раза: найм теперь срочный, риск по объему вырос, риск по поставке остался на том же уровне. Следующее решение: PM должен зафиксировать scope первой фазы до пятницы». Это дает следующему читателю достаточно, чтобы войти в контекст, а не начинать с нуля.

Что делать с паттерном дальше

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

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

И здесь помогает короткая проверка:

• Что повторилось во всех трех записях?
• Что изменилось после прошлого совета?
• Какое одно действие может уменьшить боль в течение двух недель?
• Кто может разблокировать это прямо сейчас?

Приглашайте только тех, кто может убрать этот блок. Большие встречи кажутся безопаснее, но они обычно размывают владение. Если проблема в найме, зовите hiring manager. Если она в расползании объема продукта, зовите product owner. Если проблемы с поставкой снова идут через передачи задач, приглашайте человека, который управляет этим процессом.

Некоторые паттерны выходят за пределы исправления одного проекта. Если ваши заметки на встречах program manager снова и снова указывают на структуру команды, неясное владение продуктом, инфраструктурные узкие места или схему поставки, которая создает одни и те же задержки в каждом спринте, может помочь внешний разбор. Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, и такой разбор паттернов хорошо ложится в эту работу.

Заканчивайте заметку тремя простыми строками: вмешательство, владелец и дата проверки. Если этих строк нет, паттерн остается интересным, но ничего не меняется.