lec1.ppt

ТЕХНОЛОГИИ. К НИМ МОЖНО ОТНЕСТИ РАЗРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ВНЕДРЕНИЕ

ИНФОРМАЦИОННЫХ/АВТОМАТИЗИРОВАННЫХ СИСТЕМ. РИСКИ СРЫВА СРОКОВ, ПРЕВЫШЕНИЯ ПЛАНОВОЙ ТРУДОЕМКОСТИ И НЕ ДОСТИЖЕНИЯ ЗАПЛАНИРОВАННЫХ РЕЗУЛЬТАТОВ ПО ЭТИМ ПРОЕКТАМ ОСОБЕННО ВЫСОКИ. ДЛЯ IT-ПРОЕКТОВ ХАРАКТЕРНА ВЫСОКАЯ ИНТЕНСИВНОСТЬ В СОЧЕТАНИИ С ГЛУБОКОЙ ДЕТАЛИЗАЦИЕЙ КАЛЕНДАРНО-СЕТЕВЫХ ГРАФИКОВ И ИТЕРАЦИОННОСТЬЮ ВЫПОЛНЕНИЯ РАБОТ. ОБЫЧНО ТРЕБУЕТСЯ ДЕТАЛИЗАЦИЯ ТРУДОВЫХ РЕСУРСОВ ДО КОНКРЕТНОГО ИСПОЛНИТЕЛЯ. НЕТРУДОВЫЕ РЕСУРСЫ И МАТЕРИАЛЫ ОТСЛЕЖИВАЮТСЯ ЗНАЧИТЕЛЬНО РЕЖЕ. СБОР ФАКТИЧЕСКИХ ДАННЫХ ОТ ИСПОЛНИТЕЛЕЙ, КАК ПРАВИЛО, ОСУЩЕСТВЛЯЕТСЯ С ПОМОЩЬЮ WEB-ТАБЕЛЕЙ. ПЕРИОД АКТУАЛИЗАЦИИ – ОТ ОДНОГО ДНЯ ДО НЕДЕЛИ. ЧАСТО ВОЗНИКАЕТ ЗАДАЧА ИНТЕГРАЦИИ СИСТЕМЫ УПРАВЛЕНИЯ IT-ПРОЕКТАМИ С ДРУГИМИ СИСТЕМАМИ - ПРЕЖДЕ ВСЕГО, CASE-СРЕДСТВАМИ, СИСТЕМАМИ CRM

ПРОЕКТОМ ОБЫЧНО ПОНИМАЮТ НЕКУЮ ДЕЯТЕЛЬНОСТЬ, ПРИВОДЯЩУЮ К СОЗДАНИЮ ОПРЕДЕЛЕННОГО ПРОДУКТА/УСЛУГИ.

ОБЫЧНО ХАРАКТЕРИЗУЕТСЯ ТЕМ, ЧТО ОГРАНИЧЕН ПО СРОКАМ И ПО РЕСУРСАМ.

о проекте и процессе проектирования
Управление проектом
Жизненный цикл проекта
Инициация
Планирование проекта
Планирование содержания

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

определений гласит: проект это все, что имеет «начало, конец и

цель».
Проект  — это уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включающий ограничения по срокам, стоимости и ресурсам.
Проект — это работы, планы, мероприятия и другие задачи, направленные на создание нового продукта (устройства, работы, услуги).
Выполнение проекта составляет проектную деятельность.
Таким образом, когда предполагается запуск нового ПРОЕКТА – речь всегда идет о чем-то «конечном» и имеющим цель.
«Разрабатывать программные продукты» – это не проект. Проект это, например, «создание и внедрение информационной системы XXY к 1 декабря следующего года».
Проект включает комплект документации и материалов (определённого свойства), результат проектирования.

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

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

которая включает в себя следующие стадии: концептуальную, моделирования, конструирования и

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

цели проекта. В общем виде цель проекта можно определить как

решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:
требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;
требуемой пропускной способности системы;
требуемого времени реакции системы на запрос;
безотказной работы системы;
необходимого уровня безопасности;
простоты эксплуатации и поддержки системы.
Процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

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

документации и пр.).
Обычно выделяют следующие этапы создания ИС:
формирование требований к системе
проектирование
реализация
тестирование
ввод в действие
эксплуатация и сопровождение.

работ» проекта. Эти ограничения обычно называют тройственными и изображают в

форме треугольника.

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

к управлению проектом понятны сразу же:
Управление временем (необходимо уложиться в

срок)
Управление стоимостью (мы не должны превысить бюджет)
Управление содержанием (нам нужно уточнить желания заказчика и правильно их реализовать)
Другие – менее очевидны:
Управление качеством
Управление рисками
Управление закупками (если мы используем субподрядчиков)
Управление персоналом
Управление коммуникациями
Управление интеграцией

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

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

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

лиц
Выходы:
спонсор утвердил руководителя проекта
объявлено о запуске проекта
утвержден устав проекта
Устав проекта –

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

Устав создается менеджером проекта и утверждается спонсором

не забыть что-то существенное во время выполнения проекта
Чтобы любой член

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

Это общее название ВСЕХ планов проекта, каждый из которых «живет»

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

концепцию (scope)
Принять решение «что закупаем»?
Определить команду
Создать ИСР (иерархическую структуру работ)

(WBS)
Создать перечень действий (activity list)
Создать сетевую диаграмму (network diagram)
Оценить требуемые ресурсы
Оценить продолжительность действий и стоимость
Сформировать расписание
Создать бюджет
Планировать качество – создать метрики
Создать план улучшения процессов
Распределить роли и ответственности
Создать план коммуникаций
Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски
Все повторить

по заключению договоров и контрактов. Как правило, наблюдается некий компромисс

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

проекта

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

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

десятки (или более) фамилий:
Во-первых, это каждый, кто прямо вовлечен в

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

Строки «Проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта)

должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».
Требования

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

(кто высказал), насколько данное требование важно (приоритетно). Также в матрицу

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

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

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

необходимо решить ряд вопросов. Есть ли в нашей компании доступные

сотрудники с нужной квалификацией? Требуется ли специфичное оборудование? Может, для выполнения каких-то работ нужна особая лицензия?
Для проведения таких оценок нам потребуется хорошо спланированное содержание проекта.
Необходимо решить, будут ли привлекаться субподрядчики.
Некоторые из «лучших проектных практик» рекомендуют такой подход:
Обязательно использовать субподряды:
Если это снижает риски проекта
Можно использовать субподряды:
Если мы бережем (читай «испытываем дефицит») собственных ресурсов
Если мы пытаемся повысить управляемость проекта
Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.
Результатом определения ресурсов является список ресурсов
Список ресурсов – совокупность договоренностей о выделении ресурсов на проект (обычно – в виде единого документа или набора электронных писем из корпоративной переписи).