Проект строительства MS project

Обновление:

Описанные в этой статье возможности теперь частично реализованы в PlanBridge — отраслевом дополнении к MS Project для строительных организаций.

Мы придерживаемся точки зрения, что для управления проектами в компаниях-генподрядчиках строительства не обязательно внедрять MS Project Server. Но вместе с этим смелым заявлением нужно представить и альтернативу. Мы считаем настольный MS Project, в котором работает планировщик, очень полезным инструментом для строительных компаний, и вместо сервера предлагаем использовать супер-десктоп на основе Project, содержащий отраслевые надстройки. Теперь предстоит ответить на вопросы: как сделать Project более эффективным для работы в строительной отрасли? Как следует расширить его возможности?

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

Если достраивать MS Project функциями Spider, совсем не обязательно реализовывать все «навороты». Лучше воспользоваться популярным эмпирическим правилом «20/80», согласно которому, 20% функций программы дадут нам 80% эффекта от ее использования. К тому же, попытка с ходу внедрить все передовые методологии управления проектами может привести к провалу всего внедрения. Контроль над процессами управления приобретается постепенно.

Что мы добавим в MS Project для управления строительными проектами

Вкратце опишем состав нашего решения для генподрядчиков строительства на основе MS Project.

Взаимодействие с подрядчиками

Для обмена проектной информацией с подрядчиками и субподрядчиками мы предлагаем использовать файлы формата MS Excel. Их можно экспортировать из проекта и импортировать в проект как с использованием встроенных в MS Project мастера экспорта и мастера импорта, так и с помощью нашей коммуникационной надстройки PlanBridge.

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

Модуль ресурсных расчетов

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

Частично это повторение функций сметных программ, но они обладают куда более скудными возможностями календарного планирования. Однако необходима возможность импорта данных из сметных программ через популярный формат АРПС. Поскольку советские Нормы затрат материальных ресурсов и рабочей силы (СНиП 5.01.01 — СНиП 5.01.17) давно потеряли актуальность, сметы являются главным источником данных для первоначального формирования справочников нормативов.

Шаблоны блоков работ

Помимо физ. объемов, при планировании строительных проектов удобно повторно использовать и целые блоки работ, например, такие, как этапы технологического процесса. Шаблоны блоков работ представляют собой файлы проектов MS Project, предварительно разработанные в компании и собранные в библиотеку.

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

Строительные проекты очень разнообразны, а потому нет гарантии, что описанные дополнения MS Project найдут применение во всех строительных компаниях. В первую очередь их следует внедрять в отраслях, где распространено нормирование, а проекты зачастую типовые и объем работ по ним велик. Например, это дорожное строительство и строительство инфраструктурных объектов. Но даже если в организации нашлось применение только одному из компонентов нашего решения, это пойдет на пользу её проектам.

В помощь менеджеру: планируем проект в MS Project

Знакомьтесь, это Microsoft Project, сложное ПО для управления проектами. Помогает менеджеру в текущих задачах: планировать, распределять ресурсы, анализировать сложность проекта. Автоматически делает отчеты и считает сметы. Если в нем разобраться, может стать незаменимым.

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

Как строить планы в MS Project

Создайте новый проект

В программе есть разные шаблоны, например, Простой план проекта, Запуск нового продукта или Гибкое управление проектами. Выберите подходящую структуру или откройте Новый проект.

Новый проект до внесения данных

Определите задачи

Они зависят от типа проекта. Сначала пропишите общие этапы, а потом разделите на конкретные. Для примера будем делать простой интернет-магазин. Этапы могут быть такими: аналитика, главная страница, каталог товаров, интеграция с сервисами оплаты и доставки, личный кабинет.

На верхней панели выберите блок Задача и найдите кнопку Суммарная задача. С ее помощью создайте все общие этапы. Позже добавьте подробностей.

Общие этапы проекта

Конкретизируйте задачи

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

Сведения о задаче

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

Сведения о задаче Агрегация требований

Добавьте задачи в таблицу. У нашего интернет-магазина они будут следующие.

Для аналитики:

  1. агрегация требований;
  2. прототипирование;
  3. техническое задание;
  4. проектирование базы данных.

Для главной страницы и каталога товаров:

  1. дизайн;
  2. верстка;
  3. разработка.

Для оплаты и доставки:

  1. подключение PayPal;
  2. подключение СДЭК.

Для личного кабинета:

  1. авторизация;
  2. регистрация;
  3. восстановление пароля;
  4. бонусная система;
  5. отложенные заказы;
  6. персонализация;
  7. интеграция с Axapta.

Декомпозиция задач

Определите длительность задач

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

Длительность задач

Установите зависимости между задачами

Пока вы вносите начальные данные о проекте в таблицу слева, справа автоматически строится диаграмма Ганта. Чтобы она отображалась корректно, установите зависимости между задачами. Например, чтобы сделать прототип интернет-магазина, сначала нужно собрать требования. То есть, третья задача списка зависит от второй. Все задачи программа нумерует автоматически по мере их появления.

Проставьте зависимости в графе Предшественники. Получится так.

Зависимости между задачами

Распределите ресурсы

Теперь раздайте задачи команде и отразите это в таблице. В правом нижнем углу есть пять разных вкладок. Диаграмма Ганта (большую часть времени вы будете проводить в ней), Использование задач, Визуальный оптимизатор ресурсов, Лист ресурсов и Отчет.

Выберите Лист ресурсов. В него внесите всех сотрудников, которые работают на проекте, их ставки за час работы и график. Укажите должности или фамилии, если в команде несколько сотрудников занимают одинаковую позицию. Так вы сможете избежать путаницы.

Допустим, что в команде по одному сотруднику на каждую должность. Вот, что получится.

Лист ресурсов.

Вернитесь во вкладку Диаграмма Ганта. Найдите графу Ресурсы и проставьте должности исполнителей напротив каждой задачи.

В проекте по созданию интернет-магазина аналитик отвечает за все задачи по аналитике, дизайнер — за дизайн, верстальщик — за вестку, программист — за разработку.

Задачи с проставленными ресурсами

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

Перегруженные ресурсы

Устраните проблему перегрузки

Для этого перейдите в Визуальный оптимизатор ресурсов. Он выглядит так.

Визуальный оптимизатор ресурсов

Видно, что перегружен программист. Вернитесь назад в Диаграмму Ганта. На верхней панели выберите вкладку Ресурс, а потом кнопку Автоматическое выравнивание ресурсов. Программа сама перераспределит задачи так, чтобы разгрузить программиста. Но учитывайте, что время работы над проектом при этом увеличится.

Программа автоматически выровняла ресурсы

Мы немного познакомились с MS Project. Теперь с ее помощью вы можете планировать, распределять задачи и анализировать работу. Это только базовые навыки. Программа сложная, в ней много разных функций, некоторые никогда не пригодятся. Другие здорово упрощают жизнь, но не так просто их найти и научиться ими пользоваться.

Начинающему менеджеру проектов не обойтись без опытного наставника. На курсе Skillbox вас научат правильно работать с программой MS Project. Покажут, как ее использовать, чтобы упростить не только планирование, но и весь контроль над проектом.

Курс «Управление Digital-проектами» Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Практика составления графика проекта в MS Project

2020-03-18 11343

Статья предоставлена редакцией информационно-аналитического журнала «Управление Проектами» в рамках совместного проекта с Финансовой академией “Актив”.

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

Читайте больше интересных статей в журнале «Управление Проектами»

Для кого эта статья

Существует масса пособий по работе в MS Project. Почти все они рассказывают о технике: как пользоваться приложением, какие сущности в нем существуют, какие связи между задачами используются и т.д. Однако когда доходит до практики, руководитель проекта сталкивается с необходимостью принимать решения другого характера – какие задачи должны входить в график, как найти золотую середину между детальностью графика и удобством работы с ним, какие приемы лучше использовать, чтобы минимизировать трудозатраты на планирование? Как, в конце концов, обеспечить выполнение сроков проекта?

Данная статья – для тех, кто не нуждается в детальных инструкциях по использованию MS Project. Статья предназначена для практиков, которым будет интересно познакомиться с опытом других руководителей проектов. Ниже изложены некоторые приемы и принципы, которые сформировались в результате многолетнего опыта работы, и которые позволяют сделать практичный график проекта.

Планирование проекта

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

Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:

  1. Приспособлен для информирования заказчика и проектной команды. Для этого он должен быть понятным, компактным, логичным, хорошо структурированным.
  2. Легко модифицируется в случае изменений сроков и состава задач. Его легко поддерживать в актуальном состоянии.
  3. Позволяет контролировать сроки, обнаруживать проблемы и принимать по этому поводу решения.

Для того, чтобы составить такой график предлагаем следующий план действий:

  1. Принять решение о способе планирования.
  2. Избавиться от всего лишнего и упростить план.
  3. Установить взаимосвязи между задачами.
  4. Оценить длительность задач
  5. Избавиться от распараллеливания задач
  6. Выровнять ресурсы.
  7. Установить ограничения по датам.
  8. Выявить критический путь.
  9. Добавить временные буферы в график.
  10. Проанализировать, как можно сократить сроки.

1. Принять решения о способе планирования

1.1. Планирование от начала

Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.

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

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

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

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

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

Иногда используют задержки и сдвиги между задачами.

Рисунок 1

Однако пользоваться задержками лучше по возможности меньше.

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

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

1.2. Планирование от конца

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

Логика планирования в этом случае другая, но в некотором смысле более правильная. Вы задаете себе вопрос: «что необходимо, чтобы завершить проект?». Затем определяете, что необходимо, чтобы достичь этих промежуточных результатов, добавляете предшествующие задачи, к ним в свою очередь присоединяются предыдущие задачи и т.д. Выстраивается последовательная цепочка работ, которые ведут к результатам проекта.

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

Многие скажут, что откладывать задачи на потом рискованно. Что если задача займет больше времени, чем запланировано, и результат опоздает? А она обязательно опоздает, и тогда следующая задача сдвинется и неизбежно сдвинется окончание проекта. Чтобы избежать этого, в график добавляются временные буферы. Подробнее об этом ниже.

2. Избавиться от лишнего и упростить план

Лишним считается все, что не помогает планировать сроки проекта.

2.1. Примеры задач, от которых можно избавиться

Рассмотрим группу задач «Управление проектом». Понятно, что задача управления проекта необходима, но она не определяет длительность проекта, а проект определяет ее длительность. Если мы сосредоточены на планировании сроков, можно ее убрать.

Рисунок 2

Задача «Поддержка». Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам. Можно включить ее в план проекта, но минимизировать ее детализацию. Эта задача может быть спокойно заменена в плане на две контрольные точки: Начало эксплуатации и Окончание поддержки.

Рисунок 3

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

2.2. Пример излишней детализации

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

Рисунок 4

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

3. Установить взаимосвязи между задачами

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

Можем дать следующие рекомендации для выстраивания графика.

3.1. Используйте минимум видов связей

В MS Project вы можете использовать разные виды связей между задачами «Окончание-начало», «Начало-начало» и т.д. По возможности, избегайте разнообразия использования разных типов связей. Читать график с разными видами связей сложно. Его поведение графика при модификации становится трудно предсказуемым. Чем проще, чем однообразнее — тем лучше.

3.2. Не используйте связи с суммарными задачами

Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:

Рисунок 5

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

Рисунок 6

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

Рисунок 7

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

3.3. Используйте Сетевую диаграмму

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

Рисунок 8

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

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

Рисунок 9

Рисунок 10

4. Оценить длительность задач

В литературе описано много специальных и общих методик (PERT, мозговые штурмы, Дельфи и проч.). В реальности вы либо делаете оценку из собственного опыта, либо запрашиваете у экспертов или непосредственных исполнителей.

При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:

  • О достоверности оценки лучше судить, если известны предположения, их которых исходил оценщик.
  • Учитывайте психологические особенность каждого исполнителя
  • Сделать поправку длительности. Для некоторых исполнителей, исходя из опыта работы с ними, нужно делить оценку на два, для других — умножать на три.

Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:

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

Поэтому придерживайтесь следующих правил при планировании работ:

  • Вероятность выполнения в указанный срок установите в 50%. Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое. Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
  • Ресурсы не должны быть перегружены. Люди не должны выполнять несколько задач одновременно. В этом случае их производительность будет максимально возможной.

5. Избавиться от распараллеливания задач

Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей. Например,

Рисунок 11

Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам. Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену. Наличие пяти параллельных задач не имеет смысла. Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.

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

6. Выровнять ресурсы

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

Если мы хотим планировать загрузку ресурсов, нужно загрузку выравнивать. Можно это делать не для всех ресурсов, а только критических, которые мы действительно хотим планировать. Например, мы можем планировать своих сотрудников, но не планировать ресурсы заказчика, загрузка и возможности которых находятся за пределами нашего влияния.

В MS Project имеется функция выравнивания ресурсов. Эта функция расставляет задачи с учетом связей между задачами и ограничения по максимальной загрузке каждого ресурса и приоритета (поле «Приоритет»). Не всегда это приводит к нужному результату. План становится слишком длинным, а ресурсы недогружены. Задачи привязываются в плане к конкретным датам, что мешает их перепланировать. Можно добиться более адекватного плана в ходе автоматического выравнивания с помощью пересмотра зависимостей и расстановкой приоритетов, но это очень кропотливый и трудоемкий процесс.

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

Например, модифицируем предыдущий пример:

Рисунок 12

В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.

Было бы более правильно вообще разделить задачи между двумя участниками и избавиться от параллельного выполнения задач А.Теном, но в данном случае это сделать сложно. Поэтому приходится идти на нарушение правил, которые мы сами для себя установили выше. Тем не менее, такой план лучше, т.к. помогает контролировать выполнение задач не в конце 14 рабочих дней, которые мы отвели на проектирования функционального блока «Контроль», а уже через 3 дня после начала работы. Кроме того, это дисциплинирует исполнителя с первого дня, у которого нет 14 дней в запасе, а есть целевой срок 3 дня, когда нужно закончить первый документ.

7. Исключить жесткую привязку задач к датам

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

Привязка к датам оправдана, если определяется внешними по отношению к плану условиями. Например, зафиксированная дата начала испытаний; контрольная точка, которая определяется внешним проектом; несдвигаемое событие. Во всех остальных случаях нужно избегать ограничений. Если их избежать не удается, то лучше использовать мягкие ограничения: «Начало не позднее», «Начало не ранее» и т.п. Это позволяет автоматически двигать задачи вслед за теми, от которых они зависят.

8. Выявить критический путь

Если задачи выстроены правильно, то MS Project покажет вам критический путь проекта — цепочку задач, которая определяет длительность. Изменение длительности или задержка начала выполнения любой задачи на критическом пути меняет дату окончания проекта.

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

  • Уделять задачам критического пути ежедневное внимание, контролировать готовность всех необходимых ресурсов для их выполнения.
  • Мотивировать участников на сокращение длительности выполнения задач критического пути, не допускать отвлечения на другие задачи.
  • Использовать временные буферы, страхующие отклонение по срокам.

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

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

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

Рисунок 13

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

Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».

9. Добавить временные буферы в график

Добавление буферов в план позволяет избежать нарушений конечной даты проекта или этапа при неизбежном изменении сроков по задачам.

Как правило, мы добавляем запас в каждую задачу, чтобы нас не наказывали за опоздания. Мы предпочитаем заложить запас на все риски, которые могут случиться — отвлечение на совещания, изменения требований заказчика, длительные согласования, технические проблемы и личные обстоятельства. Стараемся дать оценку необходимых сроков с вероятностью 90% их соблюдения. И несмотря на это, часто их срываем. Выше мы уже говорили о студенческом синдроме и прочих психологических моментах, которые приводят к нарушению сроков несмотря на все резервы, которые мы делаем в каждой задаче

В результате, опоздания всегда накапливаются, а опережения — практически никогда.

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

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

Рисунок 14

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

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

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

Подробнее об этом методе построения графика проекта можно прочитать в книге Э.Голдратта «Критическая цепь», которая написана в форме бизнес-романа, легко читается и действует крайне вдохновляюще.

10. Проанализировать график

Далее мы переходим к тому, для чего, собственно мы проделывали все предыдущие шаги, непосредственно к работе с графиком.

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

10.1. Сокращение сроков

Рассмотрим пример:

Рисунок 15

Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.

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

Рисунок 16

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

10.2. Риски, связанные с графиком

Интересно посмотреть на график проекта с точки зрения управления рисками. Какие риски может обнаружить график проекта?

  • Параллельное выполнение множества блоков работ или функциональных направлений. Необходимо решить, влечет ли опоздание одного из них серьезные последствия для всего проекта? Сложные проекты включают в себя до десятка направлений. Внедряется одновременно финансы, бюджетирование, HR, логистика и т.д. Если не предусмотрены работы по интеграции и координации направлений, не заложены резервы на отклонения по каждому из направлений, нет этапа интеграционного тестирования, велика вероятность неуспеха проекта в целом, а не только срыва сроков.
  • Отсутствие периода опытной эксплуатации. Если ОПЭ невозможна, то нужно рассматривать возможность поэтапного запуска, по функциональным областям или организационным единицам.
  • Излишне агрессивный график, отсутствие или недостаточный размер резервов. Об этом уже говорили. Такой проект вероятнее всего опоздает.
  • Этапы проекта или ключевые работы идут внахлест, с перекрытием. Во многих случаях это увеличивает риск переделки по уже выполненным задачам.
  • Если в графике отсутствуют работы и вехи, закрепленные за заказчиком, то возможно, мы плохо контролируем работы со стороны заказчика. Необходимо обратить внимание на то, что некоторые работы могут быть некорректно отнесены к зоне ответственности исполнителя.
  • Отсутствие в графике вех, означающих формальную приемку работ, может означать, что мы не до конца понимаем, какие промежуточные результаты и в какой момент должны подтвердить. А это чревато проблемами при сдаче результатов в конце проекта.

Заключение

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

График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам. Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.

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

Использование MS Project для управления проектами по разработке ПО

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

Небольшое введение

Вся методология — это просто набор простых методов и рекомендаций по использованию MS Project для решения прикладных задач руководителя проекта. Сразу оговорюсь, что методология не претендует на универсальность, и применима только при некоторых ограничениях, которые я буду упоминать по ходу повествования.
Для начала, давайте вспомним, что обычно требуется от руководителя проекта. Для опытных руководителей это очевидно, а начинающим (или только собирающимся стать руководителями) будет полезно лишний раз вспомнить. Итак, проект по разработке программного обеспечения — это создание некоторое уникального продукта. На разных этапах жизненного цикла проекта от РП требуется решать различные задачи.

Перед началом проекта

Перед началом проекта от руководителя проекта обычно требуется ответить на два вопроса:

  1. сколько проект займет времени
  2. сколько проект будет стоить

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

В процессе выполнения проекта

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

При завершении проекта

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

Что умеет MS Project

Несмотря на внешнюю сложность, MS Project очень прост в идейном плане. Он оперирует тремя сущностями — задачи, ресурсы, календарь и связи между ними. По сути — это база данных, пользовательский интерфейс для создания и редактирования сущностей и минимальная, довольно простая автоматизация (то, что Project делает сам, в ответ на введенные данные).
Разберем вкратце свойства сущностей.
Задача имеет длительность, объем, назначенный ресурс и еще чертову уйму различных свойств. Если встроенных свойств не хватает, можно добавить свои — этим мы потом воспользуемся. Задачи могут быть связаны между собой различными отношениями (предшественники, последователи и т.п.).
Ресурс имеет много описательных свойств, но самое главное — для него можно
задать доступность во времени, для этого используется календарь. Ресурс может быть
назначен на задачу.
На основе этих данных Project умеет делать различные представления с использованием
фильтров, группировок, сортировок и т.п. Кроме этого он умеет по некоторому алгоритму
вычислять сроки начала и окончания задач с учетом доступности назначенных ресурсов
и связей между задачами. Вот, собственно, и почти все что он умеет.
Давайте посмотрим, какую пользу можно из этого извлечь

Как это использовать

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

Подготовка плана

Итак, перед нами лежит техническое задание, и требуется дать ответ на три вопроса:

  1. Сколько времени займет этот проект?
  2. Сколько (и каких) специалистов для этого потребуется?
  3. Какие примерно трудозатраты ожидаются по этому проекту?

Для этого мы готовим прикидочный план выполнения проекта в MS Project. Т.е. просто последовательно выписываем задачи, которые необходимо выполнить. Методика превращения техзадания в набор задач — это отдельная история, я не буду на ней сейчас останавливаться.
Подготовка плана выполняется в несколько этапов:

  1. Готовим список задач
  2. Выставляем зависимости между задачами
    (результат какой задачи необходим для перехода к следующей?).
  3. Назначаем исполнителей задач
  4. Выравниваем загрузку ресурсов
  5. Балансируем то, что получилось

Общие рекомендации

При подготовке плана придерживаемся следующих рекомендаций:

  1. Не используем суммарные задачи для декомпозиции.
    Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
    но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
    используем настраиваемые поля (см.ниже).
  2. Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
  3. Срок каждой задачи не должен превышать двух недель.
    Если срок задачи превышает неделю — это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача — 2 дня, средней
    сложности — 1 неделя, сложная задача — 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
    С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны — а какая из них точная? По опытку практического применения могу сказать, что на
    больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки.
  4. Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
    только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу.
  5. При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
  6. Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.


Список задач, разделенный на этапы

Балансировка проекта

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

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

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

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

Учет рисков

Теперь — последний штрих: учет рисков. Честно признаюсь, я не занимался серьезным управлением рисками, но учитываю возможность возникновения определенных форсмажоров (таких как болезни исполнителей, забытые работы и т.п.). Для этого я добавляю в каждый этап фиктивную задачу с минимальным приоритетом, под названием «прочие работы» для каждого ресурса. После выравнивания ресурсов эти задачи оказываются в конце этапа. Длительность этих задач зависит от вероятности возникновения и степени вляния рисков, она зависит от способа определения оценок длительностей задач, здоровья членов команды и степени паранойи руководителя проекта. Обычно я выставлял длительность «прочих работ» примерно от трети до четверти длины этапа.
В результате всех перечисленных манипуляций у нас получается план выполнения проекта, с которым можно работать.

С этим планом мы можем:

  1. Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
    достоверности.
  2. Оценить примерные трудозатраты по проекту

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

Работа с планом

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

  1. Выдавать задания исполнителями
  2. Отмечать выполненные задания в плане
  3. Корректировать план в случае значительных отклонений

Выдача заданий исполнителями может выполняться по разному. Можно разбить выполнение на короткие итерации, формировать пул задач на итерацию и по окончании итерации отмечать результаты. Можно сразу озвучить лнителям набор задач на этап, выдать каждому по экземпляру диаграммы Ганта и периодически опрашивать о прогрессе. Можно использовать интеграцию MS Project и TFS и загрузить проект непосредственно в TFS. Суть не в средствах. Главное — это регулярное обновление плана. Я делаю это примерно раз-два в неделю. Это дает возможность достаточно быстро увидеть проблемные участки.
Для определения проблемного участка удобно использовать различные группировки — по исполнителями, по компонентам и др. Часто может оказаться, что проект в целом идет даже с опережением, но в определенном разрезе наблюдается отставание, например один из разработчиков неожиданно уткнулся в серьезную системную проблему, которая привела к отклонениями. Использование только средней метрики не покажет этой проблемы — она всплывет только в конце этапа, когда что либо делать будет уже поздно.

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

Диаграмма Ганта с отслеживанием

Управление структурой задач с помощью пользовательских полей

Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля. MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.
Создание пользовательского поля
После этого мы получаем возможность указать для каждой задачи компонент, к которому она относится, и, используя группировку задач по компонентам, отслеживать как идут дела.
Группировка задач по компонентам
Пользовательские поля позволяют разделять задачи по нескольким категориям, например, я разделял задачи по типу работ: Разработка, Тестирование, Документирование.
Упомяну для любопытных, что в MS Project также можно задать правила рисования диаграмм на основе свойств задач. При желании, можно сделать так, что задачи по разным компонентам будут иметь разные цвета, причем цвет будет определяться только свойством задачи, его не нужно задавать вручную для каждой задачи. Такие настройки не требуют написания сриптов, а делаются штатными средствами настройки диаграмм.
Использование пользовательских полей, а также встроенные в MS Project функции фильтрации, сортировки и группировки задач позволяют получить самые разные представления, которые позволяют получить ответы на многие вопросы, которые возникают у руководителя проекта.

Завершение проекта

В конце проекта мы получаем план, в котором все задачи выполнены. Обычно я стараюсь сохранять также и исходный план, хотя бы в качестве базового. Честно говоря, на этом этапе от MS Project мало проку, так как интересуют не плановые значения, а фактические. Какие-то решения этой проблемы предлагает MS Project Server, там есть возможность учитывать фактические трудозатраты, но это уже за пределами данной статьи.

Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.
Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно — постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.
Наверняка я что-то упустил, не стесняйтесь задавать вопросы.