ОСН_11. Планирование этапа 2 "Разработка и настройка" (часть 2)

Продолжение. Первая часть - здесь.

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

Собственно, скорректировали. А теперь переходим с следующей цели - разработке механизмов интеграции. Соответственно, здесь надо запланировать разработку API для обменов внедряемой ИС с «ИС-1» и «ИС-2».

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

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

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

• все API, которые необходимо разработать для обмена с «ИС-1» связаны исключительно со стандартной функциональностью;
• все API, которые необходимо разработать для обмена с «ИС-2» связаны исключительно с разрабатываемой функциональностью;
• их пропорция по трудозатратам - 50/50, то есть 75 чел-час на разработку API для интеграции с «ИС-1» и 75 чел-час на разработку API для интеграции с «ИС-2».

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

Для начала аналогично разработке по функциональным разрывам посчитаем трудозатраты. Итак, у нас 75 чел-час на программирование. Добавляем 20% на доработки, исправления и нюансы, которые могут всплыть на 1 этапе. Итого на программирование у нас по 90 чел-час. Теперь 75 чел-час надо поделить на прочие работы:

• постановка - 40% (30 чел-час);
• проверка на соответствие архитектуре - 5% (5 чел-час);
• проверка кода ТА - 5% (5 чел-час);
• перенос кода на тест-площадку - 5% (5 чел-час);
• тестирование - 40% (30 чел-час);
• показы заказчику - 5% (4 чел-час).

Примечание!!! По «процентовке» у нас получилось 72 чел-часа, и оставшиеся 3 часа мы распределили на проверки и перенос.

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

• постановка - 30 чел-час (системный аналитик);
• проверка на соответствие архитектуре - 5 чел-час (технический архитектор);
• программирование - 90 чел-час (разработчик);
• проверка кода ТА - 5 чел-час (технический архитектор);
• перенос кода на тест-площадку - 5 чел-час (системный инженер);
• написание тест-кейсов - 30 часов (тестировщик);
• тестирование - 30 чел-час (тестировщик);
• показы заказчику - 4 чел-час (системный аналитик).

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

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

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

Далее, через инструмент «Использование ресурса» выставляем 30 чел-час нагрузки для системного аналитика. Ставим по 6 часов в день:

Далее требуется спланировать проверку постановок. Для данной группы задач это делает технический архитектор. У нас на данную задачу есть 5 часов. Соответственно, получается, что можно спланировать работу так, чтобы проверка выполнялась ежедневно со смещением в 1 день. Делаем привязку задачи по проверке к написанию детальных постановок на разработку API, тип связки указываем «старт-старт», задержку выставляем в 1 день:

Далее через инструмент «Использование ресурса» выставляем нагрузку для технического архитектора по данной задаче:

Теперь нам нужно посмотреть нагрузку разработчиков и понять, нужен ли отдельный разработчик или вполне хватит уже запланированных ресурсов. Нам нужен 1 разработчик начиная с 13 мая на 90 чел-час (или 2 по 45 чел-час, или 3 по 30 чел-час). Смотрим:

Итак, уже запланированные разработчики будут заняты на фулл-тайм с 14.05 по 10.06. И это очень удачная ситуация с точки зрения рассмотрения. Потому что однозначно сказать, что нужно сделать в сложившейся ситуации нельзя:

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

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

Поэтому добавляем в пул ресурсов специалиста «Разработчик_5»:

Далее задачу по разработке API связываем с задачей по проверке соответствия постановок архитектуре и выставляем «Разработчика_5» в качестве исполнителя данной задачи:

Далее через инструмент «Использование ресурса» выставляем нагрузку:

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

Соответственно, тестировщики заняты практически на фулл-тайм с 06.05 по 18.06. И вот здесь у нас тестировщики внутренние. Давайте разыграем ситуацию, что больше тестировщиков невозможно выделить на проект. Ну то есть внутренние тестировщики все заняты, а подряжать внешних смысла не имеет, так как у нас есть задача по реализации API для интеграции с «ИС-2», для которой необходимо сначала реализовать разработку по функциональным разрывам. Иными словами, мы не будем иметь выгоды по времени, даже если API к «ИС-1» реализуем раньше. Зато при привлечении внешних ресурсов мы увеличим нагрузку на бюджет проекта, плюс получим прямые затраты.

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

Итак, давайте перепланировать. Разработчики у нас заняты с 14.05 по 03.06. Кроме того тестирование по функциональным разрывам закончится 18.06, а в процессе тестирования может возникать необходимость в доработках/переделках. Поэтому начало разработки по API лучше начать с 22.06. Соответственно, к 19.06 по API для «ИС-1» должны быть проверены все постановки, а к 18.06 все постановки выполнены.

Другая ситуация по API для «ИС-2». Здесь начать писать постановки системный аналитик сможет только после того, как доработки будут сделаны и протестированы (и, при необходимости, доработаны) то есть с 22.06. Поэтому нам вполне хватит одного системного аналитика.

Но первым делом нам нужно отвязать «Программиста_5» от задачи по программированию:

В результате:

Далее идем в пул ресурсов и удалим «Программиста_5» из ресурсов проекта:

В результате:

Теперь удаляем все связки по задачам разработки API для «ИС-1»:

Далее к задаче по программированию добавляем «Разработчика_1» и делаем привязку к окончанию работ по тестированию прикладной области_1:

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

Далее привязываем задачу по проверке написания постановок к задаче по программированию с типом связки «старт-финиш»:

Проверяем в инструменте «Использование ресурсов»:

Как видно, здесь не так гладко перенеслась нагрузка, но в принципе дает в сумме 5 часов, оставим так.

И теперь привязываем работы по написанию постановок на разработку API, тут у нас связка будет «финиш-финиш», а задержка - минус 2 дня:

Проверяем нагрузку:

Здесь автоматически получилось совсем ерунда, будем править:

И вот таким образом получается, что написание постановок на разработку API у нас должно проводиться с 11.06 по 18.06. Соответственно, проверка постановок - с 15.06 по 19.06. А разработка - с 22.06 по 10.07.

Далее планируем нагрузку тестировщика (будем привлекать «Тестировщика_1». Смотрим, что у него по нагрузке, начиная со второй половины июня:

И видим, что с 19.06 он не задействован в проекте.

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

Соответственно, ставим задачу по написанию тест-кейсов с 19.06 по 25.06. Привязки делаем две:

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

И распределяем нагрузку:

Далее вернемся к разработке. После того, как программист реализует функциональность, технический архитектор должен проверить код. У нас разработка API ведется с 22.06 по 10.07. На проверку кода у технического архитектора есть 5 часов, их надо распределить равномерно, последняя проверка - 13.07. Как вариант - 25.06, 30.06, 03.07, 08.07 и 13.07. Соответственно саму задачу привязываем к программированию (тип «старт-старт») с задержкой в 3 дня:

И выставляем нагрузку в соответствующие даты:

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

Переносить мы можем только код, проверенный техническим архитектором. Соответственно, исходя из графика его проверки первый перенос будем делать 01.07, второй - 09.07, третий - 14.07. И один перенос - про запас.  Соответственно связку задачи по переносам делаем с задачей по проверке (тип «старт-старт») со смещением 4 дня:

А далее выставляем нагрузку в нужные даты в инструменте «Использование ресурса»:

Переходим к планированию тестирования. Соответственно, тестировать API мы сможем тогда, когда будут готовы тест-кейсы и код будет перенесен на тестовую площадку. Закончить тестирование мы должны после последнего переноса. Исходя из этого нам надо равномерно распределить нагрузку от следующего дня после первого переноса до последнего переноса + 3 дня. По датам получается с 02.07 по 17.07.

Делаем привязку к задаче по подготовке тест-кейсов (тип «финиш-старт») и к задаче по переносу разработки на тестовую площадку (тип «старт-старт» + 1 день):

И выставляем равномерно нагрузку. Нам надо 30 часов поделить на 12 дней. Получается 6 дней по 3 часа и 6 дней по 2:

Соответственно, протестированную функциональность можем показывать заказчику. Намечаем примерно даты, например, 07.07, 13.07 и 20.07. Продолжительность поставим по 1 часу. И в резерве останется 2 часа. Связку ставим к задаче по тестированию  (тип «старт-старт») со смещением в 3 дня:

Далее через инструмент «Использование ресурса» выставляем нагрузку на показы в соответствующие даты:

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

Тестирование функциональности по прикладным областям заканчивается 18.06. Соответственно, с 22.06 мы можем начинать писать детальные постановки на разработку API для интеграции с «ИС-2». Делаем связки к 4 задачам по тестированию:

И выставляем нагрузку. Напомню, это 30 чел-час:

Далее ставим в план задачу по проверке постановок техническим архитектором. У нас 5 чел-час есть на это. Соответственно, ставим привязку к задаче по написанию постановок (тип «старт-старт» со смещением в 1 рабочий день):

Далее выставляем нагрузку ТА:

Далее планируем задачу по написанию тест-кейсов. Задачу привязываем к окончанию проверок постановок и выставляем исполнителем «Тестировщика_1»:

Теперь переходим к распределению нагрузки. Нам надо распределить 30 чел-час:

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

Далее распределяем 90 чел-час разработки:

Код должен быть проверен техническим архитектором. Проверку надо распределить равномерно, последняя проверка должна быть после окончания разработки кода. Соответственно, привязку делаем к разработке (тип «старт-старт») со смещением 3 дня:

Далее распределяем нагрузку равномерно:

Далее планируем перенос разработанного кода на тестовую площадку. Аналогично как и при разработке API для интеграции с «ИС-1», планируем 3 переноса (2 оставляем в резерве). Первый перенос сделаем как можно раньше (после первой проверки) - 30.06, второй - 08.07, третий - 16.07. Соответственно привязку переноса делаем к задаче по проверке разработанного кода со смещением в 1 день:

Далее выставляем нагрузку по переносу:

Соответственно после переноса кода на тестовую площадку (и написания тест-кейсов) тестировщики могут тестировать разработку. Привязываем задачу к переносу кода на тестовую площадку (тип «старт-старт») со смещением 1 день и добавляем в качестве исполнителя «Тестировщика_1»:

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

Ну и остается только запланировать показы. Делаем привязку показов к тестированию (тип «старт-старт») со сдвигом 4 дня:

Выставляем нагрузку на показы. Сделаем, как при разработке API для «ИС-1», 3 показа:

Итак, все задачи для достижения очередной цели спланированы. Осталось только установить веху «ДВ.2.4. Разработка API выполнена»:

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

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

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

Соответственно, привязываем задачу по настройке механизмов интеграции с «ИС-1» к окончанию показов разработки этих механизмов, указываем 6 дней и выставляем исполнителем системного аналитика:

Корректируем нагрузку:

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

Проверяем в инструменте «Использование ресурса»:

Теперь все нормально.

Аналогичным образом планируем настройку интеграции с ИС-2. Показы обменов заканчиваются 21.07. Однако у нас получается ограничение по ресурсам (до 29.07 системный аналитик занят настройкой механизмов интеграции с ИС-1). Поэтому делаем 2 связки - к окончанию показов и к окончанию настроек механизмов интеграции с ИС-1 (+ 1 день - зазор между настройками):

Корректируем нагрузку:

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

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

Правим нагрузку:

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

И корректируем нагрузку:

Итак, все задачи для достижения очередной цели мы запланировали. Осталось только внести в план веху «ДВ.2.5. Механизмы интеграции настроены и проверены»:

Написание документации по этапу 2

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

Здесь у нас только 2 документа:

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

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

Итак, приступим. Начнем с документа «Программа и методика предварительных испытаний». Часть с проверкой документации пишет функциональный архитектор. Описываются все требования к документации этапов 1-3. Источниками требований являются:

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

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

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

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

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

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

Саму задачу привязываем к вехе окончания этапа 1 и задачам по проверке постановок на соответствие архитектуре:

Далее выставляем нагрузку:

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

Чтобы сориентироваться по датам, нужно посмотреть даты завершения тестирования по всем разработкам. У нас получается, что тестирование разработки по функциональным разрывам заканчивается 18.06, а по разработке API - 20.07. На сбор всех сведений для документа и написания его в части разработки по прикладным областям 5 дней (по 6 часов) младшему аналитику должно хватить. Поэтому делим задачу на 2 части:

• написание документа «Отчет о проведении разработки» в плане функциональных разрывов;
• написание документа «Отчет о проведении разработки» в плане API.

Работы по первой части планируем за 5 рабочих дней до окончания тестирования разработки по API (то есть с 06.07). Для этого делаем связку типа «финиш-финиш»:

И устанавливаем нагрузку по 6 чел-час:

Вторую часть также привязываем к окончанию разработки по API, но уже со связкой «финиш-старт» и выставляем 3 дня на сбор данных и написания документа:

И выставляем нагрузку:

Итак задачи для достижения очередной цели запланированы. Осталось внести веху «ДВ.2.6. Документация для этапа 2 написана»:

Оперативное планирование работ этапа 3

И у нас осталась последняя цель - оперативное планирование этапа 3. Собственно, тут 2 задачи:

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

Давайте сначала разберемся с первой из них. Для начала следует понять, что предстоит на следующем этапе. Если коротко - это:

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

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

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

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

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

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

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

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

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

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

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

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

В общем же плане мы разделим задачу «1.2.1.6.1. Оценка задач по подготовке ИС к ОЭ» на:

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

Оценку задач по импорту данных мы можем начинать как только будет проведена разработка и настройка функциональности по функциональным разрывам, поэтому делаем связку с группой задач «1.2.1.4. Настройка функциональности ИС». В исполнители назначаем аналитиков. По продолжительности - даем 3 дня (по 6 часов):

Далее выставляем нагрузку:

Переходим к оценке задач на обучение пользователей. Участники - те же. Продолжительность - 2 дня (по 6 часов). Необходимы те же исходные данные, что и для предыдущей задаче, поэтому связку делаем к ней (чтобы не усложнять):

Корректируем нагрузку:

По прочим аналитикам будет аналогичная ситуация.

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

Смотрим по нагрузке (по аналитикам приведу только 1 скриншот):

У системного аналитика образуется превышение трудозатрат:

Поэтому переносим ему данную задачу на 21.08-24.08:

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

Корректируем нагрузку:

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

Корректируем нагрузку:

Собственно, все задачи для выполнения текущей цели запланированы. Остается поставить веху «ДВ.2.7. Оценка задач этапа 3 выполнена»:

Кроме того, это финальная цель этапа 2. Поэтому ставим еще и веху об окончании этапа:

Итоги (по обеим частям)

В рамках данной статьи мы рассмотрели планирование задач по этапу 2 «Разработка и настройка»:

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

Также убрали лишние задачи, включенные в ИСР при формировании.

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