Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2010 г.

Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Назад Содержание Вперёд

Глава VIII. Планируем время и стоимость с использованием специализированного ПО

Входы:

  • Концепция проекта
  • Матрица требований
  • Список ресурсов
  • Команда проекта (ключевые сотрудники по списку ресурсов)

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

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

Сразу подчеркнем:

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

Конкретный программный продукт не имеет значения. В настоящий момент на рынке существует множество платных и бесплатных решений, самые распространенные из них: MS Project, Spider Project, Primavera, Prince.В настоящей книге мы будем использовать иллюстрации на базе MS Project 2010.

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

Шаг первый: формируем ИСР (WBS)

Возвращаемся к планированию содержания. Наша задача – разбить общий результат поставки проекта (описанный в «концепции») на более мелкие соподчиненные блоки «результатов работ». Для этого мы создадим иерархическую структуру работ (или work breakdown structure) – сокращенно ИСР (WBS).

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

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

Помните – ИСР создается совместно с командой! Это очень существенный момент. Как бы организационно вы не подошли к данному вопросу (будете ли сами создавать некий «черновик» и потом «утверждать» его вместе с командой, или с самого начала соберетесь все вместе) – главное найти способ привлечь сотрудников к планированию. Это повысит достоверность планов и, в то же время, сплотит команду (см. главу IX).

О чем следует помнить, создавая ИСР?

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

Во-вторых, занимаясь декомпозицией ИСР нужно уметь вовремя остановиться. Например, при разработке программного обеспечения, важно не увлечься декомпозицией ради декомпозиции (ведь, скажем, создание экранной формы всегда можно разбить на создание «кнопочки такой-то» и «кнопочки-другой» и так далее). Слишком поверхностный WBS нам тоже не подойдет. Разумная глубина отражена в понятии «пакета работ».

Основные признаки пакета работ:

  • Относительно короткий
  • Работы по созданию пакета могут быть выполнены без прерывания
  • Работы по созданию пакета могут быть выполнены на аутсорсинге

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

Источником данных для создания WBS служит концепция проекта. А вот наиболее удобным местом хранения введенных данных выступает специализированное ПО. Любой из перечисленных продуктов позволяет хранить информацию о работах в следующем виде:


увеличить

Иногда, составление полной детализированной ИСР оказывается невозможной или нецелесообразной (например – слишком трудоемкой). В таком случае прибегают к методу «набегающей волны». Суть его состоит – в детализации лишь самых ближайших к выполнению элементов (забегая вперед – в нашем примере это работы связанные с макетом (пакеты работ № 3 и 4). Остальные элементы ИСР обознаются только на верхнем уровне (в нашем примере – можно было бы указать только создание Главной страницы, без декомпозиции на пакеты № 6, 7, 8, 9).

Важнейшим элементом ИСР служит так называемый «словарь ИСР» (WBS-dictionary). Словарь позволяет подробнее описать то, что мы имели в виду под скупой формулировкой в ИСР. В нашем сценарии роль «словаря» могут выполнять ссылки на данные результатов обследования (глава VI). При использовании специализированного ПО элементы словаря можно создавать и хранить разными способами, например – в виде специальных «заметок», привязанных к каждому элементу ИСР.

Информация словаря должна быть доступна всем членам команды – для использования при выполнении собственных работ.

Шаг второй. Определяем перечень действий.

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

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

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

Здесь уже нет четких правил. Глубина декомпозиции никак не регламентируется. Да и сам пакет работ иногда декомпозиции не требует – можно оставить его в первоначальном виде (часто, для многих пакетов так и поступают).


увеличить

В нашем примере декомпозиции подверглись только два пакета – «создать макет» и «утвердить макет у заказчика» (в каждую из них добавилось по два действия)

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

Шаг третий. Определяем последовательность действий.

Определившись с нужными действиями (а, возможно, и оставив некоторые или все пакеты в неприкосновенности) – переходим к их упорядочиванию.

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


увеличить

Один из способов наглядно отобразить результат – перевести его из таблично вида в графический, сформировав «сетевую диаграмму».

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

Шаг четвертый. Определяем ресурсы

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

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

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


увеличить

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

Шаг пятый. Определяем продолжительность и стоимость.

Сейчас нам предстоит уточнить продолжительность и стоимость работ.

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

Оцениваем время

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

Среди основных методов оценки времени иногда называют:

  • Оценку одним человеком
  • Оценку по аналогу
  • Параметрическую оценку
  • PERT
  • Эвристическую оценку
  • Анализ резервов

Метод оценки одним человеком нужно использовать с осторожностью (в силу его субъективности) и никогда не делать основным.

Оценка по аналогу – прекрасный способ мгновенно получить грубую оценку (его часто используют в фазе инициации) а также дать команде простой и понятный «ориентир продукта». Однако на многих ИТ-проектах данный метод недоступен (в силу уникальности того же продукта).

Методы параметрических и эвристических оценок порождают огромное количество споров и дискуссий в разных профессиональных сообществах (корректно ли оперировать «строчками кода в день», верно ли утверждение что «тестирование занимает 1/3 разработки») и так далее. К какому бы лагерю спорщиков вы не относились – не пренебрегайте данными оценками, но относитесь к ним критично.

PERT (или «оценка по трем точкам) – чрезвычайно полезный прием, позволяющий оценить продолжительность выполнения работ, комбинируя «оптимистичную», «пессимистичную» и «наиболее вероятную» оценки. Используйте PERT для тех работ, оценка которых затруднена и/или имеет высокий диапазон допущения.

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

Согласно PERT предполагаемая длительность (или EAD) составит:

EAD = (P + 4M +O) / 6

где P – «пессимистичная оценка» , O – «оптимистичная оценка», M – «наиболее вероятная оценка».

С помощью PERT можно дополнительно уточнить и сам диапазон допущения вот таким способом:

  1. возможное отклонение (SD) составит:

SD = (P-O) / 6

  1. диапазон колебания (range) составит:

Самый оптимистичный прогноз = EAD - SD

Самый пессимистичный прогноз = EAD + SD

Используйте и комбинируйте методы оценки времени. По-возможности – привлекайте экспертов (внутри или вне компании), используйте сложившиеся корпоративные практики (если таковые существуют).

Помните, точность создаваемых сейчас оценок должна быть достаточно высокой (с погрешностью от 5 до 25%, или даже меньше, в зависимости от характера вашего проекта).

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


увеличить

В соответствующих столбцах появляются отметки о продолжительности работ. Также становятся доступны дополнительные виды диаграмм, например, диаграмма Ганта.

Диаграмма Ганта помогает наглядно оценить продолжительность работ.

Оцениваем стоимость

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

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

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

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

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


увеличить

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

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

Шаг шестой. Создаем расписание

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

Задаем точку старта

В уставе зафиксированы даты начала и окончания проекта. Используя специализированное ПО, мы задаем точку старта проекта и видим предполагаемую дату окончания. Укладывается ли результат в сроки, указанные в уставе? Возможно.


увеличить

В этот момент нам удобно ввести понятие «вех».

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

Добавим в наше расписание значимые для нас вехи. Допустим, в уставе прописано, что до 10 сентября необходимо согласовать с заказчиком макет, а весь проект завершить не позже 15-го. Укажем в перечне задач соответствующие вехи.


увеличить

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

Сетевой анализ расписания

Как видим, обе значимые для нас вехи легко уложились в расписание. Радоваться еще рано. Во-первых, подобное редко происходит в реальной жизни. Во-вторых – нам еще нужно кое-что утончить и расписание может поменяться. Совокупность этих действий принято называть «сетевым анализом расписания».

Сетевой анализ включает в себя:

  • анализ и выравнивание ресурсов
  • анализ критического пути
  • сжатие расписания (crashing и fast track)
  • анализ Монте-Карло

Анализ и выравнивание ресурсов начинается с анализа диаграммы использования ресурсов (доступна в любом специализированном ПО). Нет ли перегрузки – не получается ли, что один и тот же разработчик должен несколько месяцев решать одновременно множество задач, работая за троих? Если да, то используйте «выравнивание ресурсов» (также стандартная опция в специализированном ПО – вот почему я так настойчиво рекомендую вам его использовать).

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

Укладываемся ли мы в ограничения сроков из устава теперь? Возможно. Но с огромной вероятностью – нет (такова природа проектов вообще и ИТ-проектов в частности). Будем работать над расписанием дальше.

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

Работы на критическом пути нельзя делать параллельно (они строго последовательны).

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

Задержка любой работы на критическом пути автоматически задерживает весь проект. Пока дизайнер не закончит – разработчик не может быть полезен на проекте.

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

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

Другой метод сжатия – «быстрый проход». Экстремальный метод, основанный на том, что работы критического пути начинают выполняться параллельно (мы начинаем разрабатывать шаблон сайта, не дождавшись согласования макета заказчиком, однако если тот не одобрит макет – нам придется многое переделать). Практическое использование метода сводится к отмене «предшественников» для определенных задач (которые вы планируете снять с критического пути), чтобы дать возможность команде приступить к ним по-раньше.

Используйте методы сжатия расписания, осознавайте риски, которые за ними стоят.

Анализ Монте-Карло – термин из теории игр. Этот вид анализа основан на задании исходных условий и дальнейшем моделировании возможных ситуаций. Осуществляется с использованием особого ПО (наше, «проектное» для этих целей не подходит, иногда пользуются электронными таблицами excel с преднастроенной логикой). В настоящей книге мы не будем останавливаться на нем подробно.

Урезание расписания

Сетевой анализ расписания иногда противопоставляют «урезанию» содержания работ (cutting scope). Порой, соблазн ПМ состоит в том, чтобы «выкинуть» некоторые работы из проекта, дабы получить более удобное расписание. Удержитесь от того, чтобы сделать это «тайком».

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

Итоговое расписание.

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

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

Шаг седьмой. Определяем предельную цену проекта (cost baseline)

Шаг 5 позволил нам оценить стоимость каждой работы (мы указали ставки и правила начисления заработной платы сотрудников, а также прочие расходы, а специализированное ПО отразило их общую стоимость).

Во время шага 6 мы создали расписание и ранее сделанные оценки стоимости автоматически скорректировались (возможно, какие-то работы придется выполнять сверхурочно или в выходные – общая сумма вознаграждения измениться, в соответствие с настроенными правилами).

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

Предельная цена проекта (cost baseline) – это сумма себестоимости всех работ по проекту и стоимости всех резервов на непредвиденные случаи (contingency reserves). Определяется менеджером проекта.

Бюджет проекта – это сумма предельной цены проекта (cost baseline) и управленческих резервов (management reserves). Определяется спонсором.

Предельная цена проекта – это одна из граней тройственного ограничения. Неотъемлемым ее компонентом является стоимость резервов, которая определяется в ходе управления рисками. Об этом мы будем подробно говорить в главе X. Все, что нам доступно прямо сейчас – грубый прогноз такой стоимости резервов (ROM-оценка), используя который мы можем получить представление о «предельной цене».

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

Бюджет проекта содержит «управленческие резервы» и поэтому является компетенцией спонсора, и нас абсолютно не интересует (немного подробнее об этом – также в главе X)

Подводя итог под уточнением треугольника

Эту главу мы начали словами, что собираемся «уточнить» каждую из граней проектного треугольника. Обратите внимание – сам треугольник мы не меняли (он заложен в устав, а устав – изменениям практически не подлежит).

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

  • Грань «содержание»: Концепция + ИСР (WBS) + словарь (WBS Dictionary)
  • Грань «время»: расписание
  • Грань «стоимость»: предельная цена проекта (cost baseline)

Обратите внимание – планы никогда не должны противоречить уставу в ущерб интересам спонсора (т.е. можно сделать работы дешевле, но не дороже; быстрее, но не медленнее и т.п.).

Выходы:

  • ИСР (WBS)
  • Сетевая диаграмма
  • Перечень действий
  • Ресурсы, распределенные по работам
  • Оценки продолжительности работ и методики их расчета
  • Оценки стоимости работ и методики их расчета
  • Расписание
  • Предельная цена проекта
  • Запросы на изменения

Назад Содержание Вперёд

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (6)
Пятница 17.11, 16:12
Apple запустила Pay Cash (2)
Четверг 09.11, 21:15
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...