|
|
| (Не показані 26 проміжних версій 6 користувачів) |
| Рядок 1: |
Рядок 1: |
| − | [[Продукты Творчества]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Продуктов Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''. | + | [[Продукти Творчості]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Продуктов Работ|Суть Продуктів Робіт]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''. |
| | | | |
| | | | |
| Рядок 9: |
Рядок 9: |
| | </gallery> | | </gallery> |
| | | | |
| − | ===Текст=== | + | ===Текст (HTML)=== |
| − | :<p><strong> Продукты Творчества</strong></p><p> Любое изделие включает в себя как измеримые, так и качественные элементы. Например, веб-сайт -- это не только и не столько работающие ссылки на определённом веб- адресе, но и содержание сайта, и дизайн.</p><p> Если опись продукта (product scope) -- это перечень функций, характеристик и свойств продукта, то как описать продукт творчества для его разработки? Функции " Мастера и Маргариты"? Характеристики " Джоконды"? Свойства " Лунной Сонаты"?</p><p> С одной стороны, создание эксклюзивного веб-дизайна, текстов и звукового оформления может занять несколько лет и миллионы долларов. С другой стороны, клонирование или изменение существующего дизайна также может занять несколько часов и стоить мелочь. </p><p>Поскольку графики для творческих работ не могут быть достаточно описаны и реально рассчитаны, есть смысл просто устанавить бюджет и сроки. Далее, руководитель проекта подбирает на разработку того дизайнера, писателя или композитора, который может выработать необходимые элементы.</p><p></p><ol type="a"><li> Вы хотите создать новый веб-сайт или изменить дизайн существующего?< li> </li> | + | :<p><strong> Продукти Творчості</strong></p><p> Будь-який виріб включає як вимірні, так і якісні елементи. Наприклад, веб-сайт -- це не тільки працюючі посилання на певній веб- адресі, а й творчий зміст сайту (тексти, картинки, медіа файли), та дизайн.</p><p> Якщо опис продукту (product scope) -- це перелік функцій, показників і якостей товару, як деталізувати товар творчості? Як визначити функції " Майстра та Маргарити"? Характеристики " Джоконди"? Властивості " Місячної Сонати"?</p><p> Організація творчих розробок зустрічається з багатьма завданнями, з яких ми тут відзначимо три.</p><ol type="a"><li>< p> Встановити бюджет та терміни. Творчі роботи неможливо знайти описані в достатніх деталях. Значить, їх графіки не розраховуються, так само як і витрати на них.</p><p> У дорогих крайностях створення ексклюзивного веб-дизайну, текстів та звукового оформлення може зайняти кілька років і мільйони доларів. У дешевих крайностях, клонування або зміна існуючого дизайну також може коштувати дрібницю та зайняти кілька годин. Реальні рішення знаходяться між цими полюсами.</p></ li>< li> Знайти розробника, який може виробити необхідні елементи у встановлений час та за обумовлені суми. Це завдання також натикається на дві крайності. З одного боку, деякі "творчі особистості" більш схильні до вільної творчості, ніж до створення працюючого продукту. З іншого боку, розробник має бути здатним зробити роботи. Скажімо, багато людей, які називають себе дизайнерами, не можуть робити дизайн. Їхнє портфоліо складено з робіт, до яких у кращому випадку вони могли мати якесь далеке відношення.</ li>< li> Зрозуміти, хто споживач і що йому необхідно.</ li></ol><p> Наприклад, наступні питання можуть допомогти знайти спільну мову зі споживачем веб-сайту:</p>< ul><li> Ви хочете створити новий веб-сайт або змінити дизайн існуючого?</ li>< li> Опишіть свій бізнес та його послуги парою пропозицій. </ li>< li> Кому пропонуються послуги?</ li><li> Що робить Ваші послуги унікальними?</li>< li> Які функції потрібні Вашому сайту? Чому?</ li>< li> Які три сайти у Вашій галузі Вам подобаються найбільше? Чому?</ li>< li> Це -- разова розробка чи постійні операції?</ li>< li> Чи є у Вас якісь посібники зі стилю та правила?</ li>< /ul><p>< i> А тепер виберіть, будь ласка, найкраще завершення наступної пропозиції.</ i> Судячи з тексту вище, для визначення продукту творчості:</p> |
| − | Опишите свой бизнес несколькими предложениями<li></li>
| |
| − | Какие услуги вы предлагаете?<li></li>
| |
| − | Кто ваша целевая аудитория?<li></li>
| |
| − | Что делает ваши услуги уникальными?<li></li>
| |
| − | Какие функции необходимы вашему сайту для успешной работы?<li></li>
| |
| − | Какие три сайта вам нравятся больше всего (и почему)?<li></li>
| |
| − | Заинтересованы ли вы в услугах контент-маркетинга?<li></li>
| |
| − | Хотели бы вы, чтобы мы обеспечивали постоянную поддержку и обслуживание?<li></li>
| |
| − | Какова ваша идеальная дата запуска веб-сайта?<li></li>
| |
| − | Есть ли у вас какие-либо руководства по стилю и правила? </li></ol><p>
| |
| − | | |
| − | </p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p> | |
| − | | |
| − | <p>Выполнение проекта начинается после утверждения Бэклога Продукта. Это отставание выполняет роль объема продукта, и разработчики принимают решения о том, какую работу им следует выполнять, исходя из этого объема. По мере того как проект по Заданному Подходу развивается, объем продукта уточняется.</p> <p>Рассмотрим подробнее значение определения Бэклог Продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале Бэклога Продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь.</p>
| |
| − | | |
| − | Служба. Средство создания возможности совместного создания стоимости путем облегчения результатов, которых хотят достичь клиенты, без необходимости управлять конкретными затратами и рисками.
| |
| − | | |
| − | Если разработка предсказуема, то следующий вопрос -- могут ли разработчики сами определять фронт своих работ или им нужет начальник.
| |
| − | | |
| − | <p>Рабочие продукты по сценарию - это те рабочие продукты, процесс разработки которых структурирован и подробно известен. Это будут конструкции, не дизайнерская одежда и продукты, приготовленные по рецептам.</p>
| |
| − | <p>Рабочие продукты без сценария - это те рабочие продукты, процесс разработки которых не структурирован или неизвестен. Они будут включать первое в истории радио, первый самолет и первый компьютер. Если у разработчиков нет инструкций по разработке чего-либо, соответственно разработка такого проекта выполняется без сценария.</p> | |
| − | <p>Проект предсказуем, если рабочий продукт по сценарию разработан в управляемой среде. Выбор клиента: (а) получить результат быстрее, но, возможно, потратить больше денег, или (б) потратить меньше денег и получить результат позже.</p><p>Плановый способ может быть отлично реализован в этих условиях и сэкономит деньги, но оперативный способ даст результаты быстрее. | |
| − | Проект непредсказуем, если продукт без сценария разрабатывается в неконтролируемой среде. Если сотрудники проекта выберут плановый способ, им придется угадывать, как будет выглядеть разработка. Большинство догадок могут не пережить реальность.</p>
| |
| − | | |
| − | <p>Вообще говоря, для планового способа нужны данные, чтобы сэкономить деньги и сократить сроки. Без данных преимущество планового способа бесполезно. В условиях полной неопределенности проектная работа может быть единственным источником данных.</p> | |
| − | <p>В то же время вся разработка не обязательно должна быть плановой или оперативной. В качестве примера возьмем разработку сайта bskol.com. Эту работу можно разделить на несколько проектов, среди которых некоторые, такие как интерфейс и бэкенд, могут быть разработаны оперативным способом, а другие, такие как дизайн, контент и SEO, могут быть плановым способом.</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-а - убедиться, что деньги покупателя тратятся на продукт, который покупатель ищет.
| |
| − | | |
| − | Общее понимание ключевых концепций и терминологии организациями
| |
| − | и отдельные люди имеют решающее значение для эффективного использования этого руководства для решения реальных проблем
| |
| − | проблемы управления услугами. С этой целью в этой главе объясняются некоторые из наиболее
| |
| − | важные концепции управления услугами, включая:
| |
| − | природа ценности и совместного создания ценности
| |
| − | организации, поставщики услуг, потребители услуг и другие заинтересованные стороны
| |
| − | продукты и услуги
| |
| − | служебные отношения
| |
| − | ценность: результаты, затраты и риски.
| |
| − | Эти концепции применимы ко всем организациям и службам, независимо от их характера.
| |
| − | и поддерживающая технология. Но первое, что необходимо выделить, - это самое
| |
| − | фундаментальный вопрос для всех: что такое «управление услугами»?
| |
| − | Определение: управление услугами
| |
| − | Набор специализированных организационных возможностей для создания ценности для клиентов
| |
| − | в виде услуг.
| |
| − | Развитие специализированных организационных возможностей, упомянутых в определении
| |
| − | требует понимания:
| |
| − | природа ценности
| |
| − | характер и круг заинтересованных сторон
| |
| − | как создание ценности возможно через услуги.
| |
| − | | |
| − | Стоимость и совместное создание ценности
| |
| − | Ключевое сообщение
| |
| − | Цель организации - создать ценность для заинтересованных сторон.
| |
| − | Термин «ценность» регулярно используется в управлении услугами и является ключевым направлением деятельности .
| |
| − | поэтому он должен быть четко определен.
| |
| − | Определение: значение
| |
| − | | |
| − | Воспринимаемые преимущества, полезность и важность чего-либо.
| |
| − | Этому определению присуще понимание того, что ценность зависит от
| |
| − | восприятие заинтересованных сторон, будь то клиенты или потребители
| |
| − | услуги или часть организаций-поставщиков услуг. Ценность может быть субъективной.
| |
| | | | |
| | ===Варианты=== | | ===Варианты=== |
| − | : | + | :необхідно ставити уточнюючі питання; можна вимірювати в будь-яких одиницях; бути орієнтованим на робочий продукт; створити опис продукту. |
| | | | |
| − | :Следующее лектио -- '''[[Интеграции Операций]]''' | + | :Следующее лектио -- '''[[Реализуемости Задумок]]''' |
| | | | |
| | ===Термины=== | | ===Термины=== |
| − | :[[WBS]], [[Объем Проекта]], [[Области Решения]], [[Критерии Приемки]], [[Бэклог Продукта]] | + | :[[Опись продукта]], [[Разработка]] |
| | | | |
| | ==Экзамен== | | ==Экзамен== |
