Что нужно сделать до старта проекта? Часть 3. Ограничения проекта
В первой статье этого цикла речь шла о формулировании целей проекта, результатов проекта и сбору требований к ним, как необходимому шагу для снижения неопределенности проекта. Вторая статья цикла посвящена формулированию допущений по проекту и переходу от допущений к рискам, которые надо будет учесть при планировании сроков и бюджета проекта.
Для того чтобы перейти к подписанию документов, подтверждающих официальное признание проекта, нужно сделать еще один важный шаг – сформулировать ограничения по проекту.
В управлении проектами используется термин «проектный треугольник», для которого используют также название «тройное ограничение проекта». Проектный треугольник описывает взаимодействие ключевых ограничений проекта:
Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в вид у?
Применительно к проекту можно рассуждать о качестве проекта и о качестве результатов проекта. Определение качества, которое использую я, следующее:
Качество – это степень соответствия результата требованиям к нему.
Когда мы говорим о качестве результатов проекта, то его можно проверить, сравнив то, что получилось сделать по результатам проекта, с тем, что требовалось получить (грубо говоря, сравнив продукт проекта с требованиями к нему).
Таким образом, качество результатов проекта тесно связано с содержанием проекта, в котором описаны требования к результатам.
Логика формирования ограничений по проекту следующая:
Как работает проектный треугольник?
Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если мы при сборе требований не учли важные требования – это приведет к появлению новых работ в содержании проекта, сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «бюджет», либо увеличив сторону «срок», либо увеличив обе эти стороны треугольника.
Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие стороны треугольника.
Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться о приоритетах: что важнее для проекта – срок, содержание, качество или бюджет.
Многие из вас уже видели похожие картинки:
Если заказчик настаивает на том, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам, то желательно, чтобы к моменту старта проекта эти требования уже были собраны и утверждены заказчиком. Тогда руководитель проекта под требования может просчитать бюджет и срок. При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования, то срок или бюджет проекта придется изменять (а может быть, и то, и другое).
Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника, то он пытается передать руководителю проекта все риски, связанные с изменениями в проекте. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например, равными 100% от расчетных значений сроков или бюджета).
Какие еще типы ограничений могут быть?
В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:
Какова логика встраивания рисков в ограничения? В PMBOK дается следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Риски, в свою очередь, могут повлиять на содержание проекта, сроки или бюджет проекта.
Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.
Стоит ли использовать подход PMBOK к ограничениям, определяя шесть типов ограничений, или достаточно определить три типа ограничений (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.
Успешность проекта
По выполнению проекта в рамках его ограничений судят об успехе проекта.
Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается, что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если базовые сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались заказчиком проекта, то измерение успешности проекта будет делаться относительно последнего согласованного заказчиком срока и бюджета.
Итак, критерием успешности проекта является реализация всех запланированных результатов проекта, причем в срок и в бюджет.
Шаги по подготовке проекта к старту следующие:
Если у вас есть вопросы и комментарии по теме ограничений проекта, давайте обсуждать. И удачи вам в реализации проектов!
Ложь железного треугольника
18 Авг 2020
Привет, дорогие друзья!
Многие из вас слышали о таком термине, как Проектный Треугольник, описывающий баланс между содержанием, стоимостью, временем и качеством проекта. Но почему же он называется треугольником, если ограничения четыре? Сопоставим ли он со Scrum’ом? Читайте об этом в данной статье!
До моей карьеры в agile у меня часто бывал такой случай, когда проект был определен, спланирован, заложен в бюджет, объявлен, продан и расписан по времени — и затем почти сразу сходил с плана. Запоздалое уточнение или внезапное новое требование к планированию может мгновенно превратить лучшие планы менеджера проекта в бессмыслицу.
Даже если этого не произойдет, естественный ход развития проекта приведет к возникновению сложностей, которые невозможно было предвидеть при первичном планировании. Никакие благие намерения или интенсивная работа нам не могли помочь — все всегда заканчивалось тем, что мы должны объяснить клиенту, почему он не получит то, за что заплатил по графику, который мы обещали. Беседа выходит всегда веселой.
Оглядываясь назад на мою карьеру с использованием водопадной методологии управления проектами, я вспоминаю, что подобные проблемы происходили гораздо чаще, чем сейчас. Я могу вспомнить только два или три проекта, которые действительно шли в соответствии с планом, который мы заложили на первой же встрече с заказчиком. И все же мы продолжали работать по старинке снова и снова! Что может быть безумнее?
Так что можете себе представить мою радость, когда меня познакомили с Железным треугольником.
Также известный как проектный треугольник или тройственная ограниченность, Железный Треугольник — Это попытка простым способом передать взаимосвязь аспектов, влияющих на реализацию проекта.
Три стороны треугольника: содержание (scope), бюджет (budget) и время (time).
Исходя из принципа треугольника, все три аспекта соединены между собой в трех углах. Можно изменить любую из сторон, но, по крайней мере, одна из оставшихся двух тоже должна измениться, если вы собираетесь сохранить треугольник.
Как говорится: ”Если сломать треугольник, качество просочится наружу”. (Об этом позже.)
Ценность этой диаграммы заключается в том, что она легко передает идею о том, что, если вы увеличиваете содержание, вам нужно либо добавить бюджет (обычно с точки зрения количества членов команды), либо время. Если вы уменьшаете бюджет без изменения времени, вам нужно будет уменьшить содержание. И так далее.
Это довольно изящное выражение взаимосвязи некоторых факторов реализации проекта. И позвольте мне сказать вам, что иллюстрация этого треугольника на доске для заказчика, который запросил новую функцию, которую он только что придумал, обеспечило одни из самых тяжелых, но удовлетворительных моментов в моей карьере.
Это очень мощный инструмент для менеджеров водопадных проектов, чтобы исключить вмешательство заказчиков в проект. Мы называем это ”защитой содержания», но на самом деле речь идет о том, чтобы ценить подписанный лист бумаги, а не работать в коллаборации с реальными людьми.
То, что я никогда не понимал, пока не начал работать по-новому, — это то, что на самом деле есть четвертая сторона Железного треугольника.
Вот что делает все это ложью. Кто-то когда-нибудь слышал о четырехгранном треугольнике?
Подумайте вот о чем: сколько из нас, работающих над проектами по водопадной модели, застряли с неизменными требованиями, невозможными сроками и негибкими бюджетами одновременно? Когда все это просто не может работать, что вы делаете? Как вы это делаете?
Ответ для меня и многих других, кого я знаю, заключается в том, что вы отказываетесь от качества. Конечно, вы можете и не называть это так. Вы «сокращаете время тестирования» (то есть экономите на Quality Assurance — обеспечении качества). Вы “понижаете серьезность» стольких дефектов, сколько можете (т. е. игнорируете их), и все. Вы также можете сжать свой план развертывания, сократив время на обучение или найдя пользователей быстрее, что является компромиссом качества реализации.
Классический Железный Треугольник говорит, что качество страдает, если любая из трех сторон перемещается независимо от других, но я лично могу поручиться, что плохое качество также является результатом отказа подвинуть любую из трех сторон перед лицом неизбежных изменений проекта.
Качество не «утечет», если вы сломаете треугольник. Качество — это невидимая «четвертая сторона» треугольника, которая часто незаметно «меняется» в попытке удовлетворить остальные три ограничения.
И, конечно же, низкое качество грозит серьезными затратами на техническое обслуживание, снижает удовлетворенность пользователей и, конечно же, ценность, поставляемую клиенту. И, само собой, поскольку стандарты качества падают, а технический долг увеличивается, сроки поставки растягиваются, а затраты растут.
К счастью, Scrum спасает нас от всего этого. Мы можем потихоньку забывать о Железном Треугольнике!
В Scrum качество фиксируется. Это задано в определении «сделано» — вот и все.
В Scrum бюджет фиксирован. Scrum-команда стабильна и кросс-функциональна, содержит все наборы навыков, необходимые для доведения работы до конца.
Время в Scrum не фиксировано. Время до релиза — это неизвестное, небольшое число коротких спринтов фиксированной длины. Мы не притворяемся, что можем видеть будущее вплоть до даты развертывания; мы знаем эмпирически, что не можем.
Теперь можно поспорить, что Scrum все-таки фиксирован по времени. В конце концов, мы знаем, как долго длится каждый спринт, и мы знаем, что каждый спринт будет производить потенциальный прирост готовности продукта. Это правда! Но ключевое слово — ”потенциально». Только потому, что каждое приращение может быть развернуто, не означает, что они все будут развернуты. Количество спринтов, которые отделяют нас от релиза, заранее неизвестно и зависит от множества факторов, некоторые из которых не находятся под контролем команды. Мы делаем эту неопределенность планирования приемлемой для клиента, заставляя каждое приращение доставлять им ценность, даже если эта ценность не полностью наглядна пользователям.
Но самое главное, что не фиксируется в Scrum, — это содержание. Оно может меняться изо дня в день, прямо во время спринта, по мере изменения потребностей бизнеса и рыночных условий. Содержание очень легко изменяется, поскольку мы узнаем больше в процессе разработки или когда мы проверяем продукт с заинтересованными сторонами и клиентом. В Scrum мы не претендуем на то, что можем видеть будущее, даже в конце конкретного спринта! Принятие этой гибкости делает нас лучше в процессе разработки, и, конечно, оставляет нас с лучшим продуктом в конце концов.
Принципиально важно, что если ты хочешь быть гибким, то концепция “как долго это еще будет продолжаться?” должна быть выброшена из твоего мышления. “Как долго” задает непостижимый вопрос о времени. И что вообще означает «законченный», если вы не наткнулись на какие-то идеи на рынке по пути? (Но обратите внимание, насколько нерационально наше мышление при водопаде, что мы думаем, что это единственный самый важный вопрос, который нужно задать? Насколько наш подход основан на предположениях, мифологии, подчинении авторитету и полном отрицании того, что говорит нам наш послужной список?)
Попробуйте представить себе, что «закончено» — это не главное и никогда им не было. Вместо того, чтобы ползти до какой-то постоянно отдаляющейся финишной черты, выпустите что-то незаконченное и крошечное! Посмотрим, что получится! Просто попробуйте с этого момента спланировать небольшой релиз!
Вскоре у вас появится ощущение того, как небольшие версии вашего продукта находятся в тренде, что позволит вам планировать, основываясь на фактическом знании чего-то, а не работать с благими, но обреченными на провал намерениями. И вы обнаружите, что защита, которую призван обеспечить Железный Треугольник, больше не нужна.
Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
Треугольник управления проектами
Треугольник управления проектом используется менеджерами для анализа или понимания трудностей, которые могут возникнуть в связи с реализацией и реализацией проекта. Все проекты независимо от их размера будут иметь много ограничений.
Хотя существует множество таких ограничений проекта, они не должны быть препятствиями для успешного выполнения проекта и для эффективного принятия решений.
Есть три основных взаимозависимых ограничения для каждого проекта; время, стоимость и объем. Это также известно как треугольник управления проектами.
Давайте попробуем понять каждый элемент треугольника проекта, а затем понять, как решать проблемы, связанные с каждым из них.
Три ограничения
Три ограничения в треугольнике управления проектами — это время, стоимость и объем.
1 раз
Действия проекта могут занимать меньше или больше времени. Выполнение заданий зависит от ряда факторов, таких как количество людей, работающих над проектом, опыт, навыки и т. Д.
Время является решающим фактором, который не поддается контролю. С другой стороны, несоблюдение сроков в проекте может создать неблагоприятные последствия. Чаще всего основная причина неудачи организаций по времени связана с нехваткой ресурсов.
2 — Стоимость
Как руководитель проекта, так и организация должны иметь примерную стоимость при реализации проекта. Бюджеты обеспечат разработку или реализацию проекта ниже определенной стоимости.
Иногда руководителям проектов приходится выделять дополнительные ресурсы, чтобы уложиться в сроки со штрафом на дополнительные расходы по проекту.
3 — Область применения
Сфера смотрит на результат предпринятого проекта. Он состоит из списка результатов, которые должны быть рассмотрены командой проекта.
Успешный менеджер проекта будет знать, как управлять масштабами проекта и любыми изменениями в масштабах, которые влияют на время и стоимость.
Качественный
Качество не является частью треугольника управления проектами, но является конечной целью каждой поставки. Следовательно, треугольник управления проектами означает качество.
Многие руководители проектов считают, что «высокое качество сопряжено с высокой стоимостью», что в некоторой степени верно. Использование ресурсов низкого качества для выполнения сроков проекта не обеспечивает успеха всего проекта.
Как и в случае с объемом, качество также будет важным результатом проекта.
Шесть этапов управления проектами
Проект проходит шесть этапов в течение своих жизненных циклов, и они отмечены ниже:
Определение проекта — это относится к определению целей и факторов, которые необходимо учитывать, чтобы сделать проект успешным.
Инициирование проекта — это относится к ресурсам, а также к планированию до начала проекта.
Планирование проекта — план относительно того, как проект должен быть выполнен. Это где треугольник управления проектом имеет важное значение. Смотрит время, стоимость и масштаб проекта.
Выполнение проекта — Проведение работы для достижения результата проекта.
Мониторинг и контроль проекта — принятие необходимых мер для обеспечения бесперебойной работы проекта.
Закрытие проекта — Принятие результатов и прекращение ресурсов, которые были необходимы для запуска проекта.
Определение проекта — это относится к определению целей и факторов, которые необходимо учитывать, чтобы сделать проект успешным.
Инициирование проекта — это относится к ресурсам, а также к планированию до начала проекта.
Планирование проекта — план относительно того, как проект должен быть выполнен. Это где треугольник управления проектом имеет важное значение. Смотрит время, стоимость и масштаб проекта.
Выполнение проекта — Проведение работы для достижения результата проекта.
Мониторинг и контроль проекта — принятие необходимых мер для обеспечения бесперебойной работы проекта.
Закрытие проекта — Принятие результатов и прекращение ресурсов, которые были необходимы для запуска проекта.
Преодоление проблем с ограничениями проекта
Это всегда требование для преодоления проблем, связанных с треугольником проекта в течение периода выполнения проекта. Руководители проектов должны понимать, что три ограничения, обозначенные в треугольнике управления проектами, могут быть скорректированы.
Важный аспект — иметь дело с этим. Менеджер проекта должен найти баланс между тремя ограничениями, чтобы качество проекта не было поставлено под угрозу.
Чтобы преодолеть ограничения, у менеджеров проекта есть несколько методов, чтобы поддержать проект. Некоторые из них будут основаны на предотвращении изменения заинтересованными сторонами сферы действия и сохранении ограничений как финансовых, так и людских ресурсов.
Роль руководителя проекта развивается вокруг ответственности. Менеджер проекта должен контролировать и контролировать проект с самого начала и до закрытия.
Следующие факторы будут определять роль менеджера проекта:
Менеджер проекта должен определить проект и распределить задачи между членами команды. Менеджер проекта также должен получить ключевые ресурсы и создать командную работу.
Менеджер проекта должен установить цели, необходимые для проекта, и работать над достижением этих целей.
Самым важным видом деятельности менеджера проекта является информирование заинтересованных сторон о ходе реализации проекта.
Менеджер проекта должен оценивать и тщательно отслеживать риски проекта.
Менеджер проекта должен определить проект и распределить задачи между членами команды. Менеджер проекта также должен получить ключевые ресурсы и создать командную работу.
Менеджер проекта должен установить цели, необходимые для проекта, и работать над достижением этих целей.
Самым важным видом деятельности менеджера проекта является информирование заинтересованных сторон о ходе реализации проекта.
Менеджер проекта должен оценивать и тщательно отслеживать риски проекта.
Навыки, необходимые для менеджера проекта
Чтобы преодолеть проблемы, связанные с треугольником проекта, и достичь целей проекта, менеджер проекта должен обладать рядом навыков, которые включают в себя:
Проектный треугольник не включает такие параметры как
Классическая форма тройственной ограниченности описывает баланс между содержанием проекта, стоимостью, временем и качеством. Качество было добавлено позже, поэтому изначально именована как тройственная ограниченность.
Как того требует любое начинание, проект должен протекать и достигать финала с учётом определённых ограничений. Классически эти ограничения определены как содержание проекта, время и стоимость. Они также относятся к Треугольнику Управления проектами, где каждая его сторона представляет ограничение. Изменение одной стороны треугольника влияет на другие стороны. Дальнейшее уточнение ограничений выделило из содержания качество, превратив качество в четвёртое ограничение.
Ограниченность времени определяется количеством доступного времени для завершения проекта. Ограниченность стоимости определяется бюджетом, выделенным для осуществления проекта. Ограниченность содержания определяется набором действий, необходимых для достижения конечного результата проекта. Эти три ограниченности часто соперничают между собой. Изменение содержания проекта обычно приводит к изменению сроков (времени) и стоимости. Сжатые сроки (время) могут вызвать увеличение стоимости и уменьшение содержания. Небольшой бюджет (стоимость) может вызвать увеличение сроков (времени) и уменьшение содержания.
Управление проектами является наукой о применении инструментов и технологий, которые дают возможность команде (не только управляющему проектом) организовать работу с учётом этих ограничений.
Иной подход к управлению проектами рассматривает следующие три ограниченности: финансы, время и человеческие ресурсы. При необходимости сократить сроки (время) можно увеличить количество занятых людей для решения проблемы, что непременно приведёт к увеличению бюджета (стоимость). За счёт того, что эта задача будет решаться быстрее, можно избежать роста бюджета, уменьшая затраты на равную величину в любом другом сегменте проекта.
”Сделаем хорошо, быстро, дешево. Выберите из этих трех условий два”.
Если сформулировать эту мысль немного иначе, каждый проект представляет собой треугольник, в котором сбалансированы время, деньги и область охвата, — изменить один из факторов, не затронув хотя бы один из других, невозможно. Задача руководителя проекта — следить за тем, чтобы треугольник не распался.
Время + деньги + область охвата = качество
Треугольник проекта также называют железным треугольником или, менее поэтично, тройным ограничением. Как его не назови, он сводится к одному: невозможно изменить бюджет, расписание или область охвата проекта, не повлияв, по крайней мере на один из других факторов.
· Чтобы приблизить дату окончания (время), вы можете потратить больше ресурсов (деньги) или убрать некоторые возможности (область охвата), чтобы было меньше работы.
· Чтобы сделать проект в рамках бюджета (затраты), вы можете не оплачивать сверхурочные и закончить проект позднее (время) либо сократить возможности продукта (область охвата).
Качество — это четвертый элемент проектного треугольника. Оно находится в центре, и любое изменение сторон влияет на него.
Тут важно помнить, что универсального стандарта качества не существует. Для каждого проекта качество определяется в нем самом. Для некоторых компаний важнейшей мерой качества является соблюдение рамок бюджета. Для других важнее вовремя вывести продукт на рынок. Руководителю проекта нужно знать, как качество определяется для организации и для самого проекта.
В большинстве проектов по меньшей мере одна сторона треугольника фиксирована.
Возможно, бюджет не обсуждается (знакомая ситуация, не правда ли?). Или, предположим, продукт непременно должен поступить в продажу к определенной дате. Вероятно, требуется и то, и другое.
Если проблемной является фиксированная сторона, зачастую ясно, что нужно делать. Например, если вы обнаружите, что разработка компонента программного обеспечения займет больше времени, чем прогнозировалось, и вы подписали контракт, требующий предоставить этот компонент (область охвата), вам придется либо отодвигать дату окончания, либо привлекать дополнительные ресурсы, чтобы закончить проект вовремя.
Если проблема не связана с фиксированной стороной, не стоит отчаиваться. В этом и заключается прелесть проектного треугольника — всегда можно что-то изменить. Например, если проект должен быть выполнен вовремя, а его область охвата расширилась, можно скорректировать затраты, добавив ресурсы.
Если фиксированы все три стороны, не паникуйте. Да, проект проблемный, но по крайней мере вы знаете это, что дает вам возможность пересмотреть его цели или стандарты качества.
14 Жизненный цикл проекта
Жизненный цикл проекта включает все фазы от момента инициации до момента завершения. Переходы от одного этапа к другому редко четко определены, за исключением тех случаев, когда они формально разделяются принятием предложения или получением разрешения на продолжение работы.
Выделяют четыре обобщенные фазы жизненного цикла (в скобках приведены используемые в различных источниках альтернативные термины): – концепция (инициация, идентификация, отбор) – определение (анализ) – выполнение (практическая реализация или внедрение, производство и развертывание, проектирование или конструирование, сдача в эксплуатацию, инсталляция, тестирование и т.п.) – закрытие (завершение, включая оценивание после завершения)
Основные процессы жизненного цикла проекта
1. Заказ – Acqusition
2. Поставка – Supply
3. Разработка – Development
4. Эксплуатация – Operation
5. Сопровождение – Maintenance
Стадии жизненного цикла pазpаботки пpогpамм ЖЦРП может сильно отличаться от пpоекта к пpоектy и от pyководителя пpоекта к pyководителю пpоекта. Однако, обычно он состоит из следyющих стадий:
• Анализ пожеланий и тpебований заказчика
• Уточнение фyнкциональных хаpактеpистик
• Создание технического пpоекта (технического задания)
15 Преимущества планирования
Менеджмент, как техпроцесс, является основным и неотъемлемым фактором развития проектов. В подавляющем большинстве случаев для стартапов нанять опытного менеджера представляется сложным — услуги достойного специалиста стоят недешево, да и доверять на раннем этапе постороннему лицу участникам стартапа будет сложно. Поэтому менеджментом занимаются, как правило, сами участники проекта.
Продуктом планирования Ит проекта является ТЗ
Техническое задание (ТЗ) – основной документ проекта, в соответствии с которым проводится разработка и введение в действие системы. В нем перечисляются задачи по автоматизации и способы их решения, включая конкретные описания форм, отчетов, справочников, характеристика объектов автоматизации, требования к системе, состав и содержание работ по ее созданию, алгоритмы взаимодействия всех элементов, а также порядок контроля и приемки системы. Разрабатывает документ менеджер проекта совместно с ИТ-службой по определенному стандарту (ГОСТ на ТЗ по созданию автоматизированной системы). Правильно составленное техническое задание – это залог успешного взаимодействия всех участников проекта. Чем точнее оно написано, тем быстрее и эффективнее будут выполняться работы.
1. Помогает решать задачи рационально и с наименьшими затратами
2. Помогает улучшить координацию действий исполнителей
3. Обеспечивает более рациональное использование ресурсов
4. Помогает руководителям мыслить перспективно, использовать будущие возможности
5. Обеспечивает возможность контроля за событиями и позволяет управлять ими
6. Готовит проект к возможным изменениям
Не нашли то, что искали? Воспользуйтесь поиском:
Лучшие изречения: При сдаче лабораторной работы, студент делает вид, что все знает; преподаватель делает вид, что верит ему. 9509 – 
| 7342 – 
или читать все.
91.146.8.87 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.
Отключите adBlock!
и обновите страницу (F5)
очень нужно
1)Проектом НЕ является:
а) внедрение системы электронного документооборота компании.
б) разработка системы управления очередью.
в) конвейерное производство автомобиля. +
г) строительство олимпийского объекта.
2)Проектный треугольник НЕ включает такие параметры как
а) время и потребительские характеристики.
б) качество и ресурсы.
в) время и ресурсы.
г) риск и доходность. +
3)Признаком проекта как системы является
а) изолированность от окружающей среды.
б) подчиненность заданной цели организации системы.
в) несводимость свойств проекта в целом к свойствам его элементов.
г) наличие изолированных подсистем. +
4)Рассмотрение проекта как совокупности элементов является
а) микроскопическим. +
б) структурным
в). функциональным.
г) процессным.
5)Если воздействие выхода системы на ее вход увеличивает его воздействие на систему, то возникает
а) положительная прямая связь.
б) отрицательная прямая связь.
в) положительная обратная связь. +
г) отрицательная обратная связь.
6)К параметрам обратной связи НЕ относится
а) управление выходом. +
б) скорость реакции на изменение.
в) управление отклонениями.
г) чувствительность к изменению.
7)Негэнтропия объясняет поведение
а) хаотичных систем.
б) самоорганизующихся систем. +
в) управляемых систем.
г) саморазрушающихся систем.
8)Согласно Закону необходимого разнообразия, управление системой возможно, если
а) разнообразие управляющих действий больше разнообразия возмущений на входе в систему. +
б) разнообразие возмущений на выходе из системы больше разнообразия управляющих действий.
в) разнообразие управляющих действий меньше разнообразия возмущений на входе в систему.
г) разнообразие возмущений на выходе из системы меньше разнообразия управляющих действий.
9)Согласно книге Д. Шервуд «Видеть лес за деревьями»,
а) для эффективного решения проблемы необходимо видеть целостную картину. +
б) для эффективного решения проблемы достаточно тщательного изучения всех элементов системы.
в) для эффективного решения проблемы необходимо правильно определять причинно-следственные связи.
г) 1 и 3 верно.
д) все ответы верны.
10)В работах как Д. Медоуз, так и Д. Шервуд рассматривается такое свойство системы как
а) самоорганизация. +
б) циклы обратной связи.
в) статичность.
г) все ответы верны.
11)Системным архетипом, выделенным Д. Медоуз, НЕ является
а) стремление системы к саморазрушению в долгосрочной перспективе. +
б) запаздывание обратной связи как характерная черта сложных системах.
в) работа стабильных систем по принципу конкурентного исключения.
г) устойчивость к внешним воздействиям как характерная черта дифференцированных неоднородных систем.
13)Примером действия закона необходимого разнообразия является
а) разветвленная функциональная организационная структура компании, позволяющая осуществлять деятельность с учетом всех необходимых факторов. +
б) достаточный запас прочности оборудования на производстве.
в) диверсифицированное производство.
г) все ответы верны.
14)Поддержание равновесного состояния при непрерывном развитии относится к признакам
а) сложной системы. +
б) открытой системы.
в) динамической системы.
г) детерминированной системы.
15)К основным характеристикам структуры НЕ относится
а) число внутренних связей.
б) вид связей.
в) частота связей.
г) нет правильного ответа. +
д) все ответы верны.
