Руководитель проекта без иллюзий. Как начать, не утонуть в хаосе и довести проект до результата

2.5. ПЛАНИРОВАНИЕ И ОЦЕНКА РЕСУРСОВ

Для начала стоит ответить себе на следующие вопросы:

— На что компания тратит больше всего денег?

— Что является для компании главным ресурсом?

Ответ на оба вопроса один, он прост и думаю вы сами это понимаете — сотрудники компании. Сотрудники, которые своим трудом создают продукты и зарабатывают для компании деньги. И именно на их зарплаты, отпуски, больничные, налоги, премии, обучение, оборудование и прочее приходится основная масса затрат компании.

Планирование этих ресурсов позволяет получить нужное количество ресурсов в нужный момент и избежать незанятости («простоя») сотрудников, а это значит минимизировать потери.

Итак, давайте теперь поговорим о самом ресурсном планировании. Начнем с того, что такое планирование ресурсов.

2.5.1. ПЛАНИРОВАНИЕ РЕСУРСОВ

Планирование ресурсов — это процесс определения того, какие ресурсы необходимы для успешного выполнения различных видов деятельности в рамках проекта, как, когда, на что эти ресурсы будут выделены и использованы.

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

Наиболее распространёнными категориями ресурсов являются:

— люди;

— знания;

— деньги;

— техническое оборудование;

— время;

— материалы.

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

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

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

Поэтому планирование ресурсов должно отвечать не только на вопрос «Что нам нужно?», но и на вопросы:

— «Когда это понадобится?».

— «Кто подтверждает доступность ресурса?».

— «Есть ли ограничения по использованию ресурса?».

— «Что произойдёт, если ресурс не будет доступен вовремя?».

Если эти вопросы не задать заранее, ресурсный план легко превращается в список пожеланий.

А список пожеланий — это не план. Это аккуратно оформленная надежда.

РЕСУРС — ЭТО НЕ ТОЛЬКО ЧЕЛОВЕК

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

Но ресурсами проекта являются не только сотрудники.

Ресурсом может быть:

— специалист с нужной компетенцией;

— эксперт, который нужен на несколько часов для консультации;

— подрядчик;

— оборудование;

— сервер;

— тестовая среда;

— лицензия на программное обеспечение;

— помещение;

— материалы;

— доступ к данным;

— согласование от конкретного должностного лица;

— время заказчика или представителя бизнеса.

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

Поэтому при планировании ресурсов важно задавать не только вопрос «Кто будет делать задачу?», нужно также спрашивать: «Что ещё нужно, чтобы эта задача действительно могла быть выполнена?».

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

Если чего-то из этого нет, задача в плане есть, но реальной возможности выполнить её нет.

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

НАЛИЧИЕ РЕСУРСА И ДОСТУПНОСТЬ РЕСУРСА

Важно различать наличие ресурса и его доступность:

— Наличие означает, что ресурс в принципе существует.

— Доступность означает, что ресурс можно использовать в нужный период и в нужном объёме.

Разница очевидна.

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

Плохой ресурсный план говорит — «Нам нужен аналитик».

Хороший ресурсный план уточняет — «Нам нужен аналитик в период подготовки требований, и его участие должно быть подтверждено заранее».

Плохой ресурсный план говорит — «Нужна тестовая среда».

Хороший ресурсный план уточняет — «Тестовая среда должна быть готова до начала проверки, с выданными доступами и тестовыми данными».

Вот здесь и проходит граница между планом и красивой самообманной таблицей.

Ресурс в таблице не равен ресурсу в проекте. Пока доступность не подтверждена, это не ресурс, а предположение.

КОМПЕТЕНЦИИ РЕСУРСОВ

Ещё одна ошибка — считать ресурсы полностью взаимозаменяемыми.

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

— один разработчик хорошо знает нужный модуль, другой видит его впервые;

— один аналитик уже работал с этим заказчиком, другой только входит в контекст;

— один тестировщик понимает бизнес-логику продукта, другой может проверить только формальные сценарии;

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

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

Вот мы и приходим к пониманию, что проекту нужны не абстрактные «единицы ресурсов», а конкретные знания, опыт, доступы и возможности.

Если не учитывать компетенции, можно формально закрыть потребность в ресурсах, но фактически получить задержки, ошибки и переделки.

В документе всё будет выглядеть прилично. В работе — начнёт сыпаться.

ЧТО ДОЛЖЕН ПОКАЗАТЬ ПЛАН РЕСУРСОВ

Хороший план ресурсов должен помогать руководителю проекта ответить на несколько практических вопросов:

— какие ресурсы нужны проекту;

— для каких задач они нужны;

— когда они понадобятся;

— кто отвечает за их предоставление;

— подтверждена ли их доступность;

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

Последний пункт особенно важен.

Если без конкретного специалиста, среды, оборудования, доступа или согласования проект остановится, это уже не просто ресурс. Это ограничение проекта, которое нужно контролировать заранее.

Плохое ресурсное планирование часто можно узнать по простой фразе: «Мы думали, он будет доступен». Но реальность другая, хорошее ресурсное планирование заранее уточняет: «Он действительно доступен? Кто это подтвердил? В какие даты? Какие есть ограничения? Что делаем, если он недоступен?».

Пока на эти вопросы нет ответов, неопределённость высока и ресурсный план нельзя считать готовым.

ПРАКТИЧЕСКАЯ ПРОВЕРКА РЕСУРСНОГО ПЛАНА

Перед переходом к оценке ресурсов план нужно проверить на реальность. Не «пробежать глазами», а именно проверить.

Для этого можно пройтись по простому списку вопросов:

— все ли ключевые ресурсы перечислены;

— понятно ли, зачем нужен каждый ресурс;

— указано ли, когда ресурс понадобится;

— подтверждена ли доступность ключевых специалистов;

— есть ли у специалистов нужные компетенции;

— нужны ли доступы, лицензии, оборудование или тестовые среды;

— понятно ли, кто отвечает за предоставление ресурса;

— есть ли зависимость от заказчика, подрядчика или другого подразделения;

— понятно ли, что произойдёт, если ресурс не будет доступен вовремя.

Если хотя бы по одному ключевому ресурсу ответ неясен, значит ресурс ещё не спланирован до конца.

Он может быть указан в документе, но пока не подтверждён управленчески.

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

ПЕРЕХОД К ОЦЕНКЕ РЕСУРСОВ

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

Важно не путать эти два шага:

— Планирование ресурсов отвечает на вопрос: «Какие ресурсы нужны проекту и когда они должны быть доступны?».

— Оценка ресурсов отвечает на вопрос: «Сколько этих ресурсов потребуется и сколько времени займёт работа с их учётом?».

Например, на этапе планирования ресурсов руководитель проекта определяет, что для задачи нужны аналитик, тестировщик, тестовая среда, доступы и участие представителя заказчика.

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

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

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

ИТОГ

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

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

Запомните:

— ресурс — это не только человек, но и знания, деньги, оборудование, время, материалы, доступы и согласования;

— наличие ресурса ещё не означает его доступность;

— ресурс должен быть нужен не «вообще», а под конкретную задачу и период;

— компетенции важны не меньше количества людей;

— ресурс в таблице без подтверждённой доступности — это не ресурс, а надежда;

— хороший ресурсный план показывает не только что нужно, но и кто, когда и на каких условиях это предоставит;

— сначала нужно понять, какие ресурсы нужны и доступны, а затем переходить к их оценке.

2.5.2. ОЦЕНКА РЕСУРСОВ

По моему мнению может быть один вариант оценки ресурсов — через составление объёма работ и его оценку.

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

Задачи будут вписаны в план-график, чтобы свести к минимуму пересечения («перекрытия») задач и ограничения. Оценка продолжительности должна учитывать саму работу, её масштабы и наличие необходимых ресурсов.

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

Замечу:

Описанное выше правило работает не всегда.

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

— Профессионализм исполнителей.

— Участие выделенных на проект специалистов в других проектах.

— Невозможность распараллелить задачи.

Ещё один важный момент для руководителя проекта — стоимость каждого ресурса. Исходя из своего опыта скажу, что она складывается минимум из: оплаты труда (зарплата, подоходный налог, премии — да, это нужно учитывать, выплаты в пенсионный фонд и фонд социального страхования, медицинская страховка, иногда компенсация питания), общехозяйственных и административных расходов (рабочее место, оборудованное помещение, техника, связь, серверы, обеспечивающий персонал — HR, бухгалтеры, юристы, персонал обслуживания — уборщики, завхозы). Могут быть и другие пункты. Эта информация понадобится для следующего шага в планировании. Итак, с общей вводной закончили, идем дальше.

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

Для первичного ресурсного планирования достаточно получить список того, что хочет клиент. Это также даст возможность спрогнозировать объём работ, количество специалистов, последовательность работ. Если клиент предоставляет этот список, то это очень хорошо. Часто бывает, что клиент не до конца сам понимает, что он хочет и нужно самим сделать за него эту работу, и согласовать с ним. Приведу несколько методов, которые может использовать руководитель проекта для определения возможного функционала планируемого продукта:

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

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

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

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

— Комбинация. Совместное использование нескольких вариантов из вышеуказанных.

В своей работе часто использую комбинированный подход, состоящий из «Анализ альтернатив» и «Оценка снизу вверх», на нём и сосредоточусь.

Замечу:

На более мелкие временные интервалы, чем неделя делать разбивку при первом приближении не стоит. Со временем план будет меняться и детализироваться.

Процесс оценки можно разбить на шаги. У меня их семь, у вас может что-то отличаться. Далее распишу эти шаги и что в них нужно делать:

— Шаг 1. Допустим, мы получили от заказчика описание, какой продукт он хочет и какие задачи он должен решать. Клиент заполнил Бриф (сам или совместно с руководителем проекта), на его основе сформировали и проработали бизнес-требования. Далее проектная команда под управлением руководителя проекта прогнозирует (метод мозгового штурма), какой функционал может потребоваться заказчику (нужно считать максимальный вариант возможностей, главное, чтобы это было логично, а не просто добавили для объёма) для достижения его целей.

— Шаг 2. Когда проектная команда сформировала у себя видение проекта, нужно систематизировать информацию, превратив её в список функциональных задач. Для этого также нужны усилия руководителя проекта и проектной команды. Список функциональных задач будет выглядеть приблизительно так:

— Регистрация и управление пользователями.

— Создание и управление группами.

— Создание онлайн-заявки на клиентской части (форма заявки с такими-то параметрами…).

— Управление расписанием сотрудников.

— Планирование закупок.

— Ведение и просмотр статистики по заявкам (перечисляются параметры и фильтры). — И так далее.

Если есть необходимость, то функциональные задачи можно разбить на подзадачи.

Этот список желательно согласовать с клиентом, чтобы понять, правильно ли его поняли и нужно ли ему то, что описано в списке. Некоторые пропускают это согласование и делают сразу прогнозную оценку работ по задачам, собирая данные в отдельный документ (тут нужно понимать проблемный клиент или нет, можно себе такое позволить или будут проблемы). Этот документ создаётся на этапе «Инициация», его также называют ballpark, о нём мы говорили в первой главе.

— Шаг 3. Далее подробней опишу, что это за документ и как это всё должно работать. Руководитель проекта с проектной командой делают прогнозную оценку по времени разработки предполагаемого функционала (с максимально допустимыми возможностями, но в пределах разумного).

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

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

Таблица 2 — Пример таблицы с прогнозными расчётами

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

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

Если заказчик не согласовал стоимость, нужно подумать, за счёт чего можно уменьшить объём работ, а значит и стоимость: упростить часть функционала, убрать отдельные возможности или увеличить срок работы над проектом, если такой вариант подходит клиенту.

— Шаг 4. После достижения согласия по стоимости работ и списку функциональных возможностей между всеми сторонами стоит приступить к детальному описанию функциональных возможностей (с постоянным взаимодействием с заказчиком) и проработке технического задания.