Как стать автором
Обновить

Управление бюджетом ИТ проекта

Время на прочтение9 мин
Количество просмотров13K


Не секрет, что одна из серьезных проблем в проектах – превышение сроков и бюджета. От этого страдают и Исполнитель и Заказчик. Заказчик не получает ожидаемый результат, а Исполнитель – ожидаемые деньги. Казалось бы, общая проблема должна объединять, но она зачастую лишь вбивает дополнительно клинья раздора между сторонами. Вы знаете, как сделать так, чтобы сроки и бюджет всегда выдерживались? Я – нет. Но кое-что в этом направлении нам удалось достичь. Перед тем как рассказать о своем опыте, хотелось бы ответить на несколько принципиальных вопросов: чего хочет Заказчик и чего хочет Исполнитель при выполнении проектов?


В нашем случае, мы будем исходить из того, что Заказчик действительно хочет сделать проект. У него есть определенный бюджет, и он не собирается «кидать», а готов заплатить оговоренные деньги за получаемый результат. Понятно, что он хочет сделать за свои деньги как можно больше. А вы, когда делаете дома ремонт, разве этого не хотите? И как каждый хозяин, нанимающий бригаду строителей, Заказчик, возможно, подозревает, что Исполнитель будет его надувать раздувать бюджет. Что поделать, такова наша действительность.

Чего хочет Исполнитель? Если это не афера, то в подавляющем большинстве случаев, проектная команда хочет сделать проект, а руководство хочет получить контрактные деньги. Но поскольку опытный Исполнитель знает, чего хочет Заказчик (см. выше), а также знает, что бюджет имеет тенденцию заканчиваться в самый разгар его желаний, то Исполнитель стремится максимально раздуть бюджет.

Каждая из сторон, по-своему, права. С этим приходится мириться и в таких условиях, не договорившись окончательно, начинать проекты. Но заложенное в самом начале проекта недопонимание, как правило, в ходе проекта только увеличивается и приводит… не будем о грустном. Расскажу о принципах и методах ведения проекта, используемых нами, которые, так или иначе, имеют отношение к соблюдению сроков и бюджета. Возможно, кому-то это поможет улучшить качество собственных проектов. Наша специализация — выполнение проектов автоматизации документооборота на ECM платформах, таких как, EMC Documentum, Alfresco. Возможно, это имеет определенную специфику, но надеюсь, непринципиальную для рассматриваемой здесь темы.

Рамки проекта


Первый ключевой момент – проработка Рамок проекта (по ГОСТ – «Тактико-техническое задание»). Рамки проекта – это документ, в котором написаны требования Заказчика к системе, но не такой фундаментальный как Техническое задание. Функциональные рамки проекта (Business requirements definition, BRD) составляет консультант/аналитик – сотрудник проектной команды Исполнителя, — на основе интервью с ключевыми специалистами Заказчика. Рамки проекта – это полное понимание всех задач, которые нужно решить в ходе проекта, но без детализации. Рамки проекта – это также перечень задач, которые не будут решены в ходе проекта. Составление рамок проекта занимает 1 – 2 недели. Столько же может занять согласование и уточнение. Обращаю внимание, что в этот момент еще нет контракта и нет проекта. И это риск, т.к. проект может так и не начаться. Кто оплатит работы Исполнителя на составление рамок, оценку, планирование, подготовку бюджета? На этот вопрос предлагаю ответить вам самостоятельно. Возможно, помогут ответы на вопросы, заданные выше: чего хотят Исполнитель и Заказчик в вашем случае. Могу лишь утверждать, что оценки сроков и бюджета, полученные без проработки рамок проекта – это фантазии, не имеющие отношения к реальности. Ничего удивительного в том, что в ходе проекта бюджет и сроки ползут, едут, летят.

Проработка архитектуры


После согласования функциональных рамок с Заказчиком, консультант передает их архитектору. Тому архитектору, который в последствии будет делать проект. Архитектор изучает рамки проекта, задает вопросы консультанту и продумывает архитектуру решения в целом и реализацию каждого конкретного требования – это второй ключевой момент. В результате появляется пара абзацев текста общей архитектуры – какие технологии предполагается использовать, — и пару предложений по каждому требованию – какие компоненты предлагается разработать и какая ожидается трудоемкость в днях. По сути — это «Эскизный проект». Но, если по ГОСТ «Этап 4.Эскизный проект» идет после «Этапа 3. Техническое задание», то мы в данном случае меняем этапы местами, т.к. без проработки архитектуры мы не можем сделать достоверную оценку трудоемкости. Иногда мы делаем его отдельным документом – «Оценка», в котором фиксируем оценку и предполагаемую реализацию. Иногда это делается в виде комментариев к каждому требованию в документе «Рамки проекта». Оценка архитектора занимает, как правило, 2-5 дней. Возникающие у архитектора вопросы могут вскрыть непроработанные консультантом аспекты и потребовать дополнительной проработки. Это отлично, т.к. уменьшаются риски возникновения данных проблем в ходе проекта. Проработку архитектуры и формирование вопросов архитектор может проделать самостоятельно. Но финальное совещание по обсуждению и оценке требований проектная команда проводит вместе, как минимум в составе: консультант, архитектор, руководитель проекта.

Архитектурные ограничения системы, вытекающие из решения, также фиксируются в документе «Рамки проекта». Помимо этого, в документе фиксируются события, значимые для проекта – необходимые ресурсы, которые должен предоставить Заказчик, сроки подготовки оборудования, классов обучения и т.п.
Шаблон рамок проекта можно посмотреть здесь: http://www.sinera.ru/methods.

Планирование работ


После проработки требований и понимания их реализации, производится предварительное планирование работ и ресурсов – архитектор определяет каких исполнителей для реализации тех или иных требований можно привлечь, в каком порядке критично требования выполнять, какие существуют взаимозависимости между требованиями. Всю информацию аккумулирует руководитель проекта, перенося ее в план проекта. В этот момент рождаются сроки проекта. Сначала все работы выстраиваются линейно. Далее задачи распределяются по ресурсам. Исходя из пожеланий, высказанных Заказчиком по срокам, а также из оптимального сочетания привлекаемых ресурсов определяется длительность проекта. Под «оптимальным сочетанием привлекаемых ресурсом» имеется в виду простая мысль – сроки проекта должны быть минимальны, людей должно быть привлечено как можно меньше, но задействованы они должны быть наиболее полно. Так появляются оценки длительности пребывания людей на проекте, которые являются основой для составления бюджета проекта.

Планирование работ мы делаем в MS Project.

Чуть не забыл важный момент.
В плане работ мы проставляем трудоемкость выполнения той или иной задачи. Оценки, выданные архитектором можно использовать только в сочетании с пониманием того, кто будет реализовывать эти требования. У нас должны появиться конкретные фамилии людей. И от того, кого конкретно мы привлекаем на данную задачу, будет зависеть корректировка оценки данной задачи, выданная ранее архитектором. Для корректировки оценки важно знать продуктивность каждого конкретного разработчика. Это третий ключевой момент. Подробней о том, как определять продуктивность, можно прочесть, например, у Джоэла Спольски в книгах «Джоэл о программировании» и «Джоэл. И снова о программировании» (Глава 20. Планирование с учетом прежних результатов (EBS).

То же самое относится к остальным работам – инсталляция системы, подготовка технического задания, тестирование и т.п. Для того чтобы знать, сколько работа займет времени, мы должны знать, кто эту работу будет делать. Фактически, для планирования и оценки проекта, мы должны собрать проектную команду.

Оценка бюджета


В результате планирования работ появляются роли и люди, участвующие в проекте и длительность их пребывания на проекте. Дальнейшие расчеты я, как руководитель проекта, — делаю в таблице Excel. Примерно так:
 РП (Пашинин)  5 0,5  2,5  420  2000 р.  336 000 р.  840 000 р.
 Ведущий консультант (Плешкова)  4  1  4  672  1400 р.  235 200 р.  940 800 р.
 Архитектор (Шаповалов)  5 840  1400 р.  235 200 р.  1 176 000 р. 
 Консультант (Корх)  4 672  1100 р.  184 800 р.  739 200 р. 
 Вед.Разработчик (Харитонов) 504  1400 р.  235 200 р.  705 600 р. 
 Разработчик(Колесников)  3 504  1100 р.  184 800 р.  554 400 р. 
               4 956 000 р.


В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно 2-3 дня.

Четвертый ключевой момент при составлении бюджета заключается в том, что мы переходим от трудоемкости задач, выставленной в плане, к длительности привлечения ресурсов. Логика простая. Основной статьей расходов Исполнителя является оплата труда персонала. Если люди находятся на проекте дольше оплаченного времени, то компания Исполнителя несет прямые убытки. Поэтому планировать и контролировать необходимо именно этот параметр. Если составление бюджета проекта и его контроль выполняется не на основе сроков пребывания людей, а на основе оценки задач, то можно быть уверенным, что в ставки специалистов заложены слишком высокие риски, чтобы не заботиться о реальном планировании ресурсов.

Уточнение рамок, срока, бюджета


В результате проделанной работы мы получили документы:
  • Рамки проекта, согласованные с заказчиком
  • Оценка проекта с предполагаемой архитектурой и тродоемкостью реализации требований
  • План проекта
  • Бюджет проекта


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

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

Вся работа по формированию рамок, планированию и оценке у нас заняла 2-6 недель. Вы уже ответили на вопрос, кто за это платит? На мой взгляд, платить должны и Исполнитель и Заказчик. Готовность Заказчика понести расход на оценку свидетельствует о серьезности намерений в реализации проекта. Расходы Исполнителя, точнее выполнение работ по себестоимости или ниже ее, свидетельствуют о его заинтересованности в проекте. Это мотивирует его сделать оценку в минимальные сроки, т.к. это работа в убыток сейчас, но с максимальной проработкой, т.к. это его риски в будущем. В каждом конкретном случае, ситуация может отличаться.

Управление сроком и бюджетом


Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос — что Исполнитель продает Заказчику? С одной стороны он продает результат, т.к. в контракте содержатся рамки работ, которые обязуется выполнить Исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы, т.к. бюджет составляется на основании длительности привлечения ресурсов, т.е. «time & materials». Это разные типы взаимоотношений. Но мы должны понимать, что от тщательности оценки, опасения Заказчика о превышении бюджета, а Исполнителя о возможном изменении требований никуда не делись. Помочь убрать опасения и решить контрактные противоречия могут определенные договоренности между Заказчиком или Исполнителем о принципах управления изменениями. Суть их заключается в следующем:
  • Исполнитель гарантирует выполнение проекта в оговоренные сроки и бюджета, в случае, если рамки проекта не будут изменены.
  • Исполнитель гарантирует, что в случае выполнения работ раньше срока, сотрудники Исполнителя, при необходимости, продолжат работу на проекте в рамках оплаченного бюджета над дополнительными задачами.
  • Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства Заказчика и Исполнителя остаются в рамках контракта.
  • Если изменения, вносимые в рамки проекта, влекут дополнительное привлечение ресурсов, то составляется дополнительное соглашение и Заказчик оплачивает работы, превышающие первоначальный бюджет.


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

Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:
  1. Для оценки сроков и бюджета необходимо сделать тщательную проработку рамок проекта. На это требуется время.
  2. Во время оценки трудоемкости выполнения задач, выполняется проработка архитектуры предполагаемого решения, которая фиксируется письменно.
  3. Планирование трудоемкости задач производится на основе продуктивности тех специалистов, которые будут эти задачи выполнять. Продуктивность – это параметр, вычисленный по предыдущим проектам для каждого специалиста.
  4. Расчет бюджета выполняется на основе длительности пребывания ресурсов на проекте.
  5. В рамки проекта вносятся функциональные требования, архитектурные ограничения, а также обязательства Заказчика, критичные для выполнения проекта Исполнителем в срок.
  6. Исполнитель берет на себя обязательства по своевременному выделению качественных ресурсов в полном объеме на сроки, оговоренные в контракте для выполнения рамок проекта. Заказчик берет на себя обязательства по выделению дополнительного бюджета, в случае, если изменения в ходе проекта приводит к увеличению сроков и бюджета.


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

Удачи на проектах!
Теги:
Хабы:
Всего голосов 23: ↑20 и ↓3+17
Комментарии4

Публикации

Ближайшие события