Когда я начинал свой путь junior PM, мне казалось, что ключ к успеху — это найти ту самую «волшебную» методологию. Scrum там, Kanban или, симпатичный, p3express. Но потом я понял одну штуку (спойлер: я еще в процессе понимания) — пока не разберёшься в пяти классических функциях менеджмента, любые модные фреймворки/методы/методологии будут лишь «пляской с бубном». При том что ты еще не стал шаманом.
Если интересно сразу посмотреть на книги, открой ссылку в новой вкладке или листай в конец статьи.

Что за 5 функций и почему они так важны

Анри Файоль ещё в начале XX века сформулировал: любой менеджмент (не только проектов, но и в целом) базируется на планировании, организации, руководстве (или «распорядительстве»), координации и контроле. И не думайте, что это ГОСТовский какой-то ретроградный отстой. Этими функциями можно выразить все основополагающие активности, которые должен предпринимать менеджер — от кикофф-собрания, где вы решаете «как жить?», до сдачи в пром.
Чем бы вы ни управляли — проектом в маленькой аутсорс студии, продуктовым стримом или внутренним проектом по миграции данных — вам придётся планировать, организовывать, руководить, координировать и контролировать. Это не просто набор теоретических постулатов, а естественная логика управления: от постановки целей до анализа результатов.
Планирование: без ясной цели и продуманных путей её достижения команда хаотично тратит ресурсы;
Организация: если не продумать структуру, роли, ресурсы, возникает путаница, конфликты, остановки;
Руководство (распорядительство): нет чёткого видения — люди не понимают приоритетов, теряют мотивацию, пробуксовывают в конфликтных моментах;
Координация: даже отличный план и сплочённая команда могут провалить проект, если действия не согласованы;
Контроль: без отслеживания показателей, корректировки курса и анализа ошибок все усилия могут свестись к нулю.
Важно помнить, что это не линейная модель (сначала планируем, потом организуем и т. п.). В реальности менеджер постоянно переключается между функциями: где-то нужно доработать план, где-то усовершенствовать оргструктуру, наладить коммуникации или ужесточить контроль.
Пример из жизни (история одного уставшего PM)

Когда я был совсем начинающим проджектом, мы выпускали новую фичу в мобильное приложение. Сроки как обычно неприятные, однако я верил в себя и свои навыки убалтывать заказчиков нашей маленькой студии. Я прикинул задачи, тикеты в битрикс завел, скинул их потегав людей в чат и назвав нужные— думаю, всё, job is done. Но «не учёл» что дизайнер начинающий студент и вообще приболел, тестировщик был новенький и первый раз видел Qase, а флаттер-разработчик вообще не в курсе, что у нас сдача через 2 недели и эта задача важнее остальных.
Планирование-то я сделал, пусть и коряво;
Организацию — там плавал внушительный половой агрегат: никто не понимал, кто за что несёт реальную ответственность;
Руководство? «Я? Ну я сказал же, что надо сделать» — думал я;
Координация? Полагаю в чат написать и подпинывать иногда достаточно;
Контроль? Я только смотрел в таск-трекер и требовал обновления статусов, не понимая насколько мы не успеваем.
В итоге, пришлось звать аккаунт-менеджера для разруливания. Он за час расставил всех по местам, объяснил, кто кому что должен и как вообще должна строиться работа, чтобы не перегореть за сутки. Было стыдно, зато урок я усвоил: 5 функций — не просто слова, это необходимая структура мозгового процесса менеджера.
Как выглядят функции менеджмента в классическом варианте
Планирование: Вы ставите цели, ищете способы и ресурсы для их достижения, оцениваете риски, рассчитываете бюджеты;
Организация: Вы выстраиваете структуру: кто за что отвечает, как распределить ресурсы и зоны ответственности;
Руководство: Вы мотивируете людей, поддерживаете дисциплину, задаёте ориентиры, решаете конфликты;
Координация: Вы синхронизируете все элементы системы: сотрудники, отделы, подрядчики должны работать сообща, а не «тянуть одеяло» каждый в свою сторону;
Контроль: Вы проверяете, идёте ли вы по плану, укладываетесь ли в бюджет, насколько команда выполняет KPI и нет ли серьёзных отклонений.
Тот же набор функций — но уже для менеджера проектов

В классическом «корпоративном» менеджменте важно удерживать общую стратегию компании, её структуру, долгосрочную перспективу. А в проектах добавляется временная природа и уникальность результата. Но «5 функций» никуда не исчезают, они лишь видоизменяются:
Планирование в проекте превращается в составление чёткой иерархической структуры работ, детального календарного плана, бюджета и реестра рисков;
Организация — это формирование проектной команды, определение ролей, выстраивание каналов коммуникации с заказчиком и стейкхолдерами;
Руководство — управление мотивацией и настройкой команды в условиях, когда сроки сжаты и надо вчера, а задачи сложны и вообще не описаны;
Координация — согласование усилий разных групп (разработчиков, тестировщиков, маркетинга, финансового отдела), чтобы не было «бутылочных горлышек»;
Контроль — отслеживание статуса задач, расхода бюджета, управление изменениями и корректировка плана.
Все современные фреймворки (p3express, PRINCE2, disciplined agile и их предшественники RUP, DSDM и т.д, а также общие практики вроде Scrum, Kanban, XP),— это, по сути, надстройка над этими базовыми принципами. Освоив фундамент, вы быстрее и осмысленнее берёте любую методологию: уже понимаете, зачем нужны спринты (планирование и контроль), ретроспективы (координация и руководство), доски Kanban (организация и контроль), ревью (координация, контроль) и тд.
Особенности для IT-проектов

IT — сфера более гибкая, сложная и требовательная к быстрой адаптации. Тем не менее, базовые функции всё ещё в игре:
Планирование должно учитывать IT-специфику: выбор архитектуры, технологического стека, возможные интеграции. Возникает непрерывный процесс пересмотра приоритетов, поскольку требования меняются зачастую «на лету»;
Организация осложняется наличием кросс-функциональных команд, разных часовых поясов (если команда распределённая), необходимостью DevOps-инфраструктуры;
Руководство в IT требует мягкого подхода (servant-лидерство), так как IT-специалисты часто ценят свободу, гибкость, интерес к технологиям. Нужно найти баланс между «давайте экспериментировать» и «укладываемся в сроки»;
Координация затрагивает постоянные интеграции (микросервисы, внешние API, технологические платформы) и быструю реакцию на изменения (Agile!), поэтому приходится синхронизировать людей и задачи практически в режиме онлайн;
Контроль плавно перетекает в автоматизированный мониторинг (CI/CD, автотесты, алертинг), сбор метрик (velocity, bug rate) и регулярные обзорные сессии. Контроль уже не столько «жёсткий», сколько прозрачный.
Для IT-проектов в 2025 году

Мы живём в эпоху удалёнки, DevOps, миллиона облаков и AI-сервисов. Но пять функций никуда не исчезают, просто меняются нюансы:
Планирование теперь с учётом часовых поясов, сложности интеграций, облачных серверов и микросервисной архитектуры, а же специфичной регуляторности и санкционных политик;
Организация — это вся эта «зона ответственности»: у тебя может быть dev-команда в одном городе, тестировщик-фрилансер в другом, а дизайнер — из третьей страны (и обожать спать в обед) в сочетании с работой в "так исторически сложилось" jira и agile даже не произноси;
Руководство требует больше эмпатии, ибо люди разбросаны, редко видят друг друга вживую и могут банально почувствовать себя одиноко;
Координация — куча сервисов, API, платёжек, и всё это надо сводить в «гладкий» продукт. Тут devops-культура помогает, но без хорошего менеджера всё равно бардак;
Контроль опирается на автотесты, CI/CD, алертинги, метрики. Активно внедряются AI агенты для для чего угодно, но AI может подсказывать риски, но если у вас нет здравого смысла — что угодно утечёт сквозь пальцы.
Книги, которые помогут прокачать все 5 функций

Если вы хотите не просто «слепо» ставить задачи в Jira, а осмысленно прокачаться как PM, ниже отличный список:
Планирование
(50+ лет) «Общее и промышленное управление» — Анри Файоль;
(~30 лет) «Вовремя и в рамках бюджета» — Лоуренс Лич;
(до 10 лет) «Бизнес с нуля (The Lean Startup)» — Эрик Рис;
(до 5 лет) «Управление проектами: быстрый старт» — Дмитрий Завертайлов;
(бизнес-роман) «Критическая цепь» — Элияху Голдратт.
Организация
(50+ лет) «Принципы научного управления» — Фредерик Тейлор;
(~30 лет) «Системный и ситуационный анализ управленческих функций» — Г. Кунц;
(до 10 лет) «Управление 3.0» — Юрген Аппело;
(до 5 лет) «Канбан Метод. Базовая практика» — Алексей Пименов;
(бизнес-роман) «Цель» — Элияху Голдратт.
Руководство
(50+ лет) «Эффективный руководитель» — Питер Друкер;
(~30 лет) «Впереди перемен (Leading Change)» — Джон Коттер;
(до 10 лет) «Лидеры едят последними» — Саймон Синек;
(до 5 лет) «Коучинг agile-команд» — Лисса Адкинс;
(бизнес-роман) «Разворот корабля!…» — Л. Дэвид Маркет.
Координация
(50+ лет) «Динамика администрирования» — Мэри Паркер Фоллетт. Эту книгу сложно найти на русском, но стоит почитать хотя бы выдержки;
(~30 лет) «Мудрость команд» — Катценбах, Смит;
(до 10 лет) «Remote. Офис не обязателен» — Фрайд, Х. Х.;
(до 5 лет) «Антихрупкость в IT» — А. В. Бындю;
(бизнес-роман) «Пять пороков команды» — Патрик Лёнсиони.
Контроль
(50+ лет) «Экономический контроль качества продукции» — Уолтер Шухарт;
(~30 лет) «Сбалансированная система показателей» — Каплан, Нортон;
(до 10 лет) «Статистическое управление процессами» — Чамберс, Уилер;
(до 5 лет) «OKR. Инструмент, который изменит вашу компанию» — Нивен, Ламорт;
(бизнес-роман) «Приключения IT-директора» — Остин, Нолан, О’Доннелл.
Вывод: полезно понимать базис, а не слепо наворачивать процессы

Понимаете, не стоит торопиться со Скрамом, если вы ещё не постигли, как вообще планировать, организовывать и координировать. Иначе будете бегать с этой доской «todo – in progress– done» и не понимать, почему всё то же самое остаётся «in progress» уже третью неделю. Пока вы не можете базово, без готовых методологий и готового набора инструментов организовать работу, слепо их применять не стоит, просто потому что только их недостаточно
Овладеть 5 функциями — это как научиться плавать, вы уже потом сможете выбирать стиль: кроль, брасс, баттерфляй, свободное плавание... А если забыть про «фундамент», то поздравляю — вы утонете (с гордым криком «Scrumban!» в руке).
Мой совет по книгам: не ломитесь сразу во все «Agile»-библии вроде книг Майкла Кона или сборников все практик с авторскими взглядами вроде книг С. Беркуна, вместо этого почитайте базу, разберитесь, почему мы делаем план, зачем распределяем роли, как руководим людьми и что за зверь этот «контроль». И тогда вы сами станете раздавать задачи в Jira, но уже понимая, что и зачем вы делаете.
Да, и если вам всё ещё лень, ну что-ж... всегда есть путь через грабли. Но грабли — они такие: хлоп, и «звёздочки» перед глазами. Хотя глядишь, так урок и усвоится.
Удачи, коллеги. Помните: хороший PM точно знает, куда, зачем и с кем он плывёт, а не просто «гребем туда!».
Если вдруг статья заинтересовала - заглядывайте ко мне в канал https://t.me/junior_pm.
Комментарии (9)
Rhbnbr
31.01.2025 09:45На мой взгляд, многие проблемы начинаются когда проектом руководит не Руководитель проекта (начальник имеющий необходимые полномочия и обладающий необходимыми техническими компетенциями) а менеджер проекта.
Менеджер проекта, может быть достаточно для выполнения несложных, типовых проектовRenewal_Studio Автор
31.01.2025 09:45А откуда взялось представление что руководитель проекта и менеджер проекта это разные вещи? За свою карьеру неоднократно встречал таковое убеждение и не понимаю откуда растут ноги у него.
Renewal_Studio Автор
31.01.2025 09:45То что в СНГ часто ПМ-ам доют огромную ответственность, но почти никаких полномочий это правда
Fullthoughtless
TLDR
На мой взгляд стандарты PMI вполне себе покрывают нужды современного PM (в IT в особенности). А золотого правила не найти - проекты индивидуальны. И тот же Рис он про продукт и Lean Startup, где ты, если ты в роли PM будешь бегать как собачка за палкой, которую бросает Product/Owner, пока наконец хозяин не наиграется и его стартап не закроется (правило 99% никто не отменял). Так что планируй - не планируй, организовывай - не организовывай.
P.S. Выдавать книги списками - такое себе.
Нужна корректура.
Renewal_Studio Автор
Как на твой взгляд лучше описать список книг?
Спасибо ошибку исправлю!
Renewal_Studio Автор
Да, но для начинающих читать своды знаний и гайды PMI не лучшая затея
Fullthoughtless
Пожалуйста.
Начинающим нужно брать что-то для примера и обучаться по факту. Вряд ли ты построишь экскаватор, если ты не помахал лопатой. Для них, что стандарты PMI, что Agile, что труды Тейлора - все едино, может быть интересно, но непонятно. Поэтому стоит сочетать теорию с практикой.
И на мой взгляд то, что ты описал про менеджмент, это базовое-дополнительное. Т.е., что-то из этого я изучал в университете, а что-то потом читал дополнительно.
Список, на мой взгляд, никак. Я лично не люблю такие громоздкие списки. В лучшем случае выделить несколько книг. Иначе такой объем вводит в ступор и отбивает желание разбираться. Выглядит как список литературы в конце реферативной работы.
Renewal_Studio Автор
Ага, спасибо. Тут видимо моя вкусовщина сыграла, я не люблю отзывы на книги, люблю скорее просто узнавать о том что есть вот такая книга, в ней вот такой то материал раскрыт. А дальше уже изучать сам
Renewal_Studio Автор
Полностью согласен, взрослые иначе и не учатся, кроме как узнавая новое и сразу обжигаясь. пытаясь это применить на практике. Выше набор скорее структурный и направленный на рефлексию, не пытался им заменить реальный опыт