Управление проектами по Технологии быстрого результата

Перечень дисциплин. Прототипирование

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

Основные мысли

В результате изучения лекции слушатель будет способен:
1. Обосновывать критическую роль дисциплин управления проектами для достижения быстрого результата.
2. Классифицировать и различать функциональные и нефункциональные требования к информационной системе.
3. Анализировать связь между архитектурой системы и реализацией нефункциональных требований (производительность, надежность, масштабируемость, отказоустойчивость).
4. Оценивать риски отказа от эмпирической проверки технологических гипотез.
5. Формулировать три основные цели применения прототипирования в ИТ-проектах.
6. Аргументировать выбор метода презентационных семинаров (ролевых тренингов) для валидации требований и обучения пользователей.
7. Сопоставлять эффективность визуального согласования интерфейса и согласования по текстовой документации.
Показывать лекцию целиком
Краткое изложение
Ключевые дисциплины для быстрого результата

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

К таким дисциплинам относятся:
• Прототипирование
• Архитектурное проектирование (дизайн системы)
• Планирование
• Управление изменениями, рисками, коммуникациями и требованиями

Рассмотрим подробнее прототипирование.

Прототипирование

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

Три назначения прототипа

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

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

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

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

Пример из практики. Заказчик заявлял о работе с миллионом номенклатурных позиций на платформе «1С:Предприятие 7.7». Никто не мог гарантировать, как поведет себя конфигурация. Был написан скрипт, сгенерировавший такой объем данных, и проведен натурный эксперимент. Система заработала, что позволило выполнить проект осознанно. Если бы проверку отложили до конца проекта, высока была бы вероятность провала и потери средств.

Типовое или отраслевое решение всегда доступно как прототип для такой проверки.

2. Согласование функциональных требований
Наличие прототипа позволяет проводить презентационные семинары (ролевые тренинги). Метод заключается в следующем:
• Собирается группа специалистов заказчика по определенному направлению (например, бухгалтерия).
• Им демонстрируют прототип системы и предлагают выполнить в нем реальные операции.
• Аналитик фиксирует реакции: «у нас не так», «здесь неудобно», «это ерунда».

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

3. Согласование требований к интерфейсу
Применимость прототипа здесь очевидна. Народная мудрость «лучше один раз увидеть, чем сто раз услышать» полностью справедлива для ИТ-отрасли. Показать заказчику экранную форму, вплоть до распечатки, на которую можно ткнуть пальцем, гораздо эффективнее, чем описывать её в тексте. Описание даже несложной экранной формы может занять около пяти страниц. Это требует усилий на внятное описание и на его последующее прочтение, понимание и согласование. Визуализация экрана решает эти проблемы, делая прототип незаменимым инструментом.

Краткие итоги

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

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

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

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

Определение прототипа и его цели

Прототип — это прообраз, работающая модель или опытный образец. В ИТ-сфере это быстрая «черновая» реализация базовой функциональности для анализа работы системы. Он выполняет реальные функции, но не обладает всеми свойствами конечного продукта.

Существует три основных назначения прототипа:
1. Проверка соответствия архитектуры требованиям заказчика.
2. Согласование функциональных требований.
3. Согласование требований к интерфейсу.

1. Проверка архитектуры и нефункциональных требований

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

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

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

2. Согласование функциональных требований

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

3. Согласование требований к интерфейсу

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

Выводы

1. Ключевыми дисциплинами для быстрого результата являются прототипирование, архитектурное проектирование, планирование, а также управление изменениями, рисками, коммуникациями и требованиями.
2. Прототип — это работающая модель с базовой функциональностью, которая не обязательно обладает всеми свойствами конечного продукта.
3. Прототипирование решает три задачи: проверка архитектуры, согласование функциональных требований и согласование пользовательского интерфейса.
4. Нефункциональные требования (производительность, надежность, масштабируемость) реализуются исключительно через архитектуру, а не через написание отдельных модулей кода.
5. Игнорирование нефункциональных требований — частая причина серьезных проблем в проектах по внедрению информационных систем.
6. Единственный способ достоверно проверить архитектуру на соответствие нефункциональным требованиям — провести нагрузочное тестирование на полномасштабном прототипе.
7. Техническая документация и спецификации не дают полной гарантии работоспособности системы в условиях реальной нагрузки или при сложных интеграциях.
8. Эмпирическая проверка технологических рисков (например, на больших объемах данных) на ранней стадии проекта критически важна для предотвращения его провала.
9. Типовое или отраслевое решение всегда следует рассматривать как готовый прототип, на котором можно верифицировать требования.
10. Презентационные семинары (ролевые тренинги) позволяют совместить обучение пользователей с анализом функциональных разрывов.
11. Согласование интерфейсов через визуализацию экрана прототипа значительно эффективнее текстового описания, которое многословно и труднее для восприятия.
12. Визуальная демонстрация макета или экранной формы снимает неопределенность и снижает риск недопонимания при согласовании с заказчиком.

Вопросы для самопроверки

1. Какие дисциплины управления проектом и исполнения являются критически важными для технологии быстрого результата?
2. Чем прототип в конструировании и разработке программного обеспечения принципиально отличается от конечного продукта?
3. Для достижения каких трех основных целей используется прототип в проектах внедрения информационных систем?
4. Какие характеристики системы относятся к категории нефункциональных требований?
5. Почему нефункциональные требования не могут быть выполнены простым написанием нового программного кода?
6. Какая связь между архитектурой информационной системы и реализацией ее производительности или масштабируемости?
7. Почему теоретический анализ и документация не могут заменить натурное нагрузочное тестирование при проверке архитектуры?
8. Какую роль выполняет аналитик во время проведения презентационного семинара (ролевого тренинга) с использованием прототипа?
9. Какой метод позволяет одновременно обучать пользователей работе в системе и выявлять функциональные разрывы?
10. В чем заключается главное преимущество визуального согласования интерфейса перед его описанием в техническом задании?
11. Какие риски для проекта в целом позволяет минимизировать создание прототипа на ранней стадии?
12. Как можно использовать типовое или отраслевое решение для проверки требований заказчика?
Вернуться к учебному плану