Предпроектный анализ: Серия 3

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

[sendpulse-form id=”278″]

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

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

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

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

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

Приступим.

Классификация ИТ-продуктов

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

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

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

Иерархия ИТ-продуктов выглядит так:

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

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

• математическое
• программное
• техническое
• информационное
• лингвистическое
• метрологическое
• эргономическое
• организационное
• методическое
• юридическое
• финансовое

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

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

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

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

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

Основной ответ на вопрос “Что же делать?” – “Понять класс своего предмета поставки и видеть, как он вписан в систему”.

Расширенная V-модель и жизненный цикл системы

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

Для иллюстрации вложенности ИТ-продуктов, порядка принятия/проверки решений и взаимодействия их жизненных циклов можно использовать V-модель. Она отражает два простых факта:

• проектировать нужно от большого к малому
• собирать в единое целое в обратном порядке

Для иерархии продуктов, описанных в предыдущем разделе можно построить следующую расширенную V-модель:

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

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

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

Классификация ИТ-проектов

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

На каждом из уровней и видов решений планируется разное количество изменений.

Есть проекты по замене сервера на более производительный. Может быть проект по переезду в другой дата-центр. Возможна смена языка системы.

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

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

Система, как финансовый актив

Последний принцип, который будет рассмотрен в этой статье играет для ИТ-систем роль Всеобщей формулы капитала Карла Маркса для экономики или цикла Шухарта-Деминга для управления процессами. В общем виде он формулируется как “Деньги-Продукт-Эффект-Деньги”. Разберем его чуть подробнее.

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

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

На каком бы уровне V-модели вы ни входили в проект, вы должны представлять себе, как сконфигурирован цикл возврата инвестиций:

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

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

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

Итого

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

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

Само по себе знание пробелов и нестыковок контекста позволяет устранить фатальные проблемы и не браться за провальный проект.

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