Відмінності між версіями «Оперативки та Плани»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(→‎Текст)
 
(Не показані 35 проміжних версій 6 користувачів)
Рядок 1: Рядок 1:
−
[[Оперативки и Планы]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектных Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Оперативки та Плани]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Проектов|Суть Проєктів]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''.
  
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[Продукция Проектов]].
+
Предшественник этого ''Лектио'' -- [[Работы по Проектам]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Рядок 9: Рядок 9:
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Оперативки и Планы</strong></p><p>Каждый проект может быть плановым или оперативным в зависимости от того, когда начинается разработка объектов приёмки -- до утверждения объёма работ, сроков и бюджета или после утверждения.</p><ol type="a"><li><p>Плановый способ управления проектом (Waterfall) -- это подход, при котором объёмы работ, сроки выполнения и бюджеты планируются и утверждаются до начала разработки. В плановых проектах, заказчик и подрядчик устанавливают специальный механизм для пересмотра планов если будет разрыв между планами и реальностью.</p><p>Возьмём строительство нового дома. Человечество строит дома тысячи лет. Процесс известен -- сначала строители кладут фундамент, а затем кладут стены. Рынок строителей сформирован. Стоимость труда, стоимость материала и сроки можно предсказать. В нужное время можно нанять нужных работников и заказать нужные материалы в соответствии с бюджетом и графиком. Плановая разработка и возможна, и предпочтительна.</p></li><li><p>Оперативный способ управления проектом (Agile) -- это подход, при котором разработка начинается до утверждения объёмов работ, сроков выполнения и бюджетов. В оперативных проектах, заказчик и подрядчик устанавливают специальный механизм для планирования одновременно с разработкой.</p><p></p></li></ol>
+
:<p><strong>Оперативки та Плани</strong></p><p>Залежно від того, коли починається розробка об'єктів приймання -- до затвердження обсягу робіт, термінів і бюджету або після затвердження -- проєкти можна класифікувати, як планові та оперативні.</p><ol type="a"><li><p><strong>Плановий</strong> спосіб управління проєктом (predictive, Waterfall) -- це підхід, при якому обсяги робіт, терміни виконання та бюджети плануються та затверджуються до початку розробки. У планових проєктах замовник і підрядник встановлюють спеціальний механізм для перегляду планів, якщо буде розрив між затвердженими планами та реальністю.</p><p>Візьмемо будівництво нового будинку. Людство будує будинки тисячі років. Процес відомий -- спочатку будівельники кладуть фундамент, а потім кладуть стіни. Ринок будівельників сформовано. Вартість праці, вартість матеріалу та терміни можна передбачити. У потрібний час можна найняти потрібних працівників та замовити потрібні матеріали відповідно до бюджету та графіку. Найняти будівельників до того, як план готовий просто затратно.</p></li><li><p><strong>Оперативні</strong> способи управління проєктом (incremental, iterative, Agile) -- це підходи, за яких розробка починається до затвердження обсягів робіт, термінів виконання та бюджетів. В оперативних проєктах замовник та підрядник встановлюють спеціальний механізм для планування одночасно з розробкою.</p><p>Візьмемо розробку Брацької Школи. Ніхто раніше не створював такої громадської ініціативи. Брацька Школа розробляється волонтерами. Кожен волонтер виконує свій внесок, виходячи зі свого розкладу. Волонтерам повідомляють орієнтири, але вони самі обирають, що вони робитимуть, а що -- ні. Навіть якщо ми примудримося передбачити обсяг робіт, ми не зможемо передбачити, коли цей обсяг буде виконано. Ніхто не може передбачити, як Школа виглядатиме, скажімо, за рік. Немає жодної можливості створити детальний план. Ми не можемо планувати деталі того, чого не знаємо.</p></li></ol><p>Розробки можуть поєднувати два підходи планові, і оперативні в тому випадку, якщо частина роботи над функціоналом, характеристиками або властивостями передбачувана, а інша частина -- ні. Наприклад, зробити дизайн будинку оперативним способом, а вже саме будівництво планово.</p><p>Планування займає час. Якщо час "дорожчий" за гроші, можна також почати проєкт оперативно і переключитися на плановий, коли план буде затверджений.</p><p><i>А тепер, виберіть, будь ласка, найкраще завершення наступної пропозиції.</i> Судячи з тексту вище, у якому разі вигідніше діяти за оперативним підходом:</p>
  
−
С другой стороны, разработка Брацкой Школы идет без каких-либо исходных условий. Никто раньше не создавал Брацку Школу - мы не можем предсказать, как это будет выглядеть, скажем, через 2 года. Волонтеры руководят разработками, которые им интересны и когда позволяет их время.</p>
+
===Варіанти===
−
<p>Начало выполнения без утвержденного плана представляет собой оперативный подход.</p>
+
:якщо ми не маємо чіткого бачення, що буде далі./ якщо ми маємо межі в часі./ якщо у нас є план операцій з розробок на найближчий фінансовий рік./ якщо розробки мають цикл, що повторюється.
−
<p>Чтобы выбрать между плановым и оперативным подходом, заказчик проекта может принять во внимание характер рабочих продуктов и среду проекта.</p>
 
−
<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><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
 
−
 
 
−
===Варианты===
 
−
:
 
−
 
 
−
:Следующее лектио -- '''[[Совместное Создание]]'''
 
  
 
===Термины===
 
===Термины===
−
:[[Плановый подход]], [[оперативный подход]], [[Контент]], [[SEO]], [[Бэкенд]], [[Отсрочка Выполнения]], [[Рабочие продукты по сценарию]], [[Рабочие продукты без сценария]]
+
:[[Критерии приемлемости]], [[Оперативно-гибкий способ]], [[Плановый способ]], [[Проектная работа]]
  
 
==Экзамен==
 
==Экзамен==

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

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


Материалы

Предшественник этого Лектио -- Работы по Проектам.

Иллюстрации

Текст (HTML)

Оперативки та Плани

Залежно від того, коли починається розробка об'єктів приймання -- до затвердження обсягу робіт, термінів і бюджету або після затвердження -- проєкти можна класифікувати, як планові та оперативні.

  1. Плановий спосіб управління проєктом (predictive, Waterfall) -- це підхід, при якому обсяги робіт, терміни виконання та бюджети плануються та затверджуються до початку розробки. У планових проєктах замовник і підрядник встановлюють спеціальний механізм для перегляду планів, якщо буде розрив між затвердженими планами та реальністю.

    Візьмемо будівництво нового будинку. Людство будує будинки тисячі років. Процес відомий -- спочатку будівельники кладуть фундамент, а потім кладуть стіни. Ринок будівельників сформовано. Вартість праці, вартість матеріалу та терміни можна передбачити. У потрібний час можна найняти потрібних працівників та замовити потрібні матеріали відповідно до бюджету та графіку. Найняти будівельників до того, як план готовий просто затратно.

  2. Оперативні способи управління проєктом (incremental, iterative, Agile) -- це підходи, за яких розробка починається до затвердження обсягів робіт, термінів виконання та бюджетів. В оперативних проєктах замовник та підрядник встановлюють спеціальний механізм для планування одночасно з розробкою.

    Візьмемо розробку Брацької Школи. Ніхто раніше не створював такої громадської ініціативи. Брацька Школа розробляється волонтерами. Кожен волонтер виконує свій внесок, виходячи зі свого розкладу. Волонтерам повідомляють орієнтири, але вони самі обирають, що вони робитимуть, а що -- ні. Навіть якщо ми примудримося передбачити обсяг робіт, ми не зможемо передбачити, коли цей обсяг буде виконано. Ніхто не може передбачити, як Школа виглядатиме, скажімо, за рік. Немає жодної можливості створити детальний план. Ми не можемо планувати деталі того, чого не знаємо.

Розробки можуть поєднувати два підходи планові, і оперативні в тому випадку, якщо частина роботи над функціоналом, характеристиками або властивостями передбачувана, а інша частина -- ні. Наприклад, зробити дизайн будинку оперативним способом, а вже саме будівництво планово.

Планування займає час. Якщо час "дорожчий" за гроші, можна також почати проєкт оперативно і переключитися на плановий, коли план буде затверджений.

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

Варіанти

якщо ми не маємо чіткого бачення, що буде далі./ якщо ми маємо межі в часі./ якщо у нас є план операцій з розробок на найближчий фінансовий рік./ якщо розробки мають цикл, що повторюється.
Следующее лектио -- Окончания Проектов

Термины

Критерии приемлемости, Оперативно-гибкий способ, Плановый способ, Проектная работа

Экзамен

Определения

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

Работа по Заданному Подходу лучше всего подойдет, когда:

Рабочий продукт написан по сценарию; Скриптовый рабочий продукт разрабатывается в управляемой среде; Ни один из ответов не верен; Все остальные ответы по существу верны; Проект предсказуем.

Отримано з https://pravka.idosvid.com/w2/index.php?title=Оперативки_та_Плани&oldid=33080