Совместное Создание — различия между версиями
Gary (обсуждение | вклад) (→Материалы) |
Sonya (обсуждение | вклад) (→Термины) |
||
| (не показаны 2 промежуточные версии 2 участников) | |||
| Строка 9: | Строка 9: | ||
</gallery> | </gallery> | ||
| − | ===Текст=== | + | ===Текст (HTML)=== |
:<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> | ||
| Строка 18: | Строка 18: | ||
===Термины=== | ===Термины=== | ||
| − | :[[ | + | :[[Требования]], [[Оперативно-гибкий способ|Agile]], [[Scrum]], [[Нулевой спринт]], [[Куратор проекта]]. |
==Экзамен== | ==Экзамен== | ||
Текущая версия на 18:51, 25 сентября 2022
Совместное Создание (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проектных Итогов. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Продукция Проектов.
Иллюстрации
Текст (HTML)
Совместное Создание
Представим, что у кого-то может сложиться впечатление, что проект -- это дело подрядчика. Как будто, если заказчик покупает услугу, то подрядчик обязан услугу предоставить. Аналогично тому, как мы ожидаем услуг связи, когда покупаем сим-карты в смартфон.
Действительно, потребителям достаточно приобрести услугу сотовой компании, чтобы их смартфоны могли соединяться с её сотовыми вышками. Мы потребители, не создаём эти услуги совместно с компанией сотовой связи. Эти услуги были разработаны и предложены для нашей покупки.
Услуги подрядчика в проекте не были созданы до открытия проекта. Их надо создавать. И, чем более уникальна услуга, тем большее участие заказчика она предполагает.
Многие проекты предполагают сложные и взаимозависимые отношения между заказчиком и подрядчиком. В частности, это сотрудничество может касаться разработок:
- Требований к изготавливаемому продукту и его разработке. Обычно, руководитель проекта и кураторы проекта на стороне подрядчика устанавливают персональные отношения с кураторами проекта на стороне заказчика. Методика "Живой Свалки" (Agile Scrum) предусматривает отдельный Нулевой Спринт (Sprint Zero). В этом спринте, представители заказчика и подрядчика одну-две недели формируют перечень пользовательских историй для разработки, и расставляют их приоритеты,
- Концепции рабочих продуктов проекта. В плановых проектах, заказчик утверждает опись продукта и объём работ. Изменения контрольных уровней должны утверждаться советом по контролю за изменениями (Change Control Board или CCB). В оперативных проектах, концепция дорабатывается в ходе работ,
- Результатов первого, второго и третьего уровней. Иногда, специальное подразделение подрядчика, офис по управлению проектами (Project Management Office или PMO), устанавливает дополнительные каналы связи с заказчиком.
Руководитель проекта может предложить другие меры. Вместо того, чтобы пытаться догадаться, что клиент "хочет", если заказчик не может ответить, подрядчику предпочтительнее создать платформы для творческого сотрудничества в создании продуктов и процессов их создания. Все заинтересованные стороны могут выиграть от возможности установки взаимовыгодных, интерактивных отношений.
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, совместное создание необходимо:
Варианты
- заказчику, для удовлетворения всех его потребностей касательно продукта./ подрядчику, для уточнения каких результатов хочет добиться заказчик./ для инициирования идей по продукту./ для разработки повторяющихся циклов.
- Следующее лектио -- Объёмы Работ
Термины
Экзамен
Определения
Вопросы экзамена
- Работа по Заданному Подходу лучше всего подойдет, когда:
Рабочий продукт написан по сценарию; Скриптовый рабочий продукт разрабатывается в управляемой среде; Ни один из ответов не верен; Все остальные ответы по существу верны; Проект предсказуем.
