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

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

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

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

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

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

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

Приступим.

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

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

 

%d такие блоггеры, как: