Что такое границы проекта
Определение образа и границ проекта
Образ продукта призван выстраивать работу всех заинтересованных лиц в одном направлении. Образ продукта должен четко определять, что представляет собой продукт как в базовой, так и в последующих версиях. Границы проекта показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект. В положении о границах должна быть четко определена черта между тем, что входит в проект и тем, что остается вовне. То есть указанные рамки по существу определяют ограничения проекта.
Говоря об образе, подразумевается весь продукт. Он будет изменяться относительно медленно при изменении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту – базовой или последующей версиям. То есть границы более динамичны, чем образ, так как менеджер проекта изменяет содержимое каждой версии в соответствии с графиком, бюджетом, ресурсами и ограничениями качества.
Таким образом, сбалансированный образ продукта, удовлетворяющий различные заинтересованные лица, должен обобщать долгосрочные цели и назначение нового продукта. Он может быть несколько идеалистичным, но должен быть основан на существующих или предполагаемых рыночных факторах, архитектуре предприятия заказчика, стратегическом направлении развития предприятия заказчика и ограничениях ресурсов.
Далее показан шаблон, состоящий из ключевых слов, которые хорошо подходят для определения образа продукта:
| Ключевое слово | Характеристика |
| для | целевая аудитория покупателей продукта |
| который | потребности, удовлетворяемые продуктом, и/или возможности, предоставляемые продуктом |
| эта (этот) | наименование продукта |
| является | категория продукта |
| который(ая) | ключевое преимущество, основная причина для покупки или использования |
| в отличие от | основной конкурирующий продукт, текущая система или текущий бизнес-процесс |
| наш продукт | положение об основном отличии и преимуществе нового продукта |
Как уже отмечалось, границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц.
Определение границы между тем, что входит и выходит за границы проекта, – отличный способ управления расползанием объема и ожиданиями клиентов.
На практике обычно определение границ конкретной версии осуществляется перечислением бизнес-требований, которые предполагается в рамках этой версии реализовать.
При поэтапной разработке базовая версия не обязательно должна быть быстрой, красиво оформленной или легкой в использовании, но она должна быть надежной; это основа работы команды. Необходимо помнить, что первая версия системы выполняет лишь базовые задачи. В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие легкость и простоту использования.
Для более наглядного представления границ проекта желательно использовать контекстную диаграмму. Она определяет оконечные элементы, расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма, по сути, представляет собой высший уровень абстракции в диаграммы потока данных. На подобной диаграмме нет смысла показывать внутренние объекты системы, процессы и данные – она вполне может быть представлена в виде единого объекта. Оконечные элементы обычно представляют классы пользователей, подразделения, другие системы или аппаратные комплексы. Главное назначение подобной диаграммы – наглядно показать, что находится за границами проекта.
Дата добавления: 2016-06-13 ; просмотров: 3150 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Управление «расползанием» границ проекта: почему, когда и как
Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание границ (от англ. «scope creep», также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.
Постоянное изменение и расширение требований затрудняет своевременную реализацию приоритетных функций. Постоянное расширение функциональности приводит к задержкам, проблемам с качеством и нерациональному использованию энергии. Расползание границ — одна из самых распространенных проблем в разработке программного обеспечения.
Определение границ
Первым шагом в борьбе с расползанием границ является документирование четко сформулированных и согласованных границ проекта. Без определения этих границ вы не сможете даже понять, что у вас наблюдается расползание границ. Техники, описанные в моей статье «Определение границ проекта», содержат несколько методов определения. Agile-проекты должны составлять краткое описание границ для каждой итерации, чтобы убедиться, что все понимают, что будет и что не будет реализовано в ходе данной итерации. В качестве альтернативы можно дать каждой итерации краткое название, передающее ее цель.
Шаблон документа «Видение и рамки», который я рекомендую, включает раздел «Ограничения и исключения». Здесь вы можете перечислить все возможности или характеристики продукта, которые заинтересованные лица могут ожидать, но которые заведомо не планируются к добавлению в продукт или в конкретный релиз. Можно также перечислить элементы, которые были исключены из границ проекта, чтобы не забыть о решении по данным рамкам. Подобное перечисление известных ограничений помогает команде быстро принимать решения, если поступает запрос на изменение какой-либо возможности, включенной в список исключений.
Входит ли это в рамки?
Вторым шагом в управлении расползанием границ является вопрос «Входит ли это в сами рамки?» всякий раз, когда кто-то предлагает какую-то дополнительную возможность продукта, например, вариант использования, пользовательскую историю, функциональное требование, функцию или результат обратите внимание, что рамки проекта могут охватывать деятельность и результаты помимо поставляемых программных продуктов. Возможно, ваши заказчики просят предоставить онлайн учебник, чтобы помочь своим пользователям освоить новую систему. Это не меняет сам программный продукт, но, безусловно, расширяет рамки общей работы по проекту, которую необходимо выполнить.
В одной из ситуаций клиент заключил контракт с поставщиком пакетного решения на перенос трех наборов архивных данных в новый пакет. В ходе выполнения проекта заказчик пришел к выводу, что необходимо выполнить еще шесть преобразований данных. Заказчик посчитал, что эта дополнительная работа входит в согласованный объем; поставщик утверждал, что она не входит в рамки проекта, и потребовал дополнительной оплаты.
Это был один из факторов, который привел к аннулированию проекта, судебному иску и консалтинговой задаче, в ходе которого я помог определить причину неудачи проекта. Более четкое определение границ объема работ на начальном этапе, а также соглашение о том, как и кем будут покрываться расходы, связанные с изменением границ проектных работ, могли бы предотвратить этот печальный исход.
Корректировка границ
Есть три возможных ответа на вопрос «Входит ли это в рамки проекта?». Если новая возможность явно входит в рамки проекта, то команде необходимо заняться этим вопросом. Если она явно выходит за рамки, команде не нужно с ней работать, по крайней мере, сейчас. Они могут запланировать новую функциональность на более поздний релиз или итерацию.
Иногда, однако, запрашиваемая функциональность выходит за рамки проекта в том виде, в котором она определена в настоящее время, но это настолько хорошая идея, что рамки должны быть расширены, чтобы вместить ее. Решение о расширении границ проекта — это бизнес-решение. Лица, принимающие ключевые решения, должны учитывать стоимость, риски, график и последствия для рынка. Это требует того, чтобы менеджер проекта, спонсор управления и ключевые клиенты проводили переговоры, чтобы определить, как лучше поступить с изменением границ проекта. Владелец бизнес-требований — спонсор управления — должен решить, станут ли предлагаемые изменения в пользовательских или функциональных требованиях ответственностью менеджера проекта в результате расширения границ (рис. 1).
Работа с расползанием границ
Ниже приведены некоторые возможные стратегии для преодоления неожиданного увеличения требований:
Отложить или исключить некоторые другие, менее приоритетные функциональные возможности, которые были запланированы в текущем релизе.
Нанять дополнительных сотрудников для выполнения дополнительной работы.
Получить дополнительное финансирование, возможно, для оплаты сверхурочных (ладно, это просто шутка), передать часть работы на аутсорсинг или приобрести инструменты, повышающие производительность.
Расширить график выпуска текущего релиза, чтобы учесть дополнительную функциональность (это не шутка).
Идти на компромисс с качеством, делая наспех работу, которую потом придется исправлять (не лучший вариант).
Расширение границ всегда имеет свою цену. Люди, финансирующие проект, должны принять взвешенное решение о том, какая стратегия управления рамками проекта является наиболее подходящей в каждой конкретной ситуации. Цель всегда состоит в том, чтобы обеспечить максимальную потребительскую ценность, согласованную с достижением определенных бизнес-целей и критериев успеха проекта, в рамках существующих ограничений.
Нет смысла притворяться, что команда проекта может реализовать все большее количество функциональных возможностей, не заплатив за это определенную цену. Кроме того, всегда разумно предвидеть определенный расширение границ работ в ходе проекта. Опытный руководитель проекта включит в проектные планы буферы на случай непредвиденных обстоятельств, чтобы команда могла в разумных пределах приспособиться к расширению границ, не нарушая при этом своих обязательств по графику.
Грамотное управление рамками проекта требует соблюдения нескольких условий:
Требования должны быть приоритетными, чтобы лица, принимающие решения, могли выбрать возможности для добавления в следующий релиз или итерацию и могли оценить запросы на изменения с учетом приоритетов требований в текущей базовой структуре. Это цель бэклога в agile-проекте (на самом деле, в любом проекте!).
Размер требований должен быть оценен для того, чтобы команда имела приблизительное представление о том, сколько усилий потребуется для их реализации. Для этого и нужны относительные единицы объема работы.
Команда должна знать свою среднюю производительность (скорость в agile-проекте), чтобы иметь представление о том, сколько требований, измеряемых в единицах размера, она может реализовать и проверить за единицу времени.
Запросы на изменения должны пройти анализ влияния изменений, чтобы команда хорошо понимала, сколько будет стоить реализация каждого из них и каковы будут последствия для проекта.
Необходимо определить лиц, принимающих решения по проекту, и определить процесс принятия ими решений, чтобы они могли эффективно принимать решения об изменении границ работ в случае необходимости.
Коммуникация — еще один важный элемент для управления scope creep. Вам необходимо обучить заинтересованные стороны, чтобы они понимали важность всех запросов на изменения через определенный (и эффективный!) процесс управления изменениями. Процесс управления изменениями — это не барьер, а скорее ворота, механизм, с помощью которого нужные люди могут принимать правильные решения для внедрения нужных изменений в нужное время. Сообщайте о решениях по утвержденным запросам на изменения всем соответствующим заинтересованным сторонам, чтобы они знали, как развивается проект и как это влияет на них.
Не становитесь жертвой расползания границ и не пытайтесь тщетно подавить изменения. Вместо этого четко определите рамки на ранней стадии проекта, а затем следуйте практическому процессу контроля изменений, чтобы справиться с неизбежной эволюцией требований. Дополнительные идеи о том, как справиться с этой вездесущей проблемой проекта, см. в статье «Как предотвратить и управлять расползанием границ проекта».
Изменения случаются: справляйтесь с ними.
Перевод материала подготовлен в рамках курса «Системный аналитик. Basic». Если интересно узнать подробнее о формате обучения и программе курса, регистрируйтесь на день открытых дверей онлайн.
Управление содержанием проекта
Содержание проекта – это то, что проект включает в себя, и в чем он состоит. Управление содержанием проекта – достаточно большая область знаний, владея которыми Руководитель проекта определяет, что входит в проект и что остается за его рамками.
Содержание проекта – это наличие в проекте тех работ, которые необходимо выполнить, для того, чтобы получить желаемый результат.
Таким образом, содержанием нужно управлять и контролировать его на протяжении всего жизненного цикла проекта, следить за тем, чтобы в списке необходимых работ не появились лишние, не относящиеся к желаемому результату проекта. Или какие-то побочные, относящиеся уже к другому проекту.
Также стоит различать содержание проекта и содержание продукта: в первом случае, это работы, которые необходимо выполнить для получения желаемого результата (продукта, услуги), во втором случае – это функции и характеристики результата.
В процессе определения содержания появляется детальный документ, в котором отражены цели и задачи проектных работ.
Не стоит так же забывать, что для достижения одного результата могут быть использованы различные альтернативные методы, таким образом, следует рассматривать вопрос шире, со всех сторон, чтобы не упустить более выгодные возможности.
После того, как разработан и утвержден устав проекта, собраны и задокументированы требования, может быть составлено описание содержания проекта. Оно уже содержит больше информации о проекте, и оно более детально.
Качественно составленное описание содержания проекта важно еще и потому, что впоследствии будет являться основой для планов и решений. В то время как при плохо определенных целях могут возникнуть значительные риски.
Чем детальнее и однозначнее звучат пункты содержания проекта, тем проще потом определить, что проект завершен, то есть выполнены все требования и достигнуты все поставленные цели.
Но мы все понимаем, что в процессе жизненного цикла проекта появляется все больше и больше уточняющей информации, что необходимо учитывать при дополнении и детализации содержания проекта, при необходимости согласовывая с заинтересованными лицами.
Содержание проекта включает в себя:
Об описании содержания проекта, критериях приемки результата и границах проекта поговорим ниже.
Описание содержания проекта
В описание проекта входит достаточно высокоуровневое описание того, какие результаты должны быть получены. По большому счету, это следующий уровень детализации того содержания, которые было приведено в уставе проекта. Важно включить сюда то, что требуется сделать или произвести для получения результата. Например, если вы внедряете новую информационную систему, в содержание проекта будет входить:
Критерии приемки результата проекта
По каждому из элементов содержания проекта, приведенному выше, указывается, как заказчик и мы сами поймем, что результат действительно соответствует ожиданиям? Это обычно самая сложная часть описания содержания проекта, т.к. степень неопределенности еще слишком высока, а договариваться нужно уже тут, на берегу,пока работы не начались.
Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.
Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.
Границы проекта
Помимо того, что команда проекта будет делать в ходе его реализации, очень важно определить, чего она делать не будет.
На рисунке ниже схематично изображено определение границ проекта.
Определение границ проекта
В ходе описания границ проекта определяются и документируются все моменты, которые могут подразумеваться как часть проекта, но таковой не являются (опять же, в идеально случае вы просто детализируете то, что ранее написали в уставе проекта).
Продолжая приведенный выше пример, в содержание проекта входит обучение пользователей, но не входят командировки проектной команды для обучения бухгалтеров в регионах или организация командировок этих бухгалтеров для обучения в Москве (об этом заказчику придется позаботиться самостоятельно).
Управление содержанием целесообразно еще и потому, что позволяет контролировать объем усилий и средств, направленных на получение результата. Что, если на выполнение проекта потрачено огромное количество ресурсов, усилий, времени – а результат, мягко говоря, того не стоит?
Хорошо написанное содержание проекта – одна из основополагающих успеха проекта и отличный инструмент коммуникации, который руководитель проекта должен уметь использовать во благо этого проекта.
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Этап подготовки проекта в теории
В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки. Это должно быть интересно как новичкам в таком непростом деле, как менеджмент проектов, так и начинающим стартаперам, и возможно, опытным менеджерам.
Что же такое проект?
Проект – одноразовая, неповторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.
В определенном смысле все проекты одинаковы. У всех есть потребитель (и) и \ или покровитель (и), которые ждут от реализации проекта достижения в определенное время результатов. Проекты часто реализуются с целью создания чего-то нового или осуществления больших изменений, которые можно рассматривать как завершенный вид деятельности. Проект может возникнуть исходя из новых запросов потребителей или пользователей услуг, либо из возможности получить выгоды для организации, либо на основании новых потребностей организации.
Не существует единственно «правильного» способа управления проектом. Традиционные подходы к управлению проектами сфокусированы на технических аспектах, и влиянию людей на реализацию проекта нередко уделяется меньше внимания. Однако именно люди заказывают и поддерживают проекты, поэтому лидерство, мотивация и управление вовлеченными в проект людьми так же важны, как и использование подходящих методов планирования, контроля и мониторинга.
Часто встречающиеся недостатки в реализации проектов:
На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):
Определение границ проекта
Проект начинается с идеи и возникает с целью удовлетворения потребностей человека. Идея состоит в том, чтобы сделать что-то, что кажется необходимым. Преобразование идеи в проект начинается с понимания природы потребности как движущей силы. Поэтому потребности являются основной движущей силой проекта.
Проблемы недостаточно точного определения потребностей:
Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:
ЗС и их потребности
В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:
После того, как установлены основные ЗС, эту информацию необходимо использовать для того, чтобы обеспечить проекту максимально возможную поддержку. Обязательно нужно проверить, как реагируют на проект люди до того, как в процессе планирования будут исключены другие варианты его реализации. Если эту возможность использовать в полной мере, то команда проекта узнает о многих потенциальных препятствиях и будет хорошо информирована о приоритетах каждой группы. Один из способов понять реакции разных ЗС является анализ их точек зрения на каждое из ключевых измерений проекта – бюджет, время и качество.
Определение предназначения и целей проекта
Предназначение проекта является широким понятием и может быть соотнесено с миссией и ценностями организации, тогда как цели проекта определяют более точно, чего стремятся достичь, реализуя проект, и каким образом можно определить его успех.
Цели должны соответствовать критериям SMART:
Поставленные цели дают возможность определить шаги, с помощью которых может быть реализовано предназначение проекта и не позволить сбиться с правильного пути; использоваться для того, чтобы убедиться, что проект хорошо вписывается в деятельность организации.
Ясность целей важна для понимания того, что должно быть сделано. Если поставлены четкие цели, то это значит, что имеется определенная система взглядов на конечный результат. На основании поставленных целей происходит структурирование проекта с тем, чтобы его можно было эффективно контролировать и управлять им. Однако иногда возникает необходимость в пересмотре целей, поскольку в процессе осуществления проекта могут возникнуть новые обстоятельства, неизвестные на стадии планирования. Поэтому цели не должны быть «каменными».
Возможности и угрозы
Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.
Проверка осуществимости проекта
Затраты и выгоды для оценки проекта
Риски и ситуационное планирование
Существует несколько способов выявления риска. Это в первую очередь обсуждение проекта с ЗС и рассмотрение различных перспектив, в ходе которых отдельные ЗС могут увидеть угрозы их интересам. Очень важно оценивать риск на каждом этапе реализации проекта и планировать возможные способы уменьшения его влияний. Там, где риск можно предвидеть, необходимо разработать ситуационный план, который можно применить, если ситуация риска реализуется.
Оценка риска и анализ влияния: ключевые вопросы
Основание для действий по проекту
Управление интеграцией проекта. Управление содержанием проекта
Устав проекта
Устав проекта ( Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос «Какую конкретную работу нужно выполнить для достижения поставленных целей?» или «Какие задачи необходимо решить для достижения поставленных целей?». Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Требования к бизнес-процессам должны включать: