|
|
| (не показано 29 промежуточных версий 2 участников) |
| Строка 1: |
Строка 1: |
| − | [[Совместное Создание]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Проектных Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''. | + | [[Изменения Одобрений]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Контролей Планов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''. |
| | | | |
| | | | |
| | ==Материалы== | | ==Материалы== |
| − | Предшественник этого ''Лектио'' -- [[Контрольные Уровни]]. | + | Предшественник этого ''Лектио'' -- [[Раздувания Планов]]. |
| | | | |
| | ===Иллюстрации=== | | ===Иллюстрации=== |
| Строка 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>Концепции рабочих продуктов проекта. В плановых проектах, заказчик утверждает опись продукта и объём работ. В оперативных проектах, концепция дорабатывается в ходе работ,</li><li> Изменений контрольных уровней. В плановых проектах, стороны устанавливают совет по контролю за изменениями (Change Control Board или CCB). Отдельные заказчики имеют тенденцию дозаказывать что-то уже после утверждения контрольных уровней. Если контрольные уровни ранее были утверждены, дозаказывание должно дополняться изменением стоимости и проходить согласование. Увеличение объёма работ без оплаты называется неконтролируемым раздуванием рамок проекта (scope creep). Наоборот, оперативно-гибкие способы такие изменения приветствуют даже если они произошли в самом конце прогона, </li><li>Результатов первого, второго и третьего уровней. Иногда, специальное подразделение подрядчика, офис по управлению проектами (Project Management Office или PMO), устанавливает дополнительные каналы связи с заказчиком.</ li></ol><p> Руководитель проекта может предложить другие меры. | + | :<p><strong> Изменения Одобрений</strong></p><p> В жизни случаются непредвиденные ситуации, которые мы не можем знать заранее, также и с проектами, ни один нельзя полностью предсказать и спрогнозировать. Если какой-либо из контрольных планов проекта не может быть выдержан в исполнении, тогда руководитель проекта делает запрос на изменение ( change request).</ p>< p>В плановых проектах, стороны устанавливают совет по контролю за изменениями (Change Control Board или CCB). Этот совет включает как представителей заказчика, так и представителей подрядчика проекта. Иногда, советов устанавливается несколько. В этом случае, разные органы имеют разные зоны ответственности, например, один решает вопросы, которые касаются изменений в продукте, а другой рассматривает вопросы, связанные с переменами в проекте.</p><p> Совет рассматривает запросы на изменение и принимает одно из трёх решений:</p>< ol type="a">< li> Утвердить в предложенном варианте,</ li>< li> Отклонить,</ li>< li> Утвердить в изменённом варианте.</ li></ li></ ol><p> Эти же советы могут принимать решение о готовности продуктов к передаче и успешности всего проекта.</p><p> Если в течении проекта что-то поменялось на стороне заказчика, он или она могут добавлять к заказу что-то, после утверждения контрольных планов. В плановых проектах, дозаказывание дополняется изменением стоимости или объёма и проходит согласование.</p><p> Так как каждое изменение контрольных планов влечёт за собой работу по пересчёту, подрядчик может предложить некоторую оплату или поставить ограничение на количество бесплатных пересчётов. Согласие руководителя проекта на увеличение работы без соответствующей оплаты называется неконтролируемым раздуванием объёмов работы (scope creep).</p><p> Опять же, контрольные планы утверждаются и переутверждаются только в плановых проектах. В оперативных проектах, опись продукта только дорабатывается; изменения объёмов работ заложены в природу оперативных проектов. Оперативно-гибкий способ даже приветствует изменения на любой стадии, вплоть до самой поздней.</p><p> <i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</ i> Судя по тексту выше, за изменение контрольных планов:</p> |
| − | | |
| − | <p>Жизнь есть жизнь, вещи случаются, и ни один проект нельзя полностью предсказать. Если какой-либо из базовых планов проекта не может быть выдержан в исполнении, менеджер проекта делает запрос на изменение, чтобы заказчик или его представитель утвердили, отклонили или изменили.</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>
| |
| − | <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-а - убедиться, что деньги покупателя тратятся на продукт, который покупатель ищет.
| |
| − | | |
| − | Общее понимание ключевых концепций и терминологии организациями
| |
| − | и отдельные люди имеют решающее значение для эффективного использования этого руководства для решения реальных проблем
| |
| − | проблемы управления услугами. С этой целью в этой главе объясняются некоторые из наиболее
| |
| − | важные концепции управления услугами, включая:
| |
| − | природа ценности и совместного создания ценности
| |
| − | организации, поставщики услуг, потребители услуг и другие заинтересованные стороны
| |
| − | продукты и услуги
| |
| − | служебные отношения
| |
| − | ценность: результаты, затраты и риски.
| |
| − | Эти концепции применимы ко всем организациям и службам, независимо от их характера.
| |
| − | и поддерживающая технология. Но первое, что необходимо выделить, - это самое
| |
| − | фундаментальный вопрос для всех: что такое «управление услугами»?
| |
| − | Определение: управление услугами
| |
| − | Набор специализированных организационных возможностей для создания ценности для клиентов
| |
| − | в виде услуг.
| |
| − | Развитие специализированных организационных возможностей, упомянутых в определении
| |
| − | требует понимания:
| |
| − | природа ценности
| |
| − | характер и круг заинтересованных сторон
| |
| − | как создание ценности возможно через услуги.
| |
| − | | |
| − | 2.1 Стоимость и совместное создание ценности
| |
| − | Ключевое сообщение
| |
| − | Цель организации - создать ценность для заинтересованных сторон.
| |
| − | Термин «ценность» регулярно используется в управлении услугами и является ключевым направлением деятельности .
| |
| − | 4; поэтому он должен быть четко определен.
| |
| − | Определение: значение
| |
| − | | |
| − | Воспринимаемые преимущества, полезность и важность чего-либо.
| |
| − | Этому определению присуще понимание того, что ценность зависит от
| |
| − | восприятие заинтересованных сторон, будь то клиенты или потребители
| |
| − | услуги или часть организаций-поставщиков услуг. Ценность может быть субъективной.
| |
| | | | |
| | ===Варианты=== | | ===Варианты=== |
| − | : | + | :отвечает совет по контролю за изменениями./ отвечает заказчик./ следит подрядчик./ в оперативных проектах никакое отдельное лицо не отвечает, так как изменения объёма работ являются характеристикой проектов. |
| | | | |
| | :Следующее лектио -- '''[[Что Есть Факторы]]''' | | :Следующее лектио -- '''[[Что Есть Факторы]]''' |
| | | | |
| | ===Термины=== | | ===Термины=== |
| − | :[[Бюджет Проекта]], [[Активы Проекта]], [[Внешние Среды]], [[Внутренние Среды]], Проектная Среда, [[Затраты На Проект]], [[График Проекта]], [[Фактор Предприятия]], [[Рабочий Продукт]], [[Временные Шкалы Проекта]] | + | :[[Бюджет проекта]], [[ССВ]], [[Объём работ]], [[Контрольный план работ]], [[Опись продукта]]. |
| | | | |
| | ==Экзамен== | | ==Экзамен== |
