ИТ-архитектура от А до Я: Теоретические основы. Первое издание

Прочие Методы и Техники

Анализ допущений (Assumptions Analysis)

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

Анализ ожидаемого денежного значения (Expected Monetary Value Analysis EMV)

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

Анализ отклонений (Variance Analysis)

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

Анализ сети (Schedule Network Analysis или Network Analysis)

Анализ сети расписания (Schedule Network Analysis) – Метод определения ранних и поздних стартов и ранних и поздних финишей для невыполненных плановых операций проекта. См. также метод критического пути, метод критической цепи, анализ возможных сценариев и выравнивание ресурсов.

Анализ тенденций (Trend Analysis)

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

Анализ резервов (Reserve Analysis)

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

Анализ чувствительности (Sensitivity Analysis)

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

Быстрый проход (Fast Tracking)

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

Выравнивание ресурсов (Resources Leveling)

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

Декомпозиция (Decomposition)

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

Метод «операции в узлах» или метод предшествования (Precedence Diagramming Method, PDM)

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

Метод сетевых графиков

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

Метод критического пути (Critical Path Method, CPM)

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

Метод критического пути – довольно часто используется в строительстве и характеризуется наличием четко выраженного пути проекта, этот путь формируют самые длинные работы проекта. Сам критический путь и определяет продолжительность всего проекта. Определяя и идентифицируя наиболее важные задачи, Вы можете оценить даты завершения, зависимости, ключевые вехи и конечные результаты. Любые отставания по датам для тех работ, которые лежат на критическом пути ведут к увеличению длительности последующих работ. При необходимости сократить длительность проекта необходимо сокращать сроки работ на «критике». Методология управления проектами при помощи критического пути позволяет сравнивать плановые и фактические показатели (как ситуация должна развиваться и что происходит на самом деле) каждый день. Четыре этапа планирования по методу:

•цели и ограничения (рассмотрение проекта по нескольким аспектам – длительность, рас, качество и проч.);

•продолжительность работы;

•сетевой график работ;

•построение диаграммы Гантта

Метод критической цепи. Метод критической цепи (Critical Chain Method CCM)

отличается от метода критического пути тем, что он ориентирован на использование ресурсов проекта, а не проектных работ. Для решения потенциальных проблем с ресурсами формируются буферы, гарантирующие своевременную реализацию проектов с соблюдением всех необходимых мер безопасности. Управление проектом по методу критической цепи помогает избегать отставаний и задержек в проекте, определяя критический путь работ, а также резервы ресурсов (запас времени) для этих работ. Поскольку графики строятся, учитывая доступность ресурсов, срок проекта может быть дольше, но вероятность срыва сроков ключевых событий может быть снижена. Основа методологии критических цепочек – формирование основных работ критически важных для проекта и удержание сроков работ, соответственно и финальной даты завершения проекта. Критические работы проекта провязываются логическими связями с учетом ресурсных и административных ограничений; Если в проекте ресурсы не ограничены, расчётные показатели будут схожими с PERT. Если в проекте все же ограничены ресурсы, то необходимо:

•Определить околокритические работы в графике, такие работы очень часто идут параллельно основной «красной»

•цепочки, но с уменьшенными сроками, они могут довольно легко стать критическими если им не уделять внимание.

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

Метод Монте-Карло (Monte Carlo Analysis)

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

Метод оптимизации выгод (Value Engineering, VE)

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

Оценка «снизу-вверх» (Bottom-up Estimating)

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

Оценка «С вверху вниз» (Top-down Estimating)

Метод оценки элемента работ. Обратный методу «снизу-вверх».

Планирование методом набегающей волны (Rolling Wave Planning)

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

Иерархическая структура рисков (Risk Breakdown Structure, RBS)

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

Матрица вероятности и последствий (Probability and Impact Matrix)

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

Матрица ответственности (Responsibility Assignment Matrix, RAM)

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

Расписание контрольных событий (Milestone Schedule)

Укрупненное расписание работ, отображающее сроки наступления основных контрольных событий.

Метод аналогий

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

Метод Экспертной Оценки (Expert Judgment)

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

Метод показателей

Используются показатели по завершенным проектам. Например, метод процентных ставок. При этом методе происходит полноценное распределение затрат по разным фазам. Например, если известны реальные затраты на первую фазу, то остальные вычисляются согласно процентному распределению. Пример: Фаза анализа – 20%, Фаза проекта – 35%, Фаза реализации – 30% и Фаза тестирования – 15%.

Оценка «Навскидку» Poker Estimate

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

•Собирается рабочая группа (разработчики, аналитики, представители бизнеса и т п).

•Озвучивается задача,

•Каждый участник оценивает сроки проекта основываясь на своем опыте и уровню,

•Каждый участник высказывает свое мнение.

•Для обсуждения рабочей группой выбираются самый короткий и самый длинный срок проекта.

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

Оценка времени или часов разработки

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

•Poker Estimate,

•Сравнение с аналогом,

•Bottom up & Top down

•Экспертная оценка.

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

•15—20% процентов времени для покрытия рисков и непредвиденных случаев

•Принимаем в расчетах 80% процентов рабочего времени (а не 100% формальных) разработчика, как основной рабочей единицы занятой на проекте

Диаграмма: Стоимость проекта

Ведение документации по проекту

Документация проекта – это набор документов, описывающих проект и регламентирующих деятельность в рамках проекта.

Проекты живут за счет быстрого обмена информации внутри проектной команды и внешними заинтересованными сторонами, поставщиками. Каждый участник проекта отвечает за предоставление или не предоставление информации.

Правило: «информация – это долг, который одни должны отдать, а другие потребовать».

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

•Внутренняя

•Внешняя.

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

•Планы

•Статусы

•Протоколы совещаний

•Документация по дефектам, тестам

•Договоры с поставщиками

Анализ рисков

Пример информации, которую можно отдать во вне:

•Матрица компетенций

•Журнал распределения обязанностей

•Статусы проекта

•График вех

•Заключительные отчеты

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

Устав проекта

•Описание содержания проекта

•Реестр заинтересованных сторон проекта

План управления проектом

Запрос на изменение в проекте

Лист согласования участия в проекте

Положение об управлении рисками

•План управления рисками

•Реестр рисков

Протокол совещания

Отчеты

•Отчет об исполнении работ по проекту

•Отчет о статусе проекта

•Отчет по завершению проекта

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

•Какие артефакты и документы нужны для вашего проекта?

•Насколько детально нужно их прорабатывать?

•Стоимость времени, потраченное на создание документа по отношению к ценности документа?

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

•Сначала выбирается минимальный набор документов.

•Заполняете на основании здравого смысла. Если что-то кажется лишним, отбрасывайте.

•Затем оцениваете, сможете ли вы с помощью этой информации достичь нужных результатов.

•Если нет, то включите недостающие разделы или документы.

•Заполните их и снова проведите оценку.

•И так далее до достижения результатов.

Инструменты по Управлению Проектами

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

Какие минимальные требования к инструментам? Что они должны помогать вам делать?

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

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

Набор инструментов:

•Для составления документов, схем, таблиц и презентаций можно использовать стандартный офисный пакет, например, MS Office. Для него есть готовые шаблоны для документов. Есть расширения для Visio, при помощи которых можно нарисовать все нужные схемы.

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

Профессиональные инструменты по Управлению Проектами такие как:

•Microsoft Project 2016 Server / Professional

•JIRA Project Management

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

•Система санкционирования выполнения работ (Work Authorization System).

•Система управления изменениями (Change Control System).

•Система управления конфигурацией (Configuration Management System).

Ключевые факторы успеха проекта

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

• Четкие цели. Для проекта жизненно необходимы четкие и понятные цели. Причем достижение этих целей должно быть важно для спонсора проекта и ключевых заинтересованных лиц.

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

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

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

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

• Обеспечить максимальное повторное использование ИТ активы организации. Все сломать и переделать – это долго и дорого. А ломать то, что действительно работает, глупо. Зачастую информационные системы и оборудование компании используются на 15—30% возможностей. Это отличная возможность для получения быстрых результатов с минимальными затратами.

• Архитекторы и менеджеры проектов должны активно работать с бизнесом и ИТ проектами. А не генерировать гениальные идеи на основе «лучших практик». Работа «в поле» для многих начинающих архитекторов крайне некомфортна. Они боятся показаться некомпетентными. Хотя то, что ИТ специалисты знают глубже конкретные технологии, чем архитекторы, совершенно нормально. Как и то, что бизнес знает лучше, как работает компания. Работа с людьми – единственный способ достичь результатов.

• Максимально использовать и распространять информацию. Основной актив архитектурного проекта – это информация. Нужно сделать доступ к ней максимально быстрым и удобным. А также рассказывать всем, что у вас есть и как они могут это использовать.

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

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

• Начинайте с пилотного проекта. На старте ваша основная цель – показать реальные результаты.

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

•Достаточно знаний и умений для того, чтобы сделать шаг

•Шаг кратковременный по времени

•Шаг имеет низкий уровень риска

•Шаг поведенческий-конкретный

•Понятно, что будет успехом шага

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

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

• Не изобретайте велосипедов.

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

• Громко скажите «спасибо» руководству за поддержку, коллегам за помощь и терпение и т. д.