Почему хороший PM во многом действует как тренер (и наоборот)

Последние несколько лет я всё чаще ловлю себя на мысли, что управление проектами и обучение взрослых — это не разные профессии, а две стороны одного и того же. Мы привыкли делить: вот PM (project manager), вот тренер. А на деле хороший PM каждый день занимается именно обучением — просто его «студентами» становятся команда, заказчики и стейкхолдеры, а «курсом» — сам проект.

Работа PM — это бесконечное превращение хаоса в структуру. Мы создаём устав проекта, дорожные карты, матрицы рисков, регламенты. Вроде бы сухие документы. Но если посмотреть на них под правильным углом, это те же самые учебные пособия.

Тренер проектирует курс так, чтобы студент прошёл из точки А в точку Б. PM делает ровно то же самое с командой и заказчиком. Разница только в том, что LMS’ом нам служит Confluence или Wiki, а оценкой — сданный в срок продукт.

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

Чтобы артефакт реально работал как учебный материал, попробуйте такой мини‑план:

1. Выберите один документ, который чаще всего вызывает вопросы (например, регламент постановки задач или процесс согласования).

2. Сократите его на 30%. Уберите сложные формулировки и всё, что не влияет на действие. Оставьте только «что делаем», «в какой момент», «к кому идти, если непонятно».

3. Добавьте блок «Частые ошибки» из 3–5 пунктов. Это сразу закрывает 80% типовых вопросов.

4. Оформите как шаблон страницы в вашей базе знаний (Wiki): разделите на вкладки «Цель», «Шаги», «Частые ошибки», «Вопросы для обсуждения». Так команда будет видеть структуру, а не сплошной текст.

🗒 Что можно сделать на этой неделе: выберите один документ, сократите его на треть и добавьте чек‑лист из 5 пунктов.

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

Человеческий мозг устроен так, что новая информация без повторения улетучивается на 80% уже через месяц. Процессы в проекте работают точно так же. Вы внедрили новый регламент — команда неделю его соблюдает, а потом всё скатывается в привычные рельсы. Вы провели тренинг — через месяц люди помнят только шутки спикера.

С тем самым регламентом, о котором я рассказала выше, так и произошло. У команды был устоявшийся, «родной» механизм работы, и, несмотря на все договорённости, люди возвращались к нему. Страдали качество и прозрачность взаимодействия с клиентом. Я начала напоминать о новом формате на планёрках. Говорила, почему это важно и какую проблему мы решаем. Потом подходила к ребятам и спрашивала: «Как нам сделать регламент удобнее, чтобы он реально работал?» Поначалу слышала честное: «Мы не знаем».

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

И для себя вывела правило: если я хочу, чтобы правило прижилось, важно «продать» его команде минимум трижды разными способами. Это чистая методика обучения.

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

Касание 1 (день 0–3): расскажите на планёрке и дайте ссылку на документ. Сформулируйте одну главную цель: «чтобы мы не теряли сроки из‑за недоговорённостей».

Касание 2 (день ~10): отправьте короткое напоминание в чат: «Вот 3 пункта, на которые стоит обратить внимание в этом процессе». Приложите чек‑лист.

Касание 3 (день ~20): на ретро или в короткой встрече спросите: «Что из нового процесса реально помогает, а что только мешает?» Это не контроль, а сбор обратной связи — и это тоже часть обучения.

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

🗒 Что можно сделать на этой неделе: запланируйте три напоминания об одном процессе и соберите короткую обратную связь на 20‑й день.

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

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

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

На этой неделе выберите ровно одну типовую ситуацию, где вы обычно сразу даёте ответ (постановка задачи, согласование ТЗ, приёмка этапа). В этот раз не давайте решение — задайте один вопрос, который заставит команду самой дойти до ответа.

Было: «Давайте согласуем ТЗ сегодня».

Стало: «Какие 3 пункта в ТЗ сейчас самые рискованные? Если их не прояснить, что сломается на этапе разработки?»

🗒 Что можно сделать на этой неделе: выберите одну типовую ситуацию (например, постановка задачи, согласование ТЗ, приёмка этапа) и в следующий раз не давайте готовое решение, а задайте 2–3 вопроса. Запишите, какой инсайт появился у команды — это и есть зона ближайшего развития в действии.

Я завела этот блог, чтобы исследовать пространство между проектным менеджментом и обучением взрослых. Впереди будет больше кейсов, инструментов и историй о моём переходе в L&D и EdTech. Для меня этот опыт особенно важен в контексте перехода в L&D и EdTech: умение превращать процессы в понятные шаги — это и есть проектирование обучения для взрослых.