Оперативки и Планы

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

Материалы

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

Текст

Оперативки и Планы

Каждый проект может быть плановым или оперативным в зависимости от того, когда начинается разработка объектов приёмки -- до утверждения объёма работ, сроков и бюджета или после утверждения.

1. Плановый способ управления проектом (Waterfall, predictive) -- это подход, при котором объёмы работ, сроки выполнения и бюджеты планируются и утверждаются до начала разработки. В плановых проектах, заказчик и подрядчик устанавливают специальный механизм для пересмотра планов если будет разрыв между планами и реальностью.

   Возьмём строительство нового дома. Человечество строит дома тысячи лет. Процесс известен -- сначала строители кладут фундамент, а затем кладут стены. Рынок строителей сформирован. Стоимость труда, стоимость материала и сроки можно предсказать. В нужное время можно нанять нужных работников и заказать нужные материалы в соответствии с бюджетом и графиком. Расходно нанимать строителей до того, как план готов.

2. Оперативный способ управления проектом (Agile, incremental, iterative) -- это подход, при котором разработка начинается до утверждения объёмов работ, сроков выполнения и бюджетов. В оперативных проектах, заказчик и подрядчик устанавливают специальный механизм для планирования одновременно с разработкой.

   Возьмём разработку Брацкой Школы. Никто раньше не создавал такую общественную инициативу. Никто также не может предсказать, как она будет выглядеть, скажем, через год. Мы не можем планировать детали того, чего не знаем. Более того, Брацка Школа разрабатывается волонтёрами. Каждый волонтёр приходит и уходит по своему расписанию. Волонтёрам сообщают ориентиры, но они сами выбирают, что они будут делать, а что- нет. Даже если мы умудримся предсказать объём работ, мы не сможем предсказать, когда этот объём будет выполнен. Нет никакой возможности создать детальный план.

Чтобы выбрать между плановым и оперативным подходом, ответственные могут принять во внимание четыре показателя:

1. Предсказуемость разработки объекта приёмки,
2. Способность разработчиков действовать независимо,
3. Вероятность глубокой вовлечённости куратора по продукту в разработку,
4. Определённость в том, что важнее для заказчика -- сделать рабочий продукт дешевле или быстрее.

Если разработка предсказуема, то следующий вопрос -- могут ли разработчики сами определять фронт своих работ или им нужет начальник.

Рабочие продукты по сценарию - это те рабочие продукты, процесс разработки которых структурирован и подробно известен. Это будут конструкции, не дизайнерская одежда и продукты, приготовленные по рецептам.

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

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

Плановый способ может быть отлично реализован в этих условиях и сэкономит деньги, но оперативный способ даст результаты быстрее. Проект непредсказуем, если продукт без сценария разрабатывается в неконтролируемой среде. Если сотрудники проекта выберут плановый способ, им придется угадывать, как будет выглядеть разработка. Большинство догадок могут не пережить реальность.

Затем руководитель проекта должен будет отправить запросы на изменение; если клиент одобряет, отклоняет или изменяет эти запросы быстро, плановый способ может получить скорость оперативного.

Вообще говоря, для планового способа нужны данные, чтобы сэкономить деньги и сократить сроки. Без данных преимущество планового способа бесполезно. В условиях полной неопределенности проектная работа может быть единственным источником данных.

В то же время вся разработка не обязательно должна быть плановой или оперативной. В качестве примера возьмем разработку сайта bskol.com. Эту работу можно разделить на несколько проектов, среди которых некоторые, такие как интерфейс и бэкенд, могут быть разработаны оперативным способом, а другие, такие как дизайн, контент и SEO, могут быть плановым способом.

Творческие работы, такие как разработка контента и дизайн, всегда включают в себя как сценарии, так и аспекты без сценария. Исключительно эксклюзивный веб-дизайн может занять несколько лет и более миллиона долларов. Клонирование или изменение существующего дизайна также может занять несколько часов и мелочь. Поскольку графики для творческих работ не могут быть реально рассчитаны, заказчик обычно просто устанавливает свои затраты и/или сроки, чтобы разработчики могли управлять своими усилиями.

В поисковых проектах этапы проекта всегда перекрываются. Предварительное планирование работы, которое называется Нулевой Спринт, устанавливает правила и приоритеты для проекта. Каждый день планирование открывается заново, чтобы учесть разработки предыдущего дня.

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

Владелец проекта несет ответственность за управление проектом. Чтобы направлять, контролировать и/или поддерживать персонал проекта, владелец может создать офис управления проектом, часто сокращенно ОУП.

В управлении проектами Гибкой Методологии ключевую роль играет руководитель проекта. Эти менеджеры концентрируются на разработке утвержденных продуктов в соответствии с утвержденными бюджетами и утвержденными графиками.

Менеджер проекта ведет Планирование проекта до утверждения базовых показателей, выполнение проекта до подтверждения результатов и закрытие проекта. На этапе планирования менеджер может нанять бизнес-аналитиков для сбора требований и системных инженеров для разработки системы, как Решения. Те разработчики, которые непосредственно создают результаты, нанимаются только на стадии Выполнения.

Если персонал проекта составляет менее 5-9 человек и график не сжат, менеджер редко выполняет выделенную роль. Один из разработчиков или кто-то другой может выступать в качестве менеджера проекта в дополнение к другим обязанностям.

В Жестком Подходе функции управления распределены между несколькими ролями. Например, разработчики определяют работу на основе требований решения, таких как пользовательские истории. На этапе Планирования некий координатор, например, менеджер по работе с клиентами, работающий в ОУП, нанимает членов группы планирования в дополнение к владельцу продукта. Эта команда проводит Нулевой Спринт или аналогичные действия, предпринимаемые для создания Бэклога Продукта.

На исполнительный этап нанимается команда разработчиков. Помимо product owner-а(Владелец Продукта), в эту команду входят разработчики и, возможно, такие официальные лица, как Scrum Master. Разработчики обычно работают в итерациях и, как только разрабатываются новые инкременты и обнаруживаются новые данные, обсуждают будущий продукт и его доставку с Владельцем Продукта. Скрам-Мастера не занимаются рабочими продуктами и поставками; Вместо этого Скрам-Мастера следят за тем, чтобы разработка шла в соответствии с согласованными правилами. В отличие от Управления проектами, администрирование разработки часто распределяется между двумя организациями, если две организации участвуют в одном проекте.

Заказчик Проекта определяет бизнес-потребность, которая является проблемой, которую необходимо решить, инициирует проект по созданию решения и предоставляет бюджет проекта. Владелец Проекта, следовательно, нанимает кого-то, кто действует от имени клиента при утверждении Требований к решению, базовых планах проекта и / или оценке того, соответствует ли рабочий продукт критериям приемки.

В проектах Гибкой Методологии -- эта административная роль называется Спонсором Проекта. Базовые показатели не являются особенностью проектов с Жесткким Подходом, поэтому администрация концентрируется только на требованиях к продукту.

Владелец продукта - ключевая административная роль в Жестких Методологиях проекта. Этот человек концентрируется на представлении правильного продукта, описании этого продукта обычно с использованием пользовательских историй и расстановке приоритетов в отставании по продукту. Владельцы Продуктов не занимаются бюджетами, графиками, а также другими функциями управления, такими как найм и закупки. Область ответственности product owner-а - убедиться, что деньги покупателя тратятся на продукт, который покупатель ищет.

Прочитав данную статью, ответьте на ниже представленный вопрос.

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

Варианты

Следующее лектио -- Совместное Создание

Термины

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

Экзамен

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

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

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