Совместное Создание — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Новая страница: «Совместное Создание (здесь и далее по тексту -- ''Лектио'') -- это часть урока Суть Проект…»)
 
(Термины)
 
(не показано 14 промежуточных версий 2 участников)
Строка 1: Строка 1:
[[Совместное Создание]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Совместное Создание]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектных Итогов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[Оперативки и Планы]].
+
Предшественник этого ''Лектио'' -- [[Продукция Проектов]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Совместное Создание</strong></p><p>В зависимости от того, когда начинается разработка объектов приёмки -- до утверждения объёма работ, сроков и бюджета или после утверждения -- проекты можно классифицировать как плановые и оперативные.</p><ol type="a"><li><p>Плановый способ управления проектом (Waterfall, predictive) -- это подход, при котором объёмы работ, сроки выполнения и бюджеты планируются и утверждаются до начала разработки. В плановых проектах, заказчик и подрядчик устанавливают специальный механизм для пересмотра планов если будет разрыв между планами и реальностью.</p><p>Возьмём строительство нового дома. Человечество строит дома тысячи лет. Процесс известен -- сначала строители кладут фундамент, а затем кладут стены. Рынок строителей сформирован. Стоимость труда, стоимость материала и сроки можно предсказать. В нужное время можно нанять нужных работников и заказать нужные материалы в соответствии с бюджетом и графиком. Расходно нанимать строителей до того, как план готов.</p></li><li><p>Оперативные способы управления проектом (Agile, incremental, iterative) -- это подходы, при которых разработка начинается до утверждения объёмов работ, сроков выполнения и бюджетов. В оперативных проектах, заказчик и подрядчик устанавливают специальный механизм для планирования одновременно с разработкой.</p><p>Возьмём разработку Брацкой Школы. Никто раньше не создавал такую общественную инициативу. Брацка Школа разрабатывается волонтёрами. Каждый волонтёр приходит и уходит по своему расписанию. Волонтёрам сообщают ориентиры, но они сами выбирают, что они будут делать, а что -- нет. Даже если мы умудримся предсказать объём работ, мы не сможем предсказать, когда этот объём будет выполнен. Никто не может предсказать, как Школа будет выглядеть, скажем, через год. Нет никакой возможности создать детальный план. Мы не можем планировать детали того, чего не знаем.</p></li></ol><p>Разработки могут сочетать и плановые, и оперативные разработки, если часть работы над функционалом, характеристиками или свойствами предсказуема, а другая часть -- нет. Например, сделать дизайн дома оперативным способом, а уже саму стройку -- планово.</p><p>Планирование занимает время. Если время "дороже" денег, можно также начать проект оперативно и переключиться на планово, когда план будет утверждён.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
+
:<p><strong>Совместное Создание</strong></p><p>Представим, что у кого-то может сложиться впечатление, что проект -- это дело подрядчика. Как будто, если заказчик покупает услугу, то подрядчик обязан услугу предоставить. Аналогично тому, как мы ожидаем услуг связи, когда покупаем сим-карты в смартфон.</p><p>Действительно, потребителям достаточно приобрести услугу сотовой компании, чтобы их смартфоны могли соединяться с её сотовыми вышками. Мы потребители, не создаём эти услуги совместно с компанией сотовой связи. Эти услуги были разработаны и предложены для нашей покупки.</p><p>Услуги подрядчика в проекте не были созданы до открытия проекта. Их надо создавать. И, чем более уникальна услуга, тем большее участие заказчика она предполагает.</p><p>Многие проекты предполагают сложные и взаимозависимые отношения между заказчиком и подрядчиком. В частности, это сотрудничество может касаться разработок:</p><ol type="a"><li>Требований к изготавливаемому продукту и его разработке. Обычно, руководитель проекта и кураторы проекта на стороне подрядчика устанавливают персональные отношения с кураторами проекта на стороне заказчика. Методика "Живой Свалки" (Agile Scrum) предусматривает отдельный Нулевой Спринт (Sprint Zero). В этом спринте, представители заказчика и подрядчика одну-две недели формируют перечень пользовательских историй для разработки, и расставляют их приоритеты,</li><li>Концепции рабочих продуктов проекта. В плановых проектах, заказчик утверждает опись продукта и объём работ. Изменения контрольных уровней должны утверждаться советом по контролю за изменениями (Change Control Board или CCB). В оперативных проектах, концепция дорабатывается в ходе работ,</li><li>Результатов первого, второго и третьего уровней. Иногда, специальное подразделение подрядчика, офис по управлению проектами (Project Management Office или PMO), устанавливает дополнительные каналы связи с заказчиком.</li></ol><p>Руководитель проекта может предложить другие меры. Вместо того, чтобы пытаться догадаться, что клиент "хочет", если заказчик не может ответить, подрядчику предпочтительнее создать платформы для творческого сотрудничества в создании продуктов и процессов их создания. Все заинтересованные стороны могут выиграть от возможности установки взаимовыгодных, интерактивных отношений.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, совместное создание необходимо:</p>
  
 
===Варианты===
 
===Варианты===
:
+
:заказчику, для удовлетворения всех его потребностей касательно продукта./ подрядчику, для уточнения каких результатов хочет добиться заказчик./ для инициирования идей по продукту./ для разработки повторяющихся циклов.
  
:Следующее лектио -- '''[[Окончания Проектов]]'''
+
:Следующее лектио -- '''[[Объёмы Работ]]'''
  
 
===Термины===
 
===Термины===
:[[Плановый подход]], [[оперативный подход]], [[Контент]], [[SEO]], [[Бэкенд]], [[Отсрочка Выполнения]], [[Рабочие продукты по сценарию]], [[Рабочие продукты без сценария]]
+
:[[Требования]], [[Оперативно-гибкий способ|Agile]], [[Scrum]], [[Нулевой спринт]], [[Куратор проекта]].
  
 
==Экзамен==
 
==Экзамен==

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

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


Материалы

Предшественник этого Лектио -- Продукция Проектов.

Иллюстрации

Текст (HTML)

Совместное Создание

Представим, что у кого-то может сложиться впечатление, что проект -- это дело подрядчика. Как будто, если заказчик покупает услугу, то подрядчик обязан услугу предоставить. Аналогично тому, как мы ожидаем услуг связи, когда покупаем сим-карты в смартфон.

Действительно, потребителям достаточно приобрести услугу сотовой компании, чтобы их смартфоны могли соединяться с её сотовыми вышками. Мы потребители, не создаём эти услуги совместно с компанией сотовой связи. Эти услуги были разработаны и предложены для нашей покупки.

Услуги подрядчика в проекте не были созданы до открытия проекта. Их надо создавать. И, чем более уникальна услуга, тем большее участие заказчика она предполагает.

Многие проекты предполагают сложные и взаимозависимые отношения между заказчиком и подрядчиком. В частности, это сотрудничество может касаться разработок:

  1. Требований к изготавливаемому продукту и его разработке. Обычно, руководитель проекта и кураторы проекта на стороне подрядчика устанавливают персональные отношения с кураторами проекта на стороне заказчика. Методика "Живой Свалки" (Agile Scrum) предусматривает отдельный Нулевой Спринт (Sprint Zero). В этом спринте, представители заказчика и подрядчика одну-две недели формируют перечень пользовательских историй для разработки, и расставляют их приоритеты,
  2. Концепции рабочих продуктов проекта. В плановых проектах, заказчик утверждает опись продукта и объём работ. Изменения контрольных уровней должны утверждаться советом по контролю за изменениями (Change Control Board или CCB). В оперативных проектах, концепция дорабатывается в ходе работ,
  3. Результатов первого, второго и третьего уровней. Иногда, специальное подразделение подрядчика, офис по управлению проектами (Project Management Office или PMO), устанавливает дополнительные каналы связи с заказчиком.

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

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

Варианты

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

Термины

Требования, Agile, Scrum, Нулевой спринт, Куратор проекта.

Экзамен

Определения

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

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

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