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

В предыдущих статьях по формированию плана проекта внедрения с помощью ProjectLibre мы:

• знакомились с описанием кейса, формировали начальный пул ресурсов и начальную ИСР (ссылка на статью);
• знакомились с объемом информации, которую надо собрать для формирования плана проекта (ссылка на статью);
• планировали первый этап проекта «Обследование и анализ» (ссылка на статью).

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

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

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

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

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

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

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

Вносим в план и делаем привязку к вехе окончания 1-го этапа:

А в качестве ресурсов выставляем не только системного инженера, но и серверы с лицензиями:

И тут мы сталкиваемся с 2 нюансами. Первое, мы не можем к ресурсу типа «материал» указать количество. Нам нужно 4 лицензии на операционные системы, а ProjectLibre не позволяет нам выставить количество. И это, я считаю, недоработка ProjectLibre. Для ИТ-проектов это не столь существенно, сейчас мы это обойдем. А вот для проектов, в которых много ресурсов типа «материал», данная недоработка может представлять серьезные неудобства. Ну вот нужно вам 100 упаковок цемента. Вам придется заводить ресурс «100 мешков цемента». Вариант «мешок цемента_1», «мешок цемента_2», «мешок цемента_102» я, само-собой, не рассматриваю. Но и обходка «100 мешков цемента» - не очень удобна. Однако для IT-проектов неудобства незначительны. Идем в ресурсы и набиваем нужное количество лицензий (сразу и для ОС, и для бизнес-ПО):

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

Второй нюанс - в количестве затрат на серверное оборудование. Допустим, проект внешний, 2 сервера закупаются под проект, а 2 сервера выделяются заказчиком из «закромов». Тогда в расходах проекта нужно указывать либо 2 сервера, либо 4 сервера (2 - с реальными затратами, а 2 - с нулевыми затратами).

Другой случай. Проект внутренний, 2 сервера закупаются, а 2 сервера лежат в «закромах». И тут 2 варианта. Либо указывать все 4 сервера по затратам. Либо только 2, аргументируя тем, что затраты ложатся на бюджет подразделения, «владеющего» оборудованием (в том числе и запасом оборудования). Тут все зависит от процессов учета, принятых в компании.

Мы же в нашем тестовом примере оставим в ресурсах задачи 2 сервера, как на предыдущем скриншоте.

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

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

Собственно, на этом основные работы по развертыванию площадок завершены. Осталось только поставить дополнительную верху «ДВ.2.1. Развертывание технических площадок завершено»:

Разработка функциональности ИС

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

А тут мы поступаем примерно так же как при оценке разработки на этапе 1 «Обследование и анализ». То есть, у нас есть (по данным кейса) 400 часов разработки. Соответственно берем еще столько же на работы помимо программирования, а к программированию добавляем еще 80 часов на доделку/переделку/ «навязку бантиков» (небольшие доработки, не входящие в основное задание, но важные для будущих пользователей ИС). Итого имеем на программирование 480 чел-час к планированию.

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

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

Соответственно,  сначала проверку ФА, ТА, показы функциональности заказчику и переносы функциональности отводим по 5%, остальное делим поровну (т.е. на постановку и тестирование - по 40%), то есть получаем:

• постановка - 40 чел-час;
• проверка на соответствие архитектуре - 5 чел-час;
• программирование - 120 чел-час;
• проверка кода ТА - 5 чел-час;
• перенос кода на тест-площадку - 5 чел-час;
• тестирование - 40 чел-час;
• показы заказчику - 5 чел-час.

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

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

• постановка - 40 чел-час;
• проверка на соответствие архитектуре - 5 чел-час;
• программирование - 120 чел-час;
• проверка кода ТА - 5 чел-час;
• перенос кода на тест-площадку - 5 чел-час;
• написание тест-кейсов - 40 часов;
• тестирование - 40 чел-час;
• показы заказчику - 5 чел-час.

Теперь прикинем вот что. Если мы будем делать сразу все 4 задачи параллельно, то нам нужно будет выделить 4 разработчика. И опять же это никоим образом не увеличит нагрузку на бюджет, т.к. стоимость программирования не будет пропорциональным количеству разработчиков, а кол-во чел-час умноженное на ставку программиста за час. Но у нас за месяц (а по затратам программиста - это примерно календарный месяц) аналитики будут задействованы примерно на 25% загрузки. А значит нам нужно будет чем-то их нагрузить, чтобы довести нагрузку до 60-70%. Тестировщик будет нагружен на 50%, что маловато, но терпимо.  ФА, ТА и системный инженер будут задействованы всего на 12%. Но при всем при этом всю разработку по функциональным разрывам мы покроем примерно за 1 месяц.

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

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

Ну и третий момент - надо разделить разработку по каждой прикладной области на:

• постановка - 40 чел-час;
• проверка на соответствие архитектуре - 5 чел-час;
• программирование - 120 чел-час;
• проверка кода ТА - 5 чел-час;
• перенос кода на тест-площадку - 5 чел-час;
• написание тест-кейсов - 40 часов;
• тестирование - 40 чел-час;
• показы заказчику - 5 чел-час.

С последнего и начнем:

Теперь нужно добавить 2 разработчиков (тоже внешних) и 2 тестировщиков (пусть будут внутренние сотрудники). Заходим в форму работы с ресурсами:

И добавляем необходимых сотрудников в соответствующие разделы иерархической структуры ресурсов, созданной нами ранее:

Далее привязываем к задачам соответствующие ресурсы:

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

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

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

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

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

• тип «финиш-старт» к работе 101 «подключение технических сервисов»;
• тип «старт-старт» с задержкой 1 день к работе «Проверка постановок...» (потому что к разработчику должны поступать только проверенные ФА постановки).

По продолжительности устанавливаем 4 недели. И, соответственно, раскидываем по 6 часов в день:

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

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

А затем идем в инструмент «Использование ресурса», и равномерно распределяем нагрузку, так, чтобы последний час пришелся на следующий день после окончания программирования. У нас получается проверка раз в 4 рабочих дня:

Далее планируем планируем переносы с площадки для разработки на тестовую площадку. Перенос осуществляется не по одной задаче, а сразу скопом. У нас 2 спринта, соответственно 2 переноса на каждую из прикладных областей (на самом деле можно организовывать и промежуточные переносы). Один - по результатам разработки 2 недель. Второй - по результатам разработки следующих 2 недель, а третий - по результатам исправлений последнего спринта (а о последнем часто забывают). Теперь по выбору дат переноса. Вспоминаем, что передавать разработку на тестирование можно только после проверки кода техническим архитектором. Посмотрим запланированные даты проверки (см. предыдущий скрин). У нас получается 19.05, 25.05, 29.05, 04.04 и 08.04. Соответственно, первый перенос должен быть сразу после 25.05, второй - после 04.04, третий - после 08.04. У нас 5 часов на каждую прикладную область. Соответственно, выставляем нагрузку системному инженеру по 1 часу для каждого переноса и оставляем еще 2 часа для дополнительных переносов по результатам исправлений.

Ставим в план. Здесь «красиво» не привяжешься к задачам (можно, но для этого нужно делать дополнительно 8 * 4 = 32 задачи, такая детализация в общем плане будет излишней). Поэтому привязку делаем типа «старт-старт» с задачей по проверке кода техническим архитектором со смещением 1 день. А далее выставляем нагрузки на конкретные даты (следующий рабочий день после 25.05). Итак:

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

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

• 25% времени на тест-кейсы по одной из двух прикладных областей;
• 25% времени на тестирование разработанной и проверенной ТА функциональности по одной из двух прикладных областей;
• 25% времени на тест-кейсы по другой из двух прикладных областей;
• 25% времени на тестирование разработанной и проверенной ТА функциональности по другой из двух прикладных областей.

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

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

А теперь накидываем по 6 часов (3+3) в день до даты первого переноса. При этом важно понимать, что сначала должна появиться постановка, а только затем к ней можно писать тест-кейс, поэтому данная задача в любом случае должна закончиться после задачи по детальной постановки (т.е. не ранее 14-15 мая):

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

Далее переходим к задаче по тестированию. Тут нам нужно распределить 40 часов на тестирование пропорционально объему задач, перенесенных на тестовую площадку. Само-собой, тестировщики могут протестировать только то, что перенесено. В рамках данного кейса делим 40 чел-час на 5 частей (по 8 чел-час / часть). По 2 части (16 чел-час) берем на тестирование функциональности  после первого и второго переносов. И одну часть (8 чел-час) - на тестирование функциональности по последнему переносу. Тестирование начинаем на следующий день после переноса. Чем раньше будет протестировано, тем лучше. Но планируем нагрузку на 6 часов в день.

Делаем привязку к переносу, также «старт-старт» со смещением в 1 день:

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

То есть у нас получается, что 1 часть разработанной функциональности тестируется с 27.05 по 03.06, 2 часть - с 08.06 по 16.06 (16.06 - 1 чел/час по каждой прикладной области), 3 часть - с 16.06 (2 чел-час) по 18.06. Опять-таки, можно сделать 3 отдельными задачами по каждой прикладной области (всего 12), но мы оставим по одной задаче на каждую прикладную область.

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

В начале делаем связку с задачами по тестированию типа «старт-старт» и ставим задержку, допустим, 1 день (не принципиально, т.к. планировать будем по датам):

То есть в наших реалиях - это 08.06 (2 часа), 19.06 (2 часа), 22 июня (1 час):

Собственно, мы распланировали все задачи для выполнения цели №2 - разработки функциональности по функциональным разрывам. Остается только установить веху «ДВ.2.2. Разработка по функциональным разрывам выполнена»:

Настройка функциональности

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

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

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

• настройка стандартной функциональности - 3 недели по 6 чел-час в день  (90 чел-час);
• настройка разработанной функциональности - 1 неделя по 6 чел-час в день (30 чел-час).

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

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

Как видно из скриншота, в период с 14.05 по 05.06 аналитики вовсе не задействованы.

В период с 08.06 по 22.06 у аналитиков есть несколько задействованных дней (это как раз показы разработанной функциональности), но большую часть периода они также не задействованы.

Ну и после 22.06 аналитики также не задействованы (скриншота приводить не буду).

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

Теперь наберем по 90 чел-час на каждую прикладную область в инструменте «Использование ресурса»:

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

После окончания разработки следует настроить и разработанную функциональность под бизнес-процессы (имеется в виду не настройка для показов, а уже полная настройка). Разработка заканчивается 10.06, поэтому приступать можно 11.06. И у нас 30 чел-час трудозатрат на каждую из прикладных областей. Однако с 08.06 по 22.06 у аналитиков проходят встречи с заказчиком по показу разработанной функциональности.  Возможны замечания к ней, доработки. Поэтому лучше данную часть работы выполнить уже после показов и дать несколько дней на потенциальные исправления. Соответственно, последний показ планируется 22.06, 23.06 и 24.06 даем на мелкие исправления. А с 25.06 начинаем настраивать функциональность, связанную с функциональными разрывами:

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

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

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

А следовательно и сутевая часть документа будет состоять из 3 разделов:

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

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

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

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

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

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

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

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

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

Соответственно, все задачи необходимые для выполнения данной цели запланированы. И осталось только установить веху «ДВ.2.3. Функциональность внедряемой ИС настроена и проверена»:

Примечание!!! Дата вехи 07.07, а не 03.07, потому что нужно оставить зазор по времени на устранение огрех.

Устранение огрех формирования ИСР

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

На самом деле тут нет ничего страшного. При удалении строк, ровно как и при добавлении, связи, сделанные ранее корректируются автоматически.

Давайте удалим задачу «1.2.1.4 Разработка механизмов импорта первоначальных данных» так как, мы ранее «выяснили», что для импорта первоначальных данных мы будем пользоваться исключительно штатными механизмами:

После удаления указанные на скриншоте задачи автоматически уменьшатся на единицу:

Ну и теперь остается скорректировать нумерацию ИСР, а то у нас после «1.2.1.3. Разработка механизмов интеграции» сразу идет «1.2.1.5. Настройка функциональности ИСР». Само-собой не забываем и подзадачи, если таковые имеются:

Продолжение - в следующей части (ссылка на вторую часть).