Мастер-класс. Интерактивная презентация + деловая игра «Управление командами разрабатывающими ПО по Agile (Scrum) и выводу нового программного продукта (ПО) на рынок» c использованием симулятора проектной деятельности (СПД) BesTeamKpi®
Как внедрить ALM/ Упр. командами разработки по (agile (scrum))
1. Как внедрить ALM систему управления командами разработки ПО (Agile (Scrum)) и остаться довольным. По мотивам презентаций А.Пушников, Экстремальные методы управления проектами. Движение к успеху в условиях неопределенности http://www.pmi.ru/articles/files/20022077_Pushnikov.pdf Денис Миллер, Сравнение методологий http: // agileguru.ru CPMP, Phd, MBA, А.Заходяйченко С [email_address]
11. Резюме проекта (пример) Что хотим видеть Параметр KPI Срок выполнения проекта 10 мес. Срок окупаемости кредита на разработку 24 мес. Срок окупаемости кредита на внедрение 3 года Стоимость проекта 3 235 884 руб. Оценочная стоимость 1 изделия 180 000 руб. Прибыль от продажи 1 изделия 40 000 руб. Ожидаемая сумма продаж 150 600 000руб./год Ожидаемая прибыль 20 600 000 руб./год
12.
13. Проблемы СНИЖЕНИЕ КАЧЕСТВА выполненных работ Конфликт целей СРЫВ СРОКОВ ПЕРЕРАСХОД запланированных средств НЕДОСТИЖЕНИЕ ЦЕЛИ ПРОЕКТА ( Scope) Невыполнение условий контрактов Неопределенность (…), Плохой контроль ???
15. План контрольных точек ( Milestone plan) Правильно выделенный комплекс вех составляет серию естественных контрольных точек проекта . Достижение вехи подразумевает переход проекта из одного состояния в другое Время Фактическое выполнение проекта Планируемый сценарий выполнения проекта Цель проекта Срок завершения проекта Веха 1 Веха 2
26. Ожидания заказчика Product Baclog Усилия разработчиков могут сосредоточиться в неверном направлении, и конечная реализация, даже являясь технически правильной, не будет полностью соответствовать потребностям пользователя 1. Как было предложено организатором разработки 2. Как было описано в техническом задании 3. Как было спроектировано ведущим системным специалистом 4. Как было реализовано программистами 5. Как было внедрено 6. Что хотел пользователь
27. Основные процессы планирования ( PMBOK 2008 ) и iteration planning Agile ( Scrum) Результат (продукт) Product baclog Спринт ( Sprint ) Список фичей (сделаны, на текущую и последующие итерации) Фокус – фактор Ответственность Product Owner
28.
29.
30. Современные концепции управления Product Baclog : качество , Lean, теории ограничений Внутренний дефект Годная продукция Внешний дефект Не требуемые свойства Требуемые свойства Внешний дефект Неудовлетворен-ные требования Дополнительные затраты Ценность продукта для производителя Стоимость продукта для производителя Ценность продукта для потребителя Стоимость продукта для потребителя
31.
32. Разработка Product Baclog Используемые подходы Декомпозиция: Разделение сложного на меньшие, простые, более управляемые элементы Объединение : Группировка отдельных элементов, имеющих общие признаки или взаимосвязи Шаблоны : Ранее разработанные элементы WBS различной степени детализации
36. Профиль специалиста Индивидуально-личностные характеристики Навыки ( умение вести переговоры , знание языков программирования, управленческие навыки и т.д. ) Компетенции Степень нацеленности на результат Тип личности (Майер-Бригс) Роли, которые может выполнятьспециалист по Р. Белбин
37. Пример Матрица навыков. Технические навыки Маркетинг и продажи Производство Работа с клиентами Финансы Управление персоналом Контроль качества Лидер НИР Ирина Павел Илья Евгений Александр Марина 4 2 1 5 6 2 3 5 4 5 3 1 2 5 6 7 5 9 Навык Член команды
38. Оптимальная команда: выполняемые в команде Agile (Scrum) роли // По Р. Белбину Product Owner Генератор идей Оформитель ( shaper ) Рабочая пчелка Scrum Master Добытчик Критик Завершающий (completer)
49. Матрица совместимости ролей ( MSF ) + Возможно ± Нежелательно - Нельзя Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском Управление выпуском Удовлетворение потребителя Тестирование Разработка Управление программой Управление продуктом - - - - - - - - - - - - + + + + + + + + + + ± ± ± ± ± ± ± ±
50. Проблемы сплоченной команды Малое количество вариантов «Зацикливание» Непринятие новых рисков Отвергание новых действий Отказ от внешней экспертизы Предвзятость к собственной позиции Отвергание организационных активов Очень сплоченная команда Ошибки в проекте
51. BesTeamKP I ® – симулятор управления портфелем IT проектов Agile (Scrum) .
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Краткое содержание : Основные стандарты управления проектами ; Понятие проекта ; Виды проектов по внедрению ИС ; Управление проектами как дисциплина ; Системы управления проектами. Из этой темы Вы узнаете: Международные стандарты по управлению проектами; Виды сертификации в области управления проектами; Основные понятия о проекте; Окружение проекта; Стандарты и нормативы при управлении проектами; Классификацию проектов Отличия ИТ-проектов от проектов в других отраслях; Развитие образования в области управления проектами; Система управления проектами; Программное обеспечение для управления проектами.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» На чем базируется изложение материала темы? Изложение материала темы базируется на требованиях к структуре и составу процедур управления, изложенных в стандартах Института Управления Проектами США (PMI, PMBoK 2004) и соответствует требованиям Российской Ассоциации Управления Проектами (Совнет, НТК 2001 - Национальные требования к компетенции специалистов по управлению проектами). На семействе стандартов ИСО 9000, которые были разработаны для того, чтобы помочь организациям всех видов и размеров внедрять и обеспечивать функционирование эффективных систем менеджмента качества: ГОСТ Р ИСО 9000-2001 описывает основные положения систем менеджмента качества и устанавливает терминологию для систем менеджмента качества; ГОСТ Р ИСО 9001-2001 определяет требования к системам менеджмента качества для тех случаев, когда организации необходимо продемонстрировать свою способность предоставлять продукцию, отвечающую требованиям потребителей и установленным к ней обязательным требованиям, и направлен на повышение удовлетворенности потребителей; ГОСТ Р ИСО 9004-2001 содержит рекомендации, рассматривающие как результативность, так и эффективность системы менеджмента качества. Целью этого стандарта является улучшение деятельности организации и удовлетворенность потребителей и других заинтересованных сторон. Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 1 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Возможный вариант развития проекта По статистике, не все проекты завершаются успешно. Приходилось ли вам участвовать в проекте, когда энтузиазм сменялся разочарованием и завершался «награждением тех, кто не участвовал»? Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Три важнейших фактора проекта Любой проект характеризуется тремя важнейшими факторами: Временем Стоимостью Масштабом Эти факторы удобно иллюстрировать в виде сторон так называемого проектного треугольника. Каждая из сторон имеет следующий смысл: Сторона треугольника «Время» определяется длительностью выполняемых в проекте задач. Сторона треугольника «Стоимость» определяется стоимостью используемых в проекте ресурсов: персонала, оборудования и материалов. Сторона треугольника «Масштаб» зависит от рамок и размера проекта, а также от того, какие назначения сделал менеджер проекта. Чем рациональнее он распределит нагрузку ресурсов, тем больших результатов ему удастся добиться в проекте, и, стало быть, тем шире будет область охвата проекта. Таким образом, три стороны треугольника взаимосвязаны, потому что при внесении изменения в один из этих элементов меняются два других. Задача менеджера проекта добиться первоначального равновесия сторон проектного треугольника: уложиться в сроки, выполнить проект в рамках выделенного бюджета и получить результаты, которые удовлетворяют требованиям заказчика. Для заметок : __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для демонстрации результатов проведенных исследований и расчетов в области организационно-экономической целесообразности выполнения проекта следует показать в графической форме: сетевой график выполнения проекта; ленточный график выполнения проекта (диаграмма Ганта); график потребности в трудовых ресурсах; структуру затрат на выполнение проекта в виде круговой диаграммы; числовые параметры, характеризующие экономическую целесообразность выполнения проекта.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Матрица компромиссов проекта – это простое и удобное средство для принятия решений Матрица помогает расставить приоритеты, обсудить их с заказчиком. С помощью матрицы определяют какой из трех факторов проекта: время, стоимость или масштаб – нужно сдерживать, какой нужно усилить, а с каким нужно согласиться. Столбцы матрицы имеют следующий смысл: Зафиксировать Изменить Пересчитать и принять В строках матрицы отображаются время, стоимость, масштаб. Менеджер проекта вместе с заказчиком решают, что нужно сделать с каждым из трех факторов, и матрица облегчает достижение соглашения по спорным вопросам. Зафиксировать. Матрица помогает обозначить проектное ограничение, воздействие на которое практически невозможно в столбце «Зафиксировать». Смысл ограничения ресурсов ясен. Ограничение по срокам означает, что дату окончания проекта невозможно перенести. Ограничение по масштабу – это стратегия выпуска продукта или услуги с набором базовых характеристик. Изменить. В столбце «Изменить» отображается элемент, который требует наилучшего значения в конце проекта. Например, оптимизация ресурсов – это минимальное их использование, оптимизация времени – это успешное завершение проекта в короткий срок, а оптимизация масштаба – это выпуск продукта или оказание услуги с наибольшим набором возможностей. Пересчитать и принять. Когда одна переменная зафиксирована, а вторая оптимизируется, то значение третьей переменной определяется значениями первых двух. Тема №1 Пререквизиты проекта и начальный этап проекта
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Давайте теперь посмотрим, как у нас нагромождаются проблемы Несвоевременная отчётность – это отчётность, которую вы предоставляете заказчику или своему руководителю. Это также отчётность, которую вам предоставляют сотрудники вашей команды. Несвоевременная отчётность может повлечь за собой несвоевременное обнаружение проблем в проекте. Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 2 - Ключевые участники проекта Поскольку проект считается успешным, когда он отвечает ожиданием ключевых участников, то в любом проекте важно определить, кто является ключевыми участниками проекта и как они могут и будут влиять на него. Чтобы определить круг ключевых участников проекта, менеджер проекта должен ответить на вопросы: Чьи интересы будут затронуты по ходу или результатам проекта? Какие функции или бизнес-процессы изменятся в результате выполнения проекта? Кто выделяет ресурсы для проекта (люди, помещение, рабочее время, инструменты, деньги)? Кто будет исполнять работы по проекту? Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
Обзор методологии MSF
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Основным результатом определения предметной области является документ , содержащий описание предметной области, которое позволяет определить цели проекта, требования к организации работ, сроки и стоимость, границы проекта и т.д. Описание предметной области позволяет определить: Цели проекта: измеримые результаты, их характеристики Требования к организации работ: условия, стандарты, обязательства Сроки и стоимость Границы проекта Критерии приемки результата Ограничения и допущения Контрольные события Изначально сформулированные риски Участники проекта Возможно, таких документов будет несколько: на этапе инициации и на этапе планирования. На этапе инициации описание предметной области содержит требования, необходимые для принятия решения о начале проекта. Обычно это самые существенные требования. Он может называться: Концепция продукта или услуги Концептуальные требования Техническое задание [ГОСТ 34.602-89 ] Вполне допустимо, что как общие, так и детальные требования будут описаны одним документом, который создается постепенно, в несколько этапов. Не следует углубляться в излишние детали до принятия решения о начале проекта. После определения и подтверждения требований можно приступать к детализации утвержденной части проекта.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 9 - Основные различия Определение требований к проекту: в ИТ-отрасли, в отличие от других, часты ситуации, когда требования к проекту чётко не определены. Это может быть связано с большим количеством заинтересованных лиц проекта, неясностью целей заказчика. Как правило, именно инициатор или заказчик проекта до конца не знает, чего он ждёт от конкретного ИТ-проекта. Нередко возникновение сложностей при завершении проектов, когда руководство компании выставляет дополнительные условия и требования при закрытии. Порой бывает очень трудно убедить высшее руководство компании в необходимости инвестиции в ИТ. Статистика такова, что более половины всех проектов остаются незавершёнными при отсутствии должной поддержки со стороны высшего руководства. При затягивании проектов (например, внедрении ERP ) возможны случаи, когда внедряемые технологии морально устаревают, и результатом внедрения становится старт нового проекта – уже по модернизации. Что касается самого внедрения продукта, то руководители ИТ-проектов сталкиваются с противодействием пользователей. При разработке продуктов ИТ критически важно учитывать мнение конечных пользователей. Ну и, конечно же, изменения в процессе реализации ИТ-проекта могут свести на нет все усилия проектной команды. А потому при реализации ИТ-проектов, особенно крупных, критически важно формализовать процедуру внесения изменений. Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №9 Особенности организации и управления крупными ИТ проектами
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Жизненный цикл продукта и жизненный цикл проекта Как известно, проекты состоят из процессов. Процессы – это серии действий, которые ведут к получению результата. Нужно различать две категории процессов: Процессы управления продуктом Продукт – это результат, это то, что создается, или услуга, которая будет оказана. Процессы управления проектом Проект – это работа, которую нужно выполнить, для того чтобы создать продукт или услугу. Эти две группы процессов могут перекрываться и интерактивно взаимодействовать в ходе проекта. Например, масштаб проекта не может быть определен, если нет понимания того, как создавать продукт. Слова «жизненный цикл» относятся и к продукту, и к проекту. Взаимосвязь жизненного цикла проекта с жизненным циклом продукта сильно зависит от отрасли. Например, проект, целью которого является разработка нового вида персонального компьютера для рынка. Этот проект – лишь одна фаза жизненного цикла продукта. Обычно в результате проекта получают один вид продукта. Например, целью большого проекта является внедрение EPM решения (Enterprise Project Management – Система для корпоративного управления проектами) в рамках всей организации. Внедренное решение – это один большой продукт, в который могут входить другие, более мелкие компоненты: внедрение в рамках пилотной зоны, в рамках отдельного департамента, в рамках всей организации. Каждый из компонентов может включать другие, более мелкие компоненты. Тема №1 Пререквизиты проекта и начальный этап проекта
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Качество продукции с точки зрения производителя и потребителя Взгляды на качество продукции со стороны производителя и потребителя разные. Они по-разному измеряют ценность и стоимость продукции. Производители, как правило, измеряют величину ценности своей продукции на основе затрат на производство. Для производителя цена и ценность продукции имеют одно и то же значение. Потребитель отождествляет как ценность только лишь ту часть свойств продукции, которая соответствует его потребностям и ожиданиям (требуемые свойства) Часть стоимости продукции может не представлять ни какой ценности для потребителя. Более тонкий аспект относится к ощущению потребителя, когда он чувствует, что платит больше, чем надлежит за полученный им набор технических характеристик. Фактический набор потребительских свойств продукции может не содержать некоторой специфической характеристики, необходимой потребителю. В этом случае, потребитель должен будет приложить дополнительные усилия (время и затраты) для того, чтобы получить в итоге желаемый результат. Для производителя соотношение ценности и стоимости всегда кажется более выигрышным, чем для потребителя. Возможны 4 стратегии повышения качества: ценность , стоимость (повышение ценности больше повышения стоимости); ценность , стоимость const (повышается ценность без увеличения стоимости); ценность const , стоимость (снижается стоимость без увеличения ценности); ценность , стоимость (снижение стоимости больше снижения ценности). Реализовать выбранную Руководством стратегию повышения удовлетворенности потребителя можно только при сокращении затрат на контроль и исправление дефектов и несоответствий. Эти затраты сокращаются только при наличии механизма предотвращения дефектов. А это, в свою очередь, возможно только при создании СМК
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Поскольку управление проектом — это конечное действие, группа процессов инициации начинает эти циклы, а группа завершающих процессов закрывает их. Интеграционная природа управления проектами требует, чтобы группа процессов мониторинга и управления взаимодействовала с каждым аспектом других групп процессов. Группа завершающих процессов, к которым и относится закрытие проекта, формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению. В группу завершающих процессов входят процессы, используемые для формального завершения всех операций проекта или фазы проекта, передачи завершенного продукта другим лицам или закрытия остановленного проекта. Когда эта группа процессов выполнена, она подтверждает, что во всех группах процессов должным образом совершены определенные процессы для закрытия проекта или фазы проекта, и формально устанавливает, что проект или фаза проекта окончены. Для заметок: ____________________________________________________________________________________________________________________________ _ ____________________________________________________________________________________________________________________________________________________________ _______________ ________________________________________________________________________________________________________________________________________________________________________________________________________________ ______________ ____________________________________________________________________________________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)». В настоящее время существует множество моделей жизненного цикла ИС, но три из них – фундаментальные. Этими фундаментальными моделями жизненного цикла являются: Каскадная Инкрементная Эволюционная Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла. При этом конкретную модель жизненного цикла следует выбирать так, чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между собой и определены их взаимосвязи с предшествующими процессами, работами (видами деятельности) и задачами (заданиями). В настоящем учебном пособии описаны три фундаментальные модели жизненного цикла с присущими им недостатками (аргументами против их применения) и преимуществами (выгодами). Эти недостатки и преимущества должны быть учтены при выборе модели жизненного цикла для проекта. Каскадная модель жизненного цикла по существу реализует принцип однократного выполнения каждого из следующих видов деятельности в их естественных границах: Установление потребностей пользователя Определение требований Проектирование системы Изготовление системы Испытание Корректировка Поставка или использование 3 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Инкрементная модель жизненного цикла, называемая также запланированным усовершенствованием продукта, начинается с выдачи набора требований и реализует разработку последовательности конструкций. Первая конструкция содержит часть требований, в последующую конструкцию добавляют дополнительные требования и так далее до тех пор, пока не будет закончено создание системы. Для каждой конструкции выполняют необходимые процессы, работы и задачи. Например, анализ требований и создание архитектуры могут быть выполнены сразу, в то время как разработку технического проекта программного средства, его программирование и тестирование, сборку программных средств и их квалификационные испытания выполняют при создании каждой из последующих конструкций. В данной модели при разработке каждой конструкции работы и задачи процесса разработки выполняют последовательно или частично параллельно с перекрытием. При частично одновременной разработке последовательных конструкций работы и задачи процесса разработки могут быть выполнены параллельно для ряда конструкций. Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки. Преимущества инкрементной модели : Однократное представление всех возможностей (характеристик) системы Необходимость только единственной фазы перехода от старой системы к новой Необходимость изначального использования характеристик системы Пригодность для использования промежуточного продукта Естественное разделение системы на наращиваемые компоненты (инкременты) 3 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» В эволюционной модели жизненного цикла систему также разрабатывают в виде отдельных конструкций, но в отличие от инкрементной модели требования изначально не могут быть полностью осознаны и установлены. В данной модели требования устанавливают частично и уточняют в каждой последующей конструкции . При таком методе для каждой конструкции работы и задачи процесса разработки выполняют последовательно или параллельно с частичным перекрытием. Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки. Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения: Все возможности системы предопределены изначально Ограниченные возможности долговременного привлечения ресурсов (средств или персонала) Преимущества использования данной модели: Изначальное определение возможностей системы Пригодность для использования промежуточного продукта Естественное разделение системы на наращиваемые компоненты (инкременты) Привлечение персонала и средств по мере необходимости Необходимая обратная связь с пользователем для полного понимания требований Упрощение надзора за изменением технологии 3 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Основные технологические процессы – целенаправленная, логически выстроенная совокупность функций, направленных на последовательную смену состояний продукта во времени и классифицированных специальным образом. Вспомогательные процессы – совокупность процессов направленных на поддержание основных процессов. Для заметок : __________________________________________________________________________ __________________________________________________________________________ _________________________________________________________________________________________________________________________________________________ _______________________________________________________________________________________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ _________________________________________________________________________________________________________________________________________________ _______________________________________________________________________________________________________________________________________________________ _________________________________________________________________________________________________________________________________________________ ___ 3 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Кривая распределения вероятности для трех проектов Поскольку предметная область проекта А определена наилучшим образом, вероятность проведения реалистичного стоимостного анализа для этого проекта высокая. Для проектов В и С эта вероятность намного ниже, так как проекты имеют существенный уровень неопределенности. Тип контракта и риски Каждому из описанных типов контрактов присущ различный уровень риска и неопределенности. Схема на слайде характеризует зависимость распределения риска от типа контракта. Другими словами, выбор механизма осуществления платежей зависит от степени неопределенности проекта и уровня его риска. Таким образом, существенной разницей между всеми типами контрактов является способ реагирования на риски проекта и их оплата, осуществляемая либо по плановой цене, либо по фактической стоимости. В контрактах, основанных на цене (фиксированная цена, цена за единицу), осуществляемые платежи покрывают все затраты, издержки и прибыль. При этом подрядчик включает в цену контракта все дополнительные расходы, связанные с возникновением в проекте рисковых событий. В контрактах, основанных на стоимости, осуществляется возмещение фактической стоимости выполнения работ плюс дополнительное вознаграждение, выплачиваемое в качестве прибыли подрядчика. Фактически в контрактах подобного типа все риски проекта оплачивает заказчик. Заказчику необходимо отслеживать прогресс проекта и детально фиксировать все его расходы, которые часто являются предметом споров и разногласий между заказчиком и подрядчиком проекта. Итак, пропорция распределения риска между сторонами проекта зависит от наличия возможности у подрядчика или заказчика эффективно планировать и управлять ходом выполнения работ и вносить изменения в план проекта. Выбор типа контракта также зависит от уровня неопределенности проекта. Чем ниже неопределенность проекта, тем выше вероятность проведения качественного стоимостного анализа, результаты которого влияют на выбор типа контракта.
1 - Типы контрактов Существует несколько типов контрактов. Тип применяемого контракта определяется степенью неопределенности проекта. На стадии заключения контракта заказчик стремится максимально переложить риск проекта на подрядчика с целью достижения более экономичного и эффективного выполнения работ проекта. В интересах подрядчика же минимизировать риск проекта с целью увеличения размера потенциальной прибыли. В зависимости от типа, набор обязательных атрибутов контракта может меняться. Однако для контрактов, в соответствии с которыми осуществляется реализация проекта, выделяют два обязательных условия заключения: юридическая грамотность документа и условия осуществления платежей. В основе классификации контрактов лежит механизм осуществления платежей. Порядок выплат во многом зависит от того, насколько определены работы проекта и степени их детализации. Если существует возможность полного описания работ проекта, определения их стоимости, расписания и исполнения без перерывов и задержек, то приемлемым будет использование контракта с фиксированной ценой. В случае высокой неопределенности, не позволяющей точно составить расписание проекта и повышающей общий уровень рисков, чаще всего применяются контракты «цена плюс», подразумевающие возмещение превышения стоимости. В соответствии с PMI категории контрактов подразделяются на типы (на слайде). Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Целеполагание уточняется в ходе выполнения группы процессов по управлению предметной областью проекта В эту группу входят процессы, необходимые для того, чтобы убедиться, что в проект включены все и только требующиеся для достижения целей проекта работы. Это определение и контроль того, что включено и что не включено в проект, а именно: Отличительные черты и функции продукта или услуги проекта Работы, которые необходимо выполнить для получения продукта с требуемыми отличительными чертами и функциями Условия, которые необходимо соблюдать при выполнении работ проекта Процессы управления предметной областью включают: Планирование предметной области – определение методологии, ответственных лиц, типовых шаблонов, инструментов и методов, используемых в рамках проекта для управления предметной областью. Определение предметной области – определение работ проекта (требований к цели, к организации работ, общих требований к проекту, определение заинтересованных лиц). Разработку WBS – детализацию и структурирование работ проекта для упрощения контроля работ, оценки и распределения ответственности. Для заметок : _______________ _________ __________________________________________________ _______________ _________ __________________________________________________ _______________ _________ __________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Определив основные, существенно влияющие на сроки и стоимость проекта требования, менеджер может уточнять подробности в процессе выполнения проекта . На этапе инициации может не потребоваться детального описания всех параметров результата. Следует отметить, что требования могут предъявляться не только к результатам проекта, но и к самому процессу выполнения работ. Сюда могут входить: Требования к соблюдению стандартов качества ( ISO и т.п.), экологических, санитарных норм Требования к персоналу (квалификация, опыт), оборудованию, инструментам и материалам Конечные сроки и стоимость работ Анализ проекта (продукта) включает в себя такие методы, как: ИСР, системный анализ, системный инжиниринг, анализ стоимости и функциональный анализ. Анализ продукта – один из важнейших элементов процесса определения предметной области, направленный на преобразования пожеланий заказчика в измеримые результаты. Требования к проекту могут быть описаны как с точки зрения потребностей – «что нужно», так и с точки зрения исключений – «чего не нужно». Это позволит исключить из проекта часть требований, которые может предъявить заказчик (например, по опыту аналогичных проектов). Определяя требования к результатам проекта, менеджер должен изучить, какие еще стороны могут повлиять на них и учесть их замечания. Для заметок : _____________ _________ ____________________ __ ______________________________ _______________ _________ ___________________________________________ __ _____ _______________ _________ ___________________________________________ __ _____ _______________ _________ ___________________________________________ __ _____
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Что такое иерархическая структура работ? ИСР обеспечивает выявление работ, необходимых для достижения целей проекта. При таком подходе проект определяется как совокупность иерархически взаимосвязанных, ориентированных на результат элементов (работ). Разбиение проекта на более мелкие составляющие необходимо для: Повышения точности оценок затрат, сроков и потребности в ресурсах Определения и фиксации исходного плана для организации контроля выполнения Упрощения распределения ответственности Получения прозрачной и контролируемой отчетности Максимальной эффективности можно добиться, привлекая к этому процессу других членов команды и используя так называемый метод «мозгового штурма». Различные уровни иерархической структуры работ содержат работы различного уровня детализации. Для структуризации используются различные системы кодов.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» При построении WBS менеджеру следует решить, насколько детально и подробно структурировать работы: какие из них разделять на максимальное число простых работ, а какие оставить на укрупненном уровне детализации . Зачастую менеджер принимает решение о прекращении дальнейшей детализации, основываясь на собственном опыте. Существуют критерии, на которые следует обратить внимание при принятии решения о дальнейшей детализации работ: Возможность оценки параметров работы Если длительность, стоимость или другие важные параметры работы с трудом поддаются оценке, стоит разделить работу на составляющие, каждую из которых оценить отдельно . Вероятно, какой-либо параметр работы не удается точно оценить в силу неопределенности. В этом случае можно попробовать выделить ту часть работы, которую можно оценить, и ту, которая является неопределенной. Возможность контроля выполнения работы Если работа имеет несколько промежуточных результатов, не нужно усложнять ее контроль, а следует разделить ее на этапы, каждый из которых приводит к определенному результату. Возможно, работа состоит из нескольких одновременно выполняемых процессов или функций, контролируемых различным образом. В этом случае ее также следует разделить на составляющие . Если работа слишком длительна, то следует разделить ее на этапы и попытаться найти промежуточные результаты для более точного контроля работы. Возможность назначения ответственных Если за работу отвечает не один человек, а несколько, то, как показывает практика, она может вообще не выполняться. В случае возникновения так называемой «множественной ответственности» необходимо разделить работу на составляющие, разграничив круг ответственности каждого из участников.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Выделяя промежуточные результаты в ходе проекта, менеджер может анализировать отклонения от промежуточных контрольных точек, а не отклонение от конечной цели. Это позволит более точно и регулярно оценивать состояние работ и своевременно проводить корректирующие мероприятия. Для заметок _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Оценка длительности работ – процесс анализа информации о работах проекта и определения их продолжительности, который может производиться на основании существующих нормативов. Правильность оценки длительности работы во многом зависит от точности и полноты исходных данных. Результатом является длительность, выраженная либо в рабочих, либо в календарных периодах. Экспертные оценки – оценки длительности выполнения работ, разрабатываемые экспертами. Отсутствие возможности получить экспертные оценки увеличивает неопределенность и риски проекта. Однако эксперты зачастую не знают всех особенностей проекта и используемых ресурсов, поэтому экспертная оценка потребует корректировки. Оценки по аналогам – оценки, использующие фактические значения длительностей аналогичных работ в предыдущих проектах. Метод часто используется для оценки длительности проекта при недостатке информации о его специфических особенностях. Оценки по аналогам достаточно надежны, если: Работы-аналоги сходны с рассматриваемыми по сути, а не только по внешним атрибутам Люди, проводящие оценку, обладают необходимым опытом Параметрическая оценка – оценка длительности, получаемая на базе объема выполняемых работ и производительности назначенных ресурсов Н апример, определенное количество квадратных метров стен, которые необходимо покрасить, делится на производительность маляра, и получается количество часов, необходимое для покраски.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Подходы для вычисления трудозатрат: определение трудоемкости на основе анализа трудоемкости известного образца (для небольших проектов, в которых трудно выделить отдельные этапы). вычисление трудоемкости на основе экспертных оценок (в тех случаях, когда сведений об аналоге проектируемого изделия нет или когда содержание проекта носит комплексный характер, например при разработке программно-технического комплекса). Затраты труда на внедрение нового решения зависят от времени на осуществление опытной эксплуатации, которое согласовывается с заказчиком и обычно составляет один месяц, или 22 чел.-дня. При 8-часовом рабочем дне этап внедрения может потребовать 176 чел.-ч.. Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для вычисления объема трудозатрат всех составляющих, их следует соотнести с объемом трудозатрат, необходимых непосредственно для разработки нового изделия (этапа), например написания текста программы. Сначала следует определить трудозатраты на алгоритмизацию задачи. Это можно определить, используя коэффициент затрат на алгоритмизацию па, равный отношению трудоемкости разработки алгоритма к трудоемкости его реализации при разработке изделия (программирование). Значение коэффициента па лежит в интервале от 0,1 до 0,5. Обычно его выбирают равным 0,3. Коэффициент затрат на проведение тестирования отражает отношение затрат труда на тестирование программы к затратам труда на ее разработку и может достигать значения 50%. Обычно его выбирают на уровне 0,3. Коэффициент коррекции программы при ее разработке отражает увеличение объема работ при внесении изменений в алгоритм или непосредственно в изделие (в текст программы) по результатам уточнения постановки и описания задачи, изменения состава и структуры входной и выводимой информации, а также в процессе улучшения качества изделия без изменения ее алгоритмов. На практике, например при разработке программы, в происходит переработка 5—40% программы. Коэффициент коррекции программы выбирают на уровне 0,3. Коэффициент затрат на написание документации отражает отношение затрат труда на создание сопроводительной документации к затратам труда на разработку изделия. Его значение может достигать 0,75. Для небольших программ коэффициент затрат на написание сопроводительной документации может составить 0,35. Зная экспертные значения трудозатрат на выполнение соответствующего этапа, можно определить затраты труда на проектирование основного содержания нового продукта.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Оценка длительности может также проводиться по трем точкам. Если получить точную детерминированную оценку длительности не удается, то производится оценка по трем точкам. Оценивается наиболее вероятная длительность работы ( ), а также наименьшая и наибольшая длительности. Вторые две оценки называют оптимистической (О) и пессимистической (П) . Анализ резервов - дополнительный интервал времени, называемый резервом или буфером , который может быть добавлен к длительности работы или к длительности проекта в целом для минимизации рисков при составлении расписания. Резерв может быть вычислен как определенный процент от длительности или как фиксированный интервал времени. В дальнейшем, по ходу получения дополнительных сведений о работе, он может быть уменьшен или аннулирован. Допущенный резерв должен быть оговорен в документации по работе. Факторы, влияющие на длительность работ Менеджеру следует внести корректировки в длительности, полученные в результате экспертной, параметрической или оценки по аналогам. Эти методы основываются на опыте предыдущих проектов и не учитывают особенности планируемого проекта, в частности, специфику его ресурсов. Болезни персонала, поломка и обслуживание техники, обучение. Подобные факторы могут быть предсказаны статистически или же являться результатом наступления рисков. Неполный рабочий день. Если заранее известно, что работа будет проводиться лишь часть стандартного рабочего дня, длительность работы, соответственно, увеличивается. Взаимовлияние ресурсов может быть связано с физическими помехами (несколько кранов на стройке мешают друг другу), с невозможностью согласованной работы (люди не успевают обмениваться информацией, делают общую работу по-разному и т.п.), а также с конфликтами в коллективе.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Методология и практика тестирования ПО Вопросы тестирования следует рассматривать в контексте всего жизненного цикла ПО, начиная от разработки ТЗ и заканчивая сопровождением приложений. Как известно, тестирование – это процедура обнаружения дефектов (ошибок) ПО до его промышленного использования. Очевидно, что трудоемкость такой работы связана с количеством самих ошибок, в связи с чем надо четко выделить основные причины их появления: неудовлетворительное организационное, методическое и техническое обеспечение всего процесса разработки сжатые сроки исполнения проекта сложность проекта, большое число требований и их изменений по ходу работы недостаточная квалификация разработчиков Тестирование является лишь составляющей частью отладки – процесса доводки ПО после его написания до эксплуатационного состояния. Процесс этот включает две основные процедуры: обнаружение ошибок (тестирование) и поиск и устранение их причин. Однако, даже учитывая все возможные взаимосвязи этих работ, нужно подчеркнуть, что тестирование является достаточно автономным, независимым этапом жизненного цикла ПО. При этом стоит подчеркнуть, что повышение качества разработки (которое обратно пропорционально количеству ошибок в приложении) напрямую снижает затраты на устранение ошибок, но на объем тестирования влияет совсем не так сильно: его нужно проводить в любом случае и желательно "по полной программе". Понятно также, что организация и методика тестирования в значительной степени зависят от целевого назначения разработки: коробочный продукт, заказной проект или внутрифирменный. И тут стоит еще раз обратить внимание на то, что прошедшие семинары были адресованы в первую очередь разработчикам ИТ-подразделений заказчиков. Объяснение этому простое: во-первых, объем разработок, выполняемых в таких компаниях и в специализированных ИТ-фирмах по крайней мере соизмерим; во-вторых, в силу ряда причин задачи тестирования при выполнении внутрифирменных проектов достаточно специфичны и очень актуальны. Говоря об особенностях процедур тестирования в ИТ-подразделениях, наверное, надо выделить три основных, весьма противоречивых аспекта. Проведение качественного тестирования требует наличия специалистов и инструментов соответствующего профиля. ИТ-подразделениям держать собственные группы тестировщиков просто невыгодно.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Основные понятия дисциплины «Тестирование» RUP : Объективная оценка – оценка ПО на основе определенных критериев (воспринимаемое качество, соответствие стандартам, выявление дефектов и т.п.). Сводная оценка результатов тестирования – объективная оценка выпуска с точки зрения согласованной миссии. План тестирования – определяет миссию и конкретные цели тестирования для каждой итерации. Список идей тестов – неформальный список, создаваемый в ходе обдумывания различных ситуаций, которое может показать необходимость создания тестов. Комплект тестов – группа, взаимосвязанных тестов, которые, будучи выполненные вместе, дают оценку общей деятельности проблемы. Тестовые сценарии – пошаговые инструкции по выполнению теста. Прецеденты тестирования – связывают тестовую задачу с тестируемой процедурой. Дефект – запрос на изменение, вызывающий внесение исправлений в последующем выпуске или итерации. Модель рабочей нагрузки – модель, характеризующая типичные и исключительные нагрузочные условия, которые должна выдерживать система. Тестовый цикл – период выполнения тестовой задачи и оценка результатов тестов. Дополнительные обязанности специалиста по тестированию: составление плана обеспечения качества участие в рецензировании требований и проектной модели участие в работе группы контроля за изменениями в целях проведения обзора дефектов и решения дальнейшей их судьбы 3 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для преодоления перечисленных проблем была предложена итеративная модель . Она предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально. С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental) . Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта). Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователь (заказчик) получает только результат финальной итерации как полную версию системы. С другой стороны, итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные идеологи вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада. Поскольку в идеале на каждом шаге мы имеем работающую систему, итеративная модель имеет следующие преимущества: можно очень рано начать тестирование пользователями можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств (в частности, за счет сокращения второстепенной функциональности) Таким образом, значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Оценка эффективности процесса 1. Обобщенная оценка эффективности процесса СМК за рассматриваемый период осуществляется на основе показателя, характеризующего его т. н. коэффициентом полезного действия, рассчитываемого по формуле: З ПР к – затраты на полезные работы в рамках К -ого процесса, руб. З ВР к – затраты на вспомогательные (операции) работы в рамках К -ого процесса, руб. З НР к – затраты на ненужные работы в рамках К -ого процесса , руб. З НО к – затраты (издержки), обусловленные несоответствиями процесса, руб. Эффективность отдельных операций (видов работ), осуществляемых в рамках анализируемого процесса, оценивается аналогично. 2. По итогам оценки эффективности анализируемых процессов определяются процессы СМК, требующие улучшения, и составляется их перечень. Для заметок: __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Роли в проектной команде Один из наиболее известных подходов к распределению ролей в проектной команде был предложен доктором Белбином (Великобритания). В соответствии с его методикой, в каждой команде, которая стремится быть эффективной в своей работе, должны выполняться восемь ролей вне зависимости от численности команды. Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
Обзор методологии MSF
Обзор методологии MSF
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Первый шаг в процессе подбора персонала – определение стратегий развития проекта и человеческих ресурсов в рамках этой стратегии. Соответствие ценностей и взглядов сотрудника ценностям компании и команды – очень важно. Учет этих факторов на этапе планирования команды: позволяет предотвратить конфликты; помогает мотивировать сотрудников. Последовательность 1. Работа, которую предстоит выполнять сотруднику. 2. Специфика стиля руководства и внутрифирменных взаимодействий. Специфика команды (совместимость людей), личность руководителя. Правила составления: Каждая компетенция формулируется предельно конкретно. В профиле должны быть четко расставлены приоритеты. Каждая компетенция в профиле должна иметь свой «измеритель». Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» На этапе набора команды проекта возможна разработка документа – матрица навыков членов команды. Исходными данными для подбора персонала являются: план управления обеспечением проекта персоналом; организационная структура с распределением ролей и ответственности; активы организационного процесса - существующие в организации правила и процедуры подбора персонала, описание возможностей сотрудников, включающее предыдущий опыт работы, личные интересы, личностные характеристики, доступность в требуемое проектом время. В качестве методов и средств подбора персонала проекта используются: предварительные назначения; переговоры руководителя проекта с функциональными менеджерами и руководителями других проектов по согласованию выделения и назначения сотрудников для работы в данном проекте; Это делается, например, когда проект является результатом победы в конкурсе, и участие определенных сотрудников было заранее оговорено в конкурсном предложении. привлечение персонала со стороны, в случае, если внутри организации отсутствуют специалисты с необходимыми знаниями и навыками. Результатами этапа подбора персонала являются: назначение персонала проекта на работу в нем (на основе полной или частичной занятости); список персонала проекта, включающий всех членов проектной команды и основных лиц, заинтересованных в результатах проекта. Список может быть формальным или неформальным, подробным или не очень в зависимости от обстоятельств, существующих в проекте.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Проектные стратегии и компетентности менеджера проектов: комплексное управление проектами (продолжение) В комплексном управлении проектами подобную декомпозицию использовать нельзя, поскольку невозможно установить содержание проектов: даже если в целом его можно определить, любая декомпозиция будет недействительной из-за постоянно происходящих изменений. Вместо декомпозиции на базовые элементы и последующего восстановления с помощью поэтапной интеграции в комплексном управлении проектами используется подход системного мышления, в котором множество представлений составляют целостную картину проекта. Комплексное управление проектами использует традиционное УП для реализации краткосрочных проектов, содержание которых характеризуется определенностью. Для проектов с неопределенным содержанием используются волновое планирование и Governance Contracting , а также методика накопления знаний с «двойным циклом обучения» для периодического обновления структуры проекта. ( Governance Contracting — специальная технология контрактинга, разработанная доктором Дэвидом Добкинсом в 1989-2002 гг.). Цепочка компетентностей комплексного управления проектами была создана на основе архетипов как традиционного, так и комплексного управления проектами. С одной стороны цепочки находится простейшая форма традиционного управления проектами: компетентности ограничены девятью функциональными областями. С другой стороны цепочки находится комплексное управление проектами с его девятью представлениями и парадигмой неопределенности. При продвижении вдоль цепочки компетентностей от традиционного управления проектами к комплексному список компетентностей растет: комплексное управление проектами включает все компетентности традиционного (рисунок на слайде). Между традиционным и комплексным управлением проектами находится переходная область, где пересекаются и накладываются друг на друга две философии. В этой точке становятся очевидными различия между дисциплинами. Тема №9 Особенности организации и управления крупными ИТ проектами 9 -
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Ирвин Джанис пришел к выводу, что когда проектная команда становится слишком сплоченной и имеет общие ожидания и нормы, в процессе принятия решений возникают семь изъянов: Малое количество вариантов Соображения команды ограничиваются малым количеством вариантов, возможности за пределами этого ряда отвергаются с ходу и совсем не рассматриваются. «Зацикливание» Первоначальные цели, которые должны были быть достигнуты в результате определенных действий, не пересматриваются и не оспариваются. Непринятие новых рисков Вновь обнаруженные риски не принимаются во внимание, чтобы поставить под сомнение изначально выбранный курс действий. Отвергание новых действий Действия, отвергнутые проектной командой с самого начала, не рассматриваются вновь в свете новой информации. Отказ от внешней экспертизы Не привлекаются опыт и знания внешних экспертов. Предвзятость собственной позиции Когда обнаруживается новая информация, команда проекта отдает предпочтения тем сведениям, которые поддерживают ее первоначальные гипотезы, и игнорирует противоречащую им информацию. Отвергание активов организационного процесса Команда не думает о том, как бюрократическая инерция или сопротивление организации могут помешать воплощению в жизнь выбранной командой линии ведения проекта.
ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Какие организации устанавливают стандарты в области управления проектами? (выберите все правильные ответы) PMBOK IPMA PMO PMA Проекты могут быть: (выберите все правильные ответы) Социальные Экономические Организационные Другие В отношении истории развития управления проектами за рубежом можно отметить, что: (выберите все правильные ответы) Как самостоятельная дисциплина управление проектами развивается с глубокой древности Программа "Поларис" (US Navy) была одной из первых, где была опробована система сетевого планирования Управление риском всегда было самостоятельной дисциплиной в сфере управления проектами