Оперативки и Планы — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Материалы)
(Термины)
 
(не показаны 32 промежуточные версии 4 участников)
Строка 1: Строка 1:
[[Оперативки и Планы]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектных Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Оперативки и Планы]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[Продукция Проектов]].
+
Предшественник этого ''Лектио'' -- [[Работы по Проектам]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Оперативки и Планы</strong></p>
+
:<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>
<p>Каждый проект может быть плановым или оперативным в зависимости от того, когда начинается выполнение -- после утверждения плана разработки или раньше.</p>
 
<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]], [[Бэкенд]], [[Отсрочка Выполнения]], [[Рабочие продукты по сценарию]], [[Рабочие продукты без сценария]]
+
:[[Критерии приемлемости]], [[Оперативно-гибкий способ]], [[Плановый способ]], [[Проектная работа]]
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 16:58, 25 сентября 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

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

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

  1. Плановый способ управления проектом (predictive, Waterfall) -- это подход, при котором объёмы работ, сроки выполнения и бюджеты планируются и утверждаются до начала разработки. В плановых проектах, заказчик и подрядчик устанавливают специальный механизм для пересмотра планов, в том случае если будет разрыв между утвержденными планами и реальностью.

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

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

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

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

Планирование занимает время. Если время "дороже" денег, можно также начать проект оперативно и переключиться на плановый, когда план будет утверждён.

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

Варианты

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

Термины

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

Экзамен

Определения

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

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

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