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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Текст)
Строка 10: Строка 10:
  
 
===Текст===
 
===Текст===
:<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>
+
:<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>
  
 
===Варианты===
 
===Варианты===

Версия 23:20, 24 февраля 2021

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


Материалы

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

Иллюстрации

Текст

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

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

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

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

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

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

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

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

Варианты

Следующее лектио -- Окончания Проектов

Термины

Плановый подход, оперативный подход, Контент, SEO, Бэкенд, Отсрочка Выполнения, Рабочие продукты по сценарию, Рабочие продукты без сценария

Экзамен

Определения

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

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

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