1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
пакета документов по управлению Проектом : Устав проекта •Описание содержания проекта •Реестр заинтересованных сторон проекта План управления проекто м Запрос на изменение в проекте Лист согласования участия в проекте Положение об управлении рисками •План управления рисками •Реестр рисков Протокол совещания Отчеты •Отчет об исполнении работ по проекту •Отчет о статусе проекта •Отчет по завершению проекта Ведение документации один из важнейших элементов любого проекта. Никто не любит писать документы… кроме тех, кто умеет. Используйте готовые шаблоны артефактов (текст, схемы, таблицы и презентации) и отчетных документов (deliverables). Но перед тем как начинать придумывать или заполнять готовые шаблоны, нужно ответить на три важных вопроса: •Какие артефакты и документы нужны для вашего проекта? •Насколько детально нужно их прорабатывать? •Стоимость времени, потраченное на создание документа по отношению к ценности документа? Генерировать кучу ненужных документов дорого, долго и глупо. Это выгодно, если проект оценивают по толщине отчетных документов. Но толстые документы никто не читает. Их ставят на самую дальнюю полку и забывают навсегда. Поэтому нужно выбрать только те документы, которые нужны для достижения целей проекта. Для результатов. И прорабатывать их настолько детально, насколько это нужно для достижения целей проекта. Логично. Но как определить эту грань? Рекомендую метод постепенного улучшения или по требованию, который представляет из себя следующую последовательность: •Сначала выбирается минимальный набор документов. •Заполняете на основании здравого смысла. Если что-то кажется лишним, отбрасывайте. •Затем оцениваете, сможете ли вы с помощью этой информации достичь нужных результатов. •Если нет, то включите недостающие разделы или документы. •Заполните их и снова проведите оценку. •И так далее до достижения результатов. Инструменты по Управлению Проектами Как и какие выбрать инструменты по управлению проектами. На рынке представлены десятки инструментов, от бесплатных до дорогих. Внедрение некоторых из них может стоить сотни тысяч долларов. Как и в случае выбора инструментов по управлению Архитектурой Предприятия, я рекомендую использовать по возможности бесплатные или дешевые инструменты. Какие минимальные требования к инструментам? Что они должны помогать вам делать? •Писать и редактировать тексты, составлять схемы, вести таблицы, делать презентации и т. д. •Размещать их на общедоступном ресурсе, регулировать права доступа к информации, обсуждать эти материалы. Набор инструментов : •Для составления документов, схем, таблиц и презентаций можно использовать стандартный офисный пакет, например, MS Office. Для него есть готовые шаблоны для документов. Есть расширения для Visio, при помощи которых можно нарисовать все нужные схемы. •Для совместной работы можно использовать корпоративный портал, систему управления документами, корпоративную почтовую систему, корпоративную систему передачи сообщений или выделенный файловый ресурс в корпоративной сети организации. Выбор решения будет зависеть от того, что уже есть у вашей компании. Профессиональные инструменты по Управлению Проектами такие как: •Microsoft Project 2016 Server / Professional •JIRA Project Management Для развитых организаций или проектных ИТ компаний желательно дополнительно использовать профессиональные системы, если они не входят в составе систем Управления Проектами, такие как: •Система санкционирования выполнения работ (Work Authorization System). •Система управления изменениями (Change Control System). •Система управления конфигурацией (Configuration Management System). Ключевые факторы успеха проекта Шансы на успех внедрения проекта повышаются, если у проекта есть поддержка топ менеджмента компании и объем работ уменьшен таким образом, чтобы минимально значимый для компании результат был достигнут в минимальные сроки и за минимальную стоимость. Кроме этого стоит уделять большое внимание планированию, рискам и получению обратной связи от заказчиков (внешних или внутренних). Можно выделить следующие ключевые факторы успеха проекта: Четкие цели. Для проекта жизненно необходимы четкие и понятные цели. Причем достижение этих целей должно быть важно для спонсора проекта и ключевых заинтересованных лиц. Быстрые результаты. Проект должен обеспечивать достижение краткосрочных целей. Важно поддерживать интерес спонсора к проекту. Для этого нужно быстро достигать необходимых для компании результатов, которые он сможет записать себе в актив. Если ближайшие результаты будут через 3 года, то интерес к проекту сильно упадет. Активно работать со всеми заинтересованными лицами . В рамках проекта часто решаются вопросы, которые требуют участия топ менеджмента, других важных и очень занятых людей. Найдите способы вовлекать их в проект. Конечно, не стоит их звать на все совещания или дергать каждый день по разным вопросам. Но вы можете привлечь в проект их доверенных лиц, присылать справку по проекту, для встреч с ними готовить списки вопросов с вариантами ответов. Избегать революционных изменений. Они очень красиво выглядят на бумаге, но их тяжело реализовать в жизни. Метод постепенных улучшений часто более эффективен. Отслеживайте ценность результатов. Для каждого архитектурного решения нужно оценить выгоды, сроки, затраты и риски. Их нужно обязательно согласовывать со спонсором и заинтересованными лицами. Результаты проекта должны давать ценность компании. Обеспечить максимальное повторное использование ИТ активы организации. Все сломать и переделать – это долго и дорого. А ломать то, что действительно работает, глупо. Зачастую информационные системы и оборудование компании используются на 15—30% возможностей. Это отличная возможность для получения быстрых результатов с минимальными затратами. Архитекторы и менеджеры проектов должны активно работать с бизнесом и ИТ проектами. А не генерировать гениальные идеи на основе «лучших практик». Работа «в поле» для многих начинающих архитекторов крайне некомфортна. Они боятся показаться некомпетентными. Хотя то, что ИТ специалисты знают глубже конкретные технологии, чем архитекторы, совершенно нормально. Как и то, что бизнес знает лучше, как работает компания. Работа с людьми – единственный способ достичь результатов. Максимально использовать и распространять информацию. Основной актив архитектурного проекта – это информация. Нужно сделать доступ к ней максимально быстрым и удобным. А также рассказывать всем, что у вас есть и как они могут это использовать. Контроль результатов реализации проектов. Для проектов реализации, которые часто делают внешние исполнители, важна формальная приемка результатов. Закрыл проекты актами и сбежал. Архитекторы должны собрать единую систему из результатов нескольких проектов. Поэтому держите руку на пульсе. Говорить с людьми на понятном языке. Говорить с бизнесом на языке бизнеса. Говорить с ИТ на языке ИТ. Старайтесь избегать сленга и профессионального жаргона. Важность коммуникации часто недооценивают. Контролируйте не только, что вы говорите, но и как, когда и кому. Если вас не понимают, это ваша вина. И очень большая проблема. Начинайте с пилотного проекта. На старте ваша основная цель – показать реальные результаты. Определите «Шаг проекта» – это понятное вам элементарное конкретное действие. Как для каждого человека, так и для проекта, ширина шага может быть разная и зависит от различных факторов. Ширину «шага успешности» при управлении проектом можно определить с помощью пяти критериев: •Достаточно знаний и умений для того, чтобы сделать шаг •Шаг кратковременный по времени •Шаг имеет низкий уровень риска •Шаг поведенческий-конкретный •Понятно, что будет успехом шага Одна из самых частых ошибок при внедрении – это сидеть и ждать, пока к вам придут люди, чтобы обсудить проблемы. Не ждите – не придут. Идите сами к людям на всех уровнях, спросите про их проблемы. Расскажите, кому вы уже помогли, предложите помочь в решении их проблем и задач. Задавайте вопросы. Помните о ценности. Каждое ваше предложение должно быть обосновано с точки зрения ценности для компании. Забудьте фразу: «Это будет более правильно с точки зрения архитектуры». Всегда помните про выгоды, сроки, затраты и риски. Не предлагайте революций без подробного экономического обоснования. Не изобретайте велосипедов. Не начинайте проект, не имея намерения его закончить . Два три вялотекущих или провальных проектов приведут к де-мотивации сотрудников. Громко скажите «спасибо» руководству за поддержку, коллегам за помощь и терпение и т. д. Основные причины провала проекта Проекты, реализуемые без использования каких-либо методов, часто терпят крах по следующим десяти причинам: •Проект представляет собой решение, приводящее к проблеме •В конечном результате заинтересована только группа, работающая над проектом •Никто ни за что не отвечает •План проекта недостаточно структурирован •План проекта недостаточно детализирован •На реализацию проекта выделено недостаточно средств •Выделенных ресурсов недостаточно для выполнения работ •Проект не сверяется с планом его реализации •Отсутствует взаимодействие между членами рабочей группы проекта •Проект отклоняется от поставленной цели При ведении любого проекта, в том числе и ИТ проекта, наиболее важными элементами являются процесс коммуникации всех вовлеченных подразделений и департаментов. Чем разнороднее участники (финансисты, представители бизнеса, ИТ и т п) тем важнее организовать коммуникацию на «одном» языке для всех участников проектной команды. В противном случае результаты проекта и его этапы могут быть похожи на диаграмму. Заключение Если подытожить результаты данной главы, то можно сделать следующие, на мой взгляд важные выводы по методологии и техники управления проектами: •Классические методы как «трактор» (если удачное завершение проекта, то как немецкий трактор) – «… сказали пахать – пашем с раннего утра и пока не вспашем…». Ориентирован на результат – выполнить любой ценной (как правило это конечный продукт, а стоимостью и временем как получится). Все делается по порядку и по инструкции. •Методология «PRINCE2» – тоже самое, но задаются вопросом «… а на кой нам это нужно если дохода нет?…» •«Вот „бабули“, больше нет – крутись как хочешь, но к завтрашнему утру чтобы было все готово. Что конкретно готово не знаем – но клиент сказал – ВСЕ». Это больше подходит на пример использования гибких методов управления проектами. •«Пашем как молотилка» – метод «SCRUM» •«KANBAN» присмотрит за тем, чтобы работники не были перегружены, а то «… сдохнут кони раньше времени…» •Методологии «LEAN» и «SIX SIGMA» присмотрят за вопросом «… а не много ли косячат?…» Ну а если серьезно, то важно отметить, что решения на все случаи жизни, даже в рамках одной организации, не существует. Сфера управления проектами постоянно развивается, а знание менеджером проектов достоинств и недостатков каждой из методологий способствует успешной реализации проектов, расширяя потенциальные возможности всех заинтересованных сторон. Все методы управления проектами по-своему хороши и в каждом есть свои плюсы и минусы, применение методологии управления проектом очень сильно зависит от целей, типа и контекста проекта. Концепция Управления Рисками Общие Принципы Управления рисками – процесс принятия и выполнения управленческих решений, которые направленны на снижение вероятности возникновения неблагоприятного результата и минимизируют влияние возможных потерь на организацию убытков, вызванных случайными событиями. Данный раздел содержит основные принципы управления рисками при проектировании архитектуры, которые должны быть приняты во внимание. В процессе разработки и внедрения различных сервисов ИТ архитектуры необходимо проводить непрерывный процесс управления рисками. Для управления ИТ рисками можно воспользоваться как общими методиками так м специфичными для ИТ. Данная глава учитывает рекомендации стандарта «Управления и анализа рисков ISO 73: 2009», а также методика CRAMM v5 (CCTA Risk Analysis & Management Method) на основе требований организации CCTA (Central Computer and Telecommunications Agency) которая соответствует стандарту BS7799/ ISO17799. Классификация рисков Общую классификацию рисков можно представить, как: Внутренние риски: •Проектные, •Технические, •Технологические, •Организационные, •Финансовые и т п Внешние риски: •Природные, •Политические, •Социальные, •Экономические и т п По типу: •Предсказуемые •Не предсказуемые По характеру: •Преднамеренные •Не преднамеренные По виду: •Прямые •Косвенные По результату: •Нарушение функционирования, •Нарушение целостности, •Нарушение достоверности •Нарушение конфиденциальности По механизму воздействия: •Аварии •Ошибка персонала Критерии оценки К основным критериям оценки ценности ресурсов можно отнести следующие: •Ущерб для репутации организации •Безопасность персонала •Разглашение персональных данных •Разглашение конфиденциальных данных •Разглашение коммерческой информации и сведений •Санкции со стороны надзорных и государственных органов •Финансовые потери •Нарушения нормального функционирования организации Основные шаги и стадии В качестве основных шагов можно принять следующие действия: Организация процесса управления рисками (General Risk Management) •Разработка процесса, политик и процедур по Управлению Рисками •Классификация ресурсов, рисков, уязвимостей, угроз •Классификация реакции на риски и методов оценки •Формирование комитета Управления Рисками •Формирование экспертной группы, в состав которой входят специалисты ИТ, а также специалисты бизнеса. Идентификация и оценка ресурсов (Identification and Valuation of Assets) •Экспертная группа идентифицирует и оценивает ценность ресурсов •Экспертная группа идентифицирует возможные риски Оценка угроз и уязвимостей (Threat and Vulnerability Assessment) •Экспертная группа оценивает уязвимости систем •Экспертная группа оценивает угрозы систем Анализ Рисков (Risk Analysis) •Экспертная группа проводит качественный и количественный анализ рисков. В качестве основных критериев определяются: «вероятность» и «влияние» и классифицируются по значениям: «высокое», «среднее» и «низкое». •Проводится количественный анализ рисков (при необходимости) •Экспертная группа группирует риски и формирует матрицу (реестр) рисков Основные механизмы и элементы анализа с технической стороны: •BIA (Business Impact Analysis) – Анализ ИТ сервиса по уровню воздействия на бизнес •SFA (Service Fault Analysis) – Анализ ИТ сервисов по уровню воздействия на связанные ИТ сервис •CFIA (Component Fault Impact Analysis) – Анализ компонентов по уровню воздействия на ИТ сервис Управление Рисками (Risk Management) •Концентрируется внимание на рисках со значениями «высокое» и «среднее». •Определяется реакция на риски (принятие, снижение, передача и т п) •Определяются возможные контрмеры и стоимость их внедрения •Формируется ряд сценариев проекта как минимум «негативный», «позитивный» и «реалистичный» •Проведение корректировки •Результаты документируются и принимается решение •Все изменения в планах проекта должны обсуждаться и документироваться Как минимум должны быть сформированы следующие документы: •реестр рисков, •запросы на изменение •протоколы обсуждений. В процессе эксплуатацию ИТ сервиса проводится процесс управления рисками (поиск новых рисков, защитных мер и т п). Процесс является непрерывным и циклическим. Диаграмма блок схема анализа Методы оценки рисков В качестве методов оценки рисков можно использовать общеизвестные методы, такие как: •Анкетирование •Интервьюирование •Комиссионный метод •«Мозговой штурм» (Brainstorm) •«Дельфи» метод (Delfy) Наиболее распространённые инструменты, методики и техники оценки риска приводятся в международном стандарте ISO/IEC 31010:2009. В стандарте кратко описывается 31 метод оценки риска: мозговой штурм, анализ «Что если…», FMEA, HAZOP, HACCP, диаграмма «галстук-бабочка», анализ дерева отказов, Байесовы сети, FN-кривые и др. Метод «Дельфи» или «Дельфийский метод» (Delfy Technique) Метод сбора информации, используемый для достижения консенсуса экспертов по некоторому вопросу. В этом методе эксперты участвуют на условиях анонимности. Устроитель с помощью вопросника представляет идеи по важным моментам проекта, относящимся к данному вопросу. Ответы суммируются и возвращаются экспертам для комментариев. Консенсуса можно достичь за несколько циклов этого процесса. Метод Дельфи помогает преодолеть необъективность в данных и устраняет избыточное влияние отдельных лиц на исход обсуждения. Суть метода «Дельфи» экспертных оценок заключается в том, что в результате серии действий независимых экспертов, формируется некоторое обобщенное мнение, являющееся более верное, чем мнение индивидуальных специалистов. В процессе использования Дельфийского метода принимают участие две группы людей: •Первая группа – это эксперты, представляющие свою точку зрения на исследуемую проблему •Вторая группа – это аналитики, приводящие мнения экспертов к единому знаменателю Сам же метод Дельфи подразумевает несколько этапов: •Собирается группа •Ставится задача •Согласованность мнений На первом этапе производится подбор экспертной группы. В неё может входить любое количество человек, однако рекомендуется формировать группу из 20 человек и не более. На втором этапе выполняются следующие шаги: Ставится проблема – эксперты получают основной вопрос, а их задачей является разбиение его не несколько более мелких. Аналитики производят отбор самых распространённых вопросов и составляют общий опросник. Полученный опросник вновь представляется экспертам. Они должны сообщить, следует ли ещё что-то добавить, хватает ли данных, нет ли какой-то дополнительной информации по проблеме. Таким образом, получается 20 ответов (зависит от количества экспертов) с подробной информацией. Аналитики составляют ещё один опросник. Новый опросник снова предоставляется экспертам. Теперь им нужно предложить свои способы решения проблемы и изучить альтернативные позиции остальных экспертов. Здесь производится оценка эффективности, наличия ресурсов, актуальности способов решения. Аналитики выделяют основные мнения экспертов и стараются их сблизить. Если чьи-то мнения идут в разрез с мнением большинства, эти мнения озвучиваются экспертам. В итоге, эксперты могут изменить свои позиции, после чего данный шаг снова повторяется. Шаги повторяются снова и снова до тех пор, пока эксперты не придут к консенсусу, и не будет установлено единого мнения. А исследование аналитиками расхождений во мнениях членов экспертной группы может указать на незамеченные до этого тонкости проблемы. В конце концов, выносится общая оценка, и составляются практические рекомендации по решению проблемы. И уже на третьем этапе проверяется согласованность мнений экспертов, анализируются полученные выводы и разрабатываются окончательные рекомендации. Наряду с представленной структурой Дельфийского метода, существуют и другие модификации. Самая распространённая из них включает в себя бесструктурный этап. Используется данная модификация в том случае, если исследование направлено на поиск чего-либо конкретного, а организаторы исследования не способны сразу же представить проблему в форме специализированных вопросов. В этом случае уже на этапе формулировки проблемы привлекают экспертную группу. Другая модификация метода Дельфи направлена на то, чтобы сократить время, которое будет затрачено на осуществление аналитического этапа – он называется «Экспресс-Дельфи». С учётом того, что традиционный метод со всеми его достоинствами является довольно трудозатраты и требует для своего применения значительного количества времени, экспресс-метод позволяет сохранить все основные элементы методики при том, что всю процедуру можно осуществить в течение нескольких часов, однако требуется специальная техническая база. Каждый член экспертной группы на протяжении отведённого временного периода находится за компьютером. Все компьютеры объединены одной общей сетью, которая замыкается на руководителе мероприятия. После того как эксперты предлагают свои решения в ускоренном режиме, аналитики точно так же должны как можно быстрее произвести оценки. Огромную роль в этом процессе играет оперативность в обработке и систематизации материала. Достоинства метода: •Метод Дельфи способствует выработке независимости мышления членов группы. •Обеспечивает спокойное и объективное изучение проблем, которые требуют оценки. Недостатки метода Дельфи: •Организаторы мероприятия обладают чрезмерно большими полномочиями, по сравнению с экспертами, а значит, экспертов можно считать беззащитными в некотором смысле •Коллективное мнение далеко не во всех случаях является верным •Аналитики отбрасывают креативные решения, имеющие наименьшее количество сторонников, а эти решения могут быть самыми эффективными •Невозможен оперативный анализ, т. к. для осуществления последнего этапа требуется много времени: каждый этап анализа может занимать минимум до 24 часов •Эксперты склонны проявлять конформизм, испытывая желание и стремясь присоединиться к мнению большинства •Организаторы имеют возможность манипулировать экспертной группой |