Відмінності між версіями «Зміни Схвалень»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Варианты)
 
(Не показано 42 проміжні версії 5 користувачів)
Рядок 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>
 
 
 
===Варианты===
 
:
 
  
 +
===Варіанти===
 +
:відповідає рада з контролю за змінами./ відповідає замовник./ стежить підрядник./ в оперативних проєктах жодна окрема особа не відповідає, оскільки зміни обсягу робіт є характеристикою проєктів.
 
:Следующее лектио -- '''[[Что Есть Факторы]]'''
 
:Следующее лектио -- '''[[Что Есть Факторы]]'''
  
 
===Термины===
 
===Термины===
:[[Бюджет Проекта]], [[Активы Проекта]], [[Внешние Среды]], [[Внутренние Среды]], Проектная Среда, [[Затраты На Проект]], [[График Проекта]], [[Фактор Предприятия]], [[Рабочий Продукт]], [[Временные Шкалы Проекта]]
+
:[[Бюджет проекта]], [[ССВ]], [[Объём работ]], [[Контрольный план работ]], [[Опись продукта]].
  
 
==Экзамен==
 
==Экзамен==

Поточна версія на 12:28, 27 листопада 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

Зміни схвалень

У житті трапляються непередбачені ситуації, які ми не можемо знати заздалегідь, так само і з проєктами, жоден не можна повністю передбачити та спрогнозувати. Якщо якийсь із контрольних планів проєкту не може бути витриманий у виконанні, тоді керівник проєкту робить запит на зміну (change request).

У планових проєктах сторони встановлюють раду з контролю за змінами (Change Control Board або CCB). Ця рада включає як представників замовника, так і представників підрядника проєкту. Іноді рад встановлюється кілька. У цьому випадку різні органи мають різні зони відповідальності, наприклад, один вирішує питання, що стосуються змін у продукті, а інший розглядає питання, пов'язані зі змінами в проєкті.

Рада розглядає запити на зміну та приймає одне з трьох рішень:

  1. Затвердити у запропонованому варіанті,
  2. Відхилити,
  3. Затвердити у зміненому варіанті.

Ці ж ради можуть приймати рішення про готовність продуктів до передачі та успішності всього проєкту.

Якщо протягом проєкту щось змінилося з боку замовника, він або вона можуть додавати до замовлення щось після затвердження контрольних планів. У планових проєктах дозамовлення доповнюється зміною вартості або обсягу і проходить узгодження.

Оскільки кожна зміна контрольних планів тягне за собою роботу з перерахунку, підрядник може запропонувати деяку оплату або поставити обмеження на кількість безкоштовних перерахунків. Згода керівника проєкту на збільшення роботи без відповідної оплати називається неконтрольованим роздуванням обсягів роботи (scope creep).

Знову ж таки, контрольні плани затверджуються та перезатверджуються лише у планових проєктах. В оперативних проєктах опис продукту тільки допрацьовується; зміни обсягів робіт закладено у природу оперативних проєктів. Оперативно-гнучкий спосіб навіть вітає зміни на будь-якій стадії, аж до найпізнішої.

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

Варіанти

відповідає рада з контролю за змінами./ відповідає замовник./ стежить підрядник./ в оперативних проєктах жодна окрема особа не відповідає, оскільки зміни обсягу робіт є характеристикою проєктів.
Следующее лектио -- Что Есть Факторы

Термины

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

Экзамен

Определения

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

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

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