Когда я открываю план проекта, первые две цифры, которые я смотрю – длительность (duration) и бюджет (cost). И если я вижу, что бюджет проекта 53 321,45$, а длительность – 93,7 дня, то точно знаю, что план проекта составлен неопытным ПМом. Почему? В жизни никогда не бывает таких точных цифр. Бюджет проекта обычно кратен тысячам, а длительность – неделям или месяцам. Почему? Читай ниже.
Итак, давайте как всегда разбираться по порядку.
Из чего складывается продолжительность? Умная книга PM BoK учит нас, что длительность проекта есть суммарная длительность задач на критическом пути (кто не знает, что такое «критический путь», то намекаю – название книги приведено не случайно).
Дальше. Что есть бюджет? Бюджет есть сумма двух величин – постоянных и переменных затрат. Постоянные затраты – это то, что платится один раз (например, покупка сервера под проект). Именно так, а не иначе. Если ты считал иначе – ты ошибался: http://en.wikipedia.org/wiki/Fixed_cost).
Переменные затраты – это то, что платится по времени (характерный пример – заработная плата). Как бюджет проекта соотносится с длительностью? Очень просто, если написать в первом приближении грубой формулой, то выглядит это так:
Бюджет = постоянные затраты + переменные затраты * длительность
Исходя из этого знания получается, что считать бюджет очень просто. Давайте разберемся на примере. Итак, дано.
- Предположим, у нас есть четыре задачи, связанный с другом как Finish – Start (последовательное выполнение): inception, elaboration, construction, transition.
- У нас есть три ресурса, выделенные под проект на 100%: Analyst (себестоимость — $10 в час), Architect (себестоимость — $15 в час), Developer (себестоимость — $10 в час).
- В добавок нам надо купить сервер под проект ($2000).
Требуется: рассчитать длительность и бюджет проекта.
Разберемся сначала с продолжительностью, потому что это самое простое.
Вводим наши задачи в MS Project. Устанавливаем связи. Добавляем ресурсы (кто что делает). Получаем фигуру 1.
Рис. 1. Отправная точка планирования — задачи, взаимосвязи, ресурсы.
Это – отправная точка планирования. Переключаем наш Project в режим ввода трудозатрат на задачи и консультируемся с командой – вот вводные данные, кому сколько времени на задачу потребуется?
Команда отвечает:
- Аналитику на Inception – 22 часа (рассчет-обоснование рассказал)
- Архитектору на Elaboration – 13 часов (рассчет-обоснование рассказал)
- Разработчку на Construction – 47 часов (рассчет-обоснование рассказал)
- Архитектору и Разработчику на Transition – 17 часов (рассчет-обоснование рассказал)
Отлично. Вводим данные в Project.
Рис. 2. Из оцененных трудозатрата Project автоматически рассчитает длительность.
Project оказывает нам неоценимую услугу – зная, что ресурсы выделены на 100%, он рассчитывает для нас длительность задач (длительность = трудозатраты \ доступные ресурсы).
Ура! Мы знаем длительность. Осталось посчитать бюджет! Переходим в представление Cost.
Нам любезно показывают, что переменные затраты составят 1097$ (сколько часов работает каждый из ресурсов * часовую ставку ресурса). Осталось добавить 2000$ фиксированных затрат – и мы получим бюджет! Вуаля!
Рис. 3. Общий бюджет проекта = переменные + постоянные затраты.
Общий бюджет проекта посчитан! Он составит 3097,50$ при длительности 11,31 дня! Задача решена! Можно идти к Спонсору проекта за утверждением. Он не утвердит (если хочет, чтоб бюджет был выполнен) и вот почему.
Потому, что полная ахинея получилась. Первый, и самый главный промах:
Предполагается, что задачи дискретны. То есть, Аналитик выполнил свои задачи, и больше его помощь никому не понадобится. Чисто из опыта – у кого на проекте так было?
То же самое и со всеми остальными специалистами, которых в проекте обычно не 3 человека. Из практики можно сказать – каждый специалист проекта на протяжении всего жизненного проекта занят работами по проекту. Аналитик – поддерживает актуальной спецификацию требований, тестер – тестирует выпущенные билды и т.д. То есть, если ваш проект продолжительностью 10 дней, то все специалисты будут заняты все 10 дней. На какой процент времени? Заранее предсказать невозможно, потому что в дело вступает куча факторов – стабильность требований, аккуратность тестирования, сложность среды развертывания и т.д.
Поэтому ваши оценки в 17 часов для опытного ПМа выглядят дико. Он знает, что вы их не выполните. Неизвестно, сколько часов в день отожрет у Аналитика работа с Заказчиком, который регулярно меняет требования.
Ошибка вторая – никто никогда не смог выполнить свои эстимации с точностью до часа. Есть такая штука – мусорное время. Предположим, активное полезное время в вашей команде выглядит вот так:
Рис. 4. Легко увидеть, что осмысленной работе по проекту человек может посвятить в лучшем случае половину своего времени.
Это означает, что самый продуктивный человек в вашей команде занят осмысленной деятельностью по проекту чуть больше половины своего рабочего времени! Соответственно, все свои оценки вы можете смело умножать на два! (статистика собрана с помощью замечательного инструмента 6th sense analytics, который можно найти здесь: www.6thsenseanalytics.com)
Ну и конечно стандартная ошибка – вы что же, предполагаете, что требования не изменятся и что в выпущенном продукте не будет дефектов? Куда вы денетесь… И если время, ресурсы и деньги для того, чтобы это исправить, не заложены в ваш бюджет – то горе вам. Именно поэтому длительность обычно кратна неделям (для проекта менее полугода) или месяцам (для проекта от полугода и выше).
Мда, скажете вы, довольно мрачно. Что же делать? Очень просто. Все, что вы до сей поры посчитали – это вид бюджета со стороны ПМа. Переключите вид – посмотрите на бюджет со стороны того, кто является вашим начальником.
Некоторые ответы сразу станут очевидны, некоторые нет. Очевидные вещи пишу списком в виде «хороших практик».
- Во-первых, всегда отталкиваться в планировании работ от объема требований. Каждая задача – реализация требования. Иначе ваше планирование оторвано от целей проекта.
- Во-вторых, не забывайте, что разработка не висит в воздухе – нужно время на тестирование, развертывание, конфигурирование среды, репликацию и т.д. Учитывайте его в планах.
- В-третьих, надо отдавать себе отчет о том, что вы планируете в идеальных часах. Соответственно надо знать коэффициент пересчета из идеальных часов в реальные для своей команды.
- В-четвертых, при оценке переменных затрат исходить не из количества часов, которое вы напланировали, а из загрузки (workload) человека. С этой концепцией обычно возникает больше всего сложностей, поэтому ее объясню детально.
Как вы обычно считает стоимость участия человека в проекте? Очень просто – у него есть часовая ставка и трудозатраты, назначенные ему в проекте (assignments). Перемножаем эти две вещи – получаем стоимость его участия. Правильно?
Неправильно. Предположим, человек назначен к вам на проект на 148 часов. На практике это означает, что он работает у вас на проекте месяц (1 месяц = 160 рабочих часов). Это что получается – работал он месяц, а зарплату он получит за 148 часов? Нет, заплатить ему придется за 160 часов. А на кого списать оставшиеся 12 часов? Вообще говоря, на тот проект, где он месяц занят – это справедливо. Соответственно стоимость его участия в вашем проекте = 160 часов * его часовую ставку. (Если вы этого не учли, ваш бюджет с негодованием будет отвергнут вашим шефом).
Поэтому пятый, и последний, совет. Включайте переменные затраты на своих людей в проект следующим образом:
Стоимость участия = длительность проекта в часах * % загрузки по проекту * часовую ставку
Тогда получается, что вы заранее включаете человека в проект с гарантированной доступностью.
Зачем это надо? Если вы включили Аналитика с 100% загрузки на 3 месяца – это значит, что все три месяца, которые продолжается проект, когда вам понадобится аналитик – он у вас будет. С точки зрения вашего начальника – вы молодцы, потому что понятно, куда списать затраты на эти три месяца.
Как это сделать технически, например в MS Project? Назначайте ресурсы на суммарные задачи, задавая процент выделения (например, на суммарную задачу фазы Inception длительностью месяц на 100% — и переменные затраты посчитать легко, и выделение человека себе вы обозначили).
А можно этого не делать? Можно. Можно попытаться посчитать количество часов его времени на каждый день трехмесячного проекта – но какова вероятность того, что вы УГАДАЕТЕ? (а как еще назвать попытку предсказать сколько часов понадобится отработать человеку в определенный день через три месяца неопределенного будущего?).
Итого. Теперь вы знаете самые распространенные ошибки, которые лезут в календарные планы и бюджеты проектов. Кто предупрежден – тот вооружен, и теперь у вас неплохие шансы их избежать. У вас – это у проектной команды, потому везде в тексте слово «вы» написано с маленькой буквы. Проектное планирование, оценки, обсуждение с руководством – это сфера ответственности команды, и если план плох, то пострадает в конечном итоге вся команда. В общем, удачи!
Автор: Денис Петелин, SEADMEX