Назначение процесса планирования ПО состоит в том, чтобы определить методы создания такого ПО, которое позволит реализовать системные требования и обеспечить уровень качества, соответствующий требованиям настоящего стандарта. Таблица А.1 содержит резюме целей и результатов процесса планирования ПО в зависимости от уровня ПО.
Цели процесса планирования ПО:
а) определить конкретные виды работ процессов разработки и интегральных процессов жизненного цикла, которые позволят реализовать системные требования и создать ПО требуемого уровня (6.2);
б) определить модели жизненного цикла ПО, включающие в себя описание взаимосвязей между процессами, последовательность их выполнения, механизмы обратной связи и критерии перехода (4.1);
в) выбрать среду поддержки жизненного цикла, включающую в себя методы и инструментальные средства, которые нужно использовать для выполнения работ в каждом процессе жизненного цикла (6.4);
г) в случае необходимости рассмотреть дополнительные аспекты разработки, обсуждаемые в разделе 13;
С чего начать разработку проекта? — Вопросы и Ответы #10
д) определить стандарты разработки, позволяющие обеспечить требования по безопасности системы в части разрабатываемого ПО (6.5);
е) разработать документы процесса планирования ПО в соответствии с 6.3 и разделом 12;
ж) координировать разработку и изменение планов ПО (6.3).
6.2 Состав работ, выполняемых в процессе планирования ПО
В процессе планирования ПО должны быть выполнены следующие работы:
— разработка планов создания ПО и передача их исполнителям, осуществляющим процессы разработки и интегральные процессы (см. требования 11.1);
— определение и выбор стандартов разработки ПО, которые будут использованы для данного проекта;
— выбор методов и инструментальных средств, которые позволят в процессах разработки предотвратить внесение ошибок в ПО;
— обеспечение координации между планами разработки ПО и планами интегральных процессов для получения согласованных стратегий выполнения различных процессов жизненного цикла;
— определение процедуры пересмотра и уточнение планов по мере развития проекта;
— выбор методов и инструментальных средств, позволяющих предотвратить и обнаружить ошибки и обеспечивающих безопасность системы в случае использования многоверсионного неидентичного ПО;
— если предполагается использование отключенного кода (7.4.3), то в процессе планирования должно быть описано, как отключенный код будет определен, верифицирован и обработан для обеспечения требований безопасности системы;
— если предполагается использовать модифицируемый пользователем код, то в стандартах и планах ПО в соответствии с требованиями 7.2.3 должны быть указаны используемые инструментальные средства и элементы данных;
— процесс планирования считают завершенным, если были выполнены контроль изменений и просмотры для всех планов ПО и стандартов разработки ПО (6.7).
До завершения процесса планирования могут быть инициированы другие процессы жизненного цикла ПО, если разработаны планы и стандарты для этих процессов.
Как устроен процесс разработки? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains
6.3 Типы планов ПО
Цель создания планов ПО состоит в том, чтобы определить средства для удовлетворения требованиям настоящего стандарта, в том числе определить организационные подразделения, которые будут выполнять эти работы. В процессе планирования должны быть разработаны следующие типы планов ПО:
— План сертификации в части ПО (12.1) служит основным средством для согласования предложенных методов разработки с сертифицирующей организацией и определяет средства для выполнения требований данного документа;
— План разработки ПО (12.2) определяет используемые модели жизненного цикла ПО и среду разработки ПО;
— План верификации ПО (12.3) определяет средства, с помощью которых будут удовлетворены цели процесса верификации ПО;
— План квалификационного тестирования ПО (12.4) определяет порядок выполнения квалификационного тестирования ПО;
— План управления конфигурацией ПО (12.5) определяет средства, с помощью которых будут удовлетворены цели процесса управления конфигурацией ПО;
— План обеспечения качества ПО (12.6) определяет средства, с помощью которых будут удовлетворены цели процесса обеспечения качества ПО;
— План установки ПО (12.7) определяет действия по установке разработанного ПО на рабочих местах пользователей, включая подготовку и обучение персонала и адаптацию существующих систем;
— План передачи ПО (12.8) определяет аппаратное обеспечение и ПО, а также другие ресурсы, необходимые для поддержки жизненного цикла передаваемого ПО, и описывает планы разработчиков для поставки передаваемых элементов через организации, осуществляющие поддержку.
Планы ПО должны соответствовать требованиям настоящего стандарта, устанавливать процедуры, используемые для реализации требуемых изменений в ПО до его применения на сертифицируемом объекте. Такие изменения могут быть результатом обратной связи от других процессов и могут, в свою очередь, вызывать изменение планов ПО. Планы ПО должны определять критерии переходов между процессами жизненного цикла ПО путем указания:
— входных данных для процесса, включая обратную связь от других процессов;
— действий интегральных процессов, которые могут потребоваться для обработки этих входных данных;
— необходимых инструментальных средств, методов, стандартов и процедур.
6.4 Планирование среды жизненного цикла ПО
Цель планирования среды жизненного цикла ПО состоит в определении методов, инструментальных средств, процедур, языков программирования и аппаратных средств, которые будут использованы для выполнения процессов жизненного цикла ПО и подготовки документов жизненного цикла ПО (раздел 12). Основными элементами среды жизненного цикла ПО являются среда разработки ПО и среда верификации ПО.
6.4.1 Среда разработки ПО
Среда разработки — важный фактор создания ПО высокого качества. Разработчик должен установить, контролировать и сопровождать среду разработки ПО. Разработчик должен гарантировать, что каждый элемент среды корректно выполняет предназначенные функции. Основные принципы выбора методов и инструментальных средств среды разработки ПО следующие:
— в процессе планирования ПО должна быть выбрана такая среда программирования, которая минимизирует потенциальный риск применения конечного программного средства;
— использование аттестованных инструментальных средств или комбинаций инструментальных средств и частей среды разработки ПО должно обеспечивать уверенность в том, что ошибка, внесенная одной частью, будет обнаружена другой. Среда разработки ПО считается приемлемой, если такие части используются согласованно;
— при определении работ процесса верификации ПО или стандартов разработки ПО необходимо учитывать уровень ПО для того, чтобы минимизировать число потенциальных ошибок, связанных со средой программирования;
— если сертификационное доверие к использованию определенной комбинации инструментальных средств достаточно высокое, то применение этих инструментальных средств должно быть определено в соответствующем плане;
— если дополнительные возможности (опции) инструментальных средств разработки ПО выбраны для использования в проекте, то эффект их применения должен быть рассмотрен и определен в соответствующем плане.
6.4.2 Язык программирования и компилятор
В процессе планирования ПО должна быть оценена допустимость использования конкретного языка программирования и компилятора. Необходимо учитывать следующее:
— некоторые компиляторы имеют возможности оптимизировать эффективность объектного кода. Если тестовые варианты дают покрытие, требуемое в соответствии с уровнем ПО, правильность оптимизации не нуждается в проверке, в противном случае воздействие этих возможностей на структурное покрытие должно быть определено в соответствии с требованиями 8.4.4;
— для реализации определенных возможностей компиляторы для некоторых языков могут производить объектный код, который не является непосредственно трассируемым к исходному тексту, например инициализация, встроенное обнаружение ошибок или обработка исключительных ситуаций (8.4.4.2, перечисление б); процесс планирования ПО должен определить в соответствующем плане средства, обнаруживающие этот объектный код, и гарантировать его тестовое покрытие;
— если в течение жизненного цикла ПО вводится новая версия компилятора, редактора связей или загрузчика или изменены опции компилятора, результаты предыдущих тестов и анализ покрытия больше не могут быть рассмотрены как адекватные. Планирование верификации должно предусматривать средства повторной верификации в соответствии с требованиями раздела 8.
6.4.3 Среда верификации ПО
Цель планирования среды верификации ПО состоит в том, чтобы определить методы, инструментальные средства, процедуры и аппаратные средства, которые будут использованы, чтобы проверить выходные результаты процессов разработки. Разработчик должен установить, контролировать и сопровождать среду верификации ПО. Разработчик должен гарантировать, что каждый элемент среды корректно выполняет предназначенные функции. Верификационное тестирование может быть выполнено на объектном компьютере, эмуляторе объектного компьютера или с использованием моделирования на инструментальном компьютере (интерпретатора). Основные требования следующие:
— эмулятор или интерпретатор в некоторых случаях требуется аттестовать как описано в 13.2;
— должны быть рассмотрены различия между результатами, полученными на объектном компьютере и эмуляторе или интерпретаторе, и воздействие этих различий на способности обнаруживать ошибки и проверять функциональные возможности; обнаружение тех ошибок, которые остаются невыявленными, необходимо обеспечивать другими процессами верификации ПО, которые должны быть определены в Плане верификации ПО.
6.5 Стандарты разработки ПО
Целью стандартов разработки ПО является определение правил и ограничений для процессов разработки. К стандартам разработки ПО относятся стандарты на требования к ПО, проектирование и кодирование ПО. Процесс верификации ПО использует эти стандарты для оценки соответствия фактических выходных данных некоторого процесса ожидаемым результатам. Стандарты разработки ПО должны:
— удовлетворять требованиям раздела 11;
— обеспечивать единообразие разработки компонентов ПО данного программного продукта или необходимого набора средств;
— исключать использование конструкций или методов, результаты которых не могут быть верифицированы или несовместимы с требованиями безопасности.
6.6 Ответственность за выполнение планирования
Разработчик должен осуществлять планирование проекта и надзор за его выполнением в соответствии со следующими требованиями. Если систему или ЭКПО разрабатывают для нескольких различных построений, планирование для каждого построения должно предусматривать:
— полное планирование для контракта;
— детализированное планирование для текущего построения;
— планирование будущих построений, предусмотренных контрактом, с уровнем детализации, соответствующим доступной на данный момент информации.
Разработчик должен создать официальный документ, планирующий проведение работ в соответствии с требованиями настоящего стандарта и требованиями контракта, связанными с ПО. Планирование должно быть выполнено в соответствии с уровнем системы и завершено включением всей требуемой информации в документы планирования.
1 Эта формулировка здесь и далее в настоящем стандарте предназначена для того, чтобы:
— подчеркнуть, что создание и регистрация информации о планировании и технологии разработки ― существенная часть процесса разработки ПО — должны быть выполнены независимо от требовании к поставляемому средству;
— использовать документ как контрольный список построений, которые покрываются действиями разработки или планирования;
— допустить для регистрации представления информацию, отличную от традиционных документов (например, автоматизированные инструментальные средства проектирования ПО).
2 Если контракт предусматривает передачу информации в соответствии с настоящим стандартом, в обязанности разработчика входит форматирование, сбор, маркировка, копирование и рассылка поставляемых документов, что требует дополнительного времени и усилий со стороны разработчика.
3 План разработки ПО может покрывать все виды работ, требуемых настоящим стандартом, и включать в себя описание планирования интегральных процессов, если контрактом не предусмотрены отдельные документы планирования для этих процессов.
Разработчик должен участвовать в разработке и регистрации планов проведения квалификационного тестирования системы, результаты должны быть включены в документ «План квалификационного тестирования ПО».
Разработчик должен создать и зарегистрировать план выполнения установки ПО и обучения пользователей, определенный в контракте, результаты должны быть включены в документ «План установки ПО».
Разработчик должен идентифицировать все ресурсы разработки ПО, которые будут необходимы для реализации концепции поддержки организации, осуществляющей поддержку. Разработчик должен создать и зарегистрировать планы, идентифицирующие эти ресурсы, и описать действия, необходимые при передаче поставляемых элементов агентству поддержки. Результаты данного планирования должны быть включены в документ «План передачи ПО».
После утверждения заказчиком любого из планов, указанных в данном подразделе, разработчик должен выполнить релевантные действия в соответствии с планами. Руководство разработчика и Служба обеспечения качества ПО должны осуществлять аудит процесса разработки ПО в интервалах, определенных в Плане разработки ПО, для гарантии того, что процесс будет выполнен в соответствии с контрактом и утвержденными планами. За исключением внутреннего планирования разработчика и информации, связанной с укомплектованием персонала, любая модификация планов должна быть одобрена заказчиком.
6.7 Просмотр результатов процесса планирования ПО
Просмотры результатов процесса планирования ПО проводят для гарантии того, что планы ПО и стандарты разработки ПО соответствуют требованиям настоящего стандарта и обеспечивают согласованное выполнение процессов жизненного цикла ПО.
Источник: www.tinlib.ru
План действий (Action Plan): 6 шагов внедрения
План действий (Action plan) в менеджменте — это инструмент планирования и контроля за выполнением планов.
В отделе продаж план действий должен применяться ежедневно — руководителем отдела для контроля за разного типа работами менеджеров; менеджерами для самоконтроля реализации мини-проектов помимо ежедневных стандартных обязанностей по работе с клиентами.
Узнайте, как применять простую таблицу плана действий для того, чтобы ваш отдел продаж шел планомерно к намеченной цели.
- План действий (Action plan): что это такое
- План действий (Action plan): в чем польза для РОПа
- План действий (Action plan): требования
- План действий (Action plan): пример
- План действий (Action plan): развитие клиента
- План действий (Action plan): 6 шагов внедрения
ПЛАН ДЕЙСТВИЙ (ACTION PLAN): ЧТО ЭТО ТАКОЕ
Что такое план действий (Action plan)?
Это обязательный элемент стратегического планирования и регулярного менеджмента. Экшн план может применяется в управлении отделами, подразделениями и проектами. А может контролировать регулярные действия по отношению к тому или иному сегменту клиентов или к тому или иному сотруднику.
План действий — обязательный элемент для того, чтобы добиться стабильного роста продаж. Любой рост — это внедрение каких-то стратегических улучшений в отделе. И эти улучшения всегда являются микро-проектами. Их приходится делать помимо стандартных обязанностей.
План действий описывает шаги или мероприятия, которые должны быть выполнены, чтобы вы смогли достичь цели.
План действий может формироваться локально, на каждую неделю, с корректировкой выполнения задач за предыдущую неделю. Разработка плана действий на следующую неделю осуществляется в пятницу.
А может быть частью глобального стратегического планирования. Цель такого плана действий — долгосрочная. И в этом случае вы формируете план действий после того, как сделали SWOT анализ, выбрали стратегию развития и сформулировали SMART цель.
Почему важно составлять план действий?
Без четких планов действий управление продажами неэффективно. Как и управление любой другой деятельностью в компании.
Однако очень часто составление плана действий часто воспринимается как утомительная процедура по сравнению с ранними этапами стратегического планирования (SWOT-анализ и SMART цель).
Поэтому часто Action plan игнорируется.
Как результат работа на этапах анализа и формирования целей оказывается бесполезной, хотя на нее потрачено силы и время. SMART цель остается на бумаге в виде «воздушного замка». Четкого плана действий по шагам не разработан и не контролируется.
Значит нет продвижения вперед.
Привычка составлять план действий в управлении продажами и в целом организацией подтверждает, что а) компания действительно совершает определенные действия для достижения цели и б) использует многочисленные методы проверки и оценки масштаба реализации плана действий.
План действий (Action plan) в управлении продажами обычно бывает двух видов:
- план действий по стратегическому развитию отдела продаж;***
- план действий по развитию клиентов.
Без плана действий (Action plan) развитие и управление продажами в компании невозможно
ПЛАН ДЕЙСТВИЙ (ACTION PLAN): В ЧЕМ ПОЛЬЗА ДЛЯ РОПА
Если у вас сложные продажи и ваш цикл сделки превышает 2 недели, таких инструментов управления как контроль отчетности в CRM и планерки, будет недостаточно.
Особенно на стадии Account management процесса продажи при развитии ключевых клиентов продавцу нужен четкий план действий: что и когда он будет делать именно с этим клиентом для того, чтобы подвести его к сделке.
В продажах есть проектная работа: например привлечение клиентов на выставке или конференции, различного рода networking. С помощью какого инструмента менеджмента вы будете контролировать подготовку мероприятия и обработку результатов?
Если вы внедряете стратегические изменения в вашем отделе продаж, у РОПа обычно в разработке от 5 до 10 проектов: от подбора кадров до внедрения или оптимизации CRM. Как вы проконтролируете работу РОПа по усилению системы продаж?
В чем польза Action plan для руководителя?
План действий (Action plan) — это обязательный элемент ежедневного управления отделом
1. План действий структурирует рабочий день: action plan это ежедневная шпаргалка, которая наглядно демонстрирует как шаг за шагом реализуется цели одного или нескольких отделов или менеджеров;///
2. План действий является инструментом тайм менеджмента : управляет вашим временем и помогает существенно снизить временные затраты на тот или иной проект или активности.///
3. План действий существенно сокращает цикл PDCA: за счет снижения временных издержек вы быстрее проходите цикл, внедряете изменения и достигаете целей.
План действий (Action plan) в обоих случаях является обязательным элементом ежедневного управления отделом.
План действий — это четкая дорожная карта вашего дня.
План действий поддерживает ваш тонус и эффективность. Он назначает вам временные рамки для каждого отдельного шага процесса.
Вы отслеживаете прогресс, сохраняя проекты в соответствии с графиком и бюджетом.
ПЛАН ДЕЙСТВИЙ (ACTION PLAN): ТРЕБОВАНИЯ
План действий должен содержать следующую информацию:
- Какое действие следует сделать;***
- Кто будет выполнять это действие;***
- Когда оно состоятся и как долго продлится;***
- Какие ресурсы (персонал, деньги, другое) необходимы для осуществления этого действия;***
- Какая коммуникация должна происходить между участниками плана (кто должен знать и что?)
Ваш план действий должен отвечать следующим требованиям:
- Быть исчерпывающим***План действий должен содержать все необходимые действия для реализации той или иной задачи.
- Быть понятным***План действий должен быть понятно изложен и быть доступным в изложении для менеджеров.
- Быть релевантным***План действий должен отражать текущую работу над задачей, использовать все новые возможности и решать все появляющиеся проблемы.
ПЛАН ДЕЙСТВИЙ (ACTION PLAN): ПРИМЕР
Многие CRM-системы сегодня позволяют вести контроль за реализацией задач, проектов и планов. В случае, если ваша CRM-система не имеет такого функционала, используйте таблицу Excel.
Разработка плана действий в «электронно-бумажного» виде — это первый шаг. После того, как он будет освоен, переносите шаблон в CRM.
Важно: бумажная версия плана действий стимулирует общаться с подчиненными лично. Автоматизированный план действий в CRM хуже мотивируют сотрудников на решение задач чем распечатанная таблица плана действий в Excel и личное совещание с Руководителем.
ПЛАН ДЕЙСТВИЙ ДЛЯ УПРАВЛЕНИЯ ОТДЕЛОМ ПРОДАЖ
План действий (Action plan) для управления отделом продаж в табличной форме:
ПЛАН ДЕЙСТВИЙ (ACTION PLAN): РАЗВИТИЕ КЛИЕНТА
План действий по развитию клиентов мы используем в своих проектах по развитию отделов продаж. План формирует мероприятия по следующим направлениям:
- Определение вероятности долгосрочного сотрудничества***Это этап квалификации клиента. В случае, если клиент сложный и собрать информации для оценки его потенциала не удалось, продавец составляет план действий для сбора нужной информации и оценки потенциального клиента.///
- Формирование стратегии работы с ЛПР, ЛВПР и/или ГПР (группа принятия решения)***На сложных рынках решение о покупке принимает не один сотрудник. Продавец должен оценить приоритеты в системе управления клиента, цели и задачи, стратегию бизнеса и прочие факторы для того, чтобы сформулировать ценностное предложение клиенту.///
- Утепление клиента***Действия по утеплению клиента: какие встречи и с кем из ГПР необходимо провести? Командировки, визиты на производство — все это мероприятия, необходимые для подготовки клиента к подписанию договора.///
- Развитие ассортимента***После подписания договора необходимо разработать шаги по стратегии развития клиента с целью увеличения продаж.///
- Развитие ресурсов***Количество требуемых ресурсов для работы особенно с ключевым клиентом может изменяться. С целью долгосрочного планирования и эффективного контроля в план действий необходимо закладывать новые данные по этому разделу.
План действий по развитию и управлению клиентом:
ПЛАН ДЕЙСТВИЙ (ACTION PLAN): 6 ШАГОВ ВНЕДРЕНИЯ
Во многих компаниях даже собственники не умеют применять инструменты регулярного менеджмента. Ниже приводим алгоритм внедрения плана действий.
Используйте его для того, чтобы приучить сотрудников детально отчитываться и самостоятельно контролировать свои действия.
Шаг 1: Сформулируйте или выберите цель. Разработайте список мероприятий, которые на ваш взгляд должны быть сделаны для реализации цели.
Шаг 2: Поставьте менеджерам сформулировать по каждой задаче:
- Список мероприятий, необходимых для выполнения;***
- Период, необходимый для выполнения и количество часов, требуемых для выполнения;***
- Ресурсы, необходимые для выполнения;***
- Сотрудники других подразделений, участие которых требуется для выполнения.
Шаг 3: Согласуйте список мероприятий, задачи и все параметры по ним с исполнителем.
Шаг 4: Назначьте дату промежуточной проверки по выполнению задач и корректировке.
Шаг 5: Следуйте принятому расписанию промежуточной проверки выполнения задач, их корректировки и окончательной приемки.
Шаг 6: Помечайте выполненные задачи как выполненные. Закрывайте то, что сделано.
Шаг 7: Обсуждайте отложенные или просроченные задачи. Анализируйте, почему возникли препятствия или причины, по которым некоторые задачи не выполняются. Иногда они нуждаются в дополнительном сопровождении с вашей стороны или от другого сотрудника.
Используйте план действий (Action plan) для регулярного управления отделом продаж.
Оцените эффективность вашей системы продаж
Скачайте чек-лист и за 20 минут оцените эффективность вашей системы продаж
Источник: activesalesgroup.ru
Составы ключевых этапов проекта
Проникая в тонкости сокровенного знания о проектной практике, начинающий профессионал-PM или человек, готовящий себя стать проект-менеджером, должен свободно ориентироваться в основном терминологическом аппарате этого рода деятельности. Часто приходится слышать вопрос о том, как грамотно сформулировать этапы выполнения проекта. Действительно, это задача сложная. Но давайте сначала задумаемся, а принято ли в профессиональной среде оперировать понятием этапов? И в каких случаях это не только возможно, но и необходимо делать?
Определение понятий
Те из нас, кто имеет определенный опыт управления проектами или хотя-бы небольшой теоретический задел, знакомы с рядом явлений, которые менеджер использует, чтобы представить жизненный цикл инвестиционной задачи и спланировать ее решение. Список этих категорий на первый взгляд прост, в его составе:
- фаза жизненного цикла;
- веха;
- стадия;
- этап;
- процесс управления.
Предложенные понятия в практике часто используют как синонимы. И если поискать в источниках, то есть вероятность обнаружить, что и словари «грешат» круговыми определениями данных философско-прикладных категорий. Можно заметить и в научной литературе, что «фаза – это стадия», «стадия – это этап» и даже веха определяется как некий этап пути. Как же быть, ведь нам нужно оперировать точным восприятием явлений?
Я предлагаю выполнить процедуру, которую мы уже однажды делали с категориями проектных задач, целей и проблем. Усилим здравое разумение и посмотрим на представленные выше понятия с позиции обычного эмпирического опыта.
Ниже показана таблица, в столбиках которой проставлены исследуемые категории, а в табличной части мы будем помещать определения, образы, примеры, которые соответствуют им. Начнем с понятия «фаза». В чем состоит суть данного понятия? Чем его можно охарактеризовать, какими отличительными качествами?
Состав отличительных качеств базовых понятий проектирования
Фазам проектной реализации посвящена статья на тему жизненного цикла проектной задачи. Эмпирически больше всего я воспринимаю фазу как длящееся и выраженное состояние выполнения проекта, например, фаза разработки или фаза завершения. Этих положений у проектной задачи несколько, и они всегда повторяются, хотим мы этого или нет. Принципов разбиения проекта на фазы может быть несколько, но подход к их формулированию един – с позиции длящегося состояния.
Вариант разбиения проекта на фазы с позиции перехода ответственности от PM
Вариант разбиения проекта на фазы с позиции ЖЦ проекта
Выше в качестве иллюстрации приведен пример двух схем фазовой разбивки проекта. С точки зрения ЖЦ фазы проекта венчают вехи – важные, значимые события его реализации. По временной шкале они представляют собой событийные точки. Фазы проекта делятся на стадии – восходящие периоды развития, отделяющие собой качественные состояния фазы. Например, стадия принятия решения о старте проекта или стадия формирования проектной команды. Более динамической категорией, чем фазы и стадии, являются процессы управления, имеющие следующие черты:
- представляют собой последовательность работ;
- связаны с управлением, основаны на регламентирующей базе;
- могут относиться к проекту в целом или к отдельной его фазе.
Этапы же являются частями процессов управления, включающих в себя однородные по сути составы работ. Таким образом, этап – это динамическая категория, которая может повторяться на каждой фазе проекта. Например, этап анализа. В небольших проектах этапы, фазы и стадии действительно сливаются в синонимы. В крупных мероприятиях этапы наиболее выражены в процессах инициации, завершения, планирования и организации исполнения.