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

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

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

В следствии выполнения первой фазы были получены следующие результаты:

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

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

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

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

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

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

  • Сформированная оценка ресурсов, также весьма приблизительная и не предоставляет возможности поэкспериментировать параметрами: содержание - ресурсы – время, для эффективного управления проектом.

В связи с вышесказанным, целью текущей стадии будет:

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

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

1.  Этапы фазы проектирования, дизайна, формирования требований

Этапы фазы часто идут итеративно (по спирали), а не строго линейно, иногда затрагивая и другие стадии. Но общий поток такой:

1.1.  Этап 1. Разработка плана-графика проектных работ

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

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

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

  • Работы (содержание, качество);

  • Ресурсы (люди, деньги, инструменты, оборудование и прочее);

  • Время (сроки реализации).

Для чего вообще нужен план-график проекта?

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

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

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

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

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

1.2.  Этап 2. Формирование детального проектного решения.

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

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

Большинство работ этого этапа выполняют системные Аналитики и Архитекторы. В профстандарте: “Системный аналитик. Код_06.022”, “Архитектор программного обеспечения. Код_06.003”.

В ходе процесса формализации требований выполняются следующие активности:

  1. Осуществляется анализ продуктового портфеля. Фиксируется текущая ИТ-архитектура предприятия и закладывается целевая архитектура ИС. Выбираются принципы производства. Вопросы построения ИТ-архитектуры предприятия подробно рассматриваются в курсе: “Архитектура ИТ решений. Часть 1. Понятие Архитектура”

  2. Формализуются цепочки бизнес-процессов, которые необходимо автоматизировать. Подробно о этих активностях можно прочитать в курсе “Проектирование ИС. Часть 7. Инжиниринг бизнес-процессов заказчика 7.1. Применение UML Activity”

  3. На базе полученных моделей бизнес-процессов определяются системные функции и потоки данных, между элементами системы. Подробно об этих активностях можно прочитать в курсе: “Проектирование ИС. Часть 6. Выявление функции системы. 6.2. Моделирование сервисов. Диаграммы IDEF0”

  4. Выявляются сущности предметной области и на их базе моделируются хранилища, определяются логические связи, отражающие взаимное влияние реальных объектов друг на друга. Подробно о этих активностях можно прочитать в курсе: “Проектирование ИС. Часть 8. Разработка логической структуры данных. 8.1. UML Class diagram”

  5. Определяется событийная модель, моделирующая реакцию спроектированных компонентов, на различные события, происходящие как в самой системе, так и во вне ее. Другими словами, поведение распределяется на сконструированные сущности системы. Подробно о этих активностях можно прочитать в курсе: “Проектирование ИС. Часть 9. Моделирование поведения 9.2. Поведенческие диаграммы UML”

  6. Определяются требования к дизайну форм для взаимодействия с пользователем;

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

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

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

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

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

Например:

1)   Стартовое архитектурное видение (Discovery - подготовительная итерация для архитектуры).

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

2)   Проектирование “just in time” (проектировать решение ровно тогда и ровно настолько, насколько оно реально понадобится в разработке).

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

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

3)   Совмещение проектирования и разработки

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

4)   Постоянная переработка дизайна (уточнение и переработка)

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

5)   Встроенные дизайн-ревью

Регулярная проверка проектных решений, встроенная в обычные Agile-ритмы команды, а не в виде отдельного формального этапа. По факту - это процесс, а не событие. Идея в том, что дизайн проверяется там же и тогда же, где принимаются решения. Происходит, например, на backlog refinement / grooming, перед началом реализации (design sync); ретроспективах; code review проводят так же на соответствие архитектуры, соблюдение контрактов и прочее.

1.3.   Этап 3. Согласование и валидация проектного решения

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

Перечисленные работы обычно выполняют системные Аналитики.

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

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

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

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

И прочие.

Для борьбы с подобными вызовами применяют гибкие методологии (Agile) важнейшие принципы, которых от имени исполнителей гласят:

«Мы принимаем изменения в требования, даже на поздних этапах реализации проекта».

«Мы больше не заставляем расписываться заказчика кровью, ограничивая его жесткими и неудобными условиями договоров».

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

То есть принципиальных трудностей по поводу внесения изменений в продукт, даже на поздних стадиях разработки в современных проектах, особо никто не испытывает. Но при этом управленческие решения усложняются, а затраты могут расти кратно. Подробно активности, связанные с управлением изменениями рассмотрены в курсе: “Проектирование ИС. Часть 11. Управление изменениями требований”

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

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

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

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

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

Бизнес-заказчики (Product Owner, заказчик, стейкхолдеры)

  • Проверяют, соответствует ли создаваемый продукт бизнес-целям.

  • Контролируют выполнение ключевых требований и их качественных характеристик.

  • Убеждаются, что разработка идет в нужном направлении в адекватные сроки.

Акценты:

  • Четко сформулированные бизнес-цели и ограничения.

  • Функциональность, которая решает проблемы пользователей.

  • Гибкость и возможность вносить изменения.

Команда разработки (Backend, Frontend)

  • Анализируют технические требования.

  • Определяют, какие архитектурные решения подходят.

  • Оценивают сложность и сроки реализации.

Акценты:

  • Однозначные, тестируемые требования.

  • Граничные условия и возможные ошибки.

  • Четкие критерии приемки (Acceptance Criteria).

UX/UI-дизайнеры

  • Опираются на пользовательские сценарии для проектирования интерфейса.

  • Учитывают ограничения системы при создании дизайна.

  • Понимают, какие интерактивные элементы нужны.

Акценты:

  • User Stories и Use Cases.

  • Описание взаимодействия пользователя с системой.

  • Ограничения платформ и доступность (Accessibility).

Проектные менеджеры (Scrum Master, PM, BA)

  • Планируют спринты и этапы разработки.

  • Контролируют выполнение требований.

  • Обсуждают с заказчиком возможные изменения.

Акценты:

  • Приоритеты и зависимости между требованиями.

  • Оценка сложности задач.

  • Гибкость и возможность адаптации требований.

DevOps-инженеры

  • Определяют требования к инфраструктуре.

  • Планируют CI/CD, мониторинг, развертывание.

Акценты:

  • Требования к отказоустойчивости.

  • Ограничения по безопасности и нагрузке.

  • Поддерживаемые среды (Cloud, On-Prem).

1.4.  Этап 4. Формирование спецификаций требований

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

Но, перед передачей требований на стадию реализации, желательно пройти дополнительный этап, преобразовав проектную документацию в Спецификации требований (software requirements specification, SRS) - структурированный набор требований к программному обеспечению и его внешним интерфейсам. (Определение на основе IEEE Std 1012:2004).

Спецификации обычно оперируют понятиями и форматами, приближенными к среде разработчиков. Например, таблицы БД, API, процедуры, формы, кнопки, меню, поля ввода и т.п. Подробно о том, как формируются SRS описано в курсе: “Проектирование ИС. Часть 10. Разработка требований 10.2. Формирование спецификаций требований”

Эти работы выполняют уже упомянутые Системные аналитики и Технические писатели, в профстандарте: “Технический писатель (специалист по технической документации в области ИТ). Код_06.019” при непосредственном участии команды разработчиков, которые и будут главными потребителями.

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

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

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

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

1.5.  Этап 5. Передача проектной документации на разработку

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

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

1)  Организация презентации документации:

  • Совместная встреча: проведение встреч с участием всех членов команды разработки для представления и обсуждения документации.

  • Визуальные материалы: использование презентаций, макетов и прототипов для наглядного представления требований.

  • Сроки и этапы: четкое указание сроков выполнения и этапов разработки.

2)  Обеспечение обратной связи:

  • Обсуждение и вопросы: поощрение команды задавать вопросы и высказывать предложения по документации.

  • Корректировки: при необходимости возможность внесения изменений в документации на основе полученной обратной связи.

3)  Документирование и доступность:

  • Хранение документации: размещение окончательной версии в общем доступе для команды (например, в системе управления проектами или на корпоративном портале).

  • Обновления: обеспечение своевременного обновления документации при изменениях и уведомление команды об этих изменениях.

4)  Постоянная коммуникация:

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

  • Каналы связи: определение основных каналов коммуникации (чаты, электронная почта, системы управления проектами) для оперативного взаимодействия.

2.  Итоги

Полноценное проектирование является одним из ключевых факторов, значительно влияющих на качество, сроки и затраты реализации ИС.

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

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

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

  • На основании проектного решения должно быть сформировано Техническое задание (ТЗ), которое необходимо согласовать с заказчиком.

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

В следующей части мы рассмотрим фазу Разработки (реализации)