4. Первичные документы по созданию проекта

Привет, сегодня поговорим про документы по созданию проекта, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое документы по созданию проекта , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

4.1. Разработка устава проекта

Устав проекта - это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.

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

• стратегические и тактические цели организации-заказчика;
• формулировка требований организации-заказчика;
• ТЭО;
• контракт;
• внутрикорпоративная методология управления проектами и соответствующие политики.

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

В табл. 4.1 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

Таблица 4.1. Требования к уставу проекта

№	Раздел	Пояснения
1.	Название проекта	Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
2.	Бизнес-причинавозникновенияпроекта	Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
3.	Бизнес-цель	Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел "Формирование бизнес-цели проекта "
4.	Требования,удовлетворяющиепотребности,пожелания и ожиданиязаказчика,спонсора и другихучастниковпроекта	Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
5.	Расписание основных контрольных событий	На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств [18]
6.	Участники проекта	Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел "Идентификация участников проекта"
7.	Окружение проекта	Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов,действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения) [20]
8.	Допущения относительно организации и окружения, а также внешние допущения	Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений: o компетенции команды проекта достаточно для выполнения предпроектного обследования; o организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта. Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе
9.	Ограничения относительно организации и окружения, а также внешние ограничения	Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ [11]. Пример ограничений проекта: увеличение стоимости проекта не более чем на 10%; не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте. Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом
10.	Объем денежных средств, выделенных на достижение бизнес-цели	На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% [18]
11.	Назначение руководителей проекта и общееопределение полномочий ключевых членов проектнойкоманды: РП, спонсор, координатор	Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [8,18]. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект2. Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. Об этом говорит сайт https://intellect.icu . На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: утверждать бизнес-цели проекта , включая расписания и бюджет, и вносимые в них изменения; назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; принимать решения о внесении изменений в базовую линию проекта. Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [8,18]. Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. сбор статуса - словосочетание, не несущее смысла, если только это не специфический термин. Я прошу обратить на него внимание. М/б, сбора информации о текущем статусе? Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта [18]

Таблица 4.2. Шаблон листа управления документом

Авторы
Файл
Дата создания
Дата последнего редактирования
Количество страниц
Версия	Дата изменения	Краткое описание изменения	Автор изменения	Подпись
01
02
Согласование документа
Замечания
№	Дата поступления	Наименование документа	Автор замечания	Подпись
1.
2.
Обработка замечаний
№	Дата обработки	Версия документа, учитывающая замечание	Исполнитель	Подпись
1.
2.

Рис. 4.1. Модель комплексного анализа участников и окружения проекта (Burnett, 1980). На рисунке ИКС - исследовательская команда спонсора

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

• информация в уставе, а также сделанные в нем допущения соответствуют исходным данным, которые содержатся в стратегических и тактических целях организации-заказчика, задокументированных предварительных требованиях организации-заказчика, ТЭО, контракте и внутрикорпоративных политиках и методологиях;
• все разделы предложенного формата устава проекта заполнены в соответствии с рекомендациями;
• в самом документе отсутствуют противоречия;
• список рассылки устава проекта включает все функциональные группы, сотрудники которых должны войти в проектную команду, а в идеале - и всех участников проекта внутри организации-заказчика.

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

4.2. Идентификация и анализ участников проекта

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

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

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

Рис. 4.2. Пример карты участников проекта (адаптировано из )

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

2. Необходимо выявить всех участников проекта, и в этом аспекте построение красивых и однозначных схем является вторичным по отношению к значимости формирования исчерпывающего списка.

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

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

Для анализа воздействия участников на проект рекомендуется использовать шаблон, приведенный в табл. 4.3.

Таблица 4.3. Анализ воздействия участников проекта (адаптировано из )

Анализ воздействия производится в разрезе двух аспектов.

1. Степень организационного влияния участника проекта

Степень участия заинтересованной стороны проекта в принятии стратегически важных для компании решений, ее влияние на реализацию различных инициатив. Крайне важно при подобном анализе не упустить из рассмотрения и неформальных лидеров организации.

2. Воздействие участников на реализуемый ИТ-проект

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

Иногда результаты данного анализа могут быть довольно неожиданными: агенты изменений из отделов, "отдаленных" от проекта, требуют гораздо большего внимания, чем сотрудники отдела, реализующего проект, которые оказались в нижнем левом углу. Данный анализ позволяет правильно расставить приоритеты и интенсивность использования типично ограниченных ресурсов, в том числе на реализацию стратегию коммуникаций.

Если анализ воздействия участников позволяет приоритизировать использование ограниченных ресурсов проекта, то оценка вовлеченности позволяет определить степень сопротивления различных участников проекта, которое характеризуется в разрезе двух аспектов .

1. Доверие

Насколько спонсор(ы) и прочие ключевые участники готовы участвовать в проекте и работать с командой до получения итогового результата, насколько можно рассчитывать на их поддержку в критический момент на проекте?

2. Согласие

Получилось ли достичь согласия с этим конкретным участником (группой участников проекта)? Разделяют ли они точку зрения руководителя проекта?

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

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

1. Союзники

Поддерживают имеющиеся ожидания по проекту, в основном разделяют видение и, скорее всего, заинтересованы в результатах.

2. Конкуренты

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

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

3. Партнеры

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

4. Противники

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

На крупных проектах рекомендуется создавать базу данных участников проекта, в которой будет храниться информация о сотрудниках, способных, так или иначе, оказать влияние на результаты реализации проекта. Хранимая информация включает в себя:

• ФИО и контактную информацию сотрудника;
• сведения об организационной единице, в которой работает сотрудник;
• определение функциональной роли сотрудника;
• категорию получаемых сообщений и их историю.

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

4.3. Формирование требований проекта

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

Организация и проведение результативного интервью

1. Подготовка

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

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

o "Большая картинка"

• Место (под)процесса в сквозном процессе
• Интерфейс с предшествующим процессом
• Интерфейс с последующим процессом

o Описание процесса

• Что? (типовой результат и его потребитель)
• Как? (последовательность шагов и показатели эффективности)
• Кто? (роли и присущая им квалификация)
• Чем? (используемые средства, инструменты, расходуемые ресурсы)

o Документы

• Входящие документы
• Исходящие документы
• Регламентирующие документы

2. Проведение

Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Учитывая весьма ограниченное время, необходимо всегда приходить в указанный час, заранее продумать маршруты пути к месту встречи. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой последовательности, чтобы обеспечить порядок проведения переговоров и удобство при дальнейшем формировании протокола интервью.

Рис. 4.2. Принцип структурирования информации о бизнес-процессе

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

Дальнейшие действия

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

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

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

Определены ли факторы ценности для заказчика?

Усвоила ли команда проекта эти факторы?

Были ли факторы ценности интегрированы в процессы и проектные продукты?

Инструментом, который позволяет обеспечить положительные ответы на эти вопросы, является функция качества или "дом качества", речь о котором пойдет ниже, в разделе, посвященном формированию требований проекта.

Таблица 4.4. Шаблон протокола интервью

Использование функции качества

Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.

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

На рис. 4.3 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.

1. Подготовка требований заказчика

Рис. 4.3. Схема и рекомендации по проведению интервью

Требования заказчика - важнейшая информация при построении "дома качества". Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях был выявлен в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества 10-ю требованиями заказчика, в противном случае использование инструмента становится громоздким.

2. Определение требований проекта

Рис. 4.4. Функция качества проекта ("домик" качества)

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

3. Формирование матрицы взаимосвязей

На этом этапе происходит проверка отсутствия взаимных противоречий между сформулированными требованиями проекта, иными словами, происходит их попарное сравнение. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи часто используют o, а для показа отрицательной - o. Идентифицированные отношения демонстрируют столкновение требований и возможность нахождения компромисса между ними, что позволяет увидеть условия проекта в совокупности, а не по отдельности.

4. Формирование матрицы отношений

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

5. Субъективная оценка через сравнительный анализ

На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.

6. Объективная оценка через установку конечных целей

Для обеспечения измерения и последующего контроля реализации требований проекта (а через них - и обеспечения требований заказчика) необходимо задать измеримые конечные цели по каждому требованию проекта, тем самым обеспечив объективную основу для управления ими.

Вау!! 😲 Ты еще не читал? Это зря!

• техническое задание , спецификация задания ,
• 7.6. Документация программного продукта
  
• эвристические методы , мозговая атака ,
• индуктивности поверхностного монтажа smd индуктивность ,
• анализ требований , виды требований ,

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

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.