Одна из серьезных проблем в проектах – превышение сроков и бюджета. Можно даже сказать, что провальных проектов как бы и нет вовсе, а есть такие, срок которых увеличен до бесконечности, а бюджет пока закончился. Примечательно, что от превышения сроков страдают и исполнитель и заказчик. Заказчик не получает ожидаемого результата, а исполнитель – ожидаемых денег. Казалось бы, общая проблема должна объединять, но она зачастую только создает дополнительные проблемы между сторонами. Как сделать так, чтобы сроки и бюджет всегда выдерживались? Кое-чего в этом направлении нам удалось достичь.
Перед тем как рассказать о своем опыте, хотелось бы ответить на несколько принципиальных вопросов: чего хочет заказчик и чего хочет исполнитель при выполнении проектов? Будем исходить из того, что заказчик действительно хочет сделать проект. У него есть определенный бюджет, и он не собирается «кидать», а готов заплатить оговоренные деньги за получаемый результат. Понятно, что он хочет сделать за свои деньги как можно больше. А вы, когда делаете дома ремонт, разве этого не хотите? И как каждый хозяин, нанимающий бригаду строителей, заказчик, возможно, подозревает, что исполнитель будет его надувать раздувать бюджет. Что поделать, такова наша действительность.
Чего хочет исполнитель? В подавляющем большинстве случаев, проектная команда хочет сделать работу, а руководство хочет получить контрактные деньги. Но поскольку опытный исполнитель знает, чего хочет заказчик, и знает, что бюджет имеет тенденцию заканчиваться в самый разгар его желаний, то исполнитель стремится максимально раздуть бюджет.
Каждая из сторон, по-своему, права. С этим приходится мириться и в таких условиях, не договорившись окончательно, начинать проекты. Но изначальное недопонимание, как правило, в ходе проекта только увеличивается и приводит… не будем о грустном. Расскажу о принципах и методах ведения проекта, используемых нами, которые, так или иначе, имеют отношение к соблюдению сроков и бюджета. Возможно, кому-то это поможет улучшить качество собственных проектов.
Рамки проекта
Первый ключевой момент – проработка рамок. Рамки проекта – это документ, в котором написаны требования заказчика к системе, но не настолько фундаментальный как ТЗ. Функциональные рамки проекта составляет консультант/аналитик – сотрудник проектной команды исполнителя – на основе интервью с ключевыми специалистами заказчика. Рамки проекта – это полное понимание всех задач, которые нужно решить в ходе проекта, но без детализации. Это также перечень задач, которые не будут решены в ходе проекта. Этот вопрос занимает одну-две недели. Столько же может занять согласование и уточнение.
Обращаю внимание, что в этот момент еще нет контракта и нет проекта. И это риск, проект может так и не начаться. Кто оплатит работы исполнителя на составление рамок, оценку, планирование, подготовку бюджета? На этот вопрос предлагаю ответить вам самостоятельно. Могу лишь утверждать, что оценки сроков и бюджета, полученные без проработки рамок проекта – это фантазии, не имеющие отношения к реальности. Ничего удивительного в том, что в ходе проекта бюджет и сроки ползут, едут, летят.
Проработка архитектуры
После согласования функциональных рамок с заказчиком, консультант передает их архитектору. Тому архитектору, который впоследствии будет делать проект. Архитектор изучает рамки проекта, задает вопросы консультанту и продумывает архитектуру решения в целом и реализацию каждого конкретного требования – это второй ключевой момент. В результате появляется пара абзацев текста общей архитектуры – какие технологии предполагается использовать, и пару предложений по каждому требованию – какие компоненты предлагается разработать и какая ожидается трудоемкость в днях.
Иногда мы делаем отдельный документ «Оценка», в котором фиксируем оценку и предполагаемую реализацию. Иногда это делается в виде комментариев к каждому требованию в документе «Рамки проекта». Оценка архитектора занимает, как правило, два-пять дней. Возникающие у архитектора вопросы могут вскрыть непроработанные консультантом аспекты и потребовать дополнительной проработки. Это отлично, ведь уменьшаются риски возникновения данных проблем в ходе проекта. Проработку архитектуры и формирование вопросов архитектор может сделать самостоятельно. Но финальное совещание по обсуждению и оценке требований проектная команда проводит вместе, как минимум в составе: консультант, архитектор, руководитель проекта.
Архитектурные ограничения системы, вытекающие из решения, также фиксируются в документе «Рамки проекта». Помимо этого, в документе фиксируются события, значимые для проекта – необходимые ресурсы, которые должен предоставить заказчик, сроки подготовки оборудования, классов обучения и т.п.
Планирование работ
После проработки требований и понимания их реализации, производится предварительное планирование работ и ресурсов – архитектор определяет, каких исполнителей для реализации тех или иных требований можно привлечь, в каком порядке критично требования выполнять, какие существуют взаимозависимости между требованиями. Всю информацию аккумулирует руководитель проекта, перенося ее в план проекта.
В этот момент рождаются сроки проекта. Сначала все работы выстраиваются линейно. Далее задачи распределяются по ресурсам. Исходя из пожеланий, высказанных заказчиком по срокам, а также из оптимального сочетания привлекаемых ресурсов определяется длительность проекта. Под «оптимальным сочетанием привлекаемых ресурсом» имеется в виду простая мысль – сроки проекта должны быть минимальны, людей надо привлечь как можно меньше, но задействовать их максимально. Так появляются оценки длительности пребывания людей на проекте, которые являются основой для составления бюджета проекта.
Планирование работ мы делаем в MS Project. В плане работ мы проставляем трудоемкость выполнения той или иной задачи. Оценки, выданные архитектором, можно использовать только в сочетании с пониманием того, кто будет реализовывать эти требования. У нас должны появиться конкретные фамилии людей. И от того, кого конкретно мы привлекаем на данную задачу, будет зависеть корректировка оценки данной задачи.
Для корректировки оценки важно знать продуктивность каждого конкретного разработчика. Это третий ключевой момент. То же самое относится к остальным работам – инсталляция системы, подготовка технического задания, тестирование и т.п. Чтобы знать, сколько работа займет времени, мы должны знать, кто эту работу будет делать. Фактически, для планирования и оценки проекта, мы должны собрать проектную команду.
Оценка бюджета
В результате планирования работ появляются роли и люди, участвующие в проекте и длительность их пребывания на проекте.
Дальнейшие расчеты я, как руководитель проекта, делаю в таблице Excel. Примерно так:
Ресурс | Длительность (мес.) | Загрузка | Единиц | Трудо- затрат, (час) | Ставка в час | Стоимость (месяц) | Стоимость (без НДС) |
РП (Пашинин) | 5 | 0,5 | 2,5 | 420 | 2000 р. | 336 000 р. | 840 000 р. |
Ведущий консультант (Плешкова) | 4 | 1 | 4 | 672 | 1400 р. | 235 200 р. | 940 800 р. |
Архитектор (Шаповалов) | 5 | 1 | 5 | 840 | 1400 р. | 235 200 р. | 1 176 000 р. |
Консультант (Корх) | 4 | 1 | 4 | 672 | 1100 р. | 184 800 р. | 739 200 р. |
Ведущий разработчик (Харитонов) | 3 | 1 | 3 | 504 | 1400 р. | 235 200 р. | 705 600 р. |
Разработчик (Колесников) | 3 | 1 | 3 | 504 | 1100 р. | 184 800 р. | 554 400 р. |
|
|
|
|
|
|
| 4 956 000 р. |
В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно два-три дня.
Четвертый ключевой момент при составлении бюджета заключается в том, что мы переходим от трудоемкости задач, выставленной в плане, к длительности привлечения ресурсов. Логика простая. Основной статьей расходов исполнителя является оплата труда персонала. Если люди находятся на проекте дольше оплаченного времени, то компания исполнителя несет прямые убытки. Поэтому планировать и контролировать необходимо именно этот параметр. Если составление бюджета проекта и его контроль выполняется не на основе сроков пребывания людей, а на основе оценки задач, то можно быть уверенным, что в ставки специалистов заложены слишком высокие риски, чтобы не заботиться о реальном планировании ресурсов.
Уточнение рамок, срока, бюджета
В результате проделанной работы мы получили документы:
- Рамки проекта, согласованные с заказчиком.
- Оценка проекта с предполагаемой архитектурой и трудоемкостью реализации требований.
- План проекта.
- Бюджет проекта.
Это полное понимание того, что необходимо сделать, как это предполагается сделать, какое время это может занять, и сколько это будет стоить. Все четыре результата необходимо представить заказчику.
Бюджет проекта и сроки – это параметры, на основе которых заказчик будет принимать решение. Требования – это параметр, которым будут управлять заказчик и исполнитель для корректировки бюджета и сроков.
Поскольку оценка бюджета полностью прозрачна, то для уменьшения сроков и бюджета можно только выкинуть или снизить требования. Стоимостной оценки каждого требования у нас нет, поэтому мы ориентируемся на трудоемкость реализации, оцененной архитектором.
После пересмотра требований, руководитель проекта производит перепланирование, руководствуясь теми же принципами: минимальные сроки – оптимальная загрузка ресурсов. После перепланирования корректируется бюджет. Рамки, сроки и бюджет являются предметной частью контракта. Вся работа по формированию рамок, планированию и оценке у нас занимает две-шесть недель.
Вы уже ответили на вопрос, кто за это платит? На мой взгляд, платить должны и исполнитель и заказчик. Готовность заказчика понести расход на оценку свидетельствует о серьезности намерений в реализации проекта. Расходы исполнителя, точнее выполнение работ по себестоимости или ниже ее, свидетельствуют о его заинтересованности в проекте. Это мотивирует его сделать оценку в минимальные сроки. Это работа в убыток сейчас, но с максимальной проработкой, ведь это его риски в будущем. В каждом конкретном случае, ситуация может отличаться.
Управление сроком и бюджетом
Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос – что исполнитель продает заказчику? С одной стороны он продает результат – в контракте содержатся рамки работ, которые обязуется выполнить исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы – бюджет составляется на основании длительности привлечения ресурсов, то есть «time & materials». Это разные типы взаимоотношений.
Но мы должны понимать, что от тщательности оценки, опасения заказчика о превышении бюджета, а исполнителя о возможном изменении требований никуда не делись. Помочь убрать опасения и решить контрактные противоречия могут определенные договоренности между заказчиком или исполнителем о принципах управления изменениями.
Суть их заключается в следующем:
1) Исполнитель гарантирует выполнение проекта в оговоренные сроки и бюджет, в случае, если рамки проекта не будут изменены.
2) Исполнитель гарантирует, что в случае выполнения работ раньше срока, сотрудники исполнителя, при необходимости, продолжат работу на проекте в рамках оплаченного бюджета над дополнительными задачами.
3) Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства сторон остаются в рамках контракта.
4) Если изменения, вносимые в рамки проекта, влекут дополнительное привлечение ресурсов, то составляется дополнительное соглашение и заказчик оплачивает работы, превышающие первоначальный бюджет.
При данном подходе исполнитель не может получить дополнительную прибыль за счет экономии бюджета, так как вынужден отработать его до конца. В то же время, у заказчика появляется дополнительный четкий стимул в удержании рамок. В случае их изменения, и соответственно, превышении сроков проекта он будет оплачивать дополнительное время специалистов исполнителя. Если исполнитель честно выполняет свои обязательства о выделении ресурсов, то основным критерием удовлетворенности заказчика становится квалификация специалистов исполнителя.
Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:
- Для оценки сроков и бюджета необходимо сделать тщательную проработку рамок проекта. На это требуется время.
- Во время оценки трудоемкости выполнения задач выполняется проработка архитектуры предполагаемого решения, которая фиксируется письменно.
- Планирование трудоемкости задач производится на основе продуктивности тех специалистов, которые будут эти задачи выполнять. Продуктивность – это параметр, вычисленный по предыдущим проектам для каждого специалиста.
- Расчет бюджета выполняется на основе длительности пребывания ресурсов на проекте.
- В рамки проекта вносятся функциональные требования, архитектурные ограничения, а также обязательства заказчика, критичные для выполнения проекта исполнителем в срок.
- Исполнитель берет на себя обязательства по своевременному выделению качественных ресурсов в полном объеме на сроки, оговоренные в контракте для выполнения рамок проекта. Заказчик берет на себя обязательства по выделению дополнительного бюджета, в случае, если изменения в ходе проекта приводят к увеличению сроков и бюджета.
В дальнейшем, в ходе проекта, остается только четко следить за соблюдением рамок проекта и за соблюдением взаимных обязательств.
Впервые статья была опубликована на Executive.ru 10 сентября 2010 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции
Источник изображений: Фотобанк stockphotos
Валерий,
Из ваших пояснений я понял, что сначала у вас есть внутренний проект, функционал которого формируется на базе требований маркетинга и аналитиков. Финансируют этот проект инвесторы. Бюджет проекта в данном случае - его себестоимость.
Далее проект (система) продается. Цена проекта формируется в каждом случае своя, зависит от ряда условий. Т.е. она скорее всего не коррелирует напрямую с бюджетом проекта, т.к. система продаются по несколько раз, возможно, с вариациями (доработками). Так?
В данном случае, тогда, вероятно, стоит вести речь о бюджете проекта, а не о цене проекта. Каким образом формируется он? Знаете ли вы его в самом начале проекта? Стремитесь ли вы к его соблюдению?
Насколько я понимаю, философия Agile - это итерационная разработка. Каждая итерация - полный цикл разработки от планирования и анализа требований до тестирования, длительностью в несколько недель. Цель - получение в конце каждой итерации работающего функционала, значимого для заказчика. Т.о. проектная команда избавлена от необходимости жесткого фиксирования всех требований в самом начале проекта - в этом достоинство гибкой методологии разработки. Но это же не позволяет заранее оценить бюджет. Разве нет?