Файл: Вопросы к дифзачету по дисциплине Управление проектами в области it.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 26.10.2023
Просмотров: 46
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Вопросы к дифзачету по дисциплине «Управление проектами в области IT»
Преподаватель: Слюсарь В.В.
1. Понятие проекта в сфере разработки ПО.
Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата. Временный характер проектов указывает на определенное начало и окончание. Окончание наступает тогда, когда цели проекта достигнуты или когда проект прекращается в связи с тем, что его цели не будут или не могут быть достигнуты, либо когда в проекте больше нет необходимости. Проект также может быть прекращен, если клиент (заказчик, спонсор или ответственное лицо) желает прекратить проект. «Временный» не обязательно предполагает краткую длительность проекта. Это относится к вовлеченности в проект и длительности проекта. «Временный», как правило, не относится к создаваемому в ходе проекта продукту, услуге или результату. Большинство проектов предпринимается для достижения устойчивого, длительного результата. Например, проект по возведению памятника государственного значения создаст результат, который останется на века. Проекты также могут приводить к воздействиям на социальную, экономическую и окружающую среду, превышающим длительность самого проекта.
Каждый проект приводит к созданию уникального продукта, услуги или результата. Конечный результат проекта может быть осязаемым или неосязаемым. Несмотря на то что в некоторых операциях и поставляемых результатах проекта могут присутствовать повторяющиеся элементы, их наличие не нарушает принципиальной уникальности работ по проекту. Например, офисные здания могут строиться из одинаковых материалов или одной и той же строительной бригадой. Но каждый такой строительный проект будет уникальным ввиду разного местоположения, отличий в архитектуре, обстоятельствах, ситуациях, разных заинтересованных сторон и т. д.
2. «Железный треугольник».
Итак, железный треугольник (iron triangle, project management triangle) – это абстракция, описывающая взаимодействие основных атрибутов или характеристик проекта: объема работ, сроков и ресурсов (команды, а следовательно и бюджета). Выглядит он обычно так:
Иногда в центр этого треугольника кладут еще Quality, отмечая таким образом четвертую вершину, которая взаимосвязана с этими тремя, но мы сейчас не будем усложнять картину.
Смысл этого треугольника в том, что ограничения на объем работ (scope), сроки (time/schedule) и бюджет (cost/budget) должны быть разумными, и любой менеджер проекта должен уметь ими управлять. В противном случае проект рискует стать провальным.
Наверняка каждый, даже не занимающиеся непосредственного управлением проектами, сталкивались с ситуациями, когда оценка на разработку системы или ее куска превышает либо сроки, за которую необходимо сделать работу, либо бюджет, имеющийся у клиента. А может, сталкивался и с такими ситуациями, когда эта самая работа должна быть сделана в указанный срок ограниченными ресурсами (командой). Эту последнюю ситуацию как раз и называют железным треугольником, то есть треугольником, в котором все наши три вершины ограничены и зажаты, и у нас нет свободы действий ни по одной из них. И чем экстремальнее это “зажимание”, тем сложнее команде выполнить взятые на себя (или пообещанные кем-то сверху) обязательства.
3. Отличия разработки ПО от других отраслей.
-
Только 35 % проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности. -
46 % проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. Среднее превышение сроков составило 120%, среднее превышение затрат 100%, обычно исключалось значительное число функций. -
19 % проектов полностью провалились и были аннулированы до завершения.
То, что производят программисты нематериально — это коллективные мысли и идеи, выраженные на языке программирования.
Ресурс - люди и их навыки. Система каждого нового проекта будет отличаться от имеющихся уже, хотя бы на часть.
4. Проект и организационная структура компании. Различия между функциональной и проектной структурой.
http://wiki.vspu.ru/workroom/pi51/%D1%87%D0%B0%D1%81%D1%82%D1%8C%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D0%B8_333
Структура предприятия влияет на структуру управления проектами, реализуемых на его базе. К основным организационным структурам относятся: функциональная, матричная, проектная.
Функциональная структура.
ФОС представляет собой иерархию, в которой для каждого ее члена четко определен один вышестоящий руководитель. Персонал группируется по специальностям
.
Функциональная структура ориентирована на производственные предприятия, направленные на создание типового продукта или услуги.
Тот формулирует ответ, который затем совершает обратное путешествие по иерархии. Таким образом, процесс занимает много времени и требует усилий тем большего числа людей, чем большее количество уровней иерархии требуется преодолеть. Недостаток ФОС: затрудненное взаимодействие между функциональными подразделениями.
Проектная структура (особенно при реализации крупных проектов) представляет собой фактически филиал фирмы внутри предприятия со своими функциональными подразделениями либо является отдельным предприятием, созданным специально под проект. Члены проектной команды полностью ориентированы на результаты проекта и его руководителя. Такая структура наиболее эффективна при наличии больших проектов с жизненным циклом более 2 лет
Проектная структура ориентирована на проектную деятельность: создание нового, уникального продукта или услуги. Проектная структура (особенно при реализации крупных проектов) представляет собой филиал фирмы внутри предприятия со своими функциональными подразделениями либо является отдельным предприятием, созданным специально под проект. Члены проектной команды полностью ориентированы на результаты проекта и его руководителя.
Обе эти структуры имеют свои преимущества и недостатки, поэтому на практике каждая из них в чистом виде используется нечасто. Это вызвано и объективными причинами, поскольку нет предприятий, в которых присутствует в рафинированном виде производственная или проектная деятельность. Обычно используется некоторая их комбинация: например, на функциональную структуру накладывается проектно-ориентированная, в результате чего появляется матричная структура.
5. Матричная организация компании. «Слабая», «сбалансированная» и «жесткая» матрицы.
Матричная структура представляет собой комбинацию функционального и проектного подходов. Существует несколько типов матричных структур. Разница между ними заключается в соотношении функционального и проектного принципов управления. В зависимости от преобладания функциональной или проектной составляющей
деятельности предприятия матричные структуры делятся на упрощенную (слабую), сбалансированную и усиленную (жесткую).
Упрощенная матричная структура ближе всего к функциональной организации.
Усиленная — к проектно-ориентированной.
Сбалансированная занимает промежуточное положение.
Руководители проектов сохраняют за собой право определять приоритетность и сроки решения той или иной задачи, в то время как руководители структурных подразделений могут лишь выбирать конкретного исполнителя и методику решения.
Основной недостаток матричной структуры — нарушение принципа единоначалия в организации. Члены проектной команды порой не могут решить, кому они прежде всего подчиняются — своему линейному руководителю или менеджеру проекта. Двойственность положения участников и двоевластие нередко порождают конфликты внутри фирмы по таким важным вопросам, как выделение специалистов и распределение ресурсов.
Достоинства матричной структуры:
-
комбинирование работников служб компании в реализуемых проектах; -
гибкость при работе с большим количеством проектов; -
увеличение взаимодействия между руководителями внутри проектных команд, усиление взаимосвязи между ними; -
вовлечение руководителей и служащих в творческую деятельность проекту и совершенствованию производства; -
сокращение нагрузки на руководителей высшего уровня управления путем передачи полномочий на средний уровень при сохранении единства координации и контроля за главными решениями; -
усиление ответственности конкретного руководителя как за проект и элементы проекта; -
быстрое реагирование на изменение внешней среды; -
преодоление барьеров внутри организации, без помех в развитии функциональной специализации.
Недостатки матричной структуры:
-
сложность для реализации: для внедрения необходима длительная подготовка работников и организационной культуры; -
структура сложна, громоздка и дорога во внедрении и эксплуатации; -
в связи с системой двойного подчинения подрывается принцип единоначалия, что часто приводит к конфликтам; порождается двусмысленность роли исполнителя и руководителей, что создает напряжение в отношениях между членами трудового коллектива компании; -
наблюдается тенденция к анархии, нечетко распределены права и ответственность между элементами; -
характерна борьба за власть, т. к. в рамках структуры четко не определены властные полномочия; -
чрезмерные накладные расходы на содержание большего количества руководителей и на разрешение конфликтных ситуаций; -
двусмысленность и потеря ответственности; -
трудности с перспективным использованием специалистов в компании; -
наблюдается частичное дублирование функций; -
несвоевременно принимаются управленческие решения; характерно групповое принятие решений; -
отмечается конформизм в принятии групповых решений; -
нарушается традиционная система взаимосвязей между подразделениями; -
затрудняется или отсутствует полноценный контроль по уровням управления; -
неэффективна в кризисные периоды.
6. Модель зрелости процессов создания ПО (CMM – Capability Maturity Model).
https://ru.wikipedia.org/wiki/Capability_Maturity_Model
Уровни зрелости управления
https://studme.org/65663/menedzhment/model_zrelosti_protsessa
Главным в модели СММ является понятие зрелости организации.
Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров и решения зачастую принимаются "на ходу". В этом случае велика вероятность превышения бюджета или срыва сроков сдачи проекта, и потому менеджеры вынуждены заниматься только разрешением ближайших проблем.
Зрелой считается организация, в которой выполняются следующие условия:
– имеются четко определенные процедуры создания программных продуктов и управления проектами, которые уточняются и совершенствуются в пилотных проектах с помощью анализа составляющих "себестоимость - прибыль";
– оценки времени и стоимости выполнения работ основываются на накопленном опыте и поэтому достаточно точны;
– в компании существуют стандарты на процессы разработки, тестирования и внедрения программного обеспечения, правила оформления конечного программного кода, компонент, интерфейсов и т.д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения.
Итак, стандарт СММ – это модель обеспечения качества, которая состоит из критериев оценки зрелости организации и рецептов улучшения существующих процессов. В модели СММ определено пять уровней зрелости организаций, характеристики которых представлены на рис.
Начальный уровень (initial level) является основой для развития предприятия на следующих уровнях. Считается, что на предприятии начального уровня организации не существует стабильных условий для создания качественного программного обеспечения. Следовательно, результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов. Это означает, что успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Если получившие в проектах опыт специалисты уходят с предприятия, то с их уходом резко падает качество производимого программного обеспечения.
Достижение второго, повторяемого уровня (repeatable level) определяется внедрением на предприятии технологии управления проектами.