Управление проектами

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

Чем проект отличается от процесса

Процесс повторяется, проект заканчивается. Расчёт зарплаты, приём заявок, отгрузка — процессы: у них нет финала, есть цикл. Переезд офиса, запуск нового продукта, внедрение CRM — проекты: у каждого есть срок, бюджет и результат, после которого работа закрывается.

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

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

Сведу отличия в таблицу — по ней удобно проверять любую входящую задачу.

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

Стадии процесса управления проектами

Классическая модель делит проект на пять стадий: инициация, планирование, исполнение, контроль и завершение. Так стадии процесса управления проектами описывает PMBOK — свод знаний Института управления проектами PMI.

Инициация — договориться, зачем проект нужен и кто за него отвечает. Планирование — разложить результат на работы, сроки и деньги. Исполнение — сама работа. Контроль — сверка плана с реальностью, он идёт параллельно исполнению. Завершение — передать результат, закрыть договорённости, разобрать уроки.

Проведу через стадии один проект — внедрение CRM в отделе продаж. Инициация: коммерческий директор фиксирует, что менеджеры теряют заявки, и назначает руководителем проекта старшего менеджера. Планирование: выбор системы, перенос базы, настройка, обучение — четыре блока работ со сроками и ответственными. Исполнение: подрядчик настраивает, менеджеры переносят клиентов. Контроль: раз в неделю руководитель сверяет факт с планом и ловит отклонение — перенос базы встал, у людей нет времени. План пересобирают: перенос дробят на порции по часу в день. Завершение: отдел месяц ведёт сделки в системе без возврата к таблицам, проект закрыт, уроки записаны.

На словах линейно, в жизни стадии наслаиваются: вы планируете вторую очередь, пока команда делает первую. Гибкие подходы — Scrum, Kanban — родились как ответ на эту нелинейность, их авторы в 2001 году зафиксировали принципы в Agile-манифесте. Для руководителя, который ведёт первый проект, спор «водопад против эджайла» вторичен. Держитесь основы: у проекта есть цель, план и точка завершения. Остальное — настройки.

Управление проектами как предмет читают в вузах и на программах MBA, но семестровый курс не заменит одного честно доведённого до конца проекта. За один такой проект — пусть с сорванным дедлайном и пересобранным планом — человек растёт сильнее, чем за годы теории. Я наблюдал это не раз.

Проект без назначенного руководителя — это не проект.

Какие роли есть в команде проекта

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

Набор ролей, без которого проект буксует:

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

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

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

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

Роль в команде проекта — это зона ответственности, а не строчка в штатном расписании.

Как распределить роли, когда людей мало

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

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

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

Совмещать роли можно. Смешивать зоны ответственности — нельзя.

Типичные ошибки руководителя проекта

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

Цель не зафиксирована. Проект стартует с устного «ну ты понял». Через два месяца выясняется, что заказчик понял по-своему. Лечится паспортом проекта на одну страницу: цель, результат, срок, бюджет, роли.

Руководитель проекта делает сам. Ловушка толкового специалиста: сделать самому — двадцать минут, объяснить — час. Итог: план знает один человек, и он же завален работой. Как управлять проектами, если вы внутри каждой задачи? Никак. Руководство проектом — это управление чужими руками.

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

Изменения принимают молча. Заказчик по ходу просит «ещё вот это, раз уж делаем», руководитель проекта кивает, чтобы не спорить. Объём растёт, срок и бюджет — нет. Правило одно: каждое изменение проходит через пересчёт срока и денег, и заказчик выбирает — расширяем объём и двигаем дату или держим дату и режем объём. Молчаливое согласие съедает проекты чаще любых внешних рисков.

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

С чего начать свой первый проект

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

Как выглядит такой паспорт вживую. Цель: отдел продаж перестаёт терять входящие заявки. Результат: все сделки ведутся в CRM, заявки из почты и мессенджеров попадают туда автоматически. Срок: 1 октября. Бюджет: 300 000 рублей на лицензии и настройку. Роли: заказчик — коммерческий директор, руководитель проекта — старший менеджер, исполнители — подрядчик и два менеджера, эксперт — системный администратор. Семь строк, и по каждой можно спорить предметно, а не «в целях улучшения работы отдела».

Дальше — план на 10–15 строк, без диаграмм Ганта и специального софта. Таблицы хватит. Назначьте по одному ответственному на строку, договоритесь о ритме коротких статусов и о правиле: об отклонении говорим в день, когда его заметили, а не в день дедлайна.

Первый проект вы доведёте с опозданием и пересборкой плана — почти наверняка, и это честная цена обучения. А вот не начать, потому что «сначала надо разобраться в методологиях», — цена куда выше. Методологии описывают то, что вы и так сделаете: договоритесь о цели, распределите роли, дойдёте до результата. Разница в том, что после первого раза у вас будет не конспект, а опыт.

Записаться на разбор →