ОСН_7. ProjectLibre. Составление кейса и формирование ИСР проекта

В предыдущей статье по работе в программе ProjectLibre я описал минимально необходимые функции для составления плана проекта.

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

Поскольку был сделан подробный разбор, то материал получился довольно объемным. Я его разделил на 7 частей:

• описание кейса и составление ИСР проекта;
• планирование 1 этапа работ «Обследование и анализ»;
• планирование 2 этапа работ «Разработка и настройка» (разделено на 2 части, т.к. есть техническое ограничение статьи на количество прикрепленных графических материалов);
• планирование 3 этапа работ «Подготовка к опытной эксплуатации»;
• планирование 4 этапа работ «Проведение опытной эксплуатации»;
• планирование 5 этапа работ «Перевод в промышленную эксплуатацию»;
• оптимизация плана проекта;
• подведение общих итогов по серии публикаций.

По каждой из частей будет сделана отдельная публикация. В настоящей статье мы рассмотрим первую часть «Описание кейса и составление ИСР проекта».

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

По окончании публикаций стоит сравнить 3 состояния плана:

• когда составлена ИСР проекта;
• когда составлен не оптимизированный план;
• когда план оптимизирован.

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

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

Примечание к кейсу

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

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

Мы возьмем простой вариант, когда продажа/покупка ведется не по конкурсу, а по КП. Это будет выражаться в формате «допустим мы запросили и нам ответили». В конкурсах такой подход не прокатит.

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

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

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

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

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

Следующий момент. Приведенные данные лишь часть того, что требуется собрать для старта проекта. Постепенно будут рассмотрены и другие части (финансовый план, план управления рисками и др.).

Вроде сделал все примечания. Но если что, дополню в ходе описания.

Начальное описание кейса для составления плана проекта

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

Первоначальное видение Заказчика и Продавца указаны ниже.

Этапность и продолжительность проекта

Общая продолжительность проекта - 1 год. Проект предполагается реализовать в 5 этапов:

• этап 1 «Обследование и анализ»;
• этап 2 «Разработка и настройка»;
• этап 3 «Подготовка к опытной эксплуатации»;
• этап 4 «Проведение опытной эксплуатации»;
• этап 5 «Перевод в промышленную эксплуатацию».

Планируемые результаты

В рамках этапа 1 «Обследование и анализ» требуется предоставить следующие результаты:

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

В рамках этапа 2 "Разработка и настройка" требуется предоставить следующие результаты:

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

В рамках этапа 3 "Подготовка к ОЭ" требуется предоставить следующие результаты:

• первоначальные данные должны быть подготовлены и загружены во внедряемую ИС (в объеме, достаточном для проведения ОЭ);
• пользователи из группы проведения ОЭ должны быть обучены;
• ИС должна быть проверена и допущена к проведению ОЭ;
• план проведения ОЭ должен быть составлен, согласован и доведён до пользователей группы ОЭ.

В рамках этапа 4 "Проведение ОЭ" требуется предоставить следующие результаты:

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

В рамках этапа 5 "Перевод в ПЭ" требуется предоставить следующие результаты:

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

Предоставление проектной документации

Следующая документация является неотъемлемой частью результатов реализации проекта.

Для этапа 1 «Обследование и анализ»:

• отчет о проведении обследования;
• частное техническое задание (ЧТЗ);
• пояснительная записка к техническому проекту;
• описание архитектуры.

Для этапа 2 «Разработка и настройка»

• отчет о проведении разработки;
• программа и методика предварительных испытаний.

Для этапа 3 «Подготовка к проведению опытной эксплуатации»:

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

Для этапа 4 «Опытная эксплуатация»

• программа и методика приемочных испытаний;
• отчет о проведении опытной эксплуатации.

Для этапа 5 «Перевод в промышленную (постоянную) эксплуатацию» - отчет о проведении ПСИ.

Примечание!!! Это далеко не полный список документации, однако для полноценного кейса по составлению плана проекта в ProjectLibre ее вполне достаточно.

Примечание!!! Не стоит смущаться, что некоторые документы с первого взгляда не соответствуют этапу. Это именно «с первого взгляда». Например, для этапа 3 в нашем кейсе предусмотрен обязательный документ «Программа и методика проведения опытной эксплуатации». А все дело в том, что документ должен быть готов не в процессе опытной эксплуатации, а до ее начала. Соответственно, опытная эксплуатация проводится на этапе 4 «Проведение опытной эксплуатации», соответственно, результат проекта «Документ ‘Программа и методика проведения опытной эксплуатации’» должен быть готов (написан и согласован) раньше. Контроль готовности осуществляется в конце предшествующего проведению опытной эксплуатации этапа 3 «Подготовка к проведению опытной эксплуатации». Так что никаких противоречий нет.

Команда проекта

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

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

Со стороны сотрудников компании:

• функциональный архитектор - 1 человек, ставка 260 р./чел-час;
• аналитик - 3 человека, ставка 213 р. / чел-час ;
• технический архитектор - 1 человек, ставка 260 р./чел-час ;
• системный инженер - 1 человек, ставка 205 р. /чел-час.

Со стороны подрядчика «Лучший подрядчик»:

• аналитик - 1 человек, ставка - 390 р./ чел-час;
• разработчик - 2 человека, ставка 480 р/чел-час.

Примечание!!! Ставки даны, разумеется, условно. Исключительно для того, чтобы просто обозначить цифру. Если кто-то проронит слезу от указанных ставок - я не виноват :).

Оборудование и лицензии

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

• лицензии на ОС «Серверная операционная система», 2 лиц., цена лицензий 1000 р.;
• лицензии на СУБД «Система управления базами данных», 2 лиц., цена лицензии 1500 р.;
• лицензии на внедряемое ПО «ПО для автоматизации», 2 лиц., цена лицензии 2000 р.;
• сервер СУБД (технические требования приводить не буду, но в реальном проекте - должно быть приведено в обязательном порядке), 1 шт., цена 10 100 р;
• сервер приложений  (технические требования приводить не буду, но в реальном проекте - должно быть приведено в обязательном порядке), 1 шт., цена 10 900 р.

Предполагается, что на протяжении проекта одновременно будет развернуто 2 площадки:

• до окончания ПСИ - площадка разработки и тестовая площадка;
• после окончания ПСИ и исправления ошибок/недоработок (если таковые обнаружатся) - тестовая площадка и промышленная площадка.

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

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

Но для начала повторим общие действия по работе с ProjectLibre.

Создание проекта и общие настройки

Создание нового проекта

При вызове программы создадим новый проект:

Внесем основные данные по проекту из кейса:

Создание модели рабочего календаря на основе «Пятидневки»

Откроем форму редактирования рабочего календаря проекта и нажмем кнопку «Новый...»:

В открывшейся форме создадим новую модель календаря на основе модели «Пятидневка»:

Отражение в рабочем календаре выходных дней (помимо суббот и воскресений)

Нерабочие и праздничные дни включая переносы в 2026 году - 01.01, 02.01, 03.01, 04.01, 05.01, 06.01, 07.01, 08.01, 09.01, 23.02, 08.03, 09.03, 01.05, 09.05, 11.05, 12.06, 04.11, 31.12.

Выберем в календаре справа даты, указанные выше (за исключением дат, выпадающих на сб. и вс.) и отметим их как нерабочие дни с помощью переключателя «Нерабочее время»:

Также отметим даты с рабочим временем, уменьшенным на 1 час. Такие даты в 2026 году следующие: 30.04, 08.05, 11.06, 03.11.

Для этого выделим даты, указанные выше, установим переключатель в положение «Рабочее время не по-умолчанию», и уменьшим рабочее время на 1 час:

По окончанию редактирования следует нажать кнопку «ОК».

Применение созданного календаря к проекту

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

Внесение ресурсов проекта

Анализ ресурсов

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

• трудовые ресурсы;
• оборудование;
• лицензии на ПО.

Трудовые ресурсы делятся на 2 группы:

• внутренние;
• внешние.

Составляем иерархическую модель ресурсов, однородную по уровням:

Внесение ресурсов

Соответственно, сначала вносим данные по уровням в ProjectLibre:

Затем выстраиваем иерархию:

Далее вносим сами ресурсы. Поскольку в кейсе не указаны конкретные фамилии сотрудников и внешних привлекаемых специалистов, то в наименовании вводим не ФИО, а роль и номер в порядке ввода:

Включаем ресурсы проекта в иерархию ресурсов:

Внесение задач проекта

Анализ задач и подготовка ИСР

Итак, первые два уровня иерархии задач понятны:

• уровень «Проект»;
• уровень «Этап проекта».

Вносим их в задачи:

Также сразу добавим в таблицу поле «WBS», чтобы можно было, не переходя в интерфейс редактирования работы, вводить код WBS:

Далее вносим коды по уже внесенным задачам:

Далее выстраиваем иерархию:

Анализируем кейс далее. Мы видим, что в каждом этапе есть 2 типа работ:

• проведение работ;
• написание документации.

Давайте внесем их в задачи:

Затем добавим их в иерархию:

Внесение в план работ по подготовке документации

Далее смотрим в описание кейса и видим, что документация там уже разнесена по этапам. Добавляем в задачи:

Затем добавляем эти задачу в структуру иерархии:

Встраивание в ИСР работ 1-го этапа «Обследование и анализ»

Итак, ИСР отстроили, встроили в нее подготовку документов. Теперь давайте проанализируем работы. Как видно в кейсе я не указал, какие работы нужно выполнить, а обозначил только результаты. Тем не менее, в плане требуется обозначить именно работы.

Давайте разбирать результаты и дополнять план работами.

Согласно кейса, в рамках 1-го этапа:

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

Подготовка целевой модели БП

Во-первых, надо обратить внимание на то, что в кейсе не указаны какие процессы должны быть автоматизированы в рамках проекта. Понятное дело, что мы автоматизировать «абсолютно любой процесс» не можем, но и деталей нет. Поэтому вводим допущение, что у проекта будет 4 прикладных области автоматизации: «Прикладная область 1», «Прикладная область 2», «Прикладная область 3» и «Прикладная область 4».

Это именно предположение, а не вывод. Почему... Мы сделали предположение исходя из количества аналитиков (по одному на прикладную область). Однако, может быть и по-другому. Аналитики могут владеть знаниями и навыками по нескольким прикладным областям (например, «Закупки» и «Логистика», учет «РСБУ» и учет «МСФО», «Продажи»  и «Маркетинг» и т.д.). И в этом случае у нас может быть запросто и 8 прикладных областей к автоматизации. А может быть и обратная ситуация. Применительно к нашему кейсу может быть, что автоматизировать нужно всего 2 прикладных области. Соответственно, по одной из них есть хороший внутренний специалист, по другой - хорошего специалиста нет, поэтому он привлечен «со стороны», кроме того есть 2 аналитика, которые хотят на практике изучить автоматизируемые процессы и будут в ходе проекта заниматься документированием  под надзором аналитиков - специалистов по автоматизируемым прикладным областям. Но мы будем строить план исходя из того, что есть 4 прикладных области автоматизации.

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

• специалист, работающий «внутри» автоматизируемого процесса;
• документация по процессам;
• заменяемая ИС, в которой в той или иной мере реализована бизнес-логика автоматизируемого процесса.

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

Соответственно проводятся аналитик проводит встречи с таким сотрудником. По окончании встреч информация, полученная в ходе ее, должна быть зафиксирована и согласована. И да,  написанием протокола и проведением согласования нагружать аналитика не следует. Это задача РП (а на крупных проектах - администратора проекта), а вот приложение к протоколу, в котором лаконично и структурировано описана информация, полученная в ходе встречи, должна быть формализована непосредственно аналитиком.

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

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

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

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

Таким образом для отражения данного результата в плане, следует добавить следующие задачи в следующей иерархии:

Сначала вносим их в список задач:

Затем встраиваем эти задачи в ИСР согласно схеме, приведенной выше:

Подготовка детального описания схемы интеграции и описания механизмов интеграции

Про интеграцию в кейсе ничего не указано. Однако в планируемых результатах есть упоминания о необходимости интеграции с какими-то ИС. Предположим, что вы связались с РП, проводившем работы по предпроектной подготовке и выяснили, что внедряемая ИС должна быть интегрирована с 2 другими информационными системами: «ИС-1» и «ИС-2». Интеграция должна производиться путем запросов через API-интерфейсы. Соответственно на стороне ИС-1 и ИС-2 добавлять интерфейсы не требуется. Со стороны внедряемой ИС должно быть разработано ряд интерфейсов (в рамках данной публикации детализировать не будем).

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

Во-первых, нам нужно понять какие данные должны передавать, по какому событию (или с какой периодичностью), направление передачи данных, а также куда конкретно в БД эти данные должны записываться.

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

Третий вопрос (о необходимости доработки API со стороны интегрируемых систем) мы в целях упрощения кейса закрыли.

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

Первым делом нужно определить потребность в данных по направлениям:

• из внедряемой системы в «ИС-1»;
• из внедряемой системы в «ИС-2»;
• из «ИС-1» во внедряемую систему;
• из «ИС-2» во внедряемую систему.

Прочие направления нас не интересуют.

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

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

Потребность по направлению в «ИС-1» и «ИС-2» определяется со стороны «владельцев» этих ИС, команда внедрения должна провести интервью с ними и собрать необходимую информацию.

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

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

Таким образом для получения данного результата нужно запланировать следующие работы:

• проработка общей концепции передачи данных между ИС;
• изучение реализованных API на стороне ИС-1 и ИС-2;
• детализация потоков данных между системами;
• подготовка задания на разработку API на стороне внедряемой системы.

И включить их в ИСР следующим образом:

Соответственно вносим задачи в таблицу инструмента «Гант»:

Далее включаем их в ИСР:

Подготовка детального описания первоначальных данных к загрузке и механизмов загрузки

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

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

Второй момент,  который следует, который требуется определить на данном этапе - это определить хранилище для перемещаемых данных. В качестве хранилища переносимых данных могут использоваться например, файлы определенного формата (xml, csv, xls и так далее). Еще один вариант - это базы данных. Как вариант можно создать хранилище там. Однако на этапе подготовки к ОЭ будет требоваться провести работы по выверке и очистке данных. И если с электронными таблицами худо-бедно умеют работать все пользователи, то работа с SQL-запросами это более редкий навык.

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

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

Пятый момент. Надо определить, способ переноса данных. То есть у систем могут быть встроенные механизмы выгрузки/загрузки. Возможно, будет удобнее использовать прямую выгрузку/загрузку непосредственно в БД, минуя слой приложения. А может оказаться менее трудозатратным написать механизм выгрузки/загрузки. И в этом случае будет необходимо написать задание на разработку механизмов загрузки/выгрузки.

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

• изучение объектов данных для переноса в системе-источнике;
• анализ данных на предмет необходимости в трансформации;
• анализ объектов для загрузки данных во внедряемой системе;
• анализ и согласование способа переноса данных и временного хранилища.

И включить их в ИСР следующим образом:

Вносим задачи в таблицу инструмента «Гант»:

Далее включаем задачи в ИСР:

Подготовка детального описания требований к инфраструктуре для внедряемой ИС и обслуживающих механизмов

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

• лицензии на ОС «Серверная операционная система», 2 лиц., цена лицензий 1000 р.;
• лицензии на СУБД «Система управления базами данных», 2 лиц., цена лицензии 1500 р.;
• лицензии на внедряемое ПО «ПО для автоматизации», 2 лиц., цена лицензии 2000 р.;
• сервер СУБД (технические требования приводить не буду, но в реальном проекте - должно быть приведено в обязательном порядке), 1 шт., цена 10 100 р;
• сервер приложений  (технические требования приводить не буду, но в реальном проекте - должно быть приведено в обязательном порядке), 1 шт., цена 10 900 р.

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

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

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

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

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

Таким образом в план нужно добавить следующие работы:

• детализация технических параметров функционирования;
• выпуск технической спецификации к внедряемой ИС.

Добавляем эти работы в план:

Далее встраиваем в ИСР:

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

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

• по автоматизируемым БП;
• по интеграции ИС;
• по внесению первоначальных данных.

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

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

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

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

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

Кроме того, собирается единый документ «Задание на разработку» из всех 3 (потенциально) частей.

Таким образом здесь вносим в план следующие задачи:

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

Вносим в эти задачи в план:

И включаем их в ИСР:

Проведение детальной оценки для оперативного планирования работ этапа 2

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

Итак, на следующем этапе мы должны выполнить следующие работы:

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

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

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

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

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

Соответственно, вынос задач на сервер оперативного планирования и  корректировка общего плана по результатам детализации - это задачи РП. Поэтому в план не вносим.

Таким образом, в план вносим следующие работы:

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

Вносим в план:

Далее включаем работы в ИСР:

Соответственно, в конце этапа проводится сдача результатов, «подбитие» наличия всех необходимых промежуточных протоколов, подписание акта сдачи-приемки результатов этапа. Вносить в план эти работы не будем, т.к. эти работы ведутся полностью на стороне РП. Да, возможны небольшие доработки и переделки результатов (и скорее всего в том или ином объеме это будет происходить), но в целом, разумеется, в план обычно такое не вносится, а закладываются риски. Но о рисках мы будем говорить вообще отдельно. Так что из планируемых задач по первому этапу в первом приближении все работы внесены.

Встраивание в ИСР работ 2-го этапа «Разработка и настройка»

Согласно кейса, в рамках 2-го этапа:

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

Развертывание технических площадок

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

Таким образом все работы можно поделить на 3 вида:

• встраивание серверов в инфраструктуру (установка в стойку, установка ОС, подключение к сети и настройка сетевых правил, установка сетевых доступов и т.д. и т.п.);
• развертывание бизнес-ПО и его компонент (из кейса - установка СУБД и сервера приложений, установка клиентов в необходимых для этапа объемах и т.д.);
• подключение технических сервисов (это могут быть как технические сервисы - например, резервное копирование не средствами ОС или внутренними сервисами, а с помощью спец.ПО для резервного копирования, также заказчик может ставить требование, чтобы исходный код разрабатываемых дополнений хранился у него в репозитарии, соответственно необходимо обеспечить доступы и права и т.д.).

В таком разрезе и включаем в план работ. Могут быть и исключения. Например, если по условиям договора всю техническую инфраструктуру должен предоставить сам заказчик, то, само-собой, нет никакого смысла включать данные задачи в план. То же самое с подключением технических сервисов. Второй же пункт в том или ином виде присутствует всегда. Могут быть исключения уже по деталям. Например, заказчик сам полностью предоставляет СУБД и т.п. Но в целом этот пункт обычно в плане должен присутствовать при внедрении. И опять же мы говорим о проекте внедрения. А может быть проект сопровождения, когда ничего развертывать и вовсе не надо, а проект в целом состоит из разработки энного количества крупных фич, плюс, допустим, интеграция с «таким-то» и «таким-то» внешними сервисами, плюс, допустим, обучение пользователей. Так что может быть очень по-разному. Но мы в рамках нашего кейса включаем все 3 пункта.

Вносим задачи в наш план:

И включаем в ИСР:

Разработка

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

Иногда в общий план пытаются встроить цепочку «Постановка задачи --> Проверка ФА --> Разработка --> Проверка ТА --> Функциональное тестирование --> Демо» или аналогичные. Но в общем плане, как мне кажется, такая группировка излишня. Дело в том, что это более детальный уровень и исполнение цепочки должно контролироваться не на общем уровне, а на оперативном. И мы будем в рамках другой публикации настраивать такие трекеры, но позже.

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

Соответственно, относительно нашего кейса у нас получается:

- разработка по функциональным разрывам:

• разработка по функциональным разрывам прикладной области 1;
• разработка по функциональным разрывам прикладной области 2;
• разработка по функциональным разрывам прикладной области 3;
• разработка по функциональным разрывам прикладной области 4;

- разработка механизмов интеграции:

• разработка механизмов интеграции с ИС «ИС-1»;
• разработка механизмов интеграции с ИС «ИС-2»;

- разработка механизмов импорта первоначальных данных.

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

Вносим эти работы в наш план:

А далее включаем эти работы в ИСР:

Настройка ИС (покрытие БП и  механизмы интеграции)

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

Также стоит провести внутреннее тестирование (то есть внутри команды внедрения), чтобы убедиться, что:

• все процессы покрыты функциональностью;
• тестовые кейсы показывают ожидаемые результаты;
• данные между системами ходят;
• результат передачи данных в каждом отдельном потоке соответствует ожидаемому.

Поскольку у нас в рамках описанного кейса наличествует обязательный документ «Программа и методика предварительных испытаний», то проще всего сначала подготовить данный документ, а затем «прогнать» тест-кейсы оттуда по настроенной ИС.

Тут логика такая - все равно данные кейсы будут применены к ИС на предварительных испытаниях (допуске к опытной эксплуатации). Если будут найдены ошибки и несостыковки в автоматизации, нам все равно нужно будет их устранять. С одной стороны - да, это дополнительные затраты (относительно небольшие, напомню, затраты на подготовку тест-кейсов у нас заложена в рамках подготовки ПМПИ). С другой стороны... Во-первых, мы получим значительно больше времени на устранение недостатков, если таковые будут обнаружены. Во-вторых, одно дело, когда вы вышли на предварительные испытания и продемонстрировали функциональность ИС либо без ошибок, либо (хотя бы) без критических ошибок, при этом их количество небольшое. Другое дело, когда вы вышли на предварительные испытания и у вас ИС начинает буквально сыпать ошибками (даже и некритическими), либо возникли критические ошибки. Впечатление другое. Ну представьте, собрались владельцы нескольких крупных процессов компании, ожидают увидеть результаты примерно полугодового труда. А напомню, они выделяли часть своего рабочего времени и времени своих подчиненных. Ждут результата, а результат - сплошная ошибка... Поэтому если есть время и ресурсы, лучше перестраховаться и, если что-то доработали или настроили неверно, то поправить до демонстрации заказчику.

Поэтому состав задач в данной группе такой:

- настройка функциональности ИС:

• настройка функциональности по прикладной области 1;
• настройка функциональности по прикладной области 2;
• настройка функциональности по прикладной области 3;
• настройка функциональности по прикладной области 4;

- функциональное тестирование настроенной функциональности;

- настройка механизмов интеграции:

• настройка механизмов интеграции с ИС «ИС-1»;
• настройка механизмов интеграции с ИС «ИС-2»;

- тестирование передачи данных между ИС.

То есть практически повторяет структуру предыдущей группы работ за некоторыми исключениями:

Добавляем эти задачи в план:

И включаем эти работы в ИСР:

Проведение детальной оценки для оперативного планирования работ этапа 3

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

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

Итак, на следующем этапе мы должны предоставлены следующие результаты:

• первоначальные данные должны быть подготовлены и загружены во внедряемую ИС (в объеме, достаточном для проведения ОЭ);
• пользователи из группы проведения ОЭ должны быть обучены;
• ИС должна быть проверена и допущена к проведению ОЭ;
• план проведения ОЭ должен быть составлен, согласован и доведён до пользователей группы ОЭ.

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

• готовый механизм импорта первоначальных данных и шаблоны загрузки
• детально расписанные процессы и готовая в функциональном плане ИС;
• готовые тест-кейсы и перечень прочих проверок в формате документа «Программа и методика предварительных испытаний».

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

А на момент формирования общего плана тут, собственно, 2 основные задачи, которые следует внести в план:

• оценка задач по подготовке ИС к ОЭ;
• определение зависимостей задач и общей последовательности их реализации.

Добавляем эти работы в план:

И встраиваем работы в ИСР:

Встраивание в ИСР работ 3-го этапа «Подготовка к проведению ОЭ»

Согласно кейса, в рамках 3-го этапа:

• первоначальные данные должны быть подготовлены и загружены во внедряемую ИС (в объеме, достаточном для проведения ОЭ);
• пользователи из группы проведения ОЭ должны быть обучены;
• ИС должна быть проверена и допущена к проведению ОЭ;
• план проведения ОЭ должен быть составлен, согласован и доведён до пользователей группы ОЭ.

Подготовка и загрузка первоначальных данных во внедряемую ИС

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

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

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

Второй момент. Данные, даже если они хранятся именно в ИС (а не в xls и и т.п.), со временем накапливают ошибки и неточности. Так, например, в справочниках могут появляться строки-дубли. И если такие строки-дубли участвовали (по связке) в отражении хозяйственных операций, и требуется переносить не только справочную информацию, но и операции, то удаление дублей будет недостаточно. Нам нужно будет сначала выбрать «правильный» вариант дубля, а потом скорректировать все связки с «неверным» вариантом записи-дубля. И только после этого удалять «неверный» вариант дубля из справочника. Само-собой, не должны переноситься строки, помеченные на удаление. Также, возможно, имеет смысл выверить переносимые значения. А кроме того, иногда требуется переносить не исходные данные, а данные в агрегированном виде (то есть «свернутые» по одной или нескольким аналитикам). Все это иногда называют очисткой данных перед переносом, иногда - выверкой и очисткой. Мы назовем это «Подготовка данных к переносу».

Ну и третий момент - это загрузка данных из временного хранилища во внедряемую ИС. Тут тоже могут быть сюрпризы. Например, если вы делаете загрузку данных не через интерфейсы приложения, а напрямую в БД, то можете столкнуться с ограничениями целостности (особенно если требуется загрузить операции, но и они возможны и при загрузке многоуровневых справочников). Поэтому загружать данные придется в строго определенном порядке (в рамках отдельных публикаций я рассмотрю многие вопросы по работе с СУБД). Но еще хуже может быть ситуация, когда ограничений целостности на уровне базы нет. Вы вроде как загрузили все необходимые данные, а во внедряемой системе часть данных либо не отображается, либо выдается ошибка при попытке открыть справочник. А все потому, что «поплыли» значения в полях - вторичных ключах. В общем, если есть возможность, то лучше пользоваться встроенными механизмами импорта данных.

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

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

Соответственно задачи в данной группе следующие:

Вносим в план:

А далее встраиваем в ИСР:

Обучение пользователей группы проведения ОЭ

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

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

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

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

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

Таким образом у нас следующие задачи в рамках данной группы:

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

Вносим данные работы в план:

И встраиваем в ИСР:

Проведение предварительных испытаний (допуск к ОЭ)

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

Перед тем, как проводить данную работу необходимо подготовить документ «Программа и методика предварительных испытаний».

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

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

Сделаем допущение, что наши предварительные испытания будут содержать следующее:

• проверка документации (само-собой, к этому времени должна быть подготовлена вся документация, которая должна быть сдана согласно нашего кейса);
• проведение показа функциональности согласно тест-кейсов, зафиксированных в документе «Программа и методика предварительных испытаний»;
• проведение демонстрации передачи данных между внедряемой ИС и ИС «ИС-1», а также между внедряемой ИС и ИС «ИС-2».

Соответственно, помимо всех организационных вопросов, которые должен решать непосредственно РП, в плане отражаем следующие задачи:

Вносим данные работы в план:

Далее встраиваем внесенные задачи в ИСР:

Планирование, согласование и публикация плана проведения ОЭ

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

То есть, смотрите, у нас есть документ «Программа и методика проведения опытной эксплуатации». Он как раз и должен содержать все необходимые инструкции, параметры и частные планы по проведению опытной эксплуатации. Это и продолжительность, и кто чем должен заниматься, и как осуществляется поддержка, и какое минимальное количество кейсов должен выполнить каждый пользователь, и где должны регистрироваться обращения по консультациям и ошибкам, и многое другое. Я буду рассматривать отдельно каждый проектный и каждый документ управления проектом. Просто если я еще и описание документов в эту публикацию заведу, то информации будет чрезмерно много, и так по ощущениям будет около 100 листов, причем кеглей 10,5.

Так вот, собственно, данный документ как раз и регламентирует проведение ОЭ. Его мы уже внесли в план. Ну а доведение до той или иной организационной информации до участников проекта - это уже всецело обязанность РП. Даже если какую-то часть документа нужно отдельно выкопировать или представить в сжатом виде (а если методика проведения ОЭ - не отписка, а реальный документ, то он довольно объемный), то все равно это все ложится на РП.

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

Ну и, понятное дело, в план дублей работ не вносим.

Проведение детальной оценки для оперативного планирования работ этапа 4

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

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

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

Ну а все параметры по проведению самой ОЭ, как мы уже говорили, описаны, согласованы и доведены до группы проведения ОЭ в формате документа «Программа и методика проведения опытной эксплуатации» (обязательно), а также в виде дополнительных материалов (опционально при необходимости).

Таким образом, нам нужно будет провести следующие работы:

Вносим работы в план:

Встраиваем задачи в ИСР:

Встраивание в ИСР работ 4-го этапа «Проведение опытной эксплуатации»

Согласно кейса, в рамках 4-го этапа:

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

Проведение опытной эксплуатации

Собственно, проведение ОЭ в соответствии со согласованной методикой проведения опытной эксплуатации.

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

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

В рамках ОЭ команда занимается следующими работами:

• консультирование группы проведения ОЭ;
• корректировка ошибок, вызванных неверной настройкой ИС и/или ошибок при разработке.

Также важно вести журнал опытной эксплуатации, в который необходимо включать абсолютно все ошибки, замечания и предложения. Да, возможно, не все замечания и предложения будут входить в объем согласованного ТЗ. Этот момент надо оговаривать еще при проведении предпроектной подготовке. В зависимости от достигнутых договоренностей устранение данных замечаний может быть проведено в рамках дополнительного соглашения после ОЭ, но до перевода в ПЭ. Возможно, по дополнительному соглашению после перевода в ПЭ. А возможно, заказчик решит заняться этими замечаниями с помощью внутренних сотрудников (если проект внешний), либо наоборот нанять отдельную команду для доработок (если проект внутренний). А может - микс всего перечисленного выше. То есть вариантов - много. Но факт, что фиксировать надо все замечания.

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

Ну а замечания и недоработки, которые входят в объем изначального ТЗ, а также ошибки, однозначно, должны быть устранены до перевода ИС в ПЭ.

Соответственно, по работам тут надо запланировать:

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

Вносим эти работы в план:

А далее вносим в ИСР:

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

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

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

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

А в работах по данной группе задач будем вносить следующее:

Вносим работы в план:

И включаем в ИСР:

Подготовка к переносу ИС на промышленную площадку

Соответственно, в подготовку к переносу включаем и задачу по развертыванию промышленной площадки.

Что тут может быть. С одной стороны, в соответствии с дополнительной информацией, полученной на этапе 1, серверное оборудование для промышленной площадки должно использоваться то, которое использовалось для площадки разработки на протяжении 4 этапов. Это подразумевает, что серверы уже находятся в стойках, системное ПО на них установлено. С другой стороны, потенциально у заказчика может быть принята такая схема инфраструктуры, в которой, например, все тестовые и вспомогательные площадки, а также не критически важное ПО физически находится по расположению офиса заказчика, а промышленные площадки для критически важного ПО располагаются в ЦОД - ах. А значит вам заранее нужно побеспокоиться, чтобы заказчик заключил договор на услуги ЦОДа. Кроме того, вы не можете просто придти в ЦОД и что-то там разместить. Вам придется писать документацию на размещение. Опять же заранее, ибо в текущей точке проекта писать уже нет времени. И только когда:

• договор на оказание услуг между заказчиком и ЦОД-ом будет подписан;
• документация на размещение оборудования в ЦОД-е будет написана и согласована с ЦОД-ом;

только тогда вы сможете привезти оборудование в ЦОД, передать его сотрудникам для размещения и ожидать, когда они его разместят, протестируют на работоспособность и выдадут вам доступ к размещенному оборудованию.

Я к тому, что все эти нюансы надо знать до старта проекта, чтобы правильно спланировать работу по проекту. А вот если мы только в конце ОЭ вдруг задумались о размещении площадки в ЦОД, то запросто может возникнуть довольно продолжительный перерыв между окончанием ОЭ и стартом работ по переводу ИС в промышленную (постоянную) эксплуатацию. То есть просадка по срокам, плюс незапланированные трудозатраты на написание документации на размещение (что, например, никак не идет в плюс к марже), плюс трудозатраты на доставку оборудования. То есть проблемы на ровном месте.

Но это - то, что потенциально может быть. Мы же для упрощения кейса будем считать, что промышленная площадка должна размещаться непосредственно в стойке у заказчика. Соответственно, работы по монтированию серверов в стойку и развертывание системного ПО у нас отсутствуют. Разве что проверить системные журналы и по необходимости «подкрутить по мелочам», но это даже планировать не будем, абсолютно стандартная работа. А сделать надо следующее:

• сделать резервное копирование бывшей площадки для разработки (возможно что-то понадобится нам или заказчику впоследствии);
• после завершения всех работ по проведению ОЭ, снять доработанную и донастроенную конфигурацию сервера приложений с тестовой площадки и перенести на платформу промышленной площадки;
• по-новой пересоздать структуру БД на СУБД и настроить ее для сервера приложений (создать пользователя, под которым сервер приложений будет ходить в БД, выдать ему права и т.д.);
• включить в серверы в промышленную подсеть сделать все необходимые первичные проверки работоспособности (сервер приложений видит БД, может сделать запись, все необходимые протоколы передачи данных включены, из пользовательского сегмента доступен сервер приложений через клиент и т.д.).

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

Вносим задачи в план проекта:

Включаем в ИСР:

Проведение детальной оценки для оперативного планирования работ этапа 5

На этапе 5 нужно завершить настройку ИС на промышленной площадке. Однако есть нюансы:

• за время, прошедшее с 3-го этапа объем данных к первоначальной загрузке изменится (точнее так - если грузим только справочную информацию, то «может измениться» и надо проверять, а если грузим еще и операции, то «точно изменится»);
• перед вводом ИС в промышленную (постоянную) эксплуатацию нам предстоит провести ПСИ, в том числе проверить хождение данных в/из интегрируемые системы. Но если мы будем тестировать при настроенной интеграции с реальными системами, то результаты тестирования «уйдут» в промышленные «ИС-1» и «ИС-2». А значит, нам нужно на время вплоть до окончания проведения ПСИ настроить механизмы интеграции на тестовые «ИС-1» и «ИС-2», провести ПСИ и только затем переключить интеграционные механизмы на промышленные «ИС-1» и «ИС-2».

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

В плане обеспечения технической поддержки и сопровождения:

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

Итак, какие работы нужно включить в план по данной группе:

Вносим работы в наш план:

А далее встроим в ИСР:

Встраивание в ИСР работ 5-го этапа «Перевод в промышленную (постоянную) эксплуатацию»

Согласно кейса, в рамках 5-го этапа:

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

Перенос ИС на промышленную площадку и настройка для проведения ПСИ

Итак, в ходе работ предыдущего этапа у нас уже развернута продуктовая площадка с настроенной бизнес-логикой. Соответственно в ходе данной группы работ нам надо:

• загрузить первоначальные данные из временного хранилища;
• проверить, не появились ли новые справочные данные в заменяемой системе, если да, то догрузить их во внедряемую систему (напомню, в рамках нашего кейса мы перегружаем только справочные данные, а с операциями было бы все значительно веселее :));
• настроить механизмы интеграции на тестовые экземпляры «ИС-1» и «ИС-2»;
• настроить права во внедряемой системе в объеме, достаточном для проведения ПСИ.

Таким образом, запланировать нужно следующие работы:

Вносим в план:

А далее встраиваем в ИСР:

Проведение ПСИ

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

На предварительных испытаниях в рамках данного кейса было 3 проверки, пусть на ПСИ будет 6 проверок:

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

Потенциальный список проверок на этом не исчерпывается. Но эти - наиболее часто применяемые.

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

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

Таким образом следует запланировать следующие работы в рамках данной группы:

Вносим данные работы в план:

И встраиваем в ИСР:

Ввод системы в постоянную эксплуатацию

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

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

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

Вносим эти работы в план:

Далее встраиваем в ИСР:

Организация сопровождения и технической поддержки

Собственно, в данной группе задач, помимо организационных работ, нам нужно:

• передать всю дополнительную информацию и вспомогательную документацию группе тех.поддержки;
• провести обучение администраторов и консультантов тех.поддержки.

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

Таким образом планируем следующие задачи:

Добавляем задачи в план:

И встраиваем их в ИСР:

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

Итоги

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

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

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