Изменения Одобрений — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(→‎Варианты)
(→‎Термины)
 
(не показано 38 промежуточных версий 2 участников)
Строка 1: Строка 1:
−
[[Совместное Создание]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектных Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Изменения Одобрений]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Контролей Планов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[Контрольные Уровни]].
+
Предшественник этого ''Лектио'' -- [[Раздувания Планов]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Совместное Создание</strong></p><p>Услуга - это рыночная форма работы, выполняемой для других лиц или от их имени. Концепция  является центральной для тех услуг, которые предполагают значительный вклад клиентов и других заинтересованных сторон.
+
:<p><strong>Изменения Одобрений</strong></p><p>В жизни случаются непредвиденные ситуации, которые мы не можем знать заранее, также и с проектами, ни один нельзя полностью предсказать и спрогнозировать. Если какой-либо из контрольных планов проекта не может быть выдержан в исполнении, тогда руководитель проекта делает запрос на изменение (change request).</p><p>В плановых проектах, стороны устанавливают совет по контролю за изменениями (Change Control Board или CCB). Этот совет включает как представителей заказчика, так и представителей подрядчика проекта. Иногда, советов устанавливается несколько. В этом случае, разные органы имеют разные зоны ответственности, например, один решает вопросы, которые касаются изменений в продукте, а другой рассматривает вопросы, связанные с  переменами в проекте.</p><p>Совет рассматривает запросы на изменение и принимает одно из трёх решений:</p><ol type="a"><li>Утвердить в предложенном варианте,</li><li>Отклонить,</li><li>Утвердить в изменённом варианте.</li></li></ol><p>Эти же советы могут принимать решение о готовности продуктов к передаче и успешности всего проекта.</p><p>Если в течении проекта что-то поменялось на стороне заказчика, он или она могут добавлять к заказу что-то, после утверждения контрольных планов. В плановых проектах, дозаказывание дополняется изменением стоимости или объёма и проходит согласование.</p><p>Так как каждое изменение контрольных планов влечёт за собой работу по пересчёту, подрядчик может предложить некоторую оплату или поставить ограничение на количество бесплатных пересчётов. Согласие руководителя проекта на увеличение работы без соответствующей оплаты называется неконтролируемым раздуванием объёмов работы (scope creep).</p><p>Опять же, контрольные планы утверждаются и переутверждаются только в плановых проектах. В оперативных проектах, опись продукта только дорабатывается; изменения объёмов работ заложены в природу оперативных проектов. Оперативно-гибкий способ даже приветствует изменения на любой стадии, вплоть до самой поздней.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, за изменение контрольных планов:</p>
−
 
 
−
 
 
−
Определения
 
−
 
 
−
Согласно маркетинговому менеджменту Келлера и Котлера (15-е издание),
 
−
 
 
−
    Служба. Любое действие или исполнение, которые одна сторона может предложить другой, по сути нематериальные и не влекущие за собой право собственности на что-либо.
 
−
 
 
−
Согласно данным Managing Quality by Foster (6-е издание),
 
−
 
 
−
    Служба. Сочетание нематериальных и материальных ценностей, поставляемых клиенту.
 
−
 
 
−
Согласно BABOK Guide (3-е издание),
 
−
 
 
−
    Сервис (бизнес-анализ). Выполнение любых обязанностей или работа для заинтересованной стороны с точки зрения заинтересованной стороны.
 
−
 
 
−
По данным ITIL Foundation 4e от Axelos,
 
−
 
 
−
    Служба. Средство создания возможности совместного создания стоимости путем облегчения результатов, которых хотят достичь клиенты, без необходимости управлять конкретными затратами и рисками.
 
−
 
 
−
Если разработка предсказуема, то следующий вопрос -- могут ли разработчики сами определять фронт своих работ или им нужет начальник.
 
−
 
 
−
<p>Рабочие продукты по сценарию - это те рабочие продукты, процесс разработки которых структурирован и подробно известен. Это будут конструкции, не дизайнерская одежда и продукты, приготовленные по рецептам.</p>
 
−
<p>Рабочие продукты без сценария - это те рабочие продукты, процесс разработки которых не структурирован или неизвестен. Они будут включать первое в истории радио, первый самолет и первый компьютер. Если у разработчиков нет инструкций по разработке чего-либо, соответственно разработка такого проекта выполняется без сценария.</p>
 
−
<p>Проект предсказуем, если рабочий продукт по сценарию разработан в управляемой среде. Выбор клиента: (а) получить результат быстрее, но, возможно, потратить больше денег, или (б) потратить меньше денег и получить результат позже.</p><p>Плановый способ может быть отлично реализован в этих условиях и сэкономит деньги, но оперативный способ даст результаты быстрее.
 
−
Проект непредсказуем, если продукт без сценария разрабатывается в неконтролируемой среде. Если сотрудники проекта выберут плановый способ, им придется угадывать, как будет выглядеть разработка. Большинство догадок могут не пережить реальность.</p>
 
−
<p>Затем руководитель проекта должен будет отправить запросы на изменение; если клиент одобряет, отклоняет или изменяет эти запросы быстро, плановый способ может получить скорость оперативного.</p>
 
−
<p>Вообще говоря, для планового способа нужны данные, чтобы сэкономить деньги и сократить сроки. Без данных преимущество планового способа бесполезно. В условиях полной неопределенности проектная работа может быть единственным источником данных.</p>
 
−
<p>В то же время вся разработка не обязательно должна быть плановой или оперативной. В качестве примера возьмем разработку сайта bskol.com. Эту работу можно разделить на несколько проектов, среди которых некоторые, такие как интерфейс и бэкенд, могут быть разработаны оперативным способом, а другие, такие как дизайн, контент и SEO, могут быть плановым способом.</p>
 
−
<p>Творческие работы, такие как разработка контента и дизайн, всегда включают в себя как сценарии, так и аспекты без сценария. Исключительно эксклюзивный веб-дизайн может занять несколько лет и более миллиона долларов. Клонирование или изменение существующего дизайна также может занять несколько часов и мелочь. Поскольку графики для творческих работ не могут быть реально рассчитаны, заказчик обычно просто устанавливает свои затраты и/или сроки, чтобы разработчики могли управлять своими усилиями.</p>
 
−
 
 
−
В поисковых проектах этапы проекта всегда перекрываются. Предварительное планирование работы, которое называется Нулевой Спринт, устанавливает правила и приоритеты для проекта. Каждый день планирование открывается заново, чтобы учесть разработки предыдущего дня.
 
−
<li>Разработка продуктов проекта начинается либо оперативно, когда неполные планы появляются, либо планово, когда полный план разработан и утверждён. Среди всех стадий, разработка продуктов почти всегда наиболее затратная стадия. В этой стадии нанимаются разработчики и закупаются материалы. Если любую другую стадию можно начинать как можно раньше, разработка продуктов типично начинается исключительно с одобрением заказчика. Разработка продуктов прекращается после того как заказчик проекта или его представитель принимает рабочий продукт,</li>
 
−
 
 
−
Владелец проекта несет ответственность за управление проектом. Чтобы направлять, контролировать и/или поддерживать персонал проекта, владелец может создать офис управления проектом, часто сокращенно ОУП.</p>
 
−
<p>В управлении проектами Гибкой Методологии ключевую роль играет руководитель проекта. Эти менеджеры концентрируются на разработке утвержденных продуктов в соответствии с утвержденными бюджетами и утвержденными графиками.</p>
 
−
<p>Менеджер проекта ведет Планирование проекта до утверждения базовых показателей, выполнение проекта до подтверждения результатов и закрытие проекта. На этапе планирования менеджер может нанять бизнес-аналитиков для сбора требований и системных инженеров для разработки системы, как Решения. Те разработчики, которые непосредственно создают результаты, нанимаются только на стадии Выполнения.</p>
 
−
<p>Если персонал проекта составляет менее 5-9 человек и график не сжат, менеджер редко выполняет выделенную роль. Один из разработчиков или кто-то другой может выступать в качестве менеджера проекта в дополнение к другим обязанностям.</p>
 
−
<p>В Жестком Подходе функции управления распределены между несколькими ролями. Например, разработчики определяют работу на основе требований решения, таких как пользовательские истории.
 
−
На этапе Планирования некий координатор, например, менеджер по работе с клиентами, работающий в ОУП, нанимает членов группы планирования в дополнение к владельцу продукта. Эта команда проводит Нулевой Спринт или аналогичные действия, предпринимаемые для создания Бэклога Продукта.</p>
 
−
<p>На исполнительный этап нанимается команда разработчиков. Помимо product owner-а(Владелец Продукта), в эту команду входят разработчики и, возможно, такие официальные лица, как Scrum Master. Разработчики обычно работают в итерациях и, как только разрабатываются новые инкременты и обнаруживаются новые данные, обсуждают будущий продукт и его доставку с Владельцем Продукта. Скрам-Мастера не занимаются рабочими продуктами и поставками; Вместо этого Скрам-Мастера следят за тем, чтобы разработка шла в соответствии с согласованными правилами.
 
−
В отличие от Управления проектами, администрирование разработки часто распределяется между двумя организациями, если две организации участвуют в одном проекте.</p>
 
−
<p>Заказчик Проекта определяет бизнес-потребность, которая является проблемой, которую необходимо решить, инициирует проект по созданию решения и предоставляет бюджет проекта.
 
−
Владелец Проекта, следовательно, нанимает кого-то, кто действует от имени клиента при утверждении Требований к решению, базовых планах проекта и / или оценке того, соответствует ли рабочий продукт критериям приемки.</p>
 
−
<p>В проектах Гибкой Методологии -- эта административная роль называется Спонсором Проекта. Базовые показатели не являются особенностью проектов с Жесткким Подходом, поэтому администрация концентрируется только на требованиях к продукту.</p>
 
−
<p>Владелец продукта - ключевая административная роль в Жестких Методологиях проекта. Этот человек концентрируется на представлении правильного продукта, описании этого продукта обычно с использованием пользовательских историй и расстановке приоритетов в отставании по продукту. Владельцы Продуктов не занимаются бюджетами, графиками, а также другими функциями управления, такими как найм и закупки. Область ответственности product owner-а - убедиться, что деньги покупателя тратятся на продукт, который покупатель ищет.
 
−
 
 
−
</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
 
  
 
===Варианты===
 
===Варианты===
−
:
+
:отвечает совет по контролю за изменениями./ отвечает заказчик./ следит подрядчик./ в оперативных проектах никакое отдельное лицо не отвечает, так как изменения объёма работ являются характеристикой проектов.
  
 
:Следующее лектио -- '''[[Что Есть Факторы]]'''
 
:Следующее лектио -- '''[[Что Есть Факторы]]'''
  
 
===Термины===
 
===Термины===
−
:[[Бюджет Проекта]], [[Активы Проекта]], [[Внешние Среды]], [[Внутренние Среды]], Проектная Среда, [[Затраты На Проект]], [[График Проекта]], [[Фактор Предприятия]], [[Рабочий Продукт]], [[Временные Шкалы Проекта]]
+
:[[Бюджет проекта]], [[ССВ]], [[Объём работ]], [[Контрольный план работ]], [[Опись продукта]].
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 18:36, 26 сентября 2022

Изменения Одобрений (здесь и далее по тексту -- Лектио) -- это часть урока Суть Контролей Планов. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.


Материалы

Предшественник этого Лектио -- Раздувания Планов.

Иллюстрации

Текст (HTML)

Изменения Одобрений

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

В плановых проектах, стороны устанавливают совет по контролю за изменениями (Change Control Board или CCB). Этот совет включает как представителей заказчика, так и представителей подрядчика проекта. Иногда, советов устанавливается несколько. В этом случае, разные органы имеют разные зоны ответственности, например, один решает вопросы, которые касаются изменений в продукте, а другой рассматривает вопросы, связанные с переменами в проекте.

Совет рассматривает запросы на изменение и принимает одно из трёх решений:

  1. Утвердить в предложенном варианте,
  2. Отклонить,
  3. Утвердить в изменённом варианте.

Эти же советы могут принимать решение о готовности продуктов к передаче и успешности всего проекта.

Если в течении проекта что-то поменялось на стороне заказчика, он или она могут добавлять к заказу что-то, после утверждения контрольных планов. В плановых проектах, дозаказывание дополняется изменением стоимости или объёма и проходит согласование.

Так как каждое изменение контрольных планов влечёт за собой работу по пересчёту, подрядчик может предложить некоторую оплату или поставить ограничение на количество бесплатных пересчётов. Согласие руководителя проекта на увеличение работы без соответствующей оплаты называется неконтролируемым раздуванием объёмов работы (scope creep).

Опять же, контрольные планы утверждаются и переутверждаются только в плановых проектах. В оперативных проектах, опись продукта только дорабатывается; изменения объёмов работ заложены в природу оперативных проектов. Оперативно-гибкий способ даже приветствует изменения на любой стадии, вплоть до самой поздней.

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

Варианты

отвечает совет по контролю за изменениями./ отвечает заказчик./ следит подрядчик./ в оперативных проектах никакое отдельное лицо не отвечает, так как изменения объёма работ являются характеристикой проектов.
Следующее лектио -- Что Есть Факторы

Термины

Бюджет проекта, ССВ, Объём работ, Контрольный план работ, Опись продукта.

Экзамен

Определения

Вопросы экзамена

Использование подвижного Подхода для разработки в Брацкой Школы лучше всего можно классифицировать как:

Актив проекта . Фактор предприятия . Проектная среда . Все остальные ответы по существу верны.

Источник — «https://pravka.bskol.com/w1/index.php?title=Изменения_Одобрений&oldid=27408»