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

Основная цель этапа Проектирования - написание Частных технических заданий (ЧТЗ) на разработку функционала закрывающего функциональные разрывы (ФР) выявленные на этапе Моделирования.

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

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

Формат самого документа, мы как Исполнители предлагаем Заказчику в рамках подготовки и согласования договорных документов на этап Проектирования, бывает так, что Заказчик хочет видеть ЧТЗ в своем формате, в этом случае, готовы идти на встречу, при сохранении смысловой нагрузки документа. Обычно одно ЧТЗ описывает устранение одного функционального разрыва (ФР), однако бывает так, что в одном ЧТЗ учитывается несколько ФР.

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

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

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

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

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

#1c #проектное