Одна и та же управленческая схема редко подходит всем проектам. В одном случае достаточно регламента и проверенной бригады. В другом проект держится на экспертизе пары ключевых людей. В третьем сначала приходится разобраться, что вообще нужно сделать, и только потом строить план.
Классификация проектов нужна, чтобы перестать «назначать сильного прораба на всё» и начать собирать команды осознанно: под уровень неопределённости, цену ошибки, число согласований и роль внешних участников. Тогда у проекта появляется шанс уложиться в сроки и деньги, а у команды — работать без постоянных конфликтов по ролям.
Дальше разберём типы проектов, их особенности и подходы, которые помогают управленцу собрать команду под конкретный формат работ. Если хочется свериться с базой по целям, ограничениям и ролям проекта, полезно держать под рукой статью «Основы управления проектами для предпринимателя».
Зачем управленцу знать классификацию проектов?
Классификация проектов — это способ заранее договориться с собой и командой, что именно будет «контролем» в этом проекте. Где-то контроль живёт в графике и чек-листе. Где-то — в журнале решений и регулярных технических ревью. Где-то — в быстрых итерациях и постоянной переприоритизации.
Если тип проекта не назван, управленец начинает тушить «пожары»: добавляет созвоны, просит отчёты, раздаёт задачи в чате. На короткой дистанции это даёт ощущение порядка, на длинной дистанции команда выгорает, а проект превращается в набор спорных договорённостей.
Ещё один бонус: легче выбрать инструменты управления. В 101 блоге эту тему разбирали в материалах «Средства управления проектами» и «Как выбрать систему управления проектами».
По каким признакам делят проекты?
Можно делить проекты по отрасли (стройка, IT, производство). Для управления это слабый критерий: два проекта в одной отрасли бывают разными по логике. Сильнее работает разрез по неопределённости и последствиям ошибок.
По каким признакам можно делить проекты:
- Определённость результата: понятны критерии «сдано/не сдано», зафиксированы объём работ и требования.
- Определённость способа: ясно, как делать, или сначала придётся искать техническое решение, собирать гипотезы, тестировать узлы.
- Цена ошибки: ошибка стоит пары дней и переделки или тянет юридические риски, большие деньги и репутацию.
- Зависимость от внешних сторон: сколько согласующих лиц, подрядчиков, поставщиков, сколько точек, где проект может остановиться.
- Темп изменений: требования живут месяцами или меняются каждую неделю.
Управленцу полезно фиксировать эти признаки в начале проекта в одном абзаце: «результат понятен», «способ понятен частично», «ошибка дорогая», «много внешних согласований». Этой записи хватает, чтобы выбрать тип проекта и понять, кого звать в команду.
Четыре типа проектов и их командная логика
Ниже — рабочая классификация проектов по неопределённости. Она подходит для строительных, ремонтных, инженерных, IT-проектов и любых проектных услуг.
| Тип проекта | Признаки | Управленческий фокус | Кого важно иметь в команде? |
|---|---|---|---|
| Регламентный | Результат и способ понятны, много повторяемых операций | План, нормы, контроль исполнения, качество, дисциплина договорённостей | Руководитель работ, снабжение, сметчик/расчётчик, контроль качества |
| Экспертный | Результат понятен, способ требует инженерных решений и координации | Решения, стыки, согласования, управление рисками и изменениями | Техлид (инженер), руководитель проекта, автор надзора/технадзор, сильный сметчик |
| Исследовательский | Результат описан как цель, способ неизвестен, много гипотез | Итерации, приоритеты, быстрые проверки, прозрачность прогресса | Владелец продукта/задачи, кросс-функциональная команда, аналитик/исследователь |
| Ситуационный | Работа в ограничениях: аварии, срывы поставок, внезапные требования | Быстрые решения, трияж задач, устранение блокеров, коммуникации | Кризисный руководитель, снабженец «с контактами», юрист/договорник, мастер на объекте |
Эта классификация проектов полезна тем, что напрямую объясняет, где находится «центр тяжести» проекта. В регламентном проекте управленец выигрывает за счёт стандартов. В экспертном — за счёт правильных решений и синхронизации. В исследовательском — за счёт скорости обучения. В ситуационном — за счёт реакции и ясной связи между людьми.
Подходы к управлению: что менять вместе с типом проекта?
Один из частых провалов выглядит так: проект исследовательский, управление построено как регламент. В результате команда тратит время на детальный план того, что ещё не понятно. Обратная ситуация тоже бьёт по деньгам: проект регламентный, управление идёт как бесконечная «гибкость», итогом становятся переделки и расползание сроков.
Ниже — что стоит менять по четырём зонам управления: планирование, решения, коммуникации, деньги. Про коммуникации полезно почитать «Управление коммуникациями проекта», там хорошо разобрана фиксация договорённостей и ожиданий.
- Регламентный проект: планируй этапами, держи чек-листы качества, фиксируй изменения через короткую процедуру согласования. Документы и решения складывай в одно место, чтобы на объекте не спорить о версии.
- Экспертный проект: вводи журнал решений (кто решил, почему, что поменяли, как влияет на сроки и деньги). Делай регулярные технические ревью: коротко, по стыкам, с подготовкой вопросов.
- Исследовательский проект: живи итерациями на 1–2 недели, держи список гипотез, показывай результаты часто. Здесь уместны практики Agile и Kanban. Если работа связана со стройкой, можно подсмотреть идеи в материале «Agile в строительстве».
- Ситуационный проект: работай короткими циклами «задача — владелец — срок — факт», ежедневно снимай блокеры. Коммуникации делай предельно прямыми: кто отвечает, кому докладывает, где фиксируется решение.
Деньги проекта меняются вместе с типом проекта. В регламентном проекте хорошо работает план-факт по статьям. В исследовательском важнее лимиты на итерацию и прозрачность трат по гипотезам. Финансовую логику удобно держать там, где команда реально ведёт работу, без таблиц и пересылок — об этом есть подробный разбор «Финансовое управление проектом в Приложении 101».
Как собрать команду под каждый тип проекта?
Сбор команды начинается не с фамилий, а с карты ролей. Роль — это зона ответственности и право принимать решения. Фамилия — человек, который эту роль тянет. Когда роли не названы, команда спорит о границах, управленец превращается в диспетчера.
Есть удобная конструкция: ядро (люди, которые нужны всегда) и усиление (подключаются по мере задач). Ядро даёт устойчивость, усиление защищает от лишнего фонда оплаты труда.
Регламентный проект. Ядро: руководитель работ/прораб, снабжение, контроль качества, расчётчик (смета, объёмы, спецификации). Усиление: узкие мастера по этапам, логистика. Управленцу стоит смотреть на дисциплину: привычка фиксировать объём, сроки, закрывающие документы, фотофакт. Здесь ценится «ровная» коммуникация, без личных договорённостей в обход правил.
Экспертный проект. Ядро: руководитель проекта, инженер/технический лидер, человек, который держит документацию и версии, сильный расчётчик. Усиление: авторский надзор, технадзор, узкие инженеры. Важно заранее назначить владельца решений по спорным зонам (инженерия, отделка, бюджет, сроки). Команда в этом типе тонет не в задачах, а в стыках.
Исследовательский проект. Ядро: владелец продукта (тот, кто отвечает за ценность и приоритеты), команда исполнителей с разными компетенциями, человек на анализе данных/фактов. Усиление: юрист, закупки, интеграторы. Управленцу важно защитить команду от бесконечного входящего потока и держать единый список приоритетов. Здесь полезно сразу договориться, как принимаются решения об остановке гипотезы.
Ситуационный проект. Ядро: кризисный руководитель, мастер/руководитель работ на месте, снабжение, договорник. Усиление: безопасность, инженеры, подрядчики «на подхват». Управленческий приём: один канал для решений, один короткий ежедневный созвон, один список блокеров. Команда в таких проектах держится на скорости и ясных полномочиях.
Когда проектов много, появляется портфель: деньги и люди перетекают между проектами. Тут помогает единая финансовая модель проекта и понятные правила перераспределения. В PRO+ есть функции для более плотного управленческого контроля и работы с внутренним фондом компании, если ты ведёшь несколько проектов одновременно.
Диагностика проекта перед набором людей
Чтобы классификация проектов работала в реальности, сделай короткую диагностику до того, как «раздать роли по привычке». На это хватает одной встречи с ключевыми участниками и 30 минут на фиксацию ответов.
- Запишите результат проекта одним предложением: что будет создано и по каким критериям это примут.
- Ответьте, понятен ли способ выполнения: есть технология, опыт, типовые решения, или сначала нужно искать вариант.
- Оцените цену ошибки: что будет, если решение окажется неверным (деньги, сроки, юридические последствия).
- Перечисли тевнешние зависимости: кто согласует, кто поставляет, кто влияет на доступ к работам, какие сроки у этих сторон.
- Назначьте владельцев четырёх зон: сроки, решения/изменения, коммуникации, деньги. Роли можно совмещать, когда проект маленький, совмещение тоже нужно зафиксировать.
- По ответам выберите тип проекта (регламентный, экспертный, исследовательский, ситуационный) и собери ядро команды.
Если хочется глубже разложить роли и структуру управления, в 101 блоге есть подборка материалов в разделе «Бизнес в строительстве» и статьи про систему управления, коммуникации и финансы проекта. Начать удобно со статьи «Как выбрать систему управления проектами»: она помогает понять, чем именно ты управляешь в проекте и где держать факты.