Что такое overview планирование
Планирование
Содержание
Что такое планирование?
Планирование — это вид деятельности, связанный с постановкой целей, задач и действий в будущем. Это одна из основных функций менеджмента. Планирование в самом общем виде подразумевает выполнение следующих этапов:
Фyнкция плaниpoвaния oзнaчaeт выpaбoткy и пpинятиe oпpeдeлeннoгo пocтaнoвлeния, пиcьмeннoгo или ycтнoгo, в кoтopoм пepeд oбъeктoм yпpaвлeния бyдeт пocтaвлeнa тa или инaя цeль, зaдaчa. Этo пocтaнoвлeниe — yпpaвлeнчecкoe peшeниe. Плaниpoвaниe — этo oдин из cпocoбoв, c пoмoщью кoтopoгo pyкoвoдcтвo oбecпeчивaeт eдинoe нaпpaвлeниe ycилий вcex члeнoв opгaнизaции к дocтижeнию ee oбщиx цeлeй. С дaннoй фyнкции нaчинaeтcя пpoцecc yпpaвлeния, oт ee кaчecтвa зaвиcит ycпex opгaнизaции.
Задача плaниpoвaния
Пo cвoeй cyти фyнкция плaниpoвaния пpизвaнa oтвeтить нa cлeдyющиe ocнoвныe вoпpocы:
Кyдa мы xoтим двигaтьcя? Мeнeджepы дoлжны, oцeнивaя вoзмoжнocти и yгpoзы в oкpyжaющeй opгaнизaцию cpeдe, oпpeдeлить, кaкими дoлжны быть цeли opгaнизaции # и чтo мoжeт пoмeшaть дocтижeнию этиx цeлeй;
Проблема реализации
Большинство менеджеров с неохотой занимаются систематическим планированием. Они более склонны действовать, чем сидеть и размышлять о поведении. Нехватка времени и загруженность работой также затрудняют для менеджеров тщательное планирование. Для многих, планирование – это скучная и утомительная работа, которую можно легко и быстро заменить непосредственными действиями.
Одна из проблем, актуальных для предпринимателей, менеджеров, консультантов и всех тех, кто на практике занимается совершенствованием систем управления, это проблема несоответствия стратегии компании и механизма ее реализации, то есть стратегического разрыва. Сегодня разработано достаточно большое количество технологий преодоления данного разрыва. Так, Майкл Ковени в своей книге «Стратегический разрыв: Технологии воплощения корпоративной стратегии в жизнь» описывает многоэтапный процесс эффективной реализации стратегии путем интеграции лучших приемов управления эффективностью бизнеса (BPM) с новейшими информационными технологиями. Технология BSC (The Balanced Scorecard) подразумевает создание такого механизма управления предприятием, при котором стратегические показатели эффективности его деятельности будут соединены через систему причинно-следственных связей со стратегическими инициативами и конкретными мероприятиями по выполнению этой стратегии.
ИТ-поддержка планирования
Число программных продуктов для поддержки всего цикла корпоративного управления, включая планирование, на российском рынке быстро растет. То и дело появляются новые системы отечественных разработчиков, локализуются зарубежные продукты. На решение этих же задач претендуют и так называемые КИС, (корпоративные информационные системы), «бум» которых начался несколько раньше.
Роль планирования в управленческом процессе
Организация в процессе планирования определяет свои действия на некоторый временной промежуток, характер действий и их последовательность. Между процессом управления и планированием существует жесткая взаимосвязь и взаимозависимость. Управление призвано добиваться целей, поставленных планированием, и держать данный процесс под постоянным контролем.
В общих чертах планированием обеспечивается:
Уровни планирования
Планирование в организации имеет несколько обязательных уровней.
Стратегическое планирование
Первый уровень. Его задача: сформировать долгосрочные цели, нарисовать перспективы, к которым организации следует стремиться. Этого невозможно достичь без определения организацией собственной миссии. Когда организация говорит о миссии, ей приходится дать себе отчет о смысле ее существования, насколько она необходима в данном обществе, и какую пользу может принести ее деятельность.
Обычно формулирование миссии производится в терминах бизнес-достижений, положения на локальном специфическом рынке, либо отношений с основными потребителями, клиентурой. Соответственно, стратегические цели указывают, чего именно организация стремится достичь в глобальном масштабе.
Стратегическое планирование не слишком подробно останавливается на деталях. Его основная задача – в общих чертах наметить путь к желаемому результату. Организация, понимая динамический характер происходящих в обществе процессов, должна иметь некоторой набор стратегий, из которых одна будет базовой, другие же реализуются в случае конкретных, не всегда желательных, ситуаций. Стратегическое планирование призвано задать границы вероятного пространства реализации основной деятельности, пространства конкретного бизнес-планирования, и базу для планирования повседневного (оперативного).
Бизнес-планирование
Второй уровень. Оно связывает деятельность по достижению конкретных результатов с подключаемыми ресурсами.
В первую очередь упор делается на грамотное использование финансовых ресурсов, но одновременно дается оценка и планируется использование ресурсов человеческих, информационных, интеллектуальных, статусных.
Бизнес-планирование показывает, насколько реально достижим намеченный уровень результатов. Позитивная роль бизнес-планирования заключается также в придании планам организации систематического вида, преобразовании общих идей в четкие показатели определенного вида.
Оперативное планирование
Третий уровень. Здесь осуществляется переход от обобщенного видения миссии и заданных перспектив на уровень решения повседневных задач. Оперативное планирование полностью основывается на конкретике: действия, их объем, процедуры, нормирование, определение сроков, объем реальных затрат.
Показатели данного уровня планирования полностью измеримы, поэтому легче всего поддаются контролю. Оперативное планирование активно включает человеческий фактор в процедуру управления деятельности организации. Повседневное планирование ориентируется на кратковременные сроки. Предусматриваются опорные точки для анализа текущих результатов следования оперативному плану. На основании результатов анализа при необходимости производится корректировка планов, внесение дополнений либо изменений.
Сравнение оперативных планов организации, анализов их выполнения за некоторый временной период, может дать реальную картину процесса управления ее деятельностью.
Ссылки
Это заготовка энциклопедической статьи по данной теме. Вы можете внести вклад в развитие проекта, улучшив и дополнив текст публикации в соответствии с правилами проекта. Руководство пользователя вы можете найти здесь
Управление проектами: планирование
Менеджер управляет проектами – а этого никак нельзя сделать, если нет никакого понимания, когда что должно произойти по ходу выполнения проекта. Для того, чтобы понимание было, мы занимаемся планированием – тема сегодняшней статьи.
Представь себе, что тебе нужно построить тот же дом. Представь, что каким-то образом ты пропустил этап “планирование” и сразу начал строить. И вот ты берешь кирпичи, кладешь их друг на друга, потом понимаешь, что не рассчитал по финансам, и эту стройку закончить не можешь. Берешь кредит, продолжаешь строительство. Докладываешь кирпичные стены, кладешь сверху шифер и вдруг оказывается, что без фундамента эта тема долго не простоит (вообще не простоит, на самом деле). Ты ломаешь все, делаешь фундамент, кладешь кирпичи, крышу, а тут вдруг (внезапно!) оказывается, что до ближайших коммуникаций тридцать километров по прямой, и строить здесь дом бессмысленно вовсе. Ну или хотел ты шестикомнатный таунхаус, а получил одноэтажный барак. Можно, конечно, рассказать коллегам, что у тебя там был эджайл и все по плану, но не было там никакого плана. Планирование – та фича, которая должна помочь избежать подобных неожиданностей. Чем четче план – тем меньше шансов, что что-то пойдет не так. Идеально не будет никогда, но с планом жить станет проще.
Планирование – один из основных процессов в управлении проектами. По важности он чуть ли не важнее реализации проекта. Стоит этот процесс сразу за “инициализацией”, когда кто-то кому-то сказал: “проекту быть!”. На деле, та же инициализация тоже планируется, но в меньших масштабах. При планировании проекта мы должны понять, что от нас требуется, когда, что у нас к этому есть, как это влияет на что-то еще и когда мы это сможем вытащить. Планирование – наше все. К планированию относится и управление рисками, о нем я тоже однажды расскажу подробнее – в самом “управлении рисками” есть свой пунктик “планирование”.
Тема применима не только к управлению проектами – она применима даже к собственной жизни. Вот то, как ты расписываешь бюджет на месяц – планирование. То, как ты в гугл-календаре расставляешь даты отпусков – планирование. Когда ты выезжаешь на работу из Подольска к Садовому – тоже планирование (когда выехать, как проехать, на чем ехать). Есть такие люди, которые вот вообще ничего не планируют и летят туда, куда их пнут. Я про них рассказывать не буду, и вы меня не просите.
Есть мнение, что неправильному планированию обязаны 80-90% провалов проектов (по срокам или содержанию, как минимум). Чтобы такого у вас (и у меня) не случалось, в этом блоке поговорим про макро-планирование, когда предмет планирования – целый проект. Я обещал углубиться в предмет с позиции практической – здесь будет с позиции практической. Все через призму менеджера проектов креативного агентства.
При планировании проектов у нас есть несколько основных групп планирования:
Ниже разберем каждый пункт отдельно. Помимо управления рисками – об этом напишу отдельно – сейчас это будут вкрапления в первые три пункта.
Главный документ в жизни проекта креативного агентства – техническое задание. В техническом задании мы расписываем общий набор того, что ожидаем на выходе. Еще технические задания подписывают и показывают потом заказчику в случае чего – мол, смотри, твоих требований в нем не имеется, потому изволь. Технические задания, кстати, пишутся до согласования стоимости проекта – стоимость потом напрямую зависит от содержания техзадания.
Возможности технического задания не ограничены – теоретически, в нем можно прописать не только все этапы, странички и кнопочки, но и то, как эти кнопки себя будут вести и какого цвета у этих страниц будет фон. Предупреждая читателя, ринувшегося срочно писать подробное техническое задание, говорю: все предусмотреть нереально и в перфекционизм особо вдаваться не рекомендую. Если написание технического задания займет полгода, а проект – месяц, то смысла в этом всем никакого нет. Некоторые проекты вообще не требуют технических заданий – включай благоразумие.
Я пишу технические задания только на функциональные вещи. Раздел такой-то, содержание такое-то, внутри происходит это-то. Увы, NDA, и ничего показать не могу, а писать отдельно под статью – не запланировано. Техническое задание должно быть структурировано, написано простым языком, избегать двусмысленностей – как мануал здесь можно брать статью о деловой переписке, правила те же.
В некоторых случаях, ты не сможешь написать техническое задание самостоятельно – от недостатка экспертизы или недостатка времени. В таких случаях подключаются другие ребята – например, сами исполнители, если исполнитель – программист, а речь идет о сложных технических вещах. В некоторых фирмах написанием техдокументации занимается отдельный специально обученный человек – технических писатель. У нас такого нет, плюс это дело мне само по себе нравится. Тебе я тоже рекомендую самостоятельно писать, чтобы люди, которые не будут отвечать за этот проект не наделали беды еще до старта оного. Или проверяй хотя бы.
Удобно писать технические задания в Google Docs, расставляя важные вещи заголовками – все чисто и аккуратно. Можно делиться ссылкой с заинтересованными лицами – они сразу напишут комментариев. Чем четче в техническом задании прописано, как что должно работать – тем меньше проблем возникнет при передаче проектных задач исполнителям. Менеджер налаживает процессы, а случаи, когда исполнитель уточняет у него каждый шаг, мало похоже на процесс. Автор знает о чем говорит, потому что автор, как человек самоуверенный, периодически может пропускать куски в техническом задании – может от ограничений во времени, а может потому что ленив.
Иногда вместо технического задания используется карта проекта – иерархическая структура. Под тип паука, в центре которого – название проекта, а из него исходят остальные задачи, соблюдая вложенность. Такое “техническое задание” сильно ускоряет оценку проекта, но снижает точность оценки – и времени, и содержания.
После того, как у нас есть техническое задание и понимание содержания проекта, задачи передаются в работу. Разумеется, после подписания задания клиентом.
Здесь у нас планирование работ для передачи исполнителем + планирование сроков исполнения задач. Кто-то верно заметил, что управление проектами – разделение большого пласта на поменьше и попытка всунуть их в какие-то сроки. Примерно так все и есть: на куски мы пилим проект, чтобы было проще контролировать выполнение и расставлять их на таймлайне.
Какой-то особой техники резки задач у меня нет – я точно знаю, что задачи не должны сваливаться на голову исполнителя скопом и должны быть расставлены в логической последовательности. Должно быть понимание критического пути – списка задач, без которых проект жить не сможет, задач, вокруг которых выстраивается весь проект.
Методов пилки задач несколько:
В несложных проектах наш друг – расстановка задач по иерархии. В диджитале сложные проекты случаются редко, потому запоминай. Графически такие планирование выливается в в иерархическую структуру работ – ИСР (или WBS). Иерархическая структура работ – один в один “карта проекта” (она же – ментальная карта или “майндмап”), только направлена в одну сторону. Можно иметь ее параллельно техническому заданию, хуже не станет.
PERT (его еще называют “сетевой график”) примерно в тысячу раз сложнее иерархического планирования, он нужен для сложных проектов – в них PERT поможет не допускать рисков, когда что-то сделано не вовремя. Этот метод планирования определяет последовательность решения задач – что следует до, что после. PERT также используется при оценки времени выполнения задач – интересной фишкой в нем является выставление трех сроков каждой задаче – оптимистическое время выполнения, пессимистическое время решение и наиболее вероятное. На основании этих трех оценок вычисляется наиболее вероятное время. Там ниже говорим про планирование времени, поймете почему это интересно и важно.
Критический путь (и метод критического пути) фича именно PERT. Я не использую сетевые графики в работе, но вот критический путь прям в душу запал. Суть его в том, что он определяет самую долгую последовательность задач – тех, которые нельзя подвинуть или избежать. Критический путь определяет минимальное время завершения проекта.
Итого, проект, в котором достаточно иерархической структуры при планировании задач, может выглядеть так:
Удобно при “водопаде”, о котором рассказывал в предыдущей статье. Плюс, такой проект гораздо проще в планировании времени – все понятно при взгляде сверху. Сетевой график используется, когда задач тысяча, и половина из них между собой связана – когда задача, которая должна быть выполнена после этапа Х зависит от задачи Y, не связанной с задачами A, B и C, которые в графике первые. PERT – такой эджайл при планировании, только что результат проекта точно определен, иначе не надо было бы вам этих графиков.
Возвращаясь к простым, линейным проектам, вернемся и к планированию сроков таких проектов. Кажется, лучшее, что было придумано в этой области – диаграмма Гантта. Это такой лист, где у тебя расписаны задачи с одной стороны, а с другой – линейный календарь, на который положены линии, когда эта задача уйдет в реализацию и будет выполнена.
Это тоже расписание проекта – у него может быть меньшая, по сравнению с сетевым графиком, детализация, но даже такая форма отображения таймлайна проекта лучше, чем никакая. Диаграмма Гантта собирается в экселе, на коленке за 5 минут.
Как-то не получилось у меня отдельно рассказать про планирование сроков проекта, расскажу вкратце и внутри блока “планирование расписания”. Сроки выполнения проекта вычисляются людьми, которые будут делать задачи внутри проекта – каждый в рамках своей зоны ответственности. Обычно это выглядит как указать пальцем в небо, и практика показывает, что палец подходит любой – даже вот твой. Планирование сроков выполнения проекта – всегда предсказание: можно угадать, а можно не угадать. Что с этим делать, я не знаю – обещал рассказать про риски, вот оно.
На планирование работы команды ( = выполнения проекта), работающей для внешнего заказчика влияют не только задачи внутри проекта – влияют задачи из параллельных проектов (ибо такого, чтобы кто-то сидел и ждал именно своего проекта, просто не бывает). Если используется PERT – сроки будут плюс-минус релевантными, ибо берется три пальца в небо и после небольшого вычисления выявляется наиболее вероятный палец. На тех проектах, где полезен PERT, вряд ли бывают конфликты между проектами, а те пальцы куда опытнее, чем мой. Быть может этот блок дополнит следующая статья, про микроменеджмент – там будет немного про управление временем.
После того как мы поняли, что нам нужно, что за чем следует и без чего проект жить не сможет, перемещаемся к планированию команды. Хотел сказать, сразу к работе, но как работать, когда работать пока некому.
Планирование команды проекта должно начинаться примерно на этапе инициализации. Чаще всего на этапе планирования задач уже есть кто-то, кто после будет работать с проектом. Например, люди, готовые поделиться экспертным мнением, чтобы ты, менеджер, потом не зафакапил чего-нибудь.
Где-то на Западе менеджер может скрупулезно выбирать членов команды под проект. Выяснять, насколько тот или иной человек подходит под проект, какие у него взаимоотношения с другими членами команды и почему у исполнителя может возникнуть нежелание работать. Для проектов он их как бы нанимает – изнутри компании, или из вне (рекрутинг или фрилансеры). Когда ты станешь менеджером, ты их тоже будешь нанимать. Только что выбора тебе особого не дадут – вот, есть человек, подключай. Это тебе скажет руководитель направления (или тимлид), в котором работает твой коллега.
Команда может планироваться двумя путями: сразу вся – когда на старте определяется, кто подключится к проекту на каждом этапе, или по мере потребности в ресурсах. В идеале, лучше первый вариант – чтобы все перезнакомились и потом показывали, что они там в процессе наделали, с чем следующему придется разбираться. Фактически чаще случается второй вариант – когда этап верстки планируется через два месяца, глупо планировать работу конкретного технолога, он за эти два месяца может переключиться на что угодно – ждать не будет. Еще есть вариант, когда в проекте группа исполнителей с одной ролью – здесь и так все понятно, они почти что один юнит исполнителя, только большой.
Планирование команды проекта (и отдельных ее членов) нужно делать заранее – никогда в нормальной жизни ты не встретишь ситуации, чтобы кто-то тебе понадобился, и вот сразу он, сидит, ждет когда ты его забрифуешь. Запрашивать ресурсы исполнителей нужно хотя бы за пару недель до – чтобы исполнитель тоже смог спланировать свою работу. Закончить ее например, или передать.
В этот блок отлично подошел бы текст про передачу задач исполнителям, но в Алматы уже вечер, а мне завтра на работу пилить, чтобы собрать для вас контент “с полей”. Добавил себе в задачи тему, поговорим о ней, когда коснемся работы с людьми в проекте.
Успешное планирование в ИТ консалтинге. Теория и практика использования JIRA и MSP
1. Введение
Поработав в нескольких крупных ИТ компаниях на позициях руководителя проектного офиса, я поучаствовал в реализации различных архитектур управления проектами и портфелями проектов. Важную и проблемную часть при этом составляли системы планирования – при кажущейся простоте и широком спектре решений на рынке.
краткосрочное планирование (спринты),
планирование проектов\контрактов (календарный план),
планирование загрузки ресурсов (ресурсный план),
и наконец финансовое планирование (квартал, год и т.д.).
Все эти процессы связанны между собой, но в практике не реализуются в одной информационной системе. Поэтому хочу поделиться о своем опыте промышленного внедрения и использования систем, удачных архитектурных решениях, которые в итоге позволили сделать более эффективными процессы управления проектами, бюджетирования и финансового планирования, благодаря интеграции различных процессов планирования.
2. Про планирование
Планирование является одним из важнейших процессов при управлении проектами разработки программного обеспечения (ПО).
Как правило, в процессах управления производством ПО центральное место занимает какой-нибудь трекер (конечно я не рассматриваю в данной статье и не имею ввиду среды разработки). Поэтому и оперативное планирование опирается на функционал трекера. Последние годы на рынке доминирует JIRA, хотя другие – такие как Redmine не уступают в функциональности. Но рынок есть рынок.
Но для планирования проектов функционала системы трекеров не достаточно, поэтому в ИТ консалтинговых компаниях (особенно которые работают с внешними заказчиками на контрактных условиях) планирование строится на базе промышленных систем, а иногда и просто в excel.
В производстве ПО уже десятилетие культивируется Agile, но в инструментах автоматизации процессов планирования существует разрыв, сложившийся по какой-то причине в ходе развития рынка. Системы календарные планирования ориентированные на создание диаграммы Ганта, такие как MSProject, Primavera, Spider и т.п., существуют давно. В них достаточно развиты инструменты календарного и ресурсного планирования, но отсутствуют возможности, присущие трекерам таким как JIRA, Redmine, TeamTrack – например движение задачи по статусам, формирование оперативных планов (спринтов), панели и dashboard для команды, связи с другими задачами и т.д.
Поэтому разумно выделяется несколько уровней планирования – о них детально рассказываю ниже. На каждом уровне переплетаются процессы взаимосвязанные друг с другом: планирование производства, проектов и финансовое планирование.
А руководителям компании интересно контролировать финансовый план компании, который собирается из всех проектных и процессных активностей. И чаще всего просто в exсel.
3. Уровни планирования
Расскажу более детально о процессах\уровнях планирования. На практике выделяется несколько уровней которые необходимы для дальнейшего управления процессами командами, проектами, компанией.
Первый– самый детальный – уровень описания конкретных требований для аналитика, фичи для разработчиков, тестировщиков, документаторов. На этом уровне оперируют недельными планами, которые можно называть спринтами (не затрагивая в деталях идеологию agile). На этом уровне анализируется бэклог одного или нескольких проектов для формирования плана работ обычно для одной команды. В терминах PMBoK это разработка расписания для проекта. Ключевая специфика – это короткий горизонт планирования и планирование набегающей волной.
Второй – уровень проекта – здесь фиксируются ключевые вехи, планируются все активности и задачи, которые входят в проект, без детализации первого уровня.
Третий – планирование загрузки подразделения на период – обычно месяц, квартал, год. План собирается из всех проектов второго уровня и процессов, в которых задействованы ресурсы подразделения, включая обеспечение саппорта, процессы обучения, непроизводственные процессы и т.д. Специфика данного планирования заключается в необходимости формирования загрузки ресурсов подразделения близкой к 100%. На практике этот уровень резервирует ресурсы и показывает проблемные точки загрузки для решения вопросов утилизации.
Четвертый – финансовый план уровня компании, который собирается из планов третьего уровня, и формируется в разрезе подразделений. Ключевая особенность в том, что на этом уровне сводятся и сопоставляются доходы по проектам (второй уровень планирования) с расходами компании (третий уровень планирования).
4. Функциональные архитектуры систем планирования
Остановлюсь сегодня детально на рассмотрении вариантов архитектуры первого и второго уровня планирования, которые фактически являются основой для последующих.
Несколько реализаций в виде плагинов в JIRA, пытающихся повторить функционал, давно реализованный в системах планирования, таких как MSProject, Primavera, Spider и т.п. можно назвать лишь потугами. Да и смысл повторять функционал таких мощных специализированных систем на мой взгляд отсутствует.
Как уже рассказал выше первый уровень планирования в текущих ИТ компаниях прочно занимает какой-нибудь трекер, второй уровень – система календарного планирования. Эффективный процесс можно постройтесь, если интегрировать данные системы.
Хорошие варианты интеграции систем планирования и трекеров мне пришлось наблюдать и в разной степени принимать участие в реализации в таких компаниях интеграторах как БИС, БФТ и РСХБ. Расскажу об архитектуре, различиях и особенностях построения процессов.
4.1. Планирование проектов в трекере
4.2. Централизованное планирование проектов трекер-MSP.
В БИС и РСХБ схему планирования реализовали, используя интеграцию трекера и MSProject. Это решение требует на 2 порядка меньше разработки и сразу дает возможность пользоваться функциями обеих систем и переходить к построению процесса разработки нужно ПО, а не прикладывать титанические усилия для внутренней автоматизации.
В качестве трекера использовался TeamTrack, все задачи заводились в нем, а в MSProject вручную строилась иерархия и вручную вносились номера задач. После планирования конкретных задач сроки автоматически передавались в задачу TeamTrack. Информация об исполнении передавалась обратно в MSProject. Вот и весь процесс, который позволял централизованно планировать производственные ресурсы всей компании – все гениальное просто.
4.3. Трекер+локальный MSP
В РСХБ тоже используется интеграция JIRA MSProject. При этом каждый руководитель ресурсного центра (являясь при этом РП конкретных проектов или программ\портфелей) создает свой локальный план в MSProject. Минусы такой системы поняты – нужно постоянно синхронизировать расхождения (по срокам, списку задач и загрузке), т.к. одни и те же ресурсы могут использоваться в различных проектах MSProject.
При этом всего три интеграционных сервиса позволяют выполнить все работы по планированию и контролю планов в связке MSProject JIRA:
Создание задач из MSProject в JIRA.
Это позволяет легко превращать план в MSProject в иерархически скомпонованный перечень задач в JIRA со сроками нужными для проекта и назначенными ресурсами, а так же при необходимости обновлять информацию процессом MSProject->JIRA.
Загрузка новых задач JIRA->MSProject.
Позволяет при необходимости выгружать в MSProject из JIRA перечень привязанных к выбранной задаче (или эпику) задач в виде иерархии.
Какая из описанных 1.-3. архитектур вам подойдет больше – нужно решать в зависимости от текущего бизнес и ИТ ландшафта, но для планирования проектов архитектура в которой интегрируются система трекинга и система календарного планирования оказалась максимально эффективной, т.к. позволила срастить современные agile подходы планирования работы команды и потребности проектного офиса в части планирования проектов.