Чтение онлайн

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

Для удобства планирования и управления по каждому элементу ИСР должен быть назначен ответственный — конкретный человек. Иногда можно обойтись указанием роли, например менеджер пакета работ, член рабочей группы, менеджер по учету затрат. Как правило, это должен быть специалист в предметной сфере, к которой относится элемент ИСР. Ему предстоит составить детальный перечень работ, установить их последовательность и оценить потребность в ресурсах. Также в обязанности ответственного входит определение взаимосвязей с другими пакетами работ и, кроме того, обоснование своей оценки количества необходимых ресурсов.

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

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

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

Чтобы достичь цели проекта, необходимо выполнить ряд работ в определенной последовательности. Это и есть логика проекта. Каждый пакет работ — это просто маленький проект со своей логикой. Операции должны быть спланированы так, чтобы результат одной служил материалом для другой. Каждую операцию можно рассматривать как процесс с материалом на входе, преобразующимся в результат на выходе. Проектные операции соответствуют модели SIPOC из TQM: поставщик — исходный материал на входе — процесс — результат на выходе — клиент. Поставщик здесь — менеджер предшествующей операции. Клиент — менеджер последующей операции. Затем при помощи контрольных точек и связей между операциями определяются взаимосвязи между пакетами работ.

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

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

• Старт-старт (с запаздыванием) — эта связь устанавливается, когда две операции могут выполняться одновременно. При этом сначала в ходе первой производится некий объем продукта, который может далее обрабатываться на второй. Например, вам нужно пропустить множество экземпляров продукции через три последовательных этапа. Вместо того чтобы запланировать три этапа для каждого экземпляра отдельно, мы делаем всего три операции типа «операция 1 для 100 экземпляров», «операция 2 для 100 экземпляров» и так далее, намечая начало каждой с отставанием на срок, равный обработке одного экземпляра на предыдущем этапе.

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

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

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

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

Логику проекта нужно выверить по следующим пунктам.