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

•Никто ни за что не отвечает

•План проекта недостаточно структурирован

•План проекта недостаточно детализирован

•На реализацию проекта выделено недостаточно средств

•Выделенных ресурсов недостаточно для выполнения работ

•Проект не сверяется с планом его реализации

•Отсутствует взаимодействие между членами рабочей группы проекта

•Проект отклоняется от поставленной цели

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

Заключение

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

•Классические методы как «трактор» (если удачное завершение проекта, то как немецкий трактор) – «… сказали пахать – пашем с раннего утра и пока не вспашем…». Ориентирован на результат – выполнить любой ценной (как правило это конечный продукт, а стоимостью и временем как получится). Все делается по порядку и по инструкции.

•Методология «PRINCE2» – тоже самое, но задаются вопросом «… а на кой нам это нужно если дохода нет?…»

•«Вот „бабули“, больше нет – крутись как хочешь, но к завтрашнему утру чтобы было все готово. Что конкретно готово не знаем – но клиент сказал – ВСЕ». Это больше подходит на пример использования гибких методов управления проектами.

•«Пашем как молотилка» – метод «SCRUM»

•«KANBAN» присмотрит за тем, чтобы работники не были перегружены, а то «… сдохнут кони раньше времени…»

•Методологии «LEAN» и «SIX SIGMA» присмотрят за вопросом «… а не много ли косячат?…»

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

Концепция управления рисками

Общие Принципы

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

Данный раздел содержит основные принципы управления рисками при проектировании архитектуры, которые должны быть приняты во внимание. В процессе разработки и внедрения различных сервисов ИТ архитектуры необходимо проводить непрерывный процесс управления рисками. Для управления ИТ рисками можно воспользоваться как общими методиками так м специфичными для ИТ. Данная глава учитывает рекомендации стандарта «Управления и анализа рисков ISO 73: 2009», а также методика CRAMM v5 (CCTA Risk Analysis & Management Method) на основе требований организации CCTA (Central Computer and Telecommunications Agency) которая соответствует стандарту BS7799/ ISO17799.

Классификация рисков

Общую классификацию рисков можно представить, как:

Внутренние риски:

•Проектные,

•Технические,

•Технологические,

•Организационные,

•Финансовые и т п

Внешние риски:

•Природные,

•Политические,

•Социальные,

•Экономические и т п

По типу:

•Предсказуемые

•Не предсказуемые

По характеру:

•Преднамеренные

•Не преднамеренные

По виду:

•Прямые

•Косвенные

По результату:

•Нарушение функционирования,

•Нарушение целостности,

•Нарушение достоверности

•Нарушение конфиденциальности

По механизму воздействия: