Содержание курса

В данном случае под термином “Разработка” подразумевается не непосредственно написание кода в узком смысле, а синоним всего комплексного процесса реализации ИС.

Разработка ИС – стадия перехода от технического задания (ТЗ) к процессу реализации ИС.

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

Но в реалиях современной практики быстрых изменений, стадия Разработки рассматривается как итеративный процесс и в ЖЦ производства. Она зачастую переплетается с другими фазами, в том числе и с Проектированием, и с Тестированием, и даже в продуктовом подходе иногда и с Внедрением.

А потому прежде всего необходимо четко разграничивать понятия: Требованиями к целевой ИС (ЧТО делаем) и Требованиями к процессу реализации, описывающими деятельность по ее созданию (КАК делаем). Эти два вида требований естественно не изолированы. Например, требования к процессу часто являются способом достижения трудноверифицируемых требований к продукту. Исходя из этого контекста, если на стадии Проектирования акценты расставлялись на требования к целевой системе, то в этой части мы будем фокусировать внимание на самом процессе ее реализации.

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

Любая стандартная методика разработки ИС содержит четыре обязательных компонента (согласно ГОСТ Р 57100-2016 и ISO/IEC 12207):

1) Этапы и стадии (ЖЦ):

Четкая последовательность работ.
Точки контроля (вехи, milestones).

2) Ролевая модель:

Кто и за что отвечает (архитектор, разработчик, тестировщик, аналитик, заказчик, PM).

3) Артефакты (результаты):

Какие документы, модели, коды, отчеты должны быть созданы на каждом этапе.

· Пример: Техническое задание, сборка версии ПО, протоколы тестирования.

4) Регламенты и стандарты:

Правила оформления кода, документов, интерфейсов.

· Пример: Стандарт оформления ТЗ по ГОСТ 34.602-2020.

1. Этапы фазы разработки, тестирования и верификации

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

В любом случае, выбор этапов - это всегда компромисс между предсказуемостью и гибкостью.

1.1. Этап 1. Планирование и инициация (разработка плана-графика работ и ресурсного плана)

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

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

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

Наглядно активности Проектного менеджера (далее PM) и их приоритеты представлены на схеме

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

План-график работ (Project Schedule) - это публичная модель реализации проекта, в которой используются следующие элементы:

Работы (задачи, этапы) привязанные к срокам (даты начала и окончания);
Ответственные, назначенные на работы (роли/люди);
Взаимосвязи (что за чем следует, что можно делать параллельно);
Контрольные точки сверки результата (milestones/вехи).

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

1) Дисциплина и обязательства:

Исполнитель понимает, когда должен сдать результат.
Заказчик понимает, когда ждать поставку.
Менеджер понимает, кого спросить за задержку.

2) Выявление узких мест и рисков еще до старта:

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

3) Координация и синхронизация (сведение в единую картину):

Позволяет синхронизировать взаимосвязанные работы.
Объединять работы в группы.

4) Контроль и раннее обнаружение отклонений:

Синхронизация плана и реальных достижений производства.

5) Бюджетирование и ресурсное планирование:

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

6) Юридическая и финансовая защита (договорные отношения):

Выступает приложением к договору.
Предоставляет инструмент распределения ответственности.

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

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

1.1.1. Определение состава работ

На начальном этапе ключевой задачей основного процесса является Определение состава операций. Как раз это обычно и представляет главную проблему для PM. Аналитики и команда разработки определили и согласовывали Требования к ИС. PM_у же для начала необходимо трансформировать их в некие производственные активности и как-то “нарезать” на отдельные задачи, которые можно идентифицировать, тарифицировать по времени и сложности, упорядочить по взаимному влиянию и прочее. И чем детальнее и точнее будет проделана эта работа, тем эффективнее он сможет далее балансировать основными показателями: содержание/качество, ресурсы, время.

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

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

На основании этого представления, совместно с командой разработки, а для пущей эффективности с ее Team Leader, происходит связывание работ с ролями и потенциальными исполнителями. В зависимости от квалификации специалистов устанавливается время, отведенное на выполнение работ. В профстандарте Team Leader определен как “Руководитель разработки Программного обеспечения. Код_06.017”.

1.1.2. Подбор и согласование специалистов на вакантные позиции проекта

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

Стаффинг (Staffing) - процесс подбора и согласование ресурсов на вакантные позиции ресурсного плана. Выполнение подобных задач лежит на стаффинг-мнеджере, HR специалисте, для которых в профстандарте ближе всего позиция “Специалист по управлению персоналом. Код_07.003”. Эта деятельность уже превратилось в отдельное направление с широким кругом задач и в рамках данного курса подробно не рассматривается.

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

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

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

1.1.3. Управление рисками

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

Выделяют следующие доминирующие группы рисков, характерные именно для текущей стадии:

А. Рыночно-контрактные (Пресейл и договор):

Незрелость заказчика. Отсутствие сформированной потребности и четкого видения продукта.
Модель ценообразования. Выбор между Fixed Price (риск не уложиться в бюджет) и Time & Materials (риск бесконтрольного роста затрат).
Расхождение в оценках. Ситуация, когда разработчик и заказчик по-разному понимают трудоемкость одной и той же формулировки задачи.

Б. Продуктово-технологические:

Технический долг и масштабирование. Типичная ошибка - фокус только на запуске MVP и игнорирование затрат на сопровождение и оптимизацию пост-релиза.
Новые технологии (ИИ, контейнеризация). Высокая неопределенность работы алгоритмов при масштабировании требуют особых методов оценки.
Регуляторные (новое). Например, с 2025–2026 гг. - риски несоответствия методике ФСТЭК. Для госкомпаний и компаний с критической информационной инфраструктурой системы с ИИ, контейнеры и микросервисы стали обязательными объектами анализа защищенности. Не учет этого требования блокирует приемку и аттестацию.

В. Человеческие и организационные:

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

Управление рисками - это отдельное направление в классическом управлении проектами (PMBOK 7-е изд., ГОСТ Р 54869, ISO 31000) и его подробное изучение не входит в рамки данного курса. Но следует отметить, что ключевая компетенция современного руководителя - не избегать рисков, а визуализировать их, назначать ответственных и встраивать обработку в обычный рабочий цикл команды.

1.1.4. Разработка ресурсного плана

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

Расчет стоимости типового оборудования и программного обеспечения для системы поддержки ИТ-услуг может, например, включать:

№	Наименование	Колич.	Цена за ед. (тыс.руб)	Оценка стоимости (тыс.руб)
1.	Сервер автоматизированной системы поддержки предоставления ИТ-услуг	1	200	200
2.	Внешнее устройство резервного копирования	1	180	180
3.	Рабочие станции обслуживающего ИТ-персонала	15	35	525
4.	Принтер	2	25	50
5.	Источник бесперебойного питания (для сервера)	1	60	60
6.	Монтажный шкаф	1	150	150
7.	ОС Сервера (MS Windows)	1	75	75
8.	ОС рабочих станций (MS Windows)	15	6	90
9.	ПО Сервер БД (MS SQL)	2 проц.	250	500
10.	Специализированное ПО поддержки предоставления ИТ-услуг	1	900	900
11.	Стоимость подменного фонда (ЗИП)	1	170	170
ИТОГО (с учетом гарантийного обслуживания технических средств)				2 900

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

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

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

1.1.5. Пересмотр границ проекта

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

Снова актуален “магический треугольник” (Time, Resources, Scope). Если все три стороны зафиксированы жестко, проект ломается. Пересмотр границ - это единственный цивилизованный способ разрешить это противоречие.

Что именно может пересматриваться?

1) Приоритизация функционала (Сокращение Scope). Это самый частый сценарий. Команда признается, что не успевает сделать все к нужному сроку с текущими специалистами. В этом случае, например, можно создать список MUST HAVE (критически важное для запуска) и NICE TO HAVE (можно и потом), меняя границы проекта.

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

3) Пересмотр технических границ (Изменение подхода). Когда детальное планирование показывает, что какой-то функционал в заявленном виде требует титанических усилий (например, написать свой видеоредактор с нуля). В результат пересмотра, например, изменяют границ продукта через технологию. Вместо своего видеоредактора выполняют интеграцию с готовым API (YouTube, Vimeo). Это меняет границы проекта (мы не пишем код, а интегрируем), но при этом сохраняет пользовательскую ценность.

4) Уточнение качества (Технического долга). План может показать, что на идеальный код, идеальное тестирование и идеальный дизайн нет ни времени, ни денег. В результате пересмотра принимается сознательное решение сократить границы качества на первом этапе (согласованный технический долг). Например, “Мы пишем код без идеальной архитектуры, но быстро, чтобы успеть к deadline. Потом выделим спринт на рефакторинг”.

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

1.1.6. Инициация проекта

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

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

Устава проекта должен содержать (согласно ГОСТ Р ИСО 21500, PMI и практике ИТ-проектов):

Название и бизнес-цели: почему проект нужен компании, какая проблема решается.
Цели проекта: формулируются по SMART (конкретные, измеримые, достижимые, релевантные, ограниченные по времени).
Границы проекта: что ВХОДИТ и что НЕ ВХОДИТ в объем (организационные, функциональные, географические границы).
Содержание (задачи): крупные блоки работ.
Ключевые роли: спонсор, заказчик, руководитель проекта (для больших и сложных проектов - PM должен быть сертифицирован).
Ориентиры: сроки, бюджет, вехи.
Допущения и ограничения.
Первоначальные риски.

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

Организация производства Информационных систем. Часть 6. Разработка. 6.1. Планирование ресурсов и инициация