Детализация проекта: технический документ

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

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Детализация проекта: технический документ (Project Server 2010).

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

Детализация проекта

Эта статья посвящена разложению проекта на составляющие.

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

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

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

Какой же подход считать правильным?

Как долго должны длиться задачи и сколько их должно быть в оптимальном календарном плане проекта? Я называю это детализацией проекта.

Каждому свое

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

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

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

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

    Представление "Диаграмма Ганта" для Agile sprints
  2. Проектирование, материально-техническое обеспечение и строительство (ПМС)   . Именно проекты ПМС привели к зарождению планирования по методу критического пути. В рамках подобных проектов создаются масштабные объекты. Это может быть крупный оборонный проект, такой как разработка ракеты "Поларис", где впервые был применен сетевой график, либо проект строительства нефтяной платформы, судна или электростанции. Подобные проекты включают в себя этап проектирования, на котором формируется представление о том, как должен выглядеть конечный результат. Этап проектирования обычно предполагает разработку каких-то новых решений. На этапе материально-технического обеспечения происходит поиск субподрядчиков, заключение договоров с ними и управление поставками для элементов проекта. Этап строительства — это создание конечного объекта и его ввод в эксплуатацию. Календарные планы проектов ПМС, как правило, рассчитаны на много месяцев или лет, а отдельные задачи длятся от нескольких недель до нескольких месяцев. Вполне обычна ситуация, когда такой проект содержит от 5000 до 20 000 задач. Планирование ресурсов почти всегда выполняется на уровне навыков, а не отдельных сотрудников. Дополнительная сложность состоит в том, что в программу или главный проект для упрощения управления может быть включено множество подпроектов.

    Представление "Диаграмма Ганта" с несколькими проектами и подпроектами
  3. Остановка предприятия   . При разработке календарного плана проекта по остановке предприятия для проведения техобслуживания и ремонта вы оказываетесь в одной из самых сложных ситуаций. Остановка предприятия для проведения техобслуживания может быть двух типов: запланированная или аварийная. Давайте пока оставим аварийную остановку в стороне, так как это совершенно особая ситуация. Длительность запланированного простоя предприятия сильно зависит от его типа. Например, "быстрый" цикл планово-профилактических ремонтных работ на энергоблоке АЭС может занять 12 месяцев. Для нефтеперерабатывающего завода этот период может составлять 4–6 недель. Однако наиболее интересными мне представляются календарные планы для таких промышленных предприятий, как сталелитейный завод, целлюлозно-бумажный комбинат или что-то в этом роде. По всему миру тысячи и сотни тысяч таких заводов, и примерно раз в год они должны проходить регулярное техобслуживание.

    Стоимость остановки в таком случае измеряется в виде упущенной выгоды, т. е. стоимости продукции, которая могла бы быть произведена за то время, пока завод простаивает. Эта стоимость измеряется за единицу времени и может достигать 150–250 тысяч долларов в час, поэтому при проведении таких работ каждая минута на счету. В подобной ситуации простой обычно длится 5–8 дней, и задержка на один день может стоить миллионы. Если вы привыкли к более длительным традиционным календарным планам, то, возможно, спрашиваете себя: "Сколько же задач могут содержать такие длящиеся всего несколько дней проекты?" Но для такого плана по остановке предприятия не редкость 2000–4000 задач, каждая из которых длится от 15 минут до пары часов. Ресурсы в данном случае выделяются на основе навыков, но выравнивание загрузки ресурсов выполняется редко. С учетом высокой стоимости простоя становится неважно, сколько людей будет выделено на проект: главное завершить его как можно скорее. Выравнивание загрузки ресурсов в таких условиях часто выполняется для наиболее узких мест. Пример: в помещении для электрооборудования одновременно могут работать только два человека, поэтому этот участок требует отдельного внимания.

    Представление диаграммы Ганта для последовательных задач

Итак, у нас есть три примера, и, хотя их можно привести гораздо больше, этого вполне достаточно для целей нашего обсуждения. В проектах первого типа (разработка программного обеспечения) задачи обычно длятся от одного дня до пары недель. В проектах второго типа (ПМС) длительность задач составляет несколько недель или месяцев. В проектах третьего типа (остановка предприятия) длительность задач измеряется блоками по 6 минут (1/10 часа), 10 минут, 15 минут (1/4 часа) и т. д. вплоть до одного или двух часов. Очевидно, что в некоторых случаях целесообразнее использовать более короткие по времени задачи, а в других — более длинные. Следуя той же логике, иногда желательно разделить проект на большое число задач, а в других случаях — нет.

Факторы, влияющие на детализацию проекта

По этим примерам становится ясно, что задачи длительностью два месяца, характерные для проектов ПМС, выглядели бы нелепо в календарном плане остановки предприятия, а 15-минутные задачи неуместны в проекте ПМС или проекте по разработке программного обеспечения. Однако не стоит без раздумий ссылаться на эту статью и говорить: "Вандерслуис утверждает, что задачи проекта по разработке программного обеспечения должны иметь длительность 1–10 дней". Вместо этого следует разобраться, от каких характеристик проекта зависит его детализация. Рассмотрим несколько очевидных особенностей.

Как долго длится проект?

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

Это обязательное правило? Конечно, нет.

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

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

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

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

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

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

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

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

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

Сколько ресурсов вовлечено?

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

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

Как осуществляется управление ресурсами и их разделение?

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

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

  • определить задачи таким образом, чтобы руководители проектов и инженерно-технический персонал субподрядчика понимали их однозначно;

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

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

  • Над каким количеством проектов в среднем отдельный ресурс будет работать в течение одного дня?

  • Сколько времени требуется сотруднику на переключение с одного проекта на другой?

  • Определена ли работа таким образом, что и сотрудникам, и руководителям отделов понятно, какие навыки требуются для ее выполнения?

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

Как быстро вы можете собрать данные и сколько усилий на это потребуется?

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

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

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

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

Как часто будет выполняться обновление данных?

Ниже приведены два основных фактора, которые следует учитывать при определении объема собираемых и включаемых в отчеты данных.

  • Подумайте, как вы будете собирать данные.

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

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

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

  • Данные полны   . Мы не ожидаем, что состояние одних задач будет обновлено, а других — нет.

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

  • Все данные прошли утверждение на каком-либо уровне   . Мы ожидаем, что руководитель проекта контролирует представляемые данные и может сказать: "Эти данные точно и достоверно отражают состояние проекта".

  • Данные непротиворечивы   . Мы не ожидаем, что данные о затратах и ресурсах будут расплывчатыми, если только не разработали отчеты и методы анализа таким образом преднамеренно.

Я часто спрашиваю руководителей, увлеченных идеей управления проектами в режиме реального времени, что они будут делать, если удастся преодолеть перечисленные выше трудности. "Вы готовы принимать управленческие решения на протяжении всей недели?" — задаю я вопрос. Ответ должен зависеть от уровня детализации. В случае с проектом по остановке предприятия он должен быть скорее утвердительным. Для проекта по разработке программного обеспечения ответ, возможно, будет следующим: "Нет, мы будем делать это еженедельно". А для проекта ПМС вместо "еженедельно" будет ответ "ежемесячно".

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

Анализ результатов

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

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

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

Может быть, это слишком?

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

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

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

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

Нужно ли вообще это делать?

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

Проект на основе гибкой методики разработки

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

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

У нас есть период от одной до трех недель, ресурсы предоставлены, и остается лишь назначить работу каждому ресурсу. Возможное число задач в рамках такой структуры имеет предел, и этим обусловлена необходимость в соответствующем уровне детализации. Да, при гибкой разработке могут возникнуть проблемы, если задачи будут слишком короткими, например "Определить Поле1: 10 минут. Определить Поле2: 10 минут. Определить Поле3: 10 минут" и т. д. Однако встречается такое нечасто.

Гибкая методика была придумана для корпоративной среды разработки, в которой программное обеспечение создается для внутреннего использования, однако она часто применяется и для разработки коммерческого ПО. (Мы используем эту методику у себя в компании HMS для разработки нашего продукта TimeControl.) Гибкая методика делает работу отдела разработки более маневренной и оперативной, но применима не к каждой отрасли и даже не к каждой компании, занимающейся программным обеспечением. Если вы управляете проектами в среде разработки программного обеспечения, то я рекомендую тщательно изучить гибкую методику разработки, вынести необходимые знания, а затем внедрить те элементы (все, некоторые или ни один из них), которые повысят вашу эффективность.

Краткое заключение

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

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

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, и являющейся партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

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

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×