Процесс создания документа состоит из следующих стадий проект согласование

Обновлено: 16.05.2024

Единая система программной документации

Unified system for program documentation. Development stages

Дата введения 1980-01-01

Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. N 1268 дата введения установлена 01.01.80

ПЕРЕИЗДАНИЕ. Январь 2010 г.

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

2. Стадии разработки, этапы и содержание работ должны соответствовать указанным в таблице.

1. Техническое задание

Обоснование необходимости разработки программы

Сбор исходных материалов.

Выбор и обоснование критериев эффективности и качества разрабатываемой программы.

Обоснование необходимости проведения научно-исследовательских работ

Определение структуры входных и выходных данных.

Предварительный выбор методов решения задач.

Обоснование целесообразности применения ранее разработанных программ.

Определение требований к техническим средствам.

Обоснование принципиальной возможности решения поставленной задачи

Разработка и утверждение технического задания

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

Разработка технико-экономического обоснования разработки программы.

Определение стадий, этапов и сроков разработки программы и документации на нее.

Выбор языков программирования.

Определение необходимости проведения научно-исследовательских работ на последующих стадиях.

Согласование и утверждение технического задания

2. Эскизный проект

Разработка эскизного проекта

Предварительная разработка структуры входных и выходных данных.

Уточнение методов решения задачи.

Разработка общего описания алгоритма решения задачи.

Разработка технико-экономического обоснования

Утверждение эскизного проекта

Разработка пояснительной записки.

Согласование и утверждение эскизного проекта

3. Технический проект

Разработка технического проекта

Уточнение структуры входных и выходных данных.

Разработка алгоритма решения задачи.

Определение формы представления входных и выходных данных.

Определение семантики и синтаксиса языка.

Разработка структуры программы.

Окончательное определение конфигурации технических средств

Утверждение технического проекта

Разработка плана мероприятий по разработке и внедрению программ.

Разработка пояснительной записки.

Согласование и утверждение технического проекта

4. Рабочий проект

Программирование и отладка программы.

Разработка программной документации

Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

Разработка, согласование и утверждение программы и методики испытаний.

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

Корректировка программы и программной документации по результатам испытаний

Подготовка и передача программы

Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.

Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.

Передача программы в фонд алгоритмов и программ

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

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

Если одобренные запросы на изменение являются результатом создания ИСР , то в описание содержания проекта включаются эти одобренные изменения.

Иерархическая структура работ

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

Словарь ИСР

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

Базовый план по содержанию

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

План управления содержанием проекта (обновления)

Если одобренные запросы на изменения являются результатом создания ИСР , то одобренные изменения могу быть включены в план управления содержанием проекта.

Запрошенные изменения

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

Подтверждение содержания

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

описание содержания проекта;
словарь ИСР ;
план управления содержанием проекта;
результаты поставки.

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

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

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

Запрошенные изменения. Запрошенные изменения могут появиться в ходе процесса подтверждения содержания и рассматриваются в ходе процесса общего управления изменениями.

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

Управление изменениями содержания

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

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

описание содержания проекта;
иерархическая структура работ ;
словарь ИСР ;
план управления содержанием проекта;
отчеты об исполнении;

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

Одобренный запрос на изменение, оказывающий влияние на содержание проекта, - любое изменение в согласованном базовом плане проекта, ИСР и словаре ИСР .

Инструменты и методы

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

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

Корректировка планов. Одобренные запросы на изменения, оказывающие влияние на содержание проекта, могут повлиять на ИСР и словарь ИСР , описание содержания проекта и план управления содержанием проекта. Эти одобренные запросы на изменения могут потребовать обновления компонентов плана управления проектом .

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

Выходы процесса

Описание содержания проекта (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то описание содержания проекта редактируется, и в новую редакцию включаются эти одобренные изменения. Обновленное описание содержания проекта становится новым базовым планом проекта для будущих изменений.

Иерархическая структура работ (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то ИСР редактируется и в новую редакцию включаются эти одобренные изменения.

Словарь ИСР (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то словарь ИСР редактируется и в новую редакцию включаются эти одобренные изменения.

Базовый план по содержанию (обновления)

Запрошенные изменения. В результате управления содержанием проекта могут появляться запрошенные изменения, обрабатываемые для рассмотрения и распоряжения в соответствии с процессом общего управления изменениями.

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

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

План управления проектом (обновления). Если одобренные запросы на изменения каким-либо образом затрагивают содержание проекта, то создается новая редакция документов и базового плана по стоимости для соответствующего элемента, а также базовых планов по стоимости, входящих в план управления проектом . В новую редакцию включаются эти одобренные изменения.

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

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

Процесс согласования в 1С: Документооборот

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

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

Отличие электронного от бумажного согласования

Сравнение типичной ситуации согласования договора наглядно показывает различие двух способов решения задачи.

Согласование документов вручную

В традиционной бумажной версии процедура выглядит так:

Юрист направляет проект ответственным работникам;
Каждый сотрудник вносит в документ свои правки;
Несколько раз исправленный текст возвращается на доработку;
Новая редакция повторно отправляется на согласование;
Процесс повторяется до принятия единого решения всеми участниками.

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

Электронный вариант согласования документов

В программе 1С: Документооборот согласование договора выглядит следующим образом:

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

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

Порядок согласования документов

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

Настройка модуля согласования документов

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

Администраторы;
Новая группа в профиле с ролью «Согласование (настройка).

Создаются роли для исполнителей, которые будут участвовать в согласовании. Они могут быть записаны как по фамилиям с именами, отчествами так и по должностям. Например, Федоров Иван Николаевич находится в списке пользователей. Его можно выбрать из другого списка по роли Главный бухгалтер.

Виды программной связи документов

Типовой функционал программы 1С: Документооборот способен отслеживать несколько десятков согласований к одному документу. Сложное переплетение взаимоотношений можно автоматизировать. Для этого классифицируют типы связей при обработке документа:

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

Обзор процессов согласования документов

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

Ход согласования документов

По мере движения задачи по указанному маршруту каждому задействованному сотруднику направляются соответствующие команды:

Рассмотрение

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

Согласование

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

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

Детали работы

группы задач по проекту, автору, типу;
персональные, делегированные, ролевые задачи;
сводки по всем задачам, в том числе новым и просроченным.

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

Шаблоны согласований

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

сотрудник создает документ-заявку;
согласует заявку руководитель данного сотрудника;
руководитель ИТ-службы согласует документ;
исполнитель ИТ-службы направляет уведомление автору заявки об ее выполнении.

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

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

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

Контроль процессов

Передача документов внешним корреспондентам и сотрудникам внутри организации учитывается программой. Согласования систематизируются по:

спискам документов;
затраченному времени;
статистике циклов и результатов.

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

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

Анализ и мониторинг согласований документов

Автоматическая служба 1С: Документооборота отслеживает более 100 показателей процессов согласований. Основные из них:

число циклов;
количество просроченных задач;
время просрочки;
средние трудозатраты.

Устанавливается пороговое значение роста или снижения показателей согласования. Программа информирует о достижении нижнего критического значения.

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

Заключение

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

Процессы и стандарты управления

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

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

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

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

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

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

Сухие цифры

Эффективность проектно-ориентированного подхода измеряется в цифрах. Согласно подсчетам IPMA (Международной ассоциации управления проектами), внедрение методологии помогает сократить финансовые расходы на 15–20 % и временны́е — на 20–30 % [1] .

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

PMBOK (Project Management Body of Knowledge) от американского института PMI;
P2M, разработанный японской Ассоциацией управления проектами PMAJ;
ICB от международной ассоциации IPMA;
ISO 21500.

Кроме того, существует российский стандарт ГОСТ Р ИСО 21500-2014 — он является аналогом международного ISO 21500.

В стандартах определена структура управления проектом. Она включает в себя несколько процессов. Согласно PMBOK, это инициация, планирование, организация исполнения, контроль и завершение. Для каждой группы процессов управления проектами разработаны инструменты и методы [2] .

Инициация

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

Планирование

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

Организация

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

Контроль

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

Завершение

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

Методы управления проектами

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

Waterfall

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

Справка

Метод управления проектами Waterfall был разработан еще в 1970 году американцем У. Ройсом и долгие годы служил эталоном для разных отраслей деятельности. Например, компания Toyota использовала водопадный метод до 2000-х годов — до тех пор, пока не разработала собственные подходы к управлению проектами (Lean и Kanban) [3,4] .

Применительно к любой сфере бизнеса можно выделить следующие универсальные этапы реализации каскадной модели:

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

В чем преимущества Waterfall-методологии управления проектами?

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

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

Agile

Agile — гибкое управление проектами — сравнительно новая и очень популярная методология. Это скорее система принципов, ставшая основой для целого ряда методов.

В чем главное отличие методологии управления проектами Agile от Waterfall?

Это лучше всего пояснить на примере разработки ПО. Процесс строится по принципу коротких циклов (итераций), в конце каждого из которых заказчик получает готовый продукт. Точнее, не полностью готовый, но способный решать часть задач — так называемых пользовательских историй. Скорость разработки — примерно четыре–шесть таких историй в неделю [6] . При этом непрерывно происходит автоматическое тестирование кода.

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

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

Scrum

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

Главным инструментом Scrum являются бэклоги — списки приоритетных задач. Перед началом спринта команда разработки совместно с владельцем проекта решает, какие задачи должны быть выполнены в первую очередь (в текущем спринте). Ежедневно проводятся краткие совещания, в ходе которых каждый из разработчиков рассказывает, что сделал вчера, что планирует сделать сегодня, с какими проблемами столкнулся. В результате команда может быстро обнаружить препятствия и при необходимости изменить стратегию. По окончании каждого спринта проводится ретроспективный анализ, цели которого — оценить эффективность работы, сделать прогнозы для последующих итераций, выявить возможные проблемы [7] .

Scrum — один из самых структурированных методов в семействе Agile [8] . И, конечно, он обладает всеми достоинствами гибкой модели, прежде всего адаптивностью и клиентоориентированностью.

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

Проектные инструменты для любого бизнеса

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

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

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

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

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

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

Корпоративные порталы помогают сотрудникам своевременно получать информацию о текущем положении дел в компании и в отделе.

Белоногова Нарцисса Николаевна Ответственный редактор

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

Экономический эффект внедрения BPM-систем для управления бизнес-процессами

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

Правила и принципы

Состав проектной документации объектов капитального строительства определен Градостроительным кодексом Российской Федерации, который предусматривает необходимость разработки не менее 14 разделов. При этом определение состава и требований к содержанию разделов проектной документации отнесено к полномочиям Правительства Российской Федерации.

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

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

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

Министерства и ведомства СССР, органы государственного надзора и общественные организации в соответствии с предоставленными им правами могли разрабатывать нормативные документы по проектированию и инженерным изысканиям, отражающие специфику отдельных отраслей народного хозяйства, отраслей промышленности и видов строительства, и утверждать их по согласованию с Госстроем СССР. Допускалось строительство объектов по иностранным лицензиям на базе комплектного импортного оборудования на основе компенсационных соглашений и контрактов с компаниями других стран. Данный принцип реализуется сейчас в гармонизации и стремлении к взаимному признанию механизмов оценки и подтверждении объектов капитального строительства установленным (или декларируемым) нормам, стандартам и иным аспектам оценки в рамках Евразийского экономического союза (ЕАЭС) и Европейского союза (ЕС).

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

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

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

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

Одним из наиболее острых вопросов, регулярно поднимаемых сообществом проектировщиков, являются избыточные требования к проектной документации. Предъявляемые в настоящее время требования к проектной документации способствуют появлению административных барьеров и увеличению расходов, как временных, так и финансовых, на разработку проектной документации и проведение ее экспертизы. Документация, выполненная с обоснованными отступлениями от действующих норм, правил и инструкций, подлежит согласованию в части этих отступлений с органами государственного надзора и заинтересованными организациями, утвердившими их. Данный принцип в подавляющем большинстве случаев позволял обходиться без разработки и согласования Специальных технических условий (далее – СТУ). В выделенных выше принципах заложена необходимость применения и активного внедрения в сфере строительства современных эффективных технических решений, технологий, материалов, конструкций и оборудования, а также возможность использования при проектировании как национальных стандартов и строительных норм, так и соответствующих передовому техническому уровню европейских стандартов

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

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

Какой объем проработанной в проектной документации информации необходим для получения разрешения на строительство?

В настоящее время в рейтинге Doing Business Всемирного банка по показателю получения разрешения на строительство Российская Федерация находится на 115-м месте. В этой связи на совещании с членами Правительства Российской Федерации, состоявшемся 31 октября 2017 года и посвященном, в том числе вопросам улучшения делового климата, Президент России В.В. Путин особо обратил внимание на необходимость активизации соответствующей работы в сфере строительства. 2 Разрешение на строительство представляет собой документ, который подтверждает соответствие проектной документации требованиям, установленным градостроительным регламентом, проектом планировки территории и проектом межевания территории. Градостроительный регламент устанавливает вид разрешенного использования земельных участков, предельные параметры разрешенного строительства, реконструкции объектов капитального строительства. Градостроительный план земельного участка содержит информацию о разрешенном использовании земельного участка, требованиях к назначению, параметрам и размещению объекта капитального строительства на указанном участке, информацию о технических условиях подключения (технологического присоединения) объектов капитального строительства к сетям инженерно-технического обеспечения. Таким образом, на момент прохождения экспертизы и получения разрешения на строительство должны быть определены назначение и предельные параметры объектов капитального строительства, а также необходимые сведения в целях обеспечения защиты жизни и здоровья граждан и охраны окружающей среды. Полный объем информации и проектных решений (рабочий проект) об объекте капитального строительства необходим только к моменту ввода его в эксплуатацию, поскольку разрешение на ввод объекта в эксплуатацию представляет собой документ, подтверждающий:

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

По мнению профессионального сообщества, данное положение предоставляет возможность изыскания иных мероприятий, способствующих дальнейшей минимизации требований к составу и содержанию разделов проектной документации на строительство, реконструкцию, капитальный ремонт объектов капитального строительства, финансируемых за счет средств частных инвесторов без привлечения средств бюджетов бюджетной системы Российской Федерации, средств юридических лиц, созданных Российской Федерацией, субъектами Российской Федерации, муниципальными образованиями, юридических лиц, доля Российской Федерации, субъектов Российской Федерации, муниципальных образований в уставных капиталах которых составляет более 50%, и не являющихся уникальными и технически сложными. Содержание проектной документации на такие объекты на момент предоставления в экспертизу возможно должно ограничиваться основными архитектурно-планировочными и конструктивными решениями, основными решениями по инженерному и технологическому оборудованию, отделке зданий, обоснованием предельных параметров объектов капитального строительства, необходимыми сведениями, направленными на обеспечение защиты жизни и здоровья граждан, охраны окружающей среды. Дальнейшая детальная проработка и увязка на объекте проектных решений должна осуществляться на последующих стадиях проектирования и завершаться до момента получения разрешения на ввод объекта в эксплуатацию.

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

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

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

Предпроектные материалы – проектное задание (задание на проектирование).

Технико-экономическое обоснование (Design Concept) – набор основных положений, касающихся проекта, учитываемых на всех этапах проектирования и принимающих во внимание все существующие ограничения.

Эскизный проект (Schematic design) – начальный проект, представленный на второй стадии процесса проектирования и основанный на концепции проекта.

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

Рабочая документация (Final design) – финальный этап проектирования, выполняемый после одобрительной оценки детального проектирования.

Стадия 5. Утвержденная рабочая документация

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

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

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

Читайте также: