ОСН_8. ProjcetLibre. Планирование этапа 1 "Обследование и анализ"

В первой части серии статей по формированию плана проекта в ProjectLibre мы:

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

Примечание!!! Здесь и далее под ИСР мы будем подразумевать именно иерархическую структуру работ.

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

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

Планирование работ по обследованию прикладных областей

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

• прикладная область 1 - 5 встреч;
• прикладная область 2 - 4 встречи;
• прикладная область 3 - 3 встречи;
• прикладная область 4 -5 встреч.

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

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

Далее расставляем исполнителей. Это Аналитик_1, Аналитик_2, Аналитик_3 и Аналитик_4 (соответственно прикладной области). Напомню, что для добавления ресурсов необходимо двойным кликом по соответствующей строке зайти в интерфейс задачи, перейти на закладку «Ресурсы» (1), нажать кнопку «Назначить ресурс» (2), в открывшемся окне выбрать один или несколько ресурсов(3), после этого кликнуть кнопку «Назначить» (4), закрыть окно назначение ресурсов «крестиком» (5):

В результате этого ресурс будет назначен на задачу. Это будет отражено в интерфейсе задачи на вкладке «Ресурсы», в инструменте «Гант» в табличной части в поле «Назначение ресурса»(2) и на диаграмме Ганта (3):

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

Явным образом подготовка ко встрече и проведение встречи занимает не целый день. Поэтому указываем приблизительную нагрузку. При этом на данном этапе нагрузка указывается очень приблизительно - примерно четверть дня (до 2 чел-час), примерно полдня (до 4 чел-час), примерно три четверти дня (до 6 чел-час) и целый день (до 8 чел-час). У нас по задачам получается 3 часа, но возможны задержки на встрече, возможно чуть больше нужно для подготовки, поэтому считаем, что в целом на встречу тратится полдня, и ставим по 4 чел-часа.

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

В открывшемся интерфейсе видим, что аналитикам на соответствующие задачи выставлено по 8 чел-часов:

Корректируем на 4 чел-час:

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

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

Напомню, что для того, чтобы выставить связи, нужно выставить в таблице задач номер строки задачи-предшественника (поле «Предшествующие»):

Затем двойным кликом зайти в интерфейс задачи, перейти на закладку «Предшественники» (1), указать тип связи (2) и выбрать смещение по времени в днях (3):

В результате получаем автоматическую установку дат начала и окончания работ и привязку к задаче-предшественнику:

Аналогичные операции делаем с прочими задачами по фитбэкам:

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

Итак первый результат этапа получен. Фиксируем дополнительную веху «ДВ 1.1 Обследование прикладных областей завершено»:

Детализация требований

Переходим к следующей цели - детализации требований, указанных в ТЗ. У нас уже есть детализация по прикладным областям. Осталось детализировать требования:

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

И все это отразить в документе «ЧТЗ».

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

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

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

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

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

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

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

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

Для написания ЧТЗ со стороны работ по интеграции этого достаточно.

Переходим к группе работ по импорту первоначальных данных. Соответственно для достижения текущей цели нам надо:

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

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

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

Начнем с разбиения:

И теперь планируем подзадачи по изучению объектов данных на стороне ИС-источника. Для изучения отводим по 3 дня каждому аналитику. Здесь логической связки с предшественником нет. Однако надо смотреть на уже запланированную нагрузку. Для этого используем инструмент «Использование ресурса»:

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

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

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

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

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

Соответственно, этими задачами занимается системный инженер. Работы по данным задачам могут начинаться сразу после старта проекта. На первую задачу дается 5 дней, на вторую - 2 дня. Вносим в план:

После выполнения данных задач у нас будет вся необходимая информация для написания документа «ЧТЗ». И тут есть 2 нюанса.

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

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

Далее подставляем в качестве исполнителя во все подзадачи по написанию ЧТЗ, кроме проверки. Делаем связки соответствующей части с соответствующим результатом по обследованию. Устанавливаем продолжительности:

• написание ЧТЗ в части тех.требований - 2 дня;
• в части функциональных требований - 5 дней;
• в части требований к интеграции - 4 дня;
• в части импорта первоначальных данных - 3 дня.

Кроме того, надо следить за тем, чтобы у исполнителя не было превышения рабочего времени. Поэтому ставим дополнительные связки между частями ЧТЗ в порядке исполнения:

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

Итак, мы спланировали достижение второй цели первого этапа проекта - детализации требований. Соответственно, этот результат мы должны будем достигнуть 05.03.

Ставим дополнительную веху «ДВ_1.2. Детализация требований выполнена», дата - 06.03:

Построение архитектуры

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

Для построения архитектуры требуется отрисовать и описать БП. К 12.02 все необходимые данные для этого будут получены в ходе обследования. Для начала изучим загрузку аналитиков, используя инструмент «Использование ресурса»:

Из скриншота видно, что описанием БП аналитики могут начать заниматься с 18.02 по 25.02. А далее - начиная с 02.03. В то же время результаты по обследованию будут получены 12.02. Соответственно, тут нет смысла привлечения дополнительных сотрудников из-за 3 рабочих дней.

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

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

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

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

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

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

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

• для описания БП прикладной области 1 - задачу 37;
• для описания БП прикладной области 2 - задачу 38;
• для описания БП прикладной области 3 - задачу 39;
• для описания БП прикладной области 4 - задачу 40.

Сам процесс описания БП довольно трудоемок. Мы установим 10 рабочих дней для каждой прикладной области. Но в реальности для описания БП может потребоваться и больше времени, и больше сотрудников. Может и меньше. Но нам просто нужна опорная цифра.

Фиксируем в план:

Однако мы помним, что 2 дня в этом периоде уже заняты под другую задачу, поэтому идем в «Использование ресурса» и правим нагрузку:

Итого получаем задачи с разрывом и смещением даты завершения на 2 рабочих дня:

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

Теперь рассмотрим интересную ситуацию. Ранее мы делили задачи на подзадачи. А теперь для удобства нам надо слить 8 задач в 2 задачи:

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

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

Ну и, конечно, нумерацию всех задач и групп задач в группе «1.1.1 Проведение работ» надо также подправить:

Связки править не надо (все скорректируется автоматически).

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

А также 5 дней на состыковку прикладных областей друг с другом:

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

А также задачу по проектированию покрытия функциональных разрывов. Связка - с задачами по анализу покрытия БП стандартной функциональностью и задаче по состыковке прикладных областей. Продолжительность - 5 дней. Исполнитель - функциональный архитектор:

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

Также нужно проверить не превышена ли нагрузка технического архитектора:

Как видим, с нагрузкой все в порядке.

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

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

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

На описание первых 2 частей выделяем по 4 дня. На описание последней - 2 дня:

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

По описанию в плане интеграции:

По описанию в плане импорта первоначальных данных:

Проверяем нагрузку функционального архитектора:

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

Проверяем нагрузку технического архитектора:

И здесь видим, что с нагрузкой по задаче описания архитектуры в плане интеграции все в норме. А по задаче описания в плане импорта первоначальных данных - конфликт 05.03. с ранее запланированной задачей. Поэтому переносим нагрузку по проверяемой задаче с 05.03 на 10.03:

Соответственно, в «Ганте» получается так:

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

Ставим дополнительную веху «ДВ.1.3. Архитектура построена»:

Проектирование

А мы переходим к очередной цели этапа - созданию пояснительной записки к техническому проекту.

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

Документ большой. Однако к этому моменту большая часть его содержания уже подготовлено. Поэтому, как и в случае с ЧТЗ, мы будем писать его по частям. Писать его будет младший аналитик. С РП - шаблон документа и описание всех «нетехнических» частей документа.

Давайте начнем с того, что поделим задачу по написанию документа на части:

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

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

По описанию автоматизируемых БП делаем привязку к задаче 25 (проверка описанных БП). По описанию покрытия БП... делаем привязку к задачам 27-31, делаем привязку к ним.

А вот для описания разрабатываемых объектов надо предварительно спланировать задачу «1.1.1.5.1. Формирование задания на разработку по функциональным разрывам» (задача 54). Задание на разработку пишут аналитики (каждый по своей прикладной области), а проверяет задание функциональный архитектор (и делает это уже после построения функциональной архитектуры). Поэтому данную задачу разбиваем на 5 частей:

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

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

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

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

Далее привязываем подзадачу «Описание разрабатываемых объектов ИС» для написания пояснительной записки к группе задач 54 «Формирование задания на разработку по функциональным разрывам».

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

Далее для задачи 80 «Описание объектов и механизмов к разработке (для интеграции ИС)» сначала надо спланировать задачу «1.1.1.2.4. Подготовка задания на разработку API на стороне внедряемой системы». Переходим к ней.

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

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

Теперь планируем ее по продолжительности, ресурсам и зависимостям. Соответственно, исполнитель у нее - технический архитектор. По продолжительности пусть будет 5 дней. Ну и завязать ее надо на задачу 35 по детализации потоков. Вносим:

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

И видим, что у нас после планирования очередной задачи у технического архитектора получается 4 дня по 16 рабочих часов. Это неприемлемо. Ищем свободное время, и получается, что ТА сможет заняться данной задачей в период с 12.03 по 15.03 включительно. Переносим задачу на этот период:

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

В рамках подзадачи по общему описанию импорта первоначальных данных. Нужно описать, какие данные переносятся, требуют трансформации или нет, куда загружаются. Соответственно привязываем ее к группам задач 37 («Изучение объектов данных для переноса в системе-источнике») и 43 («Анализ объектов для загрузки данных во внедряемой системе»), а также к задаче 42(«Анализ данных на предмет необходимости в трансформации»). А описание механизмов делаем на основании задачи 48 («Анализ и согласование способов переноса данных и временного хранилища»). Подзадачу «Описание технических площадок и их параметров» связываем с задачами 50 («Детализация технических параметров функционирования ИС») и 51 («Выпуск технической спецификации к внедряемой системе»).

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

На эту задачу завязываем подзадачу из написания пояснительной записки «Описание порядка развертывания площадок»:

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

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

Ну а теперь привязываем последнюю подзадачу из написания пояснительной записки к «формированию реестра разработки»:

Теперь все задачи привязаны. Но что-то напрягает... А напрягает, что задача «Реестр разработки» - странное название для задачи. Поэтому переименуем ее в «внесение реестра разработки в ПЗ»:

Да, так лучше. Теперь смотрим хронологию задачи:

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

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

Делаем дополнительные связки для фиксации порядка описания разделов ПЗ:

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

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

Итого 14 дней - более чем достаточно. Многие из разделов, где указан 1 день, на самом деле займет от силы 1-2 часа. Но учитывая, что мы планируем привлечь к работе младшего аналитика, то нормально (будет еще время осмысленно вчитаться в содержание, а не просто «накопипастить»).

Теперь нам надо понять, хватит ли 1 младшего аналитика. Для этого смотрим дату окончания последней подзадачи по написанию ПЗ. Это 13.04. А далее добавим связку на задачу (точнее, на группу) по написанию ЧТЗ и посмотрим, сдвинется ли эта дата или нет:

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

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

Получилась задержка в 12 дней, если делать больше - дата завершения задачи в целом начнет двигаться.

Остается добавить сюда задачу на проверку. Соответственно, задачу сделаем одну, но туда добавим всех аналитиков, ФА, ТА и системного инженера. Поставим 2 дня каждому проверяющему:

Соответственно выполнение очередной задачи спланировано. Ставим промежуточную веху:

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

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

Что у нас должно быть на следующем этапе:

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

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

Давайте чуть подробнее:

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

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

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

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

И видим, что у него 2 дня по 16 рабочих часов выходи. Поэтому смещаем время исполнения задачи:

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

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

Скриншот с нагрузкой приводить не буду - там конфликтов нет.

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

И через инструмент «Использование ресурса» ставим по 2 часа каждому специалисту:

Собственно на этом последняя цель первого этапа «Обследование и анализ» спланирована. Остается сделать несколько вещей. Во-первых, поставить последнюю дополнительную веху первого этапа - «ДВ.1.5. Оперативное планирование работ этапа 2 выполнено»:

Во-вторых, выставляем первую основную веху проекта «ОВ.1. Этап 1 завершен»:

Обратите внимание, что веха выставлена на уровне этапов, а не внутри этапа.

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

Если есть превышения - поправить план.

Таким образом планирование работ 1 этапа проекта завершено.

Итоги

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

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

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

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